Adding Logs Dynamically

The DYNAMIC_LOGS configuration parameter determines when the database server dynamically adds a logical-log file. When you use the default value of 2 for DYNAMIC_LOGS, the database server dynamically adds a new log file and sets off an alarm if the next active log file contains the beginning of the oldest open transaction.

The database server checks the logical-log space at these points:

• After switching to a new log file
• At the beginning of the transaction-cleanup phase of logical recovery

If the DYNAMIC_LOGS parameter is set to 1 and the next active log file contains records from an open transaction, the database server prompts you to add a log file manually and sets off an alarm. After you add the log file, the database server resumes processing the transaction.

If the DYNAMIC_LOGS parameter is set to 0 and the logical log runs out of space during a long transaction rollback, the database server can hang. (The long transaction prevents the first logical-log file from becoming free and available for reuse.) To fix the problem, set DYNAMIC_LOGS to 2 and restart the database server. Then the long transaction should be able to complete.

For more information, see Monitoring Events for Dynamically Added Logs and Setting High-Watermarks for Rolling Back Long Transactions.

Size and Number of Dynamically Added Log Files

When dynamically adding a log file, the database server uses the following factors to calculate the size of the log file:

• Average log size
• Amount of contiguous space available

If the logical log is low on space, the database server adds as many log files as needed to complete the transaction. The number of log files is limited by:

• The maximum number of log files supported
• The amount of disk space for the log files
• The amount of free contiguous space in the root chunk

If the database server stops adding new log files because it is out of disk space, it writes an error message and sets off an alarm. Add a dbspace or chunk to an existing dbspace. Then the database server automatically resumes processing the transaction.

The reserve pages in the root chunk store information about each log file. The extents that contain this information expand as more log files are added. The root chunk requires two extents of 1.4 megabytes each to track 32,767 log files, the maximum number supported.

If during reversion, the chunk reserve page extent is allocated from a non-root chunk, the server attempts to put it back in the root chunk. If not enough space is available in the root chunk, the reversion fails. A message containing the required space displays in the online log. The required space needs to be freed from the root chunk before trying the reversion again.

Location of Dynamically Added Log Files

The database server allocates log files in dbspaces, in the following search order. A dbspace becomes critical if it contains logical-log files or the physical log.

Pass

Allocate Log File In

1

The dbspace that contains the newest log files

(If this dbspace is full, the database server searches other dbspaces.)

2

Mirrored dbspace that contains log files (but excluding the root dbspace)

3

All dbspaces that already contain log files (excluding the root dbspace)

4

The dbspace that contains the physical log

5

The root dbspace

6

Any mirrored dbspace

7

Any dbspace

If you do not want to use this search order to allocate the new log file, you must set the DYNAMIC_LOGS parameter to 1 and execute onparams -a -i with the location you want to use for the new log. For details, refer to Monitoring Events for Dynamically Added Logs.