Ah, the age old question: "To log or not to log."

IMAGE logging is a vastly under-utilized tool, a little awkward to use perhaps (issues about the need to be the CREATOR and the problems associated with logging and manual capacity management), but well worth the effort.

Stories about performance degradation probably date back to using tape drives as the log files. No one reports seeing a performance hit greater than a few percentage points anymore on systems doing significant logging.

In addition to the obvious recovery purpose of logging:

It's much less costly than high-availability software/hardware options, yet gives very good protection when coupled with a good backup strategy

It provides an audit trail that can be used both for security reasons and to debug programs or research performance bottlenecks.

IMAGE logging is one of the few things that allow for easy performance testing in your production environment without a lot of effort. In fact, it takes about five minutes to get it going. But you might want to practice with your test database if you've never done it.

First of all, issue these commands

GETLOG yourlogid;LOG=yourlogfile name001,DISC;AUTO

BUILD yourlogfilename001,DISC

LOG yourlogid,START

Make sure users have LG capability.

You can do the above in advance.

Find a time some night when there is no one accessing the database, then do in DBUTIL:

SET db LOGID ...

ENA db FOR LOGGING

Then monitor the day's performance and any user complaints. The next night:

DIS db FOR LOGGING

If things are cool, get down to business and think out and set up your automagic log cycles, etc. If performance is not cool, don't do it.

I did not include database backup in this process because it is not required to merely test performance issues.