Configuration Parameters That Affect Rollback and Recovery

Enterprise Edition Home | Express Edition Home | Previous Page | Next Page Effect of Configuration on I/O Activity > Background I/O Activities >

Configuration Parameters That Affect Rollback and Recovery

The following configuration parameters affect fast recovery:

OFF_RECVRY_THREADS
ON_RECVRY_THREADS
PLOG_OVERFLOW_PATH
FAST_RESTART_PHYSLOG
FAST_RESTART_CKPT_FUZZYLOG

OFF_RECVRY_THREADS and ON_RECVRY_THREADS

The OFF_RECVRY_THREADS and ON_RECVRY_THREADS configuration parameters specify the number of recovery threads, respectively, that operate when the database server performs a cold restore, warm restore, or fast recovery. The setting of OFF_RECVRY_THREADS controls cold restores, and the setting of ON_RECVRY_THREADS controls fast recovery and warm restores.

With fuzzy checkpoints, fast recovery might take longer than with full checkpoints. To improve the performance of fast recovery, increase the number of fast-recovery threads with the ON_RECVRY_THREADS configuration parameter. The number of threads should usually match the number of tables or fragments that are frequently updated to roll forward the transactions recorded in the logical log.

Another estimate is the number of tables or fragments that experience frequent updates. On a single-CPU host, the number of threads should be no fewer than 10 and no more than 30 or 40. At a certain point, the overhead that is associated with each thread outweighs the advantages of parallel threads.

A warm restore takes place concurrently with other database operations. To reduce the impact of the warm restore on other users, you can allocate fewer threads to it than you would to a cold restore. However, to replay logical-log transactions in parallel during a warm restore, specify more threads in the ON_RECVRY_THREADS parameter.

PLOG_OVERFLOW_PATH

The PLOG_OVERFLOW_PATH configuration parameter specifies the location of a disk file (named plog_extend.servernum) that the database server uses if the physical log file overflows during fast recovery.

The database server removes the plog_extend.servernum file when the first checkpoint is performed during a fast recovery.

FAST_RESTART_PHYSLOG and FAST_RESTART_CKPT_FUZZYLOG

For situations when you are using fuzzy checkpoints and need faster recovery performance, you can use either or both of the following configuration parameters:

FAST_RESTART_PHYSLOG, which enables physical logging on fuzzy operations (insert, update, and delete), so that all before-images are stored in physical log. During fast recovery, these pages are loaded into the buffer pool with large block, sequential I/O during the physical recovery phase. When the database server replays the log records that modify these pages, random I/O is avoided.
FAST_RESTART_CKPT_FUZZYLOG enables saving all unflushed fuzzy dirty pages into physical log during checkpoint. This means Logical Recovery Phase A can be avoided during fast recovery.

You can use either parameter or both when using fuzzy checkpoints. The default value for both parameters is 0 (off). Set them to 1 (on) to use them.

Important:

To obtain fast recovery using FAST_RESTART_PHYSLOG, the size of the buffer pool must be at least 25 percent larger than the physical buffer size. The buffer pool must be large enough to hold the physical log, log pages, and other pages read during recovery. If fast recovery starts with a buffer pool size that is not configured correctly, fast recovery performance is compromised. If you do not want the extra physical logging, you can choose to use only the FAST_RESTART_PHYSLOG parameter.

The extra physical logging that occurs when the database server uses the FAST_RESTART_PHYSLOG configuration parameter affects runtime performance. If you do not want to sacrifice runtime performance, you can use the FAST_RESTART_CKPT_FUZZYLOG configuration parameter to reduce some recovery time.

FAST_RESTART_PHYSLOG takes effect immediately after you enable it. However, if the database server fails before the next checkpoint performs, maximum fast-recovery performance does not occur because the database server did not log all of the fuzzy updates in the checkpoint intervals.

For more information on these parameters, see the IBM Informix: Dynamic Server Administrator's Reference and information on fast restart recovery options in the IBM Informix: Dynamic Server Administrator's Guide.