This table exists to provide information about the logging environment and status. The startup options pertaining to logging are provided in the MUF_OPTIONS table. This table has a single row.
|
Column Name |
SQL Data Type |
Nullable |
Description |
|---|---|---|---|
|
AREA_NAME |
CHAR(3) |
No |
Contains LXX as the area name to easily join this row with the MUF_AREA_STATS table for logical and physical write information. |
|
BLOCK_LENGTH |
SMALLINT |
No |
Always set to 32760. MUF optimizes blocks that are written to match the data needing to be written. |
|
BLOCKS_SPILLABLE |
INTEGER |
No |
Contains zero if currently spilling. Otherwise, it contains the number of tracks that are spillable at this point in time (which may also be zero). |
|
CYCLE_NUMBER |
INTEGER |
No |
A cycle is a contiguous group of LXX tracks to be written to the Recovery File (RXX). If currently a spill is being done (SPILL=Y), then this cycle number represents the cycle being spilled. If a spill is not being done (SPILL=N), then this cycle number represents the current unspilled LXX tracks, some or all of which become the next spilled cycle. |
|
DBID |
SMALLINT |
No |
Contains zero as the database ID to easily join this row with the MUF_AREA_STATS table for logical and physical write information. |
|
GENERATION |
SMALLINT |
No |
Value returned is 1 for generation 1. |
|
IN_USE_BLOCKS |
INTEGER |
No |
Number of tracks in the Log Area that contain active log records. If spilling is active, this includes all tracks in the cycle being spilled in addition to the tracks built after the blocks being spilled. At the completion of a spill, the spilled tracks are removed from the active tracks. To calculate a percent full, use the IN_USE_BLOCKS and the TOTAL_BLOCKS. |
|
LAST_SPILLED_TIME |
TIMESTAMP |
Yes |
Contains a null if a spill has not been completed during this execution of the MUF. Otherwise, it contains the date and time of the last record spilled. |
|
LOG_BLOCK_SEQ |
DECIMAL (21,0) |
No |
Contains the assigned log track sequence number of the log record in the Log Area that is one number higher than the previous log track. |
|
LOG_RECORD_SEQ |
DECIMAL (21,0) |
No |
Each record written to the Log Area is assigned an ascending sequence number. The last number assigned is provided here. The value of the LOG_RECORD_SEQ cannot be predicted when a MUF is enabled. However, it is predictable that each log record has the next higher number within the same MUF session. This number is available here so that log activity can be measured, such as how many records are being logged in a given period of time (by reading this record at two points in time within the same MUF execution and subtracting the first LOG_RECORD_SEQ value from the second). |
|
LOG_RECORD_SEQ_G0 |
INTEGER |
No |
Specifies the Log Record Sequence number as an integer as it existed in the generation 0 table. This column is being maintained for compatibility but may not accurately represent the new larger values supported in the current release. If the true value is larger than will fit in an integer, this column is set to high values. |
|
MUF_NAME |
CHAR(8) |
No |
Name of the MUF specified in the MUF Multi-User startup option or the name of the MUF job name. |
|
PHY_PER_LOG_BLOCK |
SMALLINT |
No |
Contains a 1 with the recommended variable logging. If using spanned logging for fallback to Version 14.0, PHY_PER_LOG_BLOCK contains a 2 or a 3. |
|
RESTART_BLOCK_REDO |
INTEGER |
No |
The MUF takes into account the startup option LOGPEND and also the current activity in active requests and index and data buffers that are pipelined (write pended). From this information comes a minimum number of log tracks that RESTART processing needs to redo, during MUF startup, to ensure all index and data in the pipeline are completed. It can be a little higher than LOGPEND but is usually much lower. This track count provides a good indication of the amount of work and, therefore, the time a restart must reprocess work. |
|
RESTART_BLOCK_SCAN |
INTEGER |
No |
Contains the number of log tracks that the RESTART process during MUF startup processing would have to review to ensure all tasks are seen and processed. The scan part of RESTART must simply read through the Log Area from a point that would cause the current request for each active task (RWTSA) doing maintenance to be seen. Also, the last maintenance request for each task that is subject to transaction backout must be seen. This scan runs quickly, but the number of tracks is dependent on the current activity and is not predictable. This scan is not controlled by the LOGPEND parameter. |
|
RXX_NUMBER |
INTEGER |
No |
This is the number which is assigned to the next Recovery File (RXX) produced. In a test system with the Multi-User startup option LOGRCV NEVER specified, this number is unchanged because no Recovery File will be produced. For inactive recovery, each SPILL of log tracks causes a new number to be assigned. For active recovery, the MUF enable starts a new RXX and each COMM NEWRXX causes another. The number starts at zero when the Log Area is initialized. The number represents the number of recovery files built since the Log Area INIT. |
|
SPILL_BLOCKS_DONE |
INTEGER |
No |
As a spill is prepared, this field is set to zero. It is incremented as individual log tracks are read from the Log Area to be copied to the Recovery File. |
|
SPILL_BLOCKS_TOTAL |
INTEGER |
No |
As a spill is prepared, this field is set to contain the number of tracks that are to be spilled. This number of tracks is also called a cycle on the Recovery File. |
|
SPILLING |
CHAR(1) |
No |
Contains an R to indicate that a spill has been prepared and is committed to start. Contains a Y to indicate that a spill has been started and is in process. Contains an N to indicate that no spill is currently requested and none is currently in process. In an active environment, the spill is automatically started and runs through completion. In an inactive environment, the spill is a utility function which must be started either through an operator or could also be started through an automated tool watching for console messages. |
|
TOTAL_BLOCKS |
INTEGER |
No |
Number of log tracks (logical) that are available for logging records. Currently, the first track is reserved as a control block. The last physical track is also reserved. |
|
TOTAL_TRACKS |
INTEGER |
No |
Number of tracks that are being used for the Log Area. |
|
VARIABLE |
CHAR(1) |
No |
Indicates if the LXX was initialized as variable. |
|
VARIABLE_MAX_GT8 |
SMALLINT |
Yes |
For variable logging, this column contains a count, if you have allocated more than 8 buffers. It tells you the maximum number of buffers that have actually been used. If not null, it cannot be less than 9 nor more than the number of log-ahead buffers. It represents a high-water mark of buffer usage, because the detail used counts stop at 8. |
|
VARIABLE_USED_1 |
INTEGER |
No |
This count is the number of times the first log-ahead buffer is activated. It occurs only when the single current buffer is full and no log-ahead buffers are in use. If activated, the buffer can contain only one record or a full block of records before it is written. |
|
VARIABLE_USED_2_4 |
INTEGER |
No |
Count of times the second, third, or fourth log-ahead buffer was activated. |
|
VARIABLE_USED_5_7 |
INTEGER |
No |
Count of times the fifth, sixth, or seventh log-ahead buffer was activated. |
|
VARIABLE_USED_8 |
INTEGER |
No |
Count of times 8 or more log-ahead buffers were activated. |
|
VARIABLE_WAIT_SMP |
INTEGER |
No |
This is the count of times all log-ahead buffers were full and a wait needed to occur for a current block to free one or more buffers. If this count is large, consider increasing the number of log-ahead buffers. This column indicates whether the log was subjected to an INIT with the variable specified as yes (Y) or no (N). |
|
VARIABLE_WRITE_2_3 |
INTEGER |
No |
Contains a count of the number of times the current log block was written with a chain of 2 or 3 log blocks in a single I/O. |
|
VARIABLE_WRITE_4_6 |
INTEGER |
No |
Contains a count of the number of times the current log block was written with a chain of 4, 5 or 6 log blocks in a single I/O. |
|
WAIT_COMIT_BAD |
INTEGER |
No |
If this MUF uses the X_LOG_DELAY Multi-User startup option, this column contains the count of times a task doing a transaction-ending command delayed for another task to write the LXX block but none did within the specified time limit. If this MUF does not use the X_LOG_DELAY Multi-User startup option, this column is 0. |
|
WAIT_COMIT_GOOD |
INTEGER |
No |
If this MUF uses the X_LOG_DELAY Multi-User startup option, this column contains the count of times a task doing a transaction-ending command delayed for another task to write the LXX block and another did, therefore saving a possible LXX I/O. If this MUF does not use the X_LOG_DELAY Multi-User startup option, this column is 0. |
|
WAIT_CURR_LOG_BLK
|
INTEGER |
No |
Informational count of the times that a task had to wait on access to the log buffer that is used for adding log records. No user action is required related to this count. It provides a clue of contention to the current log block. It is used by tasks adding log records, possibly by transaction backout, or if writing an index or data block which has information in this current log block. |
|
WAIT_CURR_LOG_RCD
|
INTEGER |
No |
Informational count of the times a task wanted to add a log record, but had to wait on another task already in the process of adding a log record. This count can be large, but no action is possible. Most counts occur as each log block is written, many tasks may want to log a record during this time and wait. The count is provided as a clue to log contention. |
|
Copyright © 2014 CA.
All rights reserved.
|
|