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:
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.
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 preallocated and are always created by the server through 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 about 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 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.
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 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 constitute 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 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. For tablespace or individual data file 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 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.
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 about 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.
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 must 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.
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 through 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 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 through the ORA$FPS
DD statement) affect the way that this data set is created by the server. If you want, you can preallocate 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.
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 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 |
%n |
specifies the database name, padded on the right with 'X' characters to a total length of eight characters. For example, if |
%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, |
%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 about &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 % (that is, %%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 theFORMAT
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 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
A data set name that is produced from this format specification might look as follows:
ORA3ADBF.BKUP.ORA3DB.G6ENPJ03.P3.C1
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 if the backup remains known to RMAN; in other words, if 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 if 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.
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 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. If backup pieces remain cataloged, then the proxy backup should be considered viable and the associated tape volumes must not be 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.
Proxy backup is designed for backing up entire database files, not for incremental backup. A single proxy operation on z/OS 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 about 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.
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 must manually delete any files with a new target name before beginning the restore. You must not 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".
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."
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 recommends using a distinct identifier or jobname for each EDM channel in the script.
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 through 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.
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; }
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 |
---|---|
|
identifies the External Data Mover program. |
|
is normally included. It identifies the Oracle AUTHLOAD data set containing ORAEDM. |
|
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. |
|
is required. Normally a JES spool data set, it receives informational and error messages generated by EDM. |
|
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. |
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)