Previous Topic: Enable Dynamic System TablesNext Topic: Monitor KEY Usage Statistics

Configuration Best Practices › Implement the Parallel Variable Log Area

Implement the Parallel Variable Log Area

The Parallel Variable Log facility provides you with three key enhancements over the standard fixed block architecture LXX.

For sites where the LXX data set is DASD replicated (that is, mirrored) across long distances, the replication software has had some difficulties when replicating the fixed block LXX. The problem stems around the CA Datacom requirement to rewrite the current log block every time a COMMIT is issued. With today’s systems using the large block sizes for the LXX (1/2 or 1/3 track), the number of times and the frequency a specific physical log block can be rewritten in the process of verifying the commit point can be significant. The high frequency rewrites of the same physical block can cause some significant delay in the replication process. With the parallel variable log, you can set the LXX block size to be variable, 4 K to 32 K. This allows the system to create more and smaller physical blocks on the LXX data set. Having more and smaller blocks reduces the number of rewrites that occur and removes some of the delay experienced by the replication process.

The second benefit of the parallel variable log is the ability to specify multiple buffers to hold active log processing. In a system using fixed block logging, there is a single log buffer that is created to match the size of the physical data block on the LXX. When the log buffer fills and the next log record will not fit in the current buffer, the log buffer is written to the matching log block one last time. After the I/O completes, the log buffer is emptied and processing continues. During this process, any update activity in the system must wait because its matching log record cannot be placed into the single log buffer. This created a brief pause in all update processing.

For sites implementing the parallel variable log, there is an ability to specify multiple log buffers, the default is 8. Since multiple buffers are available, there is an ability to asynchronously I/O a full buffer while allowing update processing to continue by writing their log records into the next available log buffer. Only when all log buffers are full and awaiting an I/O would a pause occur (that is, similar to the fixed block full buffer pause). Because you can specify additional log buffers (up to 99), you can almost completely eliminate the pauses.

The final benefit is the combination of the multiple log buffers and the CA Datacom ability to do multiple block I/Os. For years, CA Datacom has done multi-block I/Os when processing data buffers to and from the data areas. With the parallel variable log, this same technique has been introduced allowing a single I/O to write multiple log buffers in sequence to their respective physical DASD blocks, which greatly reduces the number of physical I/Os necessary to process the log buffers to DASD.

Regardless of which method of logging is used, either fixed block or variable block, the DBUTLTY SPILL process and all downstream processing of the RXX data sets remains the same. There should be no user processing affected by the change in log processing.

Business Value

Any site implementing DASD replication (that is, mirroring) will find that a LXX data set on a busy CA Datacom system will be using a significant amount of the replication resources. In many cases, the systems overall response time will be based on how fast the replication processing can handle the LXX data set. For these sites, the parallel variable log will provide significant relief.

If you do not have DASD replication processing, you will find that the parallel variable log with a maximum block size can greatly reduce the amount of LXX I/Os which saves CPU usage, and you will also find that maintenance requests (that is, the adds, updates, deletes) will have a faster elapsed processing time due to the removal of the log buffer full “pauses”.

It has been shown that any site with significant CA Datacom processing will benefit from using the parallel variable log.

Additional Considerations

The specification on which type of log processing is used is decided when the LXX data set is initialized using the DBUTLTY INIT AREA=LXX function.

The MUF must be down to initialize the LXX data set and any data left on the LXX will be lost. You must take care to:

  1. Stop all processing in the MUF.
  2. Spill the contents of the LXX to the RXX.
  3. Shut down the MUF.
  4. Run the DBUTLTY INIT AREA=LXX function: 
    DBUTLTY INIT AREA=LXX,BLKSIZE=32760,VARIABLE=YES

    The BLKSIZE must be set to 32760 when VARIABLE is set to YES.

The number of MUF log buffers created for the parallel variable log system defaults to 8. To increase or decrease the amount of parallel log buffers, you can specify the X_LOG_AHEAD_BLKS MUF startup option. The maximum value is 99. You can determine the number of MUF log buffers that have been in use for a given MUF execution by querying the Dynamic System Table MUF_LOGGING or by reviewing the MUF EOJ report.

For sites that are using DASD replication, the MUF startup option X_LOG_MINIMUM_BLK can be used to set the minimum variable block size used to create a LXX physical block. Specifying a small number allows MUF to create many small LXX blocks and greatly diminishes the amount of physical block rewrites. However, using a small value would also significantly reduce DASD utilization due to the overhead of having many small blocks versus a couple of large blocks. For sites not doing DASD replication, this value should be left at the maximum of 32760.

More Information