iX V6.5 (30391-90011)

376 Chapter7

Logging and Recovery

The Mirror Database

• When using the STOP-RESTART option, the log ﬁle name and the logid must be

different.

Log File Size

Determine the size of the log ﬁles, 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 ﬁles should be made small so that they will

be ﬁlled quickly and can be sent to the secondary system frequently. Of course, making the

log ﬁles small means spending more time transferring log ﬁles from the primary to the

secondary system. It also means that the CHANGELOG maximum ﬁle 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 ﬁles is in the application of STOP-RESTART.

DBRECOV prompts to CON[TINUE] or STOP recovery if it is between log ﬁles in a log set,

and it cannot ﬁnd the next log ﬁle. Therefore, the prompts to CON[TINUE] or STOP are

more frequent when there are several small log ﬁles.

An alternate logging option would be to set the log ﬁle size very large and just manually

change to the next log ﬁle by issuing the CHANGELOG command. The idea is to continually

ﬁll the log ﬁle with transactions. When you are ready to copy the log ﬁle over to the

secondary system, change to the next log ﬁle 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 ﬁle in the log set. Even if the GETLOG command

AUTO option was speciﬁed when logging was enabled, a manual CHANGELOG command can

also be issued at any time. The closed log ﬁle is transferred to the secondary system, and

the DBRECOV roll-forward recovery process can be continued on the secondary databases.

After the log ﬁle has been processed, DBRECOV looks for the next log ﬁle in the log set on the

secondary system. If the next log ﬁle 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 ﬁle at the end of the shift.

Remember to store the RESTART ﬁle and the current, unprocessed log ﬁles with the

databases.