6 Database Backup and Recovery

6.4.1 External Data Mover

On z/OS, an External Data Mover (EDM) implementation is provided for performing RMAN-initiated data movement and backup maintenance activity. EDM runs as a separate z/OS address space, freeing the Oracle database server address space from system resource conflicts (such as tape device allocation and mounting) and from the processing demands of bulk data movement that are associated with backup and restore operations. Priorities or WLM (Workload Manger) goals of the EDM address spaces can be set as desired, separate from those of Oracle server address spaces.

RMAN ALLOCATE CHANNEL commands must specify "EDM0" as the channel type to start an EDM address space. The only other RMAN channel type allowed with a z/OS server is DISK. Allocating a DISK channel does not start an EDM address space. A DISK channel can create and read only VSAM LDS backups on direct access storage devices, and the processing occurs entirely within the Oracle server address space. An EDM channel can process backups that are physical sequential (DSORG=PS) data sets on either tape or direct access storage.

Starting and stopping EDM is done automatically by the Oracle server that hosts an RMAN session. Each RMAN ALLOCATE CHANNEL command starts a separate EDM address space on the same z/OS system as the host server. The EDM address spaces are system address spaces (similar to started tasks). Each EDM address space executes the Oracle EDM program ORAEDM.

RMAN backup and restore requests are forwarded from the target instance to EDM for processing. Each EDM can process one set of backups or restores or one proxy operation at a time. If your RMAN script allocates multiple EDM channels, RMAN distributes operations over the multiple EDM address spaces automatically. This concurrency requires asynchronous interaction between the RMAN client and the target instance and is supported only when you use TCP protocol. If you run RMAN on z/OS and connect to the target instance with XM protocol, concurrent operations across multiple EDM channels is not possible.

Before you can use RMAN to perform EDM-type operations on a z/OS system, you must set up a JCL procedure for running EDM address spaces. This procedure must be installed in a system procedure library. The JCL EXEC and DD statement requirements for this procedure are discussed in the section "EDM JCL and Parameters" . You can give the procedure any name that you desire, as long as it does not conflict with another procedure or with any subsystem that is defined to z/OS. You will need to know the name when you code an RMAN ALLOCATE CHANNEL command.

You might need to discuss EDM security requirements with your system security administrator. The EDM address spaces must be able to create and open backup data sets using data set names that you specify as part of an RMAN script. This might dictate taking actions to associate a z/OS authorization id with the EDM procedure.

6.4.2 Providing a Snapshot Control File

Certain RMAN synchronization functions require a snapshot control file, which is basically a copy of the Oracle database control file that you create with an ALTER DATABASE statement. By default, a z/OS Oracle server expects this file to be specified via a SNAPCF DD statement in the server region JCL. Of course, you cannot supply this DD statement until the associated z/OS data set exists, so if you want to rely on the default snapshot identification, then you must go through a 2-step process as described here. (Alternatively, you can use the SET SNAPSHOT CONTROLFILE NAME command in an RMAN session to specify the snapshot file by its data set name rather than by a DD name.)

To create the snapshot control file, start up the Oracle server and issue an ALTER DATABASE command similar to the following:

ALTER DATABASE BACKUP CONTROLFILE TO 'ORACLE.V10G.SNAP.CTL';

You can use any valid data set name (inside the single quotes) that conforms to the standards of your installation. In most cases, you will want to use the same high-level qualifiers that you use for other files that are part of this database. After this statement completes successfully, you will have created a snapshot control file with the specified data set name. Note that the file management parameters for the DBCT group (specified via the ORA$FPS DD statement) affect the way that this data set is created by the server. If you wish, you can pre-allocate the snapshot control file with your own invocation of IDCAMS. If you do so, make it the same size as your existing control file and include the word REUSE after the quoted name in the ALTER DATABASE statement.

Now shut down the Oracle database, stop the associated OSDI service, and add a SNAPCF DD statement to the service JCL procedure similar to the following:

//SNAPCF DD DISP=SHR,DSN=ORACLE.V10G.SNAP.CTL

