Skip Headers
Oracle® Database System Administration Guide
10g Release 2 (10.2) for IBM z/OS (OS/390)

Part Number B25398-01
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

6 Database Backup and Recovery

This chapter provides z/OS-specific details on Oracle features and techniques that are used to ensure database availability and correctness.

The following topics are included:

6.1 Overview

Before planning or attempting database backup or recovery, you should be familiar with the organization of an Oracle database as described in Oracle Database Concepts, with common database administration procedures covered in the Oracle Database Administrator's Guide, and with basic Oracle backup and recovery practices documented in the Oracle Database Backup and Recovery Book Set.

If you decide to use Oracle Recovery Manager (RMAN) for database backup and recovery, which is highly recommended, refer to the Oracle Database Recovery Manager Book Set. Finally, if you plan to implement a standby database, consult the Oracle Data Guard Concepts and Administration before reading the related material in this chapter.

6.2 Logging and Recovery

Recovery is the process of applying or reapplying database changes to reflect transactions which have been committed. Critical to the recovery process is the Oracle database redo log (or online log) of database changes that is written by the server as transactions are processed. As each log file or log file group is filled, the Oracle database switches to the next file or group in turn. When you run the database in NOARCHIVELOG mode, the process eventually wraps back around to the first log file or group, overlaying the data in that file. Most production Oracle databases run in ARCHIVELOG mode, which requires that filled logs be archived (copied to another file, called an archive log) before they can be reused. The archive logs are opened and read by the server in certain recovery situations.

On z/OS, archive logs are VSAM LDS similar to the other database files. Unlike control, database, and online log files, they cannot be pre-allocated and are always created by the server via invocation of the IDCAMS utility. This means that the server file parameters governing creation of archive logs (the DBAL file group specified in the ORA$FPS parameter file) are particularly important: these parameters must be specified so that archive logs can be created readily as needed. For additional information on the ORA$FPS parameter file, refer to "Server File Management Parameters" in Chapter 4, "Defining z/OS Data Sets for the Oracle Database".

The naming of archive log data sets is controlled by several init.ora file parameters whose z/OS-specific details are discussed in "Oracle Initialization Parameter Considerations" in Chapter 3, "Configuring a Database Service and Creating a New Database". You can specify that multiple archive copies are to be created in order to reduce the chances of losing an archive to media failure. The parameter conventions require you to supply one or more leading (left-hand) data set name prefixes, one for each copy. When you elect to create multiple copies, the respective prefixes must differ to avoid duplicate data set names, for example, "ORA1.ARCHLOG1." and "ORA1.ARCHLOG2.". A single additional parameter supplies a template for a data set name suffix that is used on all copies. Normally this suffix contains substitution symbols that are replaced with the logical log thread, sequence number, and reset logs ID, ensuring a unique data set name for each archive.

6.3 Backup and Recovery without Recovery Manager

As discussed in the Oracle Database Backup and Recovery Book Set, there are several approaches to backing up and restoring all or parts of an Oracle database independent of the Oracle server, using platform-specific utilities of your choice. On z/OS, this can be accomplished using a fast data mover such as IBM DFSMSdss or a comparable product. The Oracle database server requirements are met by any software that can backup and restore a VSAM linear data set without disturbing the contents or organization of the data. The restore can be to a different disk volume and physical location than was originally backed up, but it must create a valid ICF catalog entry for the cluster with the same high-allocated and high-used RBA characteristics as the original data set.

The key to performing independent backup of Oracle database data is making sure that the correct group of VSAM linear data sets is backed up as a logical set. Which data sets should be copied during backup depends on the type of backup you are doing. The various types of backups and the Oracle database files which comprise them are discussed in the Oracle Database Backup and Recovery Book Set.

One of the most common forms of independent backup is a tablespace backup, in which all of the files that make up a given tablespace are backed up as a set. This kind of backup can be performed while the Oracle server is running and has the tablespace online and in use. It therefore does not interfere with database availability and has little impact on application performance. When done in this fashion (called a "hot backup"), you must notify the Oracle database server of your actions immediately before and after the backup. This notification is done using SQL ALTER TABLESPACE statements. The easiest way to accomplish this is to implement the backup as a 3-step batch job in which the first and last steps execute SQL*Plus to issue the requisite SQL, and the middle step executes the data move. The data move step should be conditioned on successful execution of the first step, as shown in the following example:

