Extending the Log Area (LXX)
The ability to extend the Log Area (LXX) with MUF processing allows a larger LXX without an outage to use DBUTLTY to INIT an LXX with more tracks.
A z/OS only feature, the LXX can be extended as MUF is running using the existing DYNAMIC_EXTEND option. The process of extending the LXX is similar to that of extending the Directory (CXX). The additional space gained from the LXX extension can only be incorporated into the log to store log records until the LXX is at its "wrap point," meaning, at the end of the data set from which it "wraps" to the front. Interactions that are related to LXX maintenance and the spilling of the LXX make the log available for extension only at the next wrap point or at the end of the next two wraps.
Increasing the size of two Log Area (LXX) internal sequence number constraints helps ensure that the CA Datacom/DB Multiple User Facility (MUF) has more 24X7 availability.
Log Record Sequence Number (LRSN)
The Log Record Sequence Number (LRSN) is a count of records added to the CA Datacom/DB LXX. There is one LRSN for every maintenance command that adds, updates, or deletes a record. A few control commands, for example a commit, also add to the LRSN.
In previous releases, the LRSN was an integer with a range of from zero to one less than 4 billion. With each new execution of the MUF, the LRSN was restarted at a value of one. The LRSN was restarted whenever a user issued a QUIESCE RST console command. The restart, however, required an outage of several minutes that impacted 24X7 availability. No outages for read commands were provided, but open, close, and maintenance commands were held.
In this release, the maximum size of the LRSN is increased from 4 billion to 4 billion times 4 billion, a number large enough to not require recycling because of the LRSN. The outage required for recycling the LRSN is therefore avoided and its impact on 24X7 availability is eliminated.
Log Block Sequence Number (LBSN)
The Log Block Sequence Number (LBSN) is a count of log blocks written to the CA Datacom/DB LXX.
In previous releases, the LBSN was an integer that ranged from zero to one less than 4 billion. When the prior MUF was not force-terminated, with each new execution of the MUF the LBSN was restarted at a small number. The restart required an outage of several minutes. Some users did not ordinarily terminate the MUF normally because they did not want the short outage.
In this release, the maximum size of the LBSN is increased from 4 billion to 4 billion times 4 billion, a number large enough to never require recycling the LBSN. The outage required for recycling the LBSN is therefore avoided and its impact on 24X7 availability is eliminated.
In support of larger LRSNs and LBSNs, three return codes and two messages have been added. The return codes are 94(147), 94(148), and 94(149). The messages are DB01227I and DB01228I. For more information, see the CA Datacom/DB Message Reference Guide.
Also see the information about LXX Large Number LRSNs and LBSNs in the section on creating and maintaining the LXX in the CA Datacom/DB Database and System Administration Guide.
New STATUS_LOG Console Command
The format for STATUS_LOG is similar to the STATUS and STATUS_SMP console commands. STATUS_LOG provides Log Area (LXX) information that can prove useful. For more information, see the CA Datacom/DB Database and System Administration Guide.
New Log Area LXX WRAP message
In support of the LXX extend, a new message occurs each time the LXX is wrapped. That is, message DB00321I - LOG LXX WRAP is generated after writing to the end of the data set and being reset (wrapping) back to the start. It provides the elapsed times of the information from the first physical log record at the start to the last physical log record at the end. This provides an elapsed time covered by one physical start to finish. Also provided is the lowest time. These values can be of interest in sizing the Log Area. The size is of most interest relating to spill processing but has some interest also in Change Data Capture. For more information, see message DB00321I in the CA Datacom/DB Message Reference Guide.
Unique Row Identifier (URI) limitations in previous releases threatened 24X7 availability with rare but possible data table outages. A URI reuse feature in Version 15.0 enhances 24X7 availability by minimizing URI-related outages.
The maximum number of URI records is four billion records (4G). In previous releases, when the limit of four billion records had been reached, a return code 94 (096) was issued, and no new adds or inserts could be done until the data area was closed, backed up, and reloaded.
The URI reuse feature works with any area but is most useful in data areas that have many rows. The URI reuse process saves URI values for deleted rows that have become available for reuse, tracks, and reassigns previously used URIs within the Multi-User Facility (MUF). The values of the reuseable URIs are saved to a URI reuse key within the index of a database. After the user specifies that they want to reuse URIs, no further user action is required. Reusing URIs is chosen by specifying a Y (yes) for the URI-REUSE CA Datacom Datadictionary attribute on the AREA entity-type (batch transaction 3002). Once specified, the URI reuse process is triggered when the URI count for a data area reaches 3G. After the URI count reaches 3G (3,221,225,472), an asynchronous scan of the data area is scheduled in the MUF. This scan uses a new system task with a jobname of ***DBURI.
For details about the CA Datacom Datadictionary URI-REUSE attribute and CA Datacom Datadictionary batch transaction 3002, see the CA Datacom Datadictionary Attribute Reference Guide and the CA Datacom Datadictionary Batch Reference Guide.
Because the URI reuse feature stores available URIs in the index, consider whether increasing the size of existing indexes is needed. This is not necessarily an issue at sites using dynamic extend, or if the number of free URIs is not significantly relative to the number of rows in the data area.
The URI reuse feature has fallback considerations. Potentially, two key IDs could be created when reusing URIs, one for tracking available URIs, and one created by backward recovery. A key ID could be created by backward recovery if the available URI index exists for the DBID and area being recovered and is used to prevent CA Datacom/DB from reusing a URI that backward recovery, because of the backout of a delete, re-added to the area.
We recommend not setting the URI-REUSE attribute to Y until certain no fallback is going to be needed. When the new URI-REUSE attribute is implemented during an upgrade to Version 15.0, all existing AREA occurrences of URI-REUSE are set to N (no).If a fallback is needed after running with URI-REUSE set to Y, delete both of the URI reuse key IDs using a DBUTLTY LOAD or RETIX. The main fallback consideration for users occurs if the URI reuse feature is implemented and there is an area with a high URI count that exceeds 3G, triggering a URI scan that creates a list of available URIs and with it the associated URI reuse key ID. If you then have to fall back and run a backward recovery in Version 14.0, we recommend running a REMOVE against the URI key ID.
For more information on the URI reuse feature, see the CA Datacom/DB Database and System Administration Guide.
|
Copyright © 2014 CA.
All rights reserved.
|
|