Backup 

The DBA Planning Calendar gives you the option of making a complete backup (full image copy) or an incremental backup (incremental image copy) of all SAP tablespaces or a backup of SAP tablespaces according to the recommendations of stored procedure DSNACCOR.

CHANGELIMIT

The incremental backup uses a CHANGELIMIT threshold that switches to full image copy if this threshold of changes has been reached. Whilst a backup job is running, other programs have read-write access to the relevant tablespace (SHRLEVEL CHANGE).

 

For MCOD, you must avoid making simultaneous backups on several SAP systems, which have been scheduled on different SAP systems. These can lock each other out, resulting in errors.

Utilities Running in Parallel

The number of utilities running in parallel is controlled with a profile parameter. The higher this number, the faster the execution will be. But do not set this number not too high in data sharing environments, otherwise your group buffer pools may run out of space, resulting in utility failure.

Upload Function

If you use the upload function, a separate job for the directory tables SYSIBM.SYSCOPY, SYSIBM.SYSUTILX and SYSIBM.SYSLGRNX is generated, named either FICPYSYS (full image copy) or IICPYSYS (incremental image copy). It is located in the PDS specified for the upload. Make sure that this job is only executed after the other COPY jobs have run, otherwise locking conflicts could arise.

Template Utility

For allocation of data sets, the TEMPLATE utility is used, which has the advantage of being able to automatically size the data sets based upon catalog statistic information. Please make sure that the catalog statistics are reasonably up to date, to prevent Out of Space conditions.

Profile Parameters for Backup

The following profile parameters exist for backup. You maintain these with the JES Interface (transaction DB2J) function Profile parameters:

Storage Parameters

·        HLQ for Backup data sets:

·        MGMTCLAS (SMS)

·        STORCLAS (SMS)

·        DATACLAS (SMS)

·        Volume count

·        Number of GDG generations:

GDG is the abbreviation for “generation data group”. This is the administrative unit for a collection of historically related non-VSAM data sets that are arranged in chronological order. GDGs themselves do not contain user data.

Each data set that is part of the GDG is called a generation data set (or short: generation). The generations contain the user data. A GDG can consist only of a limited number of generations. This number is specified at initial creation of the generation data group base entry that defines the GDG. Whenever a new generation is created and this number is exceeded, the oldest generation is replaced by the new one. That way, an automatic garbage collection of outdated data sets can be implemented, for instance for backup data sets.

You can configure the number of generations here. The values allowed are 0 to 255. If you specify 0, GDGs are not used by SAP. Any other number will be the number of generations for newly created GDGs in the future. In other words, the "Number of GDG generations" for already existing GDGs will not be changed.

The naming convention for backup data sets is

<HLQ for Backup data sets>.<database>.<tablespace>.CCC

if you use GDGs. Otherwise, the data sets have the following naming convention:

   <HLQ for Backup data sets>.<database>.<tablespace>.CCC<nnnnnn>

where nnnnnn is the utility ID and CCC are three characters describing the type of COPY. The first character is I for incremental or C for full COPY. The second character is L for local or R for remote copy. The third character is P for primary or B for backup copy.

A good number here depends on your environment. Let's assume, that you take up to 3 backups per week (2 incremental and one full backup). If you need to keep the backups of the last 6 months (26 weeks), you should specify 3 * 26 = 78 for "Number of GDG Generations".

COPY-specific parameters (choose COPY)

·        Number of parallel jobs

·        Change limit:

Percentage of the changed pages of a tablespace, above which a full copy, not an incremental copy, is made. For more information, see the IBM documentation DB2 UDB for z/OS Utility Guide.

·        Age for MODIFY RECOVERY:

The MODIFY RECOVERY utility deletes records from the SYSIBM.SYSCOPY catalog table, related log records from the SYSIBM.SYSLGRNX directory table, and entries from the DBD. MODIFY RECOVERY should run regularly to clean up outdated information. This saves much space and, even more important, speeds up processes that access data from the tables mentioned above, for instance COPY utility and RECOVER utility.

MODIFY RECOVERY has a parameter AGE that can be maintained here. MODIFY RECOVERY deletes all records older than the specified number of days. If you specify 0, MODIFY RECOVERY will not be used.

The recommended number depends on your environment and should be correlated to the "Number of Generations". This is due to the following reasons:

¡        MODIFY RECOVERY only cleans up records. The backup data sets themselves will not be deleted automatically. On the other hand, only in SYSIBM.SYSCOPY are the names of the backup data sets noted, so after having deleted these records, you will not be able to determine which backup data sets have to be deleted.

There are two solutions to this problem: Either use GDGs or configure in SMS a retention period for Management Class of the data sets in question, that has the same value as the AGE parameter of MODIFY RECOVERY.

¡        A record in SYSIBM.SYSCOPY without the backup data set is useless.

¡        A backup data set without a record in SYSIBM.SYSCOPY can not be used by the RECOVER utility. You need to take a series of complicated steps to still use it (e.g. DSN1COPY or LOAD and very old archive logs). This should be reserved to emergency and will not be your normal mode of operation.

Here are some recommendations:

¡        If you do not use GDGs or some other means to discard old backup data sets, do not use MODIFY RECOVERY from within SAP, for example, specify 0 for "AGE for MODIFY RECOVERY".

¡        The minimal number is the age of the last successful FULL IMAGE COPY.

¡        Correlate it to "Number of GDG Generations". In the example above, you specified 78 for "Number of GDG Generations", which is sufficient to keep 6 months worth of backups. Correspondingly, you should specify 183 days for "AGE for MODIFY RECOVERY".

 

The backup jobs use data from the table and index monitor to size the backup data sets correctly, if the statistics data in catalog or in Real-Time Statistics is not available.

Number of objects to be copied

There is a threefold radio button group with the following options:

·        Backup all objects in the DB2 subsystem

This option chooses all table spaces in catalog table SYSIBM.SYSTABLESPACE that are physically allocated (for example SYSIBM.SYSTABLEPART(SPACE) <> -1) and indexspaces that can be copied. Any data unrelated to SAP data in the DB2 subsystem is also copied.

·        Backup ABAP & Java systems and DB2 catalog

All database objects that can be copied and that belong to all ABAP systems and the DB2 catalog are copied. In addition, all creators of the table with the name J2EE_CONFIG are determined and used to generate a list of database objects that can be copied belonging to Java AS systems. All members of this list are also copied.

·        Backup ABAP systems and DB2 catalog

This is the old habit (which is also the default), that will copy all database objects that can be copied and belonging to all ABAP systems and the DB2 catalog.

Make sure that the user that will execute the COPY utility is authorized to run the COPY utility on all objects that are going to be copied.