Start the OSDI service and startup the Oracle database. Now your instance has a snapshot control file with the expected default identification.

6.4.3 Identifying Backups

Backups created with RMAN are cataloged z/OS data sets. A separate data set is produced for each copy of each backup piece. You specify the data set name for each backup using the FORMAT parameter of the RMAN BACKUP command.

Although you can specify a fixed z/OS data set name for FORMAT, the parameter is designed to be used as a template: various substitution variables (identified by a "%" prefix) can be included in the FORMAT string, and these are replaced with specific values each time the RMAN script executes.

You can use any of the substitution variables shown in Table 6-1 as portions of a template data set name in order to form distinct, valid z/OS data set names:

You can also use Oracle Database for z/OS system symbols (identified by a "&" prefix) to form parts of the data set name. This allows a single FORMAT string to produce distinct backup data set names over multiple pieces and copies, and over multiple uses of the same RMAN script. Refer to Appendix C, "Oracle Database for z/OS System Symbols", for more information.

When you code the FORMAT parameter, you should combine appropriate high-level data set name qualifiers, %u, other RMAN substitution variables, and Oracle Database for z/OS system symbols to form a complete, meaningful data set name. Both RMAN substitution variables and Oracle Database for z/OS system symbols are translated into their current values as the BACKUP command is processed at the server. The Oracle server saves the names of backups in the RMAN catalog or in the database control file, so you do not need to supply, or even know, the names of backups in order to perform an RMAN RESTORE.

The following example is a more complex FORMAT parameter for Oracle Database for z/OS:

FORMAT '&ORAPREFD..BKUP.%d.%u.P%p.C%c'

Variables in the previous example are defined, as follows:

A data set name that is produced from this format specification might look as follows:

ORA3ADBF.BKUP.ORA3DB.G6ENPJ03.P3.C1

6.4.4 Maintaining EDM Backups

The data set name of a successfully-created RMAN backup is always cataloged in the z/OS system catalog structure. When RMAN is told to delete a backup that is no longer needed, EDM invokes the z/OS IDCAMS utility and passes it a DELETE command for the data set. If the backup is a disk data set, then DELETE uncatalogs the data set and scratches it from the disk volume. If it is a tape data set, then DELETE only uncatalogs the data set. If the backup was a disk data set, and if it has been migrated by DFSMShsm, then the DELETE command logically deletes the migrated copy without recalling it to disk.

When backups are taken directly to tape, the tape volumes must not be reused as long as the backup remains known to RMAN, in other words, as long as the backup is cataloged. The easiest way to ensure this, if you use z/OS tape management software, is to specify "catalog retention" for tape backups. In this case, the tape management system will not recycle the tape volumes as long as they are associated with a cataloged data set name. How you specify catalog retention for a tape data set depends on the tape management software that you are using. If you are using IBM's DFSMSrmm, catalog retention is specified as a retention policy. Such policies can be imposed based on the data set name or on a DFSMS management class. For further information, refer to the IBM DFSMSrmm documentation or to the documentation for the tape management software that your system uses.

6.4.5 Proxy Backup Identification

When you use RMAN proxy backup, one or more whole database files is backed up in a single invocation of the IBM DF/DSS utility running in an EDM address space. RMAN requires that each copied database file in such a backup be logically accessible for for restore processing and for possible deletion.

