We take daily System Level backups (SLB) of our SAP production environments using the BACKUP SYSTEM utility.
We use Incremental FlashCopy to reduce the amount of data that needs to be physically copied to the FlashCopy target volumes and limit the pressure on the DASD subsystem.
We regularly perform Clones from our production systems into other systems, using the production FlashCopy disks as the source.
We use the COPY command with FASTREP(REQ) to guarantee that FlashCopy will be used.
We have to break the incremental relationship between the real production disks and their FlashCopy targets to allow us to perform the Clone. If we don't, we get the following type of error message when running the Cloning Tool COPY command:
CKZ02149E SOURCE VOLSER: F0368D ACTIVE IN COPY RELATIONSHIP
IS TARGET OF RELATIONSHIP
Having to break the incremental relationship causes:
(1) operational complexity
(2) negative impact on our application workloads during the next SLB as it will force a full physical background copy.
We meet all the prerequisites to exploit Cascading FlashCopy i.e. Clone without having to end the incremental relationships in the source system (see scenario 3b in attached document).
If we issue the COPY command with FASTREP(REQ) ourselves using ADRDSSU, the command runs successfully.
If we run the Cloning Tool with FASTREP(PREF), the COPY command runs successfully and uses FlashCopy -- but we do not want to use FASTREP(PREF) as it doesn't guarantee that FlashCopy will be used.
If we run the Cloning Tool with FASTREP(REQ), we are blocked by the initial check that looks for existing relationships.
|Who would benefit from this IDEA?||Any user of the Cloning Tool using SLB as the source and running on recent disk hardware|
How should it work?
The check for existing relationships performed before COPY command with FASTREP(REQ) should be relaxed to tolerate relationships that do not block cascading FlashCopy
|Client Name||Nationwide Building Society|
|IBM's success depends on gathering feedback from customers like yourself. Aha Ideas Portal is the third party tool through which IBM Offering Managers gather feedback from customers such as yourself.|
|IBM is a global organization with business processes, management structures, technical systems and service provider networks that cross borders. As such, the information collected through Aha Ideas Portal (Customer Name, Customer Email Address) will be stored by them in the United States, and handled only as per IBM's instructions and policies. Your data (Name and Email Address) will NOT be shared with other IBM customers.|
|In order to safeguard your information in Aha, do not leave your workstation unattended while using this application, log off after using it, and print only if necessary. If you need to make a hardcopy, remember to pick up the print-out immediately, keep it under lock, and destroy it immediately when no longer needed.|
|NOTICE TO EU RESIDENTS: per EU Data Protection Policy, if you wish to remove your personal information from the IBM ideas portal, please login to the ideas portal using your previously registered information then change your email to "firstname.lastname@example.org" and first name to "anonymous" and last name to "anonymous". This will ensure that IBM will not send any emails to you about all idea submissions|