Configuration files used for cloning

Edit online

IBM® Storage Protect Snapshot uses preprocessing and postprocessing configuration files during cloning operations. The functions that are provided by the processing scripts depend on the cloning environment where they are issued.

All processing configuration files and the scripts that are defined in the configuration files must meet the following requirements:
  • Files and scripts are stored on the clone system.
  • Files and scripts have permissions for read and write access for the clone database instance owner. The preprocessing and postprocessing scripts have permissions for read and write access for the user who updates and runs the scripts. If the scripts are run by any user registered on the system, the scripts are owned by the root user. The root user has permission to read and write for the User, Group, and World user groups.
  • Files and scripts have permission for read access for the production database instance owner.
Attention: If a write access level for the World user group is given, there is a security risk.
An example of a preprocessing configuration files for DB2® is: /db2/P01/acs/preprocessing.ini. When adding processing configuration files, place each script on a separate line as shown in the following example:
/db2/P01/acs/scripts/PreProcessing_stopsap.sh 
/db2/P01/acs/scripts/PreProcessing_stopdb.sh
Both processing configuration files support embedded user comments. A comment line in the configuration file is denoted by the number sign character: #. The scripts are specified with fully qualified file names. Each line of the processing configuration file represents one processing script. The IBM Storage Protect Snapshot Offload Agent, tsm4acs, uses these arguments and their values when calling the scripts:
DBNAME_PROD
The database name on the production system.
DBNAME_CLONE
The database name on the cloning system.
DBHOST_PROD
The host name of the production system.
DBHOST_CLONE
The host name of the cloning system.
CLONE_TIMESTAMP
The timestamp when the clone was created. This entry is also the time when the production database is suspended and the FlashCopy® operation begins. The timestamp format is YYYYMMDDhhmmss. During preprocessing, the timestamp identifies when the previous FlashCopy clone is created. During postprocessing, the timestamp identifies when the current FlashCopy clone was created.
SCHEMA
The database schema of the production database as specified by the profile parameter DATABASE_SCHEMA. Depending on SAP® Kernel release, this schema is SAPR3 or SAPDBname.
You can use the following processing scripts:
  • SQL scripts with the extension .sql.
  • Shell scripts with the extension .sh. Shell scripts can be started by a database user who is different from the clone database user. For example, when installing the SAP license for the cloned SAP system, start the postprocessing shell script as the SAP administration user sidadm: 
    scripts/PostProcessing_saplicense.sh:c01adm

    By adding :c01adm to the script file name, the script runs as user c01adm instead of user db2c01. This addition requires that the owner of the script to be identical to the user who is intended operator of the script. In this example, c01adm is the owner of the script. There is one exception. If a preprocessing or postprocessing script is owned by the root user, the script can be run by any user registered on the system.

The processing scripts that are defined in the processing configuration files run sequentially. The return code of each script is validated. The following values are used:
RC=0
Processing ends successfully. If this script is the last script to be run, continue cloning. If this script is not the last script, continue with the next script.
RC=1
Processing ends successfully with warning. If this script is the last script to be run, continue cloning. If this script is not the last script, continue with the next script.
RC=2
Processing ends with an error. Cloning immediately stops. No additional scripts run.
The return code for each script is written to the cloning log files. The output is written to dedicated log files with the following file names:
clone_preproc.<timestamp>
clone_postproc.<timestamp>