Alternative Fast Restart Recovery Options for Fuzzy Operations

For situations when you need recovery performance that is faster than the default recovery operations described above, you can use the following configuration parameters:

• The FAST_RESTART_PHYSLOG configuration parameter, which enables the database server to perform physical logging on fuzzy pages while the server is running normally.
• The FAST_RESTART_CKPT_FUZZYLOG configuration parameter, which enables the database server to put unflushed dirty fuzzy pages in the physical log at checkpoint time. These unflushed dirty fuzzy pages are taken into the database server buffer pool at the beginning of the fast recovery.

When the database server is online:

• Set the FAST_RESTART_PHYSLOG configuration parameter to 1 to enable physical logging. Only use this parameter if the buffer pool is at least 25 percent larger than the physical log file size. The buffer pool must be large enough to hold the physical log, log pages, and other pages read during recovery.

  If the buffer pool is not configured correctly, fast recovery performance is compromised.

• Set the FAST_RESTART_CKPT_FUZZYLOG configuration parameter to 1 to enable the flushing of dirty-pages table records to the physical log at checkpoint.

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

The FAST_RESTART_PHYSLOG and FAST_RESTART_CKPT_FUZZYLOG configuration parameters improve recovery performance. You must set these parameters when you start the database server. If you wait and set these parameters when the server is running, the parameters will not take effect.

The extra physical logging that occurs when the database server uses the FAST_RESTART_PHYSLOG parameter affects runtime performance. If you do not want to sacrifice runtime performance, use the FAST_RESTART_CKPT_FUZZYLOG parameter to reduce some recovery time. FAST_RESTART_CKPT_FUZZYLOG, which needs less buffer pool space than the FAST_RESTART_PHYSLOG, needs up to 20 percent of the physical log size and it needs extra buffer pool size. When configuring the buffer pool before starting fast recovery, the number of unflushed dirty buffer pages are written to physical log at checkpoint time can help you determine how much more buffer pool space you should consider.

Which configuration parameter is faster depends on your system configuration and applications when the database server shuts down. For example:

• If the database server performs a fuzzy checkpoint, has a large number of unflushed fuzzy dirty pages, and then shuts down shortly after this checkpoint, FAST_RESTART_CKPT_FUZZYLOG makes a big difference in the fast recovery performance. In this situation, and FAST_RESTART_PHYSLOG has little effect.
• However, if the database server performs a hard checkpoint or performs a fuzzy checkpoint but has few or no unflushed fuzzy dirty pages and then shuts down after running for a long time before next checkpoint, FAST_RESTART_PHYSLOG makes a big difference in the fast recovery performance. In this situation, FAST_RESTART_CKPT_FUZZYLOG has little effect.

Thus, if you want better performance during fast recovery and have a bigger buffer pool configuration, always turn on FAST_RESTART_CKPT_FUZZYLOG. This does not affect database server runtime performance. If you are willing to sacrifice some runtime performance for better fast recovery performance, you can also turn on FAST_RESTART_PHYSLOG.

FAST_RESTART_PHYSLOG takes effect when you restart the database server. 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.

FAST_RESTART_CKPT_FUZZYLOG takes effect when you restart the database server. If the total number of unflushed, fuzzy dirty pages exceeds 20 percent of the total physical log space, the pages will not be written to the physical log.

Neither parameter changes the way to initiate fast recovery.