TurboIMAGE/XL Database Management System Reference Manual (30391-90012)

378 Chapter7
Logging and Recovery
The Mirror Database
• When using the STOP-RESTART option, the log file name and the logid must be
different.
Log File Size
Determine the size of the log files, based on how far behind the secondary system will be,
and how often backups will be done. To keep the secondary system as close to a mirror
image of the primary database as possible, log files should be made small so that they will
be filled quickly and can be sent to the secondary system frequently. Of course, making the
log files small means spending more time transferring log files from the primary to the
secondary system. It also means that the CHANGELOG maximum file limit of 999 will be
exhausted quickly. In the event that this limit is exhausted, stop, backup the database, and
reinitiate logging on the primary system.
One disadvantage of having several small log files is in the application of STOP-RESTART.
DBRECOV prompts to CON[TINUE] or STOP recovery if it is between log files in a log set,
and it cannot find the next log file. Therefore, the prompts to CON[TINUE] or STOP are
more frequent when there are several small log files.
An alternate logging option would be to set the log file size very large and just manually
change to the next log file by issuing the CHANGELOG command. The idea is to continually
fill the log file with transactions. When you are ready to copy the log file over to the
secondary system, change to the next log file on the primary system, copy the current one
to the secondary system, and start recovery. This method requires someone at the system
console to monitor the logging and database maintenance processes. If you want to
schedule backups on the secondary system around certain times of the day, for example, at
the beginning and end of a work day, use this logging procedure on the mirror database.
You can log a full shift's transactions and then manually issue a CHANGELOG command at
the system console to create a new log file in the log set. Even if the GETLOG command
AUTO option was specified when logging was enabled, a manual CHANGELOG command can
also be issued at any time. The closed log file is transferred to the secondary system, and
the DBRECOV roll-forward recovery process can be continued on the secondary databases.
After the log file has been processed, DBRECOV looks for the next log file in the log set on the
secondary system. If the next log file on the primary system is in use, the user is prompted
to CON[TINUE] or STOP. At this point, recovery can be stopped and the secondary
database can be stored and await the arrival of the next log file at the end of the shift.
Remember to store the RESTART file and the current, unprocessed log files with the
databases.