DBRC Functions
| The following sections describe DBRC's major functions:
Recording and Controlling Log InformationAs IMS operates, it constantly records its activities in the IMS logs. The IMS logs contain information about:
The IMS logs consist of the:
Figure 23-1 shows the log data sets and restart data set (RDS) that IMS produces and the RECON data set that DBRC creates and maintains. Figure 23-1. Logs Produced for Recovery and Restart Related Reading: See IMS Version 9: Operations Guide for detailed discussions of the IMS logging process. After you have initialized DBRC, it participates in the IMS logging process by recording and controlling information about IMS's logging activities. This information is recorded in the RECON data set. If you want DBRC to control the recovery of your database data sets (DBDSs), you must register them with DBRC. DBRC automatically records many items in the RECON data set, including:
IMS uses this information for restarting itself and for database recovery jobs (if the databases are registered with DBRC). DBRC also tracks the archiving requirements of the OLDS and, if requested, generates and submits the JCL for archiving jobs. DBRC also provides unit-of-recovery management for all attached subsystems. DBRC provides information about these units of recovery for batch backout, dynamic backout, partial backout, and restart. For logs produced by batch systems, you are not required to use DBRC. The advantage of using DBRC for batch jobs is that DBRC records information about all the log data sets that are produced by batch jobs and prevents batch update jobs from executing if you specify a dummy or null log data set. Changing Log Records in the RECON Data SetUse the CHANGE.PRILOG or CHANGE.SECLOG commands to modify the information about OLDSs, RLDSs, or SLDSs in the log record of the RECON data set. Update the log record to indicate when errors have occurred on the data sets or that volume serial numbers have changed. You do not normally need to use these commands. Archiving an OLDSRun the Log Archive utility to archive an OLDS to an SLDS so that IMS can reuse the OLDS. How frequently you should archive depends on the load on the subsystem and the number of log records written to the OLDSs. The Log Archive utility always produces an SLDS. The SLDS contains all log records that are required for both database recovery and for online IMS restart. You can ask the Log Archive utility to produce an RLDS in addition to an SLDS. The RLDS contains only those log records that are required for database recovery. If you request an RLDS, information about the output RLDS data sets is recorded in the PRILOG record in the RECON data set and information about the SLDS data sets is recorded in the PRISLD record. If you do not request an RLDS, the same information about the SLDS data sets is recorded in both the PRILOG and PRISLD records. If there is a secondary OLDS, or if you request that dual logs be produced from a single OLDS, the information about the secondary-log output is recorded in corresponding SECLOG and SECSLD records. Important: Log data sets that are output from IMS batch jobs are technically SLDSs, but the information about them is recorded in the PRILOG and SECLOG records. Run the Log Archive utility by issuing the GENJCL.ARCHIVE command. DBRC then determines which OLDSs are full, and generates the appropriate JCL. Related Reading: See Member DFSVSMxx in IMS Version 9: Installation Volume 2: System Definition and Tailoring for more information on the ARCHDEF statement and automatic archiving. Recommendation: Whether you use automatic archiving or invoke archiving yourself, make sure the archive jobs run as quickly as possible. The online subsystem only reuses an OLDS after it has been archived. If the archive job is not run and all the OLDS become full, the online subsystem waits. One way to ensure that archive jobs run quickly is to use an initiator that runs with a fairly high priority and is not used by many other users. This ensures that the archive jobs do not remain on the internal reader queue for too long. If DBRC has marked an OLDS in the RECON data set as having errors, the GENJCL function does not submit it for archiving. If one of a pair of OLDSs has been destroyed or is unavailable, you can choose to mark it in the RECON data set as having errors. The following references point to where you can find more information about archiving log records. Related Reading:
DBRC Log-Related CommandsUse the following commands to perform DBRC log-related functions in your operational procedures:
In addition to the LIST.LOG command, you can use a LOG or OLDS query API request to retrieve log-related information from the RECON data set. How DBRC Helps in RecoveryDBRC can generate JCL for executing a database recovery, because DBRC records this information in the RECON data set. Whether you use the GENJCL commands to generate JCL or provide the JCL yourself, DBRC uses information in the RECON data set to determine exactly which data sets are required for input. The Database Recovery utility runs only if DBRC verifies that the JCL is correct. You can omit all logged changes after a certain time from the input by performing a time-stamp recovery. A time-stamp recovery is equivalent to backing out the omitted changes from the database. Most time-stamp recoveries require DBRC in order to be successful. When you involve DBRC in your request for a time-stamp recovery, DBRC selects the correct logs and, at execution time, communicates to the Database Recovery utility where to stop processing the input to correctly perform your request. Figure 23-2 on page 386 shows how DBRC works with the Database Recovery utility. Figure 23-2. How DBRC Works with the Database Recovery Utility Recommendation: Implement DBRC in phases, defining at first only a few recoverable databases in the RECON data set. This allows you to gain experience in the use of DBRC, and gives you an opportunity to assess, make, and test any changes needed in your backup, recovery, and operational procedures. Information for a database recovery can come from any or all of the following sources:
You can use DBRC to track all of these information sources, greatly simplifying the task of database recovery. Related Reading: Refer to IMS Version 9: Operations Guide for more information about the recovery process. If you register recoverable databases in the RECON data set, DBRC records the association of the databases to the log data sets containing database change records. DBRC also records information about:
DBRC is invoked by recovery tools and utilities to provide information about the resources required for database recovery. These resources can include information about image copies, logs, change accumulations, and database data sets. DBRC can:
Generating Recovery JCLYou can use the GENJCL.RECOV command to generate the JCL that is necessary to recover a registered database data set. Using information recorded in the RECON data set, DBRC:
If change accumulation input is required (because of data sharing), but it is not present or usable, DBRC informs you of that fact and the GENJCL.RECOV command fails. The GENJCL.USER command can generate user-defined output, which can include JCL. No skeletal JCL execution members are supplied to support the GENJCL.USER command. If you want to enter GENJCL.USER commands, you must supply the members to support them. Issue the GENJCL command to request that DBRC generate JCL in batch or issue the /RMGENJCL command online. When you enter either command, DBRC reads skeletal JCL and replaces symbolic parameters with actual values based on the information recorded in the RECON data set to build the appropriate JCL. For example, if you request that DBRC generate JCL to recover a database, DBRC retrieves the skeletal JCL member from the library and completes the JCL with information about the latest image copy, change accumulation, and log data sets, if necessary. Your databases must be registered in order for DBRC to generate JCL to process them. The amount of time and effort required to recover a database can be significantly reduced by using the GENJCL to generate the JCL and control statements necessary for the recovery. Using the GENJCL command also eliminates the causes of many recovery errors. You could spend a large amount of time during database recoveries determining which input data sets should be provided in what order to the Database Recovery utility. When change accumulation data sets or PRILOG records (in the RECON data set) are available, DBRC selects them rather than the SLDS for recovery. This results in quicker database recoveries if you run the Database Change Accumulation regularly. DBRC knows which log data sets are required and ensures that IMS processes all volumes in the correct order. DBRC also selects the most recent image copy for database recovery. DBRC always selects the optimum input for the Database Recovery utility by using change accumulation data sets whenever possible. If you have not used the Database Change Accumulation utility, or if that utility did not process some log data sets, DBRC selects the required log data sets from the PRILOG (or SECLOG) records, which can contain RLDS, SLDS, or both RLDS and SLDS entries. Related Reading:
Recommendation: For increased availability of data entry databases (DEDBs), use the DEDB Area Data Set Create utility to provide additional usable copies of an online area. It does not provide backup copies for recovery. The DEDB Area Data Set Create utility uses the RECON data set as part of its input. Validating Utility JCLWhen a recovery utility processes a registered database data set, the utility presents its input to DBRC for validation. Whether the recovery JCL was created by you or by DBRC, DBRC verifies that the input JCL to the utility is correct (according to the current information in the RECON data set). It is possible, even if you created the JCL with the GENJCL command, that intervening events could invalidate the input JCL before the utility is run. DBRC is invoked by the following IMS utilities and services to validate input and record the results:
Figure 23-3 on page 390 shows DBRC's role in running the previously mentioned utilities. Figure 23-3. DBRC's Role in Utility Execution Related Reading: See IMS Version 9: Utilities Reference: Database and Transaction Manager for more information on the IMS recovery utilities. When you run the Batch Backout utility (DFSBBO00), DBRC determines the complete set of logs that are needed for a particular backout job. In addition, DBRC manages information about the logs so that backout and restart jobs can be easily coordinated. Exception: DBRC does not verify the JCL input for the HD and the HISAM Reorganization utilities, but does record information about their execution in the RECON data set. Recording the ResultWhen the recovery completes successfully, DBRC records information about the recovery in the RECON data set. If you performed a time-stamp recovery, DBRC records information about the range of omitted changes. Requirement: If a time-stamp recovery is performed within a database allocation interval, you must immediately create an image copy to ensure a valid starting point for subsequent recovery attempts. DBRC then prevents the changes from being reapplied on any subsequent recovery. Recording Information about Opening and Updating DatabasesAfter IMS opens a database, DBRC passes back the RECON data set initialization token (RIT) and any extended error queue elements (EEQEs) associated with each DBDS. The RIT allows IMS to determine whether the database has been used without DBRC or whether the database has been controlled by a different RECON data set. Related Reading: See IMS Version 9: Operations Guide for information on EEQEs. When changes to DBDSs and areas occur, DBRC records information about these changes in the RECON data set. DBRC subsequently uses this information to determine which log data sets might contain change records for a given DBDS or area. When a DBDS that is registered in the RECON data set is first opened for updates (or allocated), IMS tells DBRC to create an ALLOC record. In the case of a DEDB area, the ALLOC record is created when the area is first opened for update. The ALLOC record identifies the DBDS or area and contains the time stamp of the first update and the open time stamp of the corresponding PRILOG. When DBRC creates the ALLOC record, DBRC also enters the name of the DBDS or area being changed in the LOGALL record for the PRILOG that is active at the time of the change. When you deallocate (close) a DBDS or area using a /DBRECOVERY command from the operator console of the online IMS subsystem, DBRC writes a deallocation time stamp in the ALLOC record. If no deallocation time is recorded, DBRC uses the closing time of the associated log as the deallocation time. Thus the RECON data set contains a list of the names of DBDSs or areas for which change records might exist on a given log data set (LOGALL record), a list of the time ranges where changes could exist for a specific DBDS or area (ALLOC records), and a list of the logs containing the changes. Supporting Data SharingData sharing introduces the concept of database authorization. Database authorization determines if an online IMS or batch IMS can have access to the requested databases. DBRC authorizes or refuses to authorize access to the databases depending on the current authorizations and the access intent of the IMS system. Data sharing requires that the databases be registered with DBRC. DBRC checks that subsystems have authority to perform the requested task and that other subsystems are not currently reserving the database. Related Reading: See IMS Version 9: Operations Guide and IMS Version 9: Administration Guide: System for more information on data sharing. Access IntentDBRC determines access intent. When IMS tries to allocate a database:
There are four levels of access intent for a database. Table 23-1 shows these attributes in reverse order, from the highest access intent (the most restrictive) to the lowest (the least restrictive)
Levels of Data SharingDBRC supports the two levels of IMS data sharing: Database level
Block level
Definition: For OSAM databases, the block is a physical data block that is stored on DASD. For VSAM databases and DEDBs, the block is a control interval (CI). Recording Data-Sharing Information in the RECON Data SetDBRC records the following data-sharing information in the RECON data set for all registered databases:
Assigning a Sharing Level with DBRCThe sharing level of a database or DEDB area determines whether a request for access is granted. DBRC allows you to establish one of four sharing levels. The following sharing levels are defined using the INIT.DB command and modified with the CHANGE.DB command. SHARELVL 0
SHARELVL 1
SHARELVL 2
SHARELVL 3
Note: To ensure the integrity of databases in data-sharing environments when batch jobs running without IRLM support access SHARELVL 3 databases, DBRC authorizes batch jobs that have update access only if all other IMS systems and batch jobs that are currently authorized by DBRC to the database have read-only access. If IRLM=N is specified in the IMSCTRL macro or DBBBATCH procedure, DBRC authorizes a batch job for update access to a database only if all other IMS systems and batch jobs that are currently authorized by DBRC to the database have read-only access. When a batch IRLM=N job has authorization for update, authorization for an online system or other batch job fails unless it is for read-only access. Supporting Remote Site RecoveryDBRC assists you with the definition and management of IMS components in the RSR complex. In support of RSR, DBRC provides:
During a remote takeover, DBRC changes the state information of the registered databases at the new active site to indicate that they are now the active databases. Related Reading: See IMS Version 9: Administration Guide: System for more information about controlling database recovery in an RSR environment. Supporting IMSplexesWhen an I/O error occurs on a RECON data set in an IMSplex and a spare data set is available, the instance of DBRC that noticed the error copies the good RECON data set to the spare, activates the spare, and deallocates the original RECON data set. At this point in the processing, the DBRC that noticed the I/O error can automatically notify the other DBRCs in the IMSplex about the reconfiguration. Then, after the original RECON data set is deallocated, it can be deleted and redefined as the spare RECON data set. Related Reading: See IMS Version 9: Common Service Layer Guide and Reference for more information about IMSplexes. |
EAN: 2147483647
Pages: 226
- Measuring and Managing E-Business Initiatives Through the Balanced Scorecard
- Technical Issues Related to IT Governance Tactics: Product Metrics, Measurements and Process Control
- Governing Information Technology Through COBIT
- The Evolution of IT Governance at NB Power
- Governance Structures for IT in the Health Care Industry
- Using SQL Data Definition Language (DDL) to Create Data Tables and Other Database Objects
- Creating Indexes for Fast Data Retrieval
- Using Keys and Constraints to Maintain Database Integrity
- Performing Multiple-table Queries and Creating SQL Data Views
- Writing External Applications to Query and Manipulate Database Data