¿Cuál estrategia de servicio al cliente aplican en su
SERVICIOS GENERALES 696
Chapter 10 Change Accumulation
Change accumulation does not read databases, so it is not a subsystem. Because of this, it does not sign on to DBRC or request authorization. However, DBRC checks the input and output data sets and records the execution.
The advantage of change accumulation is that it sorts and merges all the changes from the logs, so if a segment has been updated twenty times, only the last change is required for recovery and that is the one stored on the change accumulation data set, which makes recovery faster. The disadvantage is the extra workload.
This chapter looks at how change accumulation works with DBRC and how to reduce this workload.
Change Accumulation Groups
One of the neat features that comes with DBRC is the ability to define multiple change accumulation groups (CAGRPs). Before talking about CAGRPs, I would first like to consider why people (should) run change accumulation at all.
• To reduce image copy frequency
If you use change accumulation, you can leave a longer period between image copies without impacting recovery times. This can lead to major reductions in the number of cartridges required for backup, and help to relieve the pressure on the batch window.
Change Accumulation Groups
• To reduce recovery times
The recovery utility will run faster if you use change accumulation as input. (The change accumulation utility is basically a sort process which throws away all of the database updates except the latest ones and then sorts the updates in the same order as the image copy). In this case, the recovery utility merges the image copy and the change accumulation file and then applies any logs in a separate second stage.
If you use the IMS utility and input one or more logs, then each
individual database change record on the input log(s) will be handled via DL/1—a very slow process. The IMS utility is also designed to only recover one database data set per run, so you will also end up reading the logs over and over again.
If you use BMC Software's RECOVERY PLUS, then you will only read the logs once even when recovering multiple databases. However, the BMC Software utility will also run faster with change accumulation input because it now has much less input data to read and does not have to do any sorting.
• To prove the logs are readable
It is embarrassing (and potentially extremely time-consuming) to find out your logs are unreadable when you come to run a recovery.
• To reduce the number of logs/amount of first level recovery data Many customers use the technique of logging to disk in batch and/or archiving to an RLDS on disk for online. They then run change
accumulation and let HSM migrate the input log(s) to a cheaper medium. Hence, the “shelf life” of a disk log/RLDS is relatively short and you free up expensive DASD for the next job. Use of IDRC tape drives for the migration gives the added benefit of compressing the logs. Change accumulation can also use compression for its output data set as from IMS V3.1 or when using BMC Software's CHANGE ACCUMULATION PLUS.
Change Accumulation Groups
BMC Software, Inc., Confidential and Proprietary Information
Chapter 10 Change Accumulation 115 • Because you are running n-way sharing or using/DBR NOFEOV
If you are running sharing (or take databases offline with/DBR NOFEOV
and then run batch work), you will have overlapping logs with updates for the same databases. The log records in recovery have to be in timestamp order, so you have to sort them prior to recovery. To do this you either use change accumulation/CHANGE ACCUMULATION PLUS or BMC Software's RECOVERY PLUS (which also sorts log records).
Note: Even if you are not using sharing, you are recommended to run a log sort process prior to recovery—I have come across scenarios where not using DBRC and not sorting logs leads to database corruption.
Why Should I Use CAGRPs?
If you run change accumulation without DBRC, then you code up control statements to say which database data sets should be accumulated together in one execution. Hence, you can accumulate all of them or you can do a subset at a time.
With DBRC, you have to define one or more CAGRPs. A CAGRP is simply a list of the database data sets you wish to accumulate together in one execution of change accumulation. You can have one group with all the database data sets in it or you can have multiple groups.
The reasons for having multiple groups are: • Faster recovery
Having groups means that each of the change accumulation files will be smaller and, hence, the recovery utility has less data to read.
• Parallel recoveries
If you have multiple groups, then you can run parallel recovery jobs—one for each group.
• Faster change accumulations
Each change accumulation execution will be quicker as there is less data to sort. This also has major benefits in terms of SORTWRK space—lots of small sorts run much faster and use much less space than one big sort.
Change Accumulation Groups
Group Rules (OK?)
A change accumulation group is a collection of database data sets processed in a given execution of change accumulation. Change accumulating
everything usingDB0*ALL is not possible with DBRC. Change accumulation is always run on a group basis (the group can, of course, contain all your database data sets) when using DBRC.
A single change accumulation job cannot handle a mixture of registered and unregistered databases. A given database data set can only belong to a single change accumulation group.
A change accumulation group in IMS V2 can contain up to 1024 members (= database data sets). In V6, this was increased to 2000. TheADD and
DELETEoperands on theCHANGE.CAGRPcommand allow you to add new members to an existing change accumulation group or delete members from a change accumulation group without having to delete the entire change accumulation group. You are recommended to copy any member you move or add—if you don’t, then the next time you run change accumulation for that group, it will pull all the logs in again to give itself a valid change accumulation output data set.
Do not change the members of aCAGRPwhile a change accumulation for this group is running. It corrupts the CA record in RECON!
The main problem with the standard change accumulation utility is the following:
Assume that there are 600 database data sets accessed by the online system. You define six change accumulation groups with 100 in each because that is the way your applications split down. Change accumulation is basically a sort, and it is more efficient to run six small sorts than one big one. This means that to change accumulate all of the database data sets, you must run change accumulation six times—once for each group. Unfortunately, DBRC is not clever enough to allow these to run in parallel, and each change accumulation needs a pass of the logs. If a single change accumulation group with 600 members is defined, the logs are only processed once, but the sort is not nearly as efficient and uses all your sort workspace. Hence, many
customers drop the idea of running change accumulation at all, or only in the event of recovery, which is unfortunate as regular change accumulation can decrease the need for image copy and speed up recoveries.
The solution to this problem is BMC Software’s CHANGE
ACCUMULATION PLUS, which handles multiple groups in parallel with one pass of the logs. In a recent test, CHANGE ACCUMULATION PLUS handled 96 input logs with 10 CAGRPs in 1.25 hours. The standard utility required 20 hours for each group.
Change Accumulation Rules
BMC Software, Inc., Confidential and Proprietary Information
Chapter 10 Change Accumulation 117
Change Accumulation Rules
When using the standard utility, useGENJCL to generate the job because every time change accumulation is run, the JCL is different. With BMC Software products, there is no need to useGENJCL—see “GENJCL and BMC Software” on page 12.
Logs are not included as input to a change accumulation group if they were created prior to the latest image copy.DB0 control statements are needed for each member in the change accumulation group. These are created for you by DBRC and include purge times. The purge time is equal to the latest image copy time. Any log records older than the purge time are thrown away, because these changes are already on the image copy; this way change accumulation is more efficient.
Warning! Do not touch these purge times or try to set them yourself. If you put the wrong purge time in, you may throw away records required for recovery and corrupt your database.
When change accumulation runs successfully, it creates a change
accumulation record. This record contains information such as the change accumulation data set name and VOLSER(s). It also records which log volumes participated in this particular change accumulation.
You should modify the skeletal JCL that is provided with DBRC. The skeletal JCL provided requires a tape drive for every tape volume that change accumulation reads. Use the UNIT=AFF technique to reduce the number of tape drives required. For example:
//DUMMYDD DD DSN=DUMMY.TAPE.%time,UNIT=(TAPE,,DEFER),DISP=NEW //DFSULOG DD DSN=UTILITY.%logdsn,UNIT=AFF=DUMMYDD,....
Figure 41 UNIT=AFF in CAJCL
If you are using CHANGE ACCUMULATION PLUS, then you are
recommended to use dynamic allocation in the JCL and all of this is handled for you automatically.
If you are using Fast Path, you need to update theID control statement in the skeletal JCL. See the Utilities Reference manual for details.
DBRC does not record any data set(s) created by theDB1 control statement(s). It is recommended you use RLDSs instead. See Chapter 7, “Bad Data Sets” for instructions on what to do if there is a bad (unreadable) RLDS or change accumulation data set.
Change Accumulation Strategies
Change Accumulation Strategies
There are various change accumulation options open to you. The one you choose depends on your environment, volatility of databases, criticality of recovery, etc.
• Regular change accumulation
This change accumulation option provides rapid recovery, but requires a regular workload. Keep groups to a minimum, unless you have
CHANGE ACCUMULATION PLUS.
• Run change accumulation only in the event of recovery
The overall recovery time is longer than the previous case, because you have to run change accumulation first, but this option requires no regular change accumulation workload.
• Temp CAGRP
Combine this with the previous option. Only define a group when required, run change accumulation, run recovery, and delete the group. • Do not run change accumulation
Use logs in recovery. Recovery will be much longer because logs use the DL/1 buffer handler (applying each change individually) whereas change accumulation uses native access methods.
Also consider BMC Software’s RECOVERY PLUS product, which accepts image copy, change accumulation and log input, and is much faster than the IMS recovery utility. See Chapter 12, “BMC Software and DBRC” for more information about RECOVERY PLUS.
Common Problems
One problem with DBRC is that if the situation changes between generating the JCL and executing the JCL, DBRC may object to your job and abend it (RC=8). An example of this is if you generate JCL for change accumulation and then before the job starts to execute, the databases are image copied. DBRC now decides there is nothing to accumulate and stops the job. The moral here is to run your change accumulations and then trigger off your image copies. Again, this can be avoided if you use CHANGE
IMS V3 Changes
BMC Software, Inc., Confidential and Proprietary Information
Chapter 10 Change Accumulation 119 One parameter that causes confusion is theCATIME parameter. You can use this to change accumulate up to a certain time. You cannot use this parameter to go beyond an image copy. You can only use it to change accumulate a subset of logs that have not been accumulated yet.
Figure 42 CATIME Flow
For example, you image copy a database (IC1), then you update it on LOG1 and LOG2. Now you image copy it again (IC2) and update it on LOG3 and LOG4. If you tried to do aGENJCL.CA CATIME to the end of LOG1, it would say there is nothing to accumulate because you have image copied the database.
You could useCATIME to the end of LOG3 or LOG4. The only way you can change accumulate to the end of LOG1 is to mark IC2 asINVALID. Now DBRC says none of the logs has been accumulated, and the database has not been copied, so it is valid to run a change accumulation.
See also “DBRC Log Selection” on page 110 and Appendix D, “IMS Change Accumulation Utility” for rules of log selection and details of spill records.
IMS V3 Changes
The recovery utility was rewritten in IMS V3 for Fast Path DEDBs. Prior to V3, the recovery utility would include all DEDB change records it found on the input logs. With V3, the recovery utility ignores any incomplete chains. The change accumulation utility has also been changed. A CA created under V3 may contain a new type of record, representing uncommitted data (incomplete chains). DBRC lists the CA record as containing IN-DOUBTs. Subsequent change accumulation or recovery will find the rest of the chain on the next log.
This has implications on several areas covered later, namely/ERE failure, disaster recovery, and shadow databases.
IC1 Log 1 Log 2 IC2 Log 3 Log 4
No
BMC Software, Inc., Confidential and Proprietary Information
Chapter 11 Recovery 121
132
Chapter 11 Recovery
The major fault of the IMS recovery utility is that it only recovers one DBDS/area per job step. This means that you have to read the logs once for each DBDS/area. Change accumulation, as discussed in the previous chapter, can help in this process. However, as the recovery utility requests
EXCLUSIVE authorization and DBRC only allows one utility with EXCLUSIVE at a time to access a database (full function) you cannot recover multiple data sets or partitions within the same database at the same time with the standard IMS utility. Multiple areas can be recovered in parallel as DBRC authorization is at the area level for DEDBs.
This chapter shows how recovery works and how to achieve parallelism.
Recovery Basics
Three types of recovery are supported by DBRC: full recovery, timestamp recovery, and track recovery.
• Full recovery is normally used for a media failure. Full recovery allows you to recover a database to its original state at the time of failure. • Timestamp recovery allows you to recover a database to its state at a
specified time.
• Track recovery (VSAM only) is used to recover a track in error. Track recovery will not be discussed in this document, because I’ve only ever found one customer who had tried it (and it didn’t work!).
You should always useGENJCL to create the JCL for a full recovery or timestamp recovery (unless you have BMC Software’s RECOVERY PLUS or RECOVERY MANAGER for IMS—see “GENJCL and BMC Software” on page 12). The JCL will be different every time you execute a recovery.
Full Recovery
You are allowed to put job steps on the front and the back of the particular step you wish to generate. For instance, as the first step of a recovery job you could generate an IDCAMS step to delete/define the relevant DBDS.
%DELETE (%DBDSAM NE 'VSAM')
//STEP0 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD DSN=ARM.IDCAMS.PDS(%DBDDN)
%ENDDEL
Figure 43 Sample JCL to Generate an IDCAMS Step to Define a DBDS
Full Recovery
Figure 44 Valid Recovery Points
The inputs to a full recovery are the latest image copy, the latest change accumulation (if one exists), plus any required logs. DBRC checks the logs to determine if a merge situation exists (discussed below). TheGENJCL, or the utility itself, will fail if a merge is required. In the case of a failure, run change accumulation first.
BMC Software’s RECOVERY PLUS performs not only the recovery, but in the same pass of the inputs (image copy, change accumulation, and logs) performs any necessary merge, performs an image copy, checks the database (using BMC Software’s POINTER CHECKER PLUS® or FAST PATH ANALYZER/EP™), and rebuilds the primary and secondary indexes (using BMC Software’s SECONDARY INDEX UTILITY/EP). It does this for multiple DBDSs/areas in parallel with one pass of the input data sets, and can recover multiple data sets or partitions in the same database in parallel. It also contains a facility to execute the relevant member(s) of an IDCAMS PDS to delete and define the database data sets.
/DBR Batch Job
Can recover to:
Previous IC + online logs New IC New IC +
batch log Input:
Online
Full Recovery
BMC Software, Inc., Confidential and Proprietary Information
Chapter 11 Recovery 123 BMC Software’s RECOVERY MANAGER for IMS will create and optimize RECOVERY PLUS and IMS recovery utility JCL for an entire group of databases.
Merge Needed
DBRC recognizes when two or more overlapping logs exist, both containing changes for one or more databases. This happens in block-level sharing and in non-sharing situations where you take a database offline with theNOFEOV
parameter and then update it in batch. You cannot input the logs directly to recovery because recovery checks timestamps, which are now out of
sequence. So change accumulation must be run first to sort the records in the right order. See Chapter 15, “IMS and the TOD Clock” and Appendix D, “IMS Change Accumulation Utility” for details of how it does this. If you try to runGENJCL.RECOV, DBRC will tell you that a merge is required and does not generate the recovery JCL.
As stated above, RECOVERY PLUS does the merge for you, so there is no need to run change accumulation prior to the recovery.
Recovery Authorization
Recovery requests EXCLUSIVE authorization. For DL/1 databases, the first thing that happens is theRECOVERY NEEDED flag and counter in RECON are turned on (if not on already). Fast Path areas can only be recovered if they are flagged asRECOVERY NEEDED. BMC Software’s RECOVERY MANAGER for IMS automates this process for Fast Path areas.