//ORABKTS1 JOB 1,'Oracle Backup'
//PLUS1    EXEC PGM=SQLPLUS,PARM='/NOLOG',REGION=4M
//STEPLIB  DD DISP=SHR,DSN=ORACLE.V10G.CMDLOAD
//ORA$LIB  DD DISP=SHR,DSN=ORACLE.V10G.MESG
//SYSERR   DD SYSOUT=*
//SYSOUT   DD SYSOUT=*
//ORA@ORA1 DD DUMMY
//SYSIN    DD *
WHENEVER SQLERROR EXIT FAILURE
WHENEVER OSERROR EXIT FAILURE
CONNECT / AS SYSDBA
ALTER TABLESPACE ARREQ1 BEGIN BACKUP;
EXIT
/*
//BACKUP   EXEC PGM=ADRDSSU,COND=(0,NE,PLUS1)
//SYSPRINT DD SYSOUT=*
//BKUPDS   DD DISP=(,CATLG,DELETE),
//  DSN=ORACLE.ORA1.ARREQ1.BKF,
//  UNIT=(TAPE,,DEFER)
//SYSIN    DD *
 DUMP DATASET(INCLUDE(ORACLE.ORA1.ARREQ1.DBF*)) -
  OUTDD(BKUPDS)
/*
//PLUS2    EXEC PGM=SQLPLUS,PARM='/NOLOG',REGION=4M,COND=EVEN
//STEPLIB  DD DISP=SHR,DSN=ORACLE.V10G.CMDLOAD
//ORA$LIB  DD DISP=SHR,DSN=ORACLE.V10G.MESG
//SYSERR   DD SYSOUT=*
//SYSOUT   DD SYSOUT=*
//ORA@ORA1 DD DUMMY
//SYSIN    DD *
CONNECT / AS SYSDBA
ALTER TABLESPACE ARREQ1 END BACKUP;
EXIT
/*

In a recovery situation (following a media failure, for example), the Oracle server must not be accessing the logical structure that is being recovered. In the case of tablespace or individual datafile recovery not involving the SYSTEM tablespace, the server can be up and running, but the affected tablespace must be offline. For recovery of the SYSTEM tablespace or for full database recovery, the Oracle database instance must be shut down. You should restore all data sets comprising the entity that you are recovering, for example: all tablespace files for a tablespace that is to be recovered. Normally, you will restore using the original data set names of the files. If you change the data set names during restore, you will have to start the Oracle database server without opening the database (using STARTUP MOUNT) and issue ALTER DATABASE RENAME statements to update the Oracle database control file with the new names.

When all restores are completed and any required renaming has been done, you are ready to begin recovery as described in the Oracle Database Backup and Recovery Book Set. During recovery, the Oracle server will open and read all log data that has been written since the backup (that you restored) was taken. Usually this involves both archive logs and online logs. All of the required archive logs must be available during recovery. If you allow archive logs to be migrated by a product such as IBM DFSMShsm, then you must recall them to disk before Oracle attempts to open them.

6.4 Recovery Manager on z/OS

The Recovery Manager (RMAN) utility automates and simplifies backup and recovery operations. You provide RMAN an input script that directs backup or recovery processing and RMAN connects to the database being backed up or recovered (the target instance) to execute the script. The actual data movement for backup and restore is done by the target instance, not by the RMAN utility program. For more information on RMAN, refer to the Oracle Recovery Manager Book Set.

There are two major categories of RMAN backup and restore processing when RMAN is used with a z/OS target instance. If your RMAN script specifies a DISK channel, backup and restore uses VSAM LDS just like the ones comprising the database. If you use an EDM (External Data Mover) channel, which is unique to z/OS, backup and restore operations are executed in a separate, dynamically-started address space on the target system. With an EDM channel, discussed in the following section, backup and restore operations can use sequential (DSORG=PS) data sets on disk or tape. EDM also supports RMAN proxy backup and restore, invoking the IBM DF/DSS utility program to perform bulk data movement.

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 server, 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 server. 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:

Table 6-1 FORMAT Parameter Substitution Variables

Variable Description

%c

specifies the copy number of the backup piece within a set of duplexed backup pieces. If you did not issue the set duplex command, then this variable will be 1. If you issued set duplex, the variable identifies the copy number: 1, 2, 3, or 4.

%d

specifies the database name. Note: The database name substitution variables (%d and %n) use the database name specified in the CREATE DATABASE command (or in the init.ora parameter file). The database name can be up to eight characters long and must start with a letter (or #, $, or @) and only contain letters, numbers, the special characters #, $, @ or the hyphen ('-') in the second and subsequent positions to be valid as a standalone part of a data set name (as in 'ORACLE.BACKUP.%d'). If the database name starts with a number but is otherwise valid and is less than eight characters long, a letter (or #, $, or @) can be placed in the pattern before the %d (as in 'ORACLE.BACKUP.X%d'). Thus, if the %d will be used in the FORMAT string, care should be taken in choosing the database name in the CREATE DATABASE command to ensure that it is valid in a z/OS data set name.

%n

specifies the database name, padded on the right with 'X' characters to a total length of eight characters. For example, if PROD1 is the database name, then PROD1XXX is the padded database name. (See the note under %d, above.)

%p

specifies the backup piece number within the backup set. This value starts at one for each backup set and is incremented by one as each backup piece is created. The number will never exceed four digits (9999 maximum).

%s

specifies the backup set number. This number is a counter in the control file that is incremented for each backup set. The counter value starts at one and is unique for the lifetime of the control file. If you restore a backup control file, then duplicate values can result. Also, CREATE CONTROLFILE initializes the counter back to one. If this value exceeds 9,999,999, only the right seven digits of the number will be used. The number will be from one to seven digits long.

%t

specifies the backup set timestamp, which is a four-byte binary unsigned integer value derived as the number of seconds elapsed since a fixed reference time. The combination of %s and %t can be used to form a unique name for the backup set. The unsigned binary integer is formatted into a string in this format: Tsssssss. The sssssss is a base-32 representation of the number using the letters A-V and the numbers 0-9. The generated value will always be eight characters in length.

%u

specifies an eight-character name constituted by compressed representations of the backup set number and the time the backup set was created. This will always be eight characters in length and it will start with a letter so it will be valid within a z/OS data set name. Note: In Oracle8i, the variable was '.*%u' which generated '.Axxxx.Axxxx'. The '.*%u' is still accepted, but now generates '.xxxxxxxx' (just as if '.%u' were specified).

%D

specifies the current day of the month from the Gregorian Calendar in DD format.

%F

specifies that dbid (a numeric value that identifies an Oracle database), year, month, day and sequence be combined so that the generated name is unique and repeatable.

When %F is used in combination with another string or variable, the generated format is: Iiiiiiii.Dyymmdd.Sss.

The iiiiiii is a base-32 representation of the dbid using the letters A-V and the numbers 0-9 and will always be seven characters. The yy, mm, and dd are the year, month and day, respectively. The ss is a hexadecimal representation of the sequence.

When %F is used alone, it generates a complete data set name: &ORAPREFD..&ORASRVN..OBKCF.Iiiiiiii.Dyymmdd.Sss

In addition, when RMAN's control file autobackup feature is used, %F is the default format for the control file backup name.

%M

specifies the current month from the Gregorian Calendar in MM format.

%T

stands for year, month and day in the format YYMMDD. This will always be six characters in length. The first two characters of year are dropped (2008 becomes 08).

%U

specifies a convenient shorthand for &ORAPREFD..&ORASRVN..ORABKUP.%u.P%p.C%c that guarantees uniqueness in generated backup filenames. If you do not specify a format, RMAN uses %U by default. Note: For more information on &ORAPREFD and &ORASRVN, see Appendix C, "Oracle Database for z/OS System Symbols".

%Y

specifies the current year from the Gregorian Calendar in YYYY format.

%%


stands for % (i.e. %%Y is actually the string %Y).


Note:

Several of the substitution variables generate numbers only, and should not be used immediately after a period in the FORMAT string, or an invalid data set name will result. For example, %s generates a one-digit to seven-digit number. In a FORMAT string, a period and a letter (or #, $, or @) have to precede the %s to make it valid in a data set name (for example, 'ORACLE.BACKUP.S%s').

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:

Table 6-2 Variable Definitions for Code Example

Variable Definition

&ORAPREFD.

is replaced with the default data set name prefix (a server region parameter). Note that the system symbol, "&ORAPREFD.", has the required period terminator.

%d

is replaced with the Oracle database name.

%u

is replaced by a unique, 8-byte string.

%p

is replaced by the backup piece number.

%c

is replaced by the backup copy number.


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.5.1 Proxy Backup Restrictions

Proxy backup is designed for backing up entire database files, not for incremental backup. A single proxy operation on OS/390 can copy up to 255 files in a single invocation of DFSMSdss. If your proxy backup operation involves more than 255 files, it has to be divided across multiple RMAN channels or done in multiple RMAN scripts. For information on these techniques, refer to the Oracle Database Recovery Manager Book Set.

Only tape devices are supported for proxy backups on z/OS. Disk backups can be made with existing EDM facilities or the Oracle server itself.

6.4.5.2 Proxy Restore

Whenever it restores a backed up file, RMAN is designed to overwrite the target file. The target file will be overwritten even if you use RMAN's SET NEWNAME FOR DATAFILE syntax to rename the restored target file and even if a file with the new name already exists on disk. In contrast, DFSMSdss will refuse to restore a file that is being renamed if a file with the new name already exists on disk. Therefore when using proxy restore with DFSMSdss, you will need to manually delete any files with a new target name before beginning the restore. You will not need to delete any files if you restore to the original file.

For an example that illustrates file management parameters containing file group definitions that might be used for proxy backup and restore operations, refer to "File Management Parameters Example".

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.

Note:

The z/OS RMAN client cannot exploit multiple channels for concurrency when a protocol=XM connection to the database is used. Multiple channel concurrency may be achieved by establishing a TCP connection to the database.

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:

Table 6-3 JCL Procedure Descriptions

JCL Procedure Description

PGM=ORAEDM

identifies the External Data Mover program.

//STEPLIB

is normally included. It identifies the Oracle AUTHLOAD data set containing ORAEDM.

//ORA$FPS

is recommended. It specifies parameters that allow control over the creation, attributes, and processing of backup data sets by EDM. If omitted, internal and system defaults are used.

//SYSPRINT

is required. Normally a JES spool data set, it receives informational and error messages generated by EDM.

//PXYPRINT

is conditionally required. For an EDM instance to perform proxy operations, this DD must be specified. Normally a JES spool data set, it receives messages generated by DFSMSdss.


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)