System Copy with NOT LOGGED tablespaces
[530 not logged in] [database] [DB2] [load] [logged] [logged out] [Not] [tablespaces] [V9] [z/OS]
Related:
- 640PC: Drop J2EE Content with Schema other than defaultSymptom You are not able to drop a J2EE content...
- DB6 and DB2/390: Java Database Connectivity (JDBC) traceSymptom A problem occurs in the SAP J2EE Engine. SAP...
- DB2-z/OS: Automatic REBUILD INDEX within DDICSymptom Long running CREATE INDEX statements when generating or changing...
- DB2-z/OS: Seamless JDBC Database Failover for SAP Java stackSymptom This SAP Note describes how to enable high availability...
- DB2-z/OS: DB2 Connect 9.1 JDBC Failover for SAP Java stackSymptom This SAP Note describes how to enable high availability...
- DB2-z/OS: Inconsistent fields with DDIC type RAW/LRAW/VARCSymptom You are requested by a SAP tool or documentation...
- DB2-z/OS: PLAN_TABLE & DSN_STATEMNT_TABLE for v9.1Symptom The note describes a fix that allows to create...
- DB2-z/OS: Transports & Support Packages (7.0 and higher)Symptom This is a release-dependent attachment to note 101217. It...
Symptom
You want to perform a System Copy or Unicode Migration and you want to
speed up the database load phase. Be aware that implementing this
Note is not compatible with Note 1062976 or 1296510 (fast load with
DB2 LOAD utility).
Other terms
DB2 z/OS V9 NOT LOGGED tablespaces database load
Reason and Prerequisites
Reason:
During database load, DB2 log I/O performance can cause a bottleneck.Setting the attribute “NOT LOGGED” for large tablespaces on DB2 for z/OS V9 solves this issue.
Prerequisites:
DB2 >= V9 for z/OSSAP Kernel 700, R3load#76SAP Kernel 710, R3load#XX
Note:
To be able to recover a tablespace after performing a database load with “NOT LOGGED” tablespaces, you need to perform an image copy of a each tablespace that was loaded with the parameter set to “NOT LOGGED”. Setting the tablespace attributes from “NOT LOGGED” to “LOGGED” sets the tablespace in status copy-pending. R3load sets the tablespace to “LOGGED” and starts the tablespace with “ACCESS(FORCE)” after load is completed.This method is not compatible with DB2 Load Utility fast load (Note 1062976).To avoid deadlocks if the table splitterR3tais used, you need to serialize packages that belong to one table on the import. This is valid for partitioned and non partitioned tablespaces. If you need to serialize the load of several packages, see Migration Monitor documentation (find documentation on SMP as described in SAP Note 784118).
Solution
The following steps are necessary to perform the database load with “NOT LOGGED” tablespaces:
Set the following environment variables:R3LD_FASTL_THRmust be set to the threshold in bytes when fast load is used. You obtain this information from.EXTfiles.LOADERTYPEmust be set toV9_NO_LOGGINGPerform the following steps to enable-loadprocedure fastas an additional R3load argument and (if necessary) define load groups:If you use Distribution Monitor you need to add-loadprocedure fastto ther3load.import.loadArgsparameter as described in the Distribution Monitor documentation attached toSAP Note 855772. If you need to serialize the load of several packages, see the Migration Monitor documentation. You can find this documentation in the SAP Service Marketplace as described inSAP Note 784118.On installations for releases based on SAP kernel 700/710, you need to start Migration Monitor manually. Therefore, select the optionStart Migration Monitor manuallyin SAPinst. Then add-loadprocedure fastto theloadArgsparameter in the fileimport_monitor_cmd.properties. For example:loadArgs=-loadprocedure fastInstall in SAPinst in Custom Mode.During the installation, when SAPinst stops to start Migration Monitor manually, exchange R3load in the SAPexedirectory (for example:/usr/sap/JCM/SYS/exe/run).