The backup created by DF/DSS during proxy operation is a single sequential z/OS data set on one or more tape volumes. The name of this data set is not a backup file name; it is controlled instead with the EDM_TAPEDSN file management parameter. Although this is the real name of the backup data set (written on the tape's standard label) this data set name is not cataloged in the z/OS system catalog. Instead, each backup piece name is cataloged. Thus, on completion of a proxy backup of ten datafiles, you will have ten different entries in your z/OS catalog pointing to the same set of tape volumes.

During proxy restore, EDM issues a z/OS LOCATE macro using a backup piece name to determine the tape device type and volumes required for the DF/DSS restore. When DF/DSS executes, EDM provides DF/DSS control statements to select the particular backup pieces to be restored. Thus, the z/OS catalog entry for any proxy backup piece must persist in order for that backup piece to be usable in a proxy restore.

Conversely, when deleting a logical backup piece during RMAN maintenance processing, the associated z/OS catalog entry is deleted. It is possible for some of the files backed up in a proxy backup to be deleted in this way and others not. As long as any backup pieces remain cataloged the proxy backup should be considered viable and the associated tape volumes not scratched or recycled. When the last backup piece is logically deleted and there are no z/OS catalog entries referring to the tape volumes, the tapes can be reused.

6.4.6 EDM Backup Allocation Parameters

The z/OS-specific parameters for backup data sets are specified indirectly in an RMAN BACKUP command using the POOL parameter. The actual parameters are supplied in the EDM procedure in a file identified by an ORA$FPS DD statement. These parameters are coded the same as those for the database server region, discussed in "Server File Management Parameters" in Chapter 4, "Defining z/OS Data Sets for the Oracle Database". The ORA$FPS parameter file that you use with EDM will contain different file groups with different parameter settings than those used in the database server.

The file group identifier (in the EDM case) consists of the letter "P" followed by a three-digit decimal pool number. For example, if your backup script specifies "POOL 6", EDM searches the ORA$FPS file for parameters associated with file group P006. The POOL parameter defaults to zero, and EDM will therefore search for file group P000 if no POOL is coded in the script.

As with the database server, if the matching group cannot be found, then EDM will use parameters specified for the DFLT (default) group if they are included in the EDM's ORA$FPS file. If no DFLT group exists, then EDM will attempt to create the backup file with only a data set name, disposition, and (possibly) space parameters. This is likely to fail unless your installation uses automatic classification (ACL) logic to set suitable allocation parameters.

Additional details and an example ORA$FPS file are included in the section "EDM JCL and Parameters" below. The full description of ORA$FPS keywords and syntax is in "Database Region JCL" in Chapter 3, "Configuring a Database Service and Creating a New Database".

6.4.7 ALLOCATE CHANNEL Considerations

For a target server on z/OS, the ALLOCATE CHANNEL command must specify the channel TYPE as either DISK or "EDM0". The full quotes must be included when the EDM0 type is used. A DISK channel can be used to create and read only backups or copies that are VSAM LDS. This processing takes place within the target database server address space and does not involve EDM. Allocating a TYPE "EDM0" channel starts an EDM address space that can create and read backups that are physical sequential (DSORG=PS) data sets on disk or tape.

The EDM JCL procedure is identified using the PARMS parameter of ALLOCATE CHANNEL. At minimum, PARMS must specify the one-character to eight-character JCL procedure name for your EDM JCL procedure. The PARMS string can also include other fields that are valid for a z/OS START command, including a job identifier, JOBNAME or SUBSYS keywords, and procedure-specific JCL symbolic keywords. This string is case-sensitive and generally must be supplied in all uppercase letters. If apostrophes are required around a JCL symbolic parameter, then they must be doubled inside the outer apostrophes that are part of RMAN's PARMS parameter syntax.

The following example is an ALLOCATE CHANNEL command for an EDM whose JCL procedure, ORAEDM1, includes a procedure-specific keyword parameter FPS. A job identifier (EDMC1) is also included:

ALLOCATE CHANNEL C1 TYPE "EDM0" PARMS 'ORAEDM1.EDMC1,FPS=''FPS1''';

The PARMS parameter defaults to an empty string. If you omit PARMS on an EDM channel allocation for a z/OS server, then the command will fail.

If your backup script creates multiple backup pieces or copies, or if a restore script is going to call for multiple pieces or copies, then consider allocating multiple EDM channels to improve concurrency.

Each ALLOCATE command can specify the same EDM procedure name. If you specify a job identifier (or the JOBNAME parameter), Oracle Corporation recommends using a distinct identifier or jobname for each EDM channel in the script.

6.4.8 BACKUP Considerations

The BACKUP command parameters with z/OS-specific considerations are FORMAT and POOL. As discussed earlier, FORMAT must specify a string that will produce a valid, distinct z/OS data set name for each backup piece and copy after RMAN metasymbol and z/OS system symbol substitutions have been performed. FORMAT can also be specified in the ALLOCATE CHANNEL command, in which case the specified string applies to all backups that are created using the associated channel.

The POOL parameter is used to select backup file creation parameters that are supplied via the ORA$FPS DD statement in the EDM JCL procedure. The three-digit pool number (padded on the left with zeroes if necessary) is appended to the letter "P" to form the four-character file group identifier that is looked up in the EDM's ORA$FPS file. If POOL is omitted, it defaults to zero, which means EDM will attempt to locate parameters for file group P000.

6.4.9 Example RMAN Backup Script

run {
  allocate channel c1 type "EDM0" parms 'ORAEDM.EDM1';
  allocate channel c2 type "EDM0" parms 'ORAEDM.EDM2';
  backup database format 'ORA1.BKUPDB.%u.P%p.C%c' pool 6;
    }

6.4.10 EDM JCL and Parameters

To use EDM, you must have a JCL procedure in a system procedure library.

For example:

//EDMPROC  PROC FPS=EDMFPS 
//EDMPROC  EXEC PGM=ORAEDM,REGION=0M 
//STEPLIB   DD DISP=SHR,DSN=ORACLE.V10G.AUTHLOAD 
//ORA$FPS   DD DISP=SHR,DSN=ORACLE.ORA1.PARMLIB(&FPS) 
//SYSPRINT  DD SYSOUT=*
//PXYPRINT  DD SYSOUT=*

where:

6.4.11 File Management Parameters Example

The following example illustrates file management parameters containing file group definitions that might be used for backup and restore operations (both conventional and proxy). Note that Pool 0 is always used for restore operations. This causes FILE_GROUP(P000), or, if not defined, FILE_GROUP(DFLT) to be used:

*  Define file group P000 to be used for restore operations.
*  BUFNO() will be honored for only conventional (non-proxy)
*  restore operations; otherwise it is ignored.  This entry
*  works well for both conventional and proxy  restore
*  operations.
*  
FILE_GROUP(P000)
BUFNO(20)
RECALL(ALL)
*    
* Define file group P001 to use for conventional backup to
*  _disk_ operations.
*  
FILE_GROUP(P001)
BUFNO(20)
UNIT(SYSDA)
*  
*  Define file group P002 to use for conventional backup to
*  _tape_ operations.
*  
FILE_GROUP(P002)
BUFNO(20)
VOLUME_COUNT(255)
UNIT(3490)
*  
*  Define file group P003 to be used for proxy backup
*  operations.  These _must_ go to tape.
*   
FILE_GROUP(P003)
VOLUME_COUNT(255)
UNIT(3490)
DSS_COMPRESS(YES)
EDM_TAPEDSN(SYSBKUP.ORACLE.D&&LYYMMDD..T&&LHHMMSS)
*  
*  Define file group P004 to be used for conventional _and_ 
*  proxy backup to _tape_ operations. If proxy, BUFNO() will be
*  ignored; if conventional, DSS_COMPRESS() and EDM_TAPEDSN()
*  will be ignored.
*  
FILE_GROUP(P004)
BUFNO(20)
VOLUME_COUNT(255)
UNIT(3490)
DSS_COMPRESS(YES)
EDM_TAPEDSN(SYSBKUP.ORACLE.D&&LYYMMDD..T&&LHHMMSS)

Since parameters irrelevant to the task at hand are ignored, it is possible to define just one file group definition to cover all flavors of conventional and proxy backup and restore operations. Additionally, if the file group is designated as P000 or DFLT, as in the following example, lack of a pool specification on a backup command would cause the definition to be used (and restore operations would use it by default):

FILE_GROUP(DFLT)
BUFNO(20)
RECALL(ALL)
VOLUME_COUNT(255)
UNIT(TAPE)
DSS_COMPRESS(YES)
EDM_TAPEDSN(SYSBKUP.ORACLE.D&&LYYMMDD..T&&LHHMMSS)