David, in short I don't know :)

but since I've either missed any answers to your question, or most of us
missed your question, I'll throw my 2 Drachmas worth your way :

        - I consider Image Logging so useful that I'd insist on it regardless of
any overhead. We don't use it for rollback/forward recovery, but it's great
for debugging, for being able to explain those "strange" values, for being
able to answer questions like "who deleted this part number ?", for
gathering stats about users, programs and datasets.
        - On occasion mass updates to the databases have had to be reversed (2-3
days later, thus ruling out a restore). I've had to dump the log files to
ASCII files and then write programs to read them and "undo" the wrongs. It
gives me peace of mind to know that there is a safety-net out there and
although it's a pain, a reversal can be done if need be.
        - At times we have had to run our production databases without logging. I
really don't notice any difference in performance with logging enabled or
disabled. Our modest (by Hp3000-L standards) setup consists of a 968, 100
concurrent sessions and jobs,  6 TurboIMAGE databases, about 5gig of data,
Transact/iX.
        - Log files use 1 sector per transaction (only an observation). So disk
space needed would be the number of transactions in a given time X 256
bytes. How large you let these files get and how often you purge them or
store them, is up to you. Bear in mind that dbfind and dbget don't get
logged, as I believe dbopen in read-only mode (and it's equivalent dbclose)
doesn't. So the term transaction only refers to database alterations, their
respective dbopens and dbcloses and any dbmemos you choose to use.
        - In Bradmarks DBAudit manual (a log file reporting product we use), in
the chapter "Getting Started with Logging" it says that "Most problems that
could arise with logging can usually be corrected by adding more memory to
the computer", so maybe memory is a consideration.
        - Other things to consider : jobs or command files to start new logging
cycles, time and effort for storing the log files, structural changes to
the db render them useless, structural changes to the db require a new log
cycle, a tool/product is needed to process them.

I think it's going to be hard to objectively quantify the overhead. Is a
"carefully observed" trial run not possible? That's what we did and logging
is now part of the system. If the system starts to slow down we'll add more
resources, we won't remove logging :)

Costas Anastassiades,
INTRACOM SA
Information Systems and Internal Communications Dept
Athens - Greece