Managing the CDS, a key task because of the critical data that the CDS contains. The following sections tell how to safeguard the CDS and how to recover it if you lose one or more copies of the CDS. For information about planning and creating the CDS, see Configuring HSC and VTCS.
If all copies of the CDS fail (that is, you lose the Primary, Secondary, and Standby copies), you must restore the CDS from a backup. You can back up the CDS using non-ELS facilities such as disk mirroring, third party backup software such as Fujitsu ARCS and Fujitsu DARCV, or third party Point-In-Time Copy software such as IBM FlashCopy. Oracle, however, does not recommend these methods, as they do not guarantee CDS consistency and integrity.
Instead, Oracle recommends to create a snapshot backup using the HSC BACKUP utility.
Oracle recommends that you back up the CDS at least daily. If using CDS Logging, you should also run a Log File Offload immediately after you back up the CDS so that during recovery, you can select the log offload file that corresponds to the backup file you use for recovery.
You should also back up the CDS before configuration changes and other significant events, including, but not limited to:
Running the SLUADMIN SET utility
Running the VTCS CONFIG utility
Moving a CDS
Expanding a CDS
Merging CDSs.
Running the BACKup utility:
Allocate the SLSBKUP data set.
It should be slightly larger than the CDSs. The size depends upon the number of discrepancies found. However, a recommended size is five percent larger than the current CDS.
The backup data set is formatted as RECFM=F, BLKSIZE=4096. The logical record length may be LRECL=0. In this case, LRECL=0 indicates to default to the block size.
Run the BACKup utility.
The CDS is placed in a reserve state only long enough for the data to be copied to the SLSBKUP data set. No other functions can access the CDS data sets during backup processing:
If HSC is not active, you must identify the primary, secondary, and standby CDSs to be used for the backup by specifying the SLSCNTL, SLSCNTL2, and SLSSTBY DD statements in the JCL.
If the HSC is active and you identify the primary, secondary, and standby CDSs to be used for the backup by specifying the SLSCNTL, SLSCNTL2, and SLSSTBY DD statements in the JCL, the DD statements are used even if HSC is active on the host where the utility is being executed. If the HSC is active and these DD statements are omitted, the data sets used by the active HSC on the host where the utility is being executed are used.
Example JCL for backing up the Primary, Secondary, and Standby CDSs:
//JOBBKUP job (account),programmer //S1 EXEC PGM=SLUADMIN,PARM=MIXED //STEPLIB DD DSN=hlq.SEALINK,DISP=SHR //SLSBKUP DD DSN=backup.dataset.name(+1),DISP=(NEW,CATLG,DELETE), // UNIT=SYSDA,SPACE= //SLSCNTL DD DSN=primary.dataset.name,DISP=SHR //SLSCNTL2 DD DSN=secondary.dataset.name,DISP=SHR //SLSSTBY DD DSN=standby.dataset.name,DISP=SHR //SLSPRINT DD SYSOUT=A //SLSIN DD * BACKUP
The HSC Transaction Logging Service is an internal HSC service that records information into one or, optionally, two Log Files. If all copies of the CDS fail (that is, you lose the Primary, Secondary, and Standby copies), recovery from a backup can be time consuming. When recovering from a backup, CDS logging can aid in resynchronizing the CDS with the data content of the VSM subsystem. If you are initially setting up logging in your configuration, see Configuring HSC and VTCS. The following sections tell how to manage CDS Logging.
Note:
Recovery using log files involves an analysis of the log data and construction of the required MVC audit statements to restore access to the latest versions of data. This does not recover the CDS to its exact state before the failure! For example, a VTV can exist on multiple MVCs. The audit recovers access to all copies of that VTV, but the copies may not be on exactly the same MVCs as before a CDS loss. The objective of CDS logging is to recover access to data, which is not a bit by bit CDS recovery!You need to periodically offload log files to keep them from filling up, which stops logging. Here are some Best Practices for doing so:
Set up a PROC to periodically offload the log files. Experimenting for a while to see how long it takes for the log file to fill under normal or peak operations, and then run log offload at that interval.
Also consider setting up your auto-ops package to intercept the SLS1781E message, which is displayed starting at 70% full for the Log File data sets.
You should also schedule a log file offload to be run when you run your periodic CDS backup so that during recovery, you can select the log offload file that corresponds to the backup file you use for recovery.
If the CDS is lost (all three copies are gone) or unreliable for any reason, do not attempt to offload the log file, instead see "Restoring the CDS."
If you need to expand your log files, or re-allocate them for any reason, do the following:
Create and format new log files.
The size of the allocated log files depends on the number of transactions your system generates, as well as the frequency of performing the offload. Oracle suggests you allocate and activate some test log files and determine the rate at which they fill before determining the size of the production log files.
Sample JCL:
//FMTLOG JOB (account),REGION=1024K //S1 EXEC PGM=SLUADMIN,PARM=MIXED //STEPLIB DD DSN=hlq.SEALINK,DISP=SHR //SLSLOG1 DD DSN=hlq.CDSLOG1,DISP=(,CATLG,DELETE), // UNIT=SYSDA,SPACE=(CYL,100) //SLSLOG2 DD DSN=hlq.CDSLOG2,DISP=(,CATLG,DELETE), // UNIT=SYSDA,SPACE=(CYL,100) //SLSPRINT DD SYSOUT=* //SLSIN DD * FMTLOG
Run SET LOGFILE to specify the new log files.
Sample JCL:
//SETLOG JOB (account),REGION=1024K //S1 EXEC PGM=SLUADMIN,PARM=MIXED //STEPLIB DD DSN=hlq.SEALINK,DISP=SHR //SLSPRINT DD SYSOUT=* //SLSIN DD * SET LOGFILE(hlq.CDSLOG1,hlq.CDSLOG2)
Run OFFLOAD LOGFILE to offload the old log files.
//JOBOFFL job (account),programmer //S1 EXEC PGM=SLUADMIN,PARM=MIXED //STEPLIB DD DSN=hlq.SEALINK,DISP=SHR //SLSOFFLD DD DSN=offload.dataset.name(+1),DISP=(NEW,CATLG,DELETE), // UNIT=SYSDA,SPACE= //SLSCNTL DD DSN=primary.dataset.name,DISP=SHR //SLSCNTL2 DD DSN=secondary.dataset.name,DISP=SHR //SLSSTBY DD DSN=standby.dataset.name,DISP=SHR //SLSPRINT DD SYSOUT=A //SLSIN DD * OFFLOAD LOGFILE
This automatically causes HSC to switch to the new log files.
As described in "Backing Up the CDS," if you specify multiple CDS copies, HSC automatically switches to another CDS copy if the Primary CDS fails. Why would you want to manually switch to another CDS copy? Basically, you do so in either of the following situations:
You want to move the CDS and/or expand it.
After an HSC automatically switches CDS copies, you want to delete the old Primary, reallocate it, and repopulate it. Once you enable the reallocated Primary CDS, HSC recopies the valid CDS data to it from a backup copy.
You use the CDS ENABLE/DISABLE commands to switch, expand, or move CDS copies. For more information, see ELS Command, Control Statement, and Utility Reference.
You can use the CDS EXpand command to add VOLPARM data, VTCS CONFIG data, or vaulted volume data to the CDS. To make other configuration changes that may require increasing the size of the CDS (such as adding new ACSs and LSMs when the LIBGEN did not use the FUTRACS and FUTRLSM parameters) you must use other methods instead of CDS EXpand. See ”Reconfiguring a TapePlex” in Configuring HSC and VTCS for more information.
Caution:
Oracle recommends backing up all CDS copies before issuing the CDS EXpand command. Failures during the expand operation usually cause the CDS to become unusable. It is important to back up the CDS before invoking the CDS EXpand command to make sure that the latest copy of the CDS is available in case of a failure during the expand operation.The following are guidelines for CDS EXpand:
HSC must be active and tape activity can be ongoing when using CDS EXpand.
Do not issue CDS Enable and/or Disable commands simultaneously from multiple hosts. Doing so can cause the HSC to issue error messages. If this occurs, refer to ELS Messages and Codes to determine if user action is required.
Update your CDSDEF control statement in the HSC PARMLIB as necessary to make it consistent with the results of any expand operation.
Restoring the CDS to a larger pre-allocated data set cannot be used to dynamically expand a CDS; the additional space is not formatted and cannot be used as is
Oracle recommends that all CDSs be allocated with the same amount of DASD space. The usable space in the CDS is determined by the number of 4096 byte blocks that fit in the CDS with the smallest DASD space allocation.
To expand all CDSs:
Disable each CDS (one at a time) with the CDS DISABLE command.
Reallocate each CDS with a larger primary space quantity.
Do not specify a secondary space quantity; all CDSs must have only a single extent.
Re-enable each CDS with the CDS ENABLE command.
Enter the CDS EXpand command.
All CDSs that are known to the HSC (that is, are enabled) are expanded at the same time with a single invocation of the CDS EXpand command.
CDS names do not change as the result of a CDS automatic or manual switch. You can use a sequence of CDS Disable and Enable commands to restore the order and match the data set names to their expected roles.
Enter a Display CDS command to view the current status and assignment of the CDSs:
SYS000001 = ELS.SYSCNTL2 PRIVOL = PROD02 FLAGS(40) ACTIVE SYS000002 = ELS.SYSCNTL SECVOL = PROD01 FLAGS(40) ACTIVE
The display shows that SYSCNTL (the original Primary) is now the Secondary and SYSCNTL2 (the original Secondary) is now the Primary.
Disable the current Primary:
CDS DISABLE PRIMARY
ELS.SLSCNTL2 is disabled, and ELS.SLSCNTLT becomes the new Primary.
Re-enable ELS.SLSCNTL2 as the new active Secondary:
CDS ENABLE DSN(ELS.SLSCNTL2)
Enter Display CDS command to confirm that the CDSs are rotated:
SYS000001 = ELS.SYSCNTL PRIVOL = PROD02 FLAGS(40) ACTIVE SYS000002 = ELS.SYSCNTL2 SECVOL = PROD01 FLAGS(40) ACTIVE
There are two methods for renaming a CDS:
Use the CDS Disable and Enable commands to do the rename without stopping HSC.
Stop HSC and use the BACKup and RESTore utilities to do the rename.
The obvious disadvantage to using the BACKup and RESTore utilities is that HSC must be stopped; however, the advantage is that a backup of the CDS is created.
To rename a CDS using commands:
Disable the CDS you want to rename on all hosts.
For example:
CDS DISABLE DSN(ACS.DBASEOLD)
Rename the data set that contains the CDS.
For example, rename ACS.DBASEOLD to ACS.DBASECPY.
Enable the CDS by its new name.
For example:
CDS ENABLE DSN(ACS.DBASECPY)
If the Enable command fails for the renamed CDS, CDS definitions are restored to what they were before the command was issued. Modify the CDSDEF control statement in the HSC PARMLIB to keep it consistent with the active CDS.
The CDS names are recorded in the Database Heartbeat (DHB) record. During HSC initialization, the data set names in the DHB are compared with the data set names specified on the CDSDEF control statement in the HSC PARMLIB.
If a data set name specified on the CDSDEF statement does not match any of the CDS names recorded in the DHB, that CDS is disabled. If all the specified CDSs are disabled, the HSC does not initialize. The specific assignment of enabled CDSs to the primary, secondary, and standby CDS(s) is made based on the CDS assignments recorded in the Database Heartbeat record.
If the CDS(s) needs to be renamed, use the HSC BACKup and RESTore utilities as described in the rename procedure below. Do not use MSP, TSO ISPF, or thirdparty utilities to rename the CDS(s) without running the BACKup and RESTore utilities.
To relocate a CDS:
Disable the CDS you want to relocate on all hosts.
For example:
CDS DISABLE DSN(ACS.DBASECPY)
Allocate a new data set with the appropriate CDS attributes.
For more information, see Configuring HSC and VTCS.
Enable the CDS the data set allocated in step 2:
For example:
CDS ENABLE DSN(ACS.DBASENEW)NEWLOC
Note:
MSP uses catalog services to resolve the volume and unit definitions, if not specified.If a rename or relocate operation fails, CDS definitions are restored to what they were before the command was issued. Modify the CDSDEF control statement to keep it consistent with the active CDS.
Assume that ACS.DBASECPY has been disabled and deleted (or uncataloged), and ACS.NOTCATLG has been allocated and cataloged. The following command relocates an uncataloged CDS copy:
CDS ENABLE DSN(ACS.NOTCATLG) NEWVOL(HSC001),NEWUNIT(ABC)
Modify the CDSDEF control statement to make it consistent with the CDS definitions in this command. If a rename or relocate operation fails, CDS definitions are restored to what they were before the command was issued.
In contrast with relocating a CDS using HSC commands or utilities, there are a number of third-party software products that allow disk data sets to be swapped from one location to another without affecting the users of those data sets. The HSC has been enhanced to dynamically update the unit address information stored in the CDS within a few seconds after a TDMF, FDRPAS, or P/DAS swap operation takes place so that HSC and VTCS utilities always use the new CDS location.
This enhancement does not provide an unrestricted ability to move a CDS. Moving a CDS by a means other than a PPRC or swap operation requires a change to the VOLSER of the CDS. The traditional process of a SLUADMIN BACKup and RESTore of the CDS must be used to reset both unit address and volume serial information if the VOLSER of the CDS changes.
If all copies of the CDS fail (that is, you lose the Primary, Secondary, and Standby copies), you must restore the CDS from a backup. If you lose a single copy of the CDS (and you have multiple copies), you can use the CDS ENABLE/DISABLE commands to continue running on the valid copy and recreate the copy that has the error. For more information, see "Manually Switching to Another CDS Copy."
Caution:
If you think you have lost all copies of the CDS, contact Oracle Software Support to ensure that restoring the CDS from a backup is actually required and to assist, if necessary, with the restore process.Before doing a restore, you should either do a new backup of the corrupt CDS, or rename all the current CDS copies to preserve them for later analysis.
Note:
The RESTORE process is identical to SLUADMIN BACKUP, which is used to create the CDS backup.
Before running a restore, you should either run a new backup of the corrupt CDS, or rename all the current CDS copies to preserve them for later analysis.
To restore the CDS from a backup copy:
If HSC is still active on any host, stop the active HSC systems.
If logging is enabled, continue with step 2 to resynchronize VSM data. Otherwise, go to step 3.
If the CDS can be accessed, run the normal log file offload job.
This offload is to capture the VSM activity since your last offload.
//JOBOFFL job (account),programmer //S1 EXEC PGM=SLUADMIN,PARM='execution parameters' //STEPLIB DD DSN=hlq.SEALINK,DISP=SHR //SLSOFFLD DD DSN=offload.dataset.name(+1),DISP=(NEW,CATLG,DELETE), // UNIT=SYSDA,SPACE= //SLSCNTL DD DSN=primary.dataset.name,DISP=SHR //SLSCNTL2 DD DSN=secondary.dataset.name,DISP=SHR //SLSSTBY DD DSN=standby.dataset.name,DISP=SHR //SLSPRINT DD SYSOUT=A //SLSIN DD * OFFLOAD LOGFILE
If the CDS cannot be accessed, offload the log file using the LOGDSN parameter. The normal CDS logging process uses log information stored in the CDS. If the CDS is inaccessible, then you need to use the logging information that is in the current log file, which you specify with the LOGDSN parameter.
//JOBOFFL job (account),programmer //S1 EXEC PGM=SLUADMIN,PARM='execution parameters' //STEPLIB DD DSN=hlq.SEALINK,DISP=SHR //SLSOFFLD DD DSN=offload.dataset.name(+1),DISP=(NEW,CATLG,DELETE), // UNIT=SYSDA,SPACE= //SLSPRINT DD SYSOUT=A //SLSIN DD * OFFLOAD LOGFILE LOGDSN(hsc.log1)
Note:
If the CDS cannot be accessed, note that if you attempt to run theOFFLOAD LOGFILE utility after restoring the CDS but without using the LOGDSN option, the offload may not succeed, or may create an erroneous log offload file.Restore the CDS from the last good backup.
//JOBREST job (account),programmer //S1 EXEC PGM=SLUADMIN,PARM='execution parameters' //STEPLIB DD DSN=hlq.SEALINK,DISP=SHR //SLSBKUP DD DSN=backup.dataset.name(0),DISP=SHR //SLSCNTL DD DSN=primary.dataset.name,DISP=SHR //SLSCNTL2 DD DSN=secondary.dataset.name,DISP=SHR //SLSSTBY DD DSN=standby.dataset.name,DISP=SHR //SLSPRINT DD SYSOUT=A //SLSIN DD * RESTORE
Caution:
It is critical that your RESTORE JCL specifies all HSC data sets in use (Primary, Secondary, Standby).For more information, see ELS Command, Control Statement, and Utility Reference.
Note:
Special precautions should be taken for running BACKup and RESTore when local/remote-linked libraries run CDSs independent of each other. These precautions should be followed when the link connecting the local and remote libraries is disrupted. See ELS Legacy Interfaces Reference for more information.If you are using log files for recovery, continue with step 4. Otherwise, go to step 9.
Ensure that the restored CDS is referencing the correct log file information:
Run SET LOGFILE(OFF).
//SETLOG JOB (account),REGION=1024K //S1 EXEC PGM=SLUADMIN,PARM='execution parameters' //STEPLIB DD DSN=hlq.SEALINK,DISP=SHR //SLSPRINT DD SYSOUT=* //SLSIN DD * SET LOGFILE(OFF)
Run the FMTLG utility to reformat the log files.
//FMTLOG JOB (account),REGION=1024K //S1 EXEC PGM=SLUADMIN,PARM='execution parameters' //STEPLIB DD DSN=hlq.SEALINK,DISP=SHR //SLSLOG1 DD DSN=hlq.CDSLOG1,DISP=(,CATLG,DELETE), // UNIT=SYSDA,SPACE=(CYL,100) //SLSLOG2 DD DSN=hlq.CDSLOG2,DISP=(,CATLG,DELETE), // UNIT=SYSDA,SPACE=(CYL,100) //SLSPRINT DD SYSOUT=* //SLSIN DD * FMTLOG
Run SET LOGFILE again, specifying the names of the newly initialized log files.
//SETLOG JOB (account),REGION=1024K //S1 EXEC PGM=SLUADMIN,PARM='execution parameters' //STEPLIB DD DSN=hlq.SEALINK,DISP=SHR //SLSPRINT DD SYSOUT=* //SLSIN DD * SET LOGFILE(hlq.CDSLOG1,hlq.CDSLOG2)
Run the LOGUTIL command to generate a data set with the AUDIT MVC commands required for recovery and run the commands in that data set.
In the following example, assume that last known good CDS backup was taken on 5/12/2009 at 10 p.m:
The LOGIN statement specifies a DD statement for each offload log file, beginning with the log file created with the last known good backup and ending with the log file that you created in 2.
LOGUTIL GENAUDIT specifies RECVCMD as the DD name of the data set that contains the commands for recovery of the VSM data.
//JOBLOGR job (account),programmer,REGION=1024k //S1 EXEC PGM=SLUADMIN,PARM='execution parameters' //STEPLIB DD DSN=hlq.SEALINK,DISP=SHR //LOGIN DD DSN=offload.dataset.name(-2),DISP=OLD // DD DSN=offload.dataset.name(-1),DISP=OLD // DD DSN=offload.dataset.name(0),DISP=OLD //RECVCMD DD DSN=offload.dataset.genaudit,DISP=(,CATLG,DELETE), // UNIT=SYSDA,SPACE= //SLSPRINT DD SYSOUT=* //SLSIN DD * LOGUTIL FROMDATE(2009-5-12) FROMTIME(22:00:00) LOGDD(LOGIN) GENAUDIT COMMANDS(RECVCMD)
If LOGPOL=REQUIRED is currently specified in the VTCS configuration:
Specify LOGPOL=OPTIONAL in the CONFIG GLOBAL statement and run CONFIG to temporarily disable logging in the VTCS configuration. This is required to successfully execute the MVCMAINT commands while HSC/VTCS is not active.
Set the MVCs to be audited to read-only status:
Execute the MVCMAINT READONLY(ON) commands for the MVCs to be audited with HSC/VTCS inactive. This ensures that the MVCs are not used when HSC/VTCS is active.
//JOBAUDIT job (account),programmer,REGION=1024K
//S1 EXEC PGM=SLUADMIN,PARM='execution parameters'
//STEPLIB DD DSN=hlq.SEALINK,DISP=SHR
//SLSPRINT DD SYSOUT=*
//SLSIN DD *
MVCMAINT READONLY(ON) MVC( +
mvc1 +
mvc2 +
… +
mvcn +
)
If LOGPOL=REQUIRED is required in the VTCS configuration:
Specify LOGPOL=REQUIRED in the CONFIG GLOBAL statement and run CONFIG if LOGPOL=OPTIONAL was temporarily specified at step 6 (above).
Restart HSC on one hosts, but do not start tape activity.
To recover the non-VSM portion of the CDS, run SLUADMIN AUDIT on all ACSs.
//JOBAUDIT job (account),programmer,REGION=1024k //S1 EXEC PGM=SLUADMIN,PARM='execution parameters' //STEPLIB DD DSN=hlq.SEALINK,DISP=SHR //SLSPRINT DD SYSOUT=* //SLSIN DD * AUDIT ALL
Audit all VTSSs.
//JOBAUDITV job (account),programmer,REGION=1024k //S1 EXEC PGM=SLUADMIN,PARM='execution parameters' //STEPLIB DD DSN=hlq.SEALINK,DISP=SHR //SLSPRINT DD SYSOUT=* //SLSIN DD * AUDIT VTSS(VTSS0,VTSS1)
Run scratch synchronization.
Run SLUCONDB to synchronize HSC scratch status with the TMS(s). For more information, see ELS Command, Control Statement, and Utility Reference.
If you are using logging, audit affected MVCs using the recovery commands from the data set created in step 5.
//JOBRMVC job (account),programmer,REGION=1024k //S1 EXEC PGM=SLUADMIN,PARM='execution parameters' //STEPLIB DD DSN=hlq.SEALINK,DISP=SHR //SLSIN DD DSN=offload.dataset.genaudit,DISP=SHR //SLSPRINT DD SYSOUT=*
If you are not using logging, contact Oracle Software Support for assistance in determining which MVCs need to be audited.
Start HSC on all hosts.
Restart tape activity.