View previous topic :: View next topic
|
Author |
Message |
ananth86
New User
Joined: 10 Jun 2009 Posts: 59 Location: Hyderabad
|
|
|
|
HI
I want to know the difference between three disk copy services that are provided by DFSMS:
Concurrent copy
Snapshot copy
Flash copy
I read it from some manual, but i could not get the basic concept behind each one. can anyone explain me. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
SNAPSHOT is a function of a RAMAC Virtual Array (RVA) -- a specific type of disk subsystem used by IBM. The term does not apply if you are not using an RVA. It is a very quick copy of the data.
Concurrent copy is a copy that is consistent even though updates are occurring while the copy is underway (i.e., the updates are not applied to the concurrent copy of the data).
Flash copy is a point-in-time copy of the data -- updates are not reflected in it since updates occur over time and flash copy is at a single point in time. |
|
Back to top |
|
|
ananth86
New User
Joined: 10 Jun 2009 Posts: 59 Location: Hyderabad
|
|
|
|
Robert Sample wrote: |
Concurrent copy is a copy that is consistent even though updates are occurring while the copy is underway (i.e., the updates are not applied to the concurrent copy of the data).
Flash copy is a point-in-time copy of the data -- updates are not reflected in it since updates occur over time and flash copy is at a single point in time. |
As per your statement both concurrent and Flash copy wont reflect the updates. Then what is the differnece?
I cant find any difference between these two copy techniques. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
Concurrent copy starts the copy immediately but it takes time to complete. Until the copy is complete and the system notification is generated, you cannot guarantee the backup is valid. One reason the backup may fail is that so many updates are applied so quickly that the disk subsystem cannot record them all in the available space for application after the backup is done.
Flash copy is a volume-level "instant" copy method. Which means the data is not physically copied, just the pointers to the data. This can be done very quickly (typically under a minute) but has implications for application recovery. Any updates done after the flash copy would not be reflected in the copy. |
|
Back to top |
|
|
Pete Wilson
Active Member
Joined: 31 Dec 2009 Posts: 580 Location: London
|
|
|
|
Suggest you read the IBM Advanced Copy Services manual where all is revealed.
Note: Flashcopy can operate at both the volume and dataset level these days when using DFDSS |
|
Back to top |
|
|
Pete Wilson
Active Member
Joined: 31 Dec 2009 Posts: 580 Location: London
|
|
|
|
This is a bit more of an explanation, but not exhaustive. Disclaimers apply!
IBM Flashcopy (and similar for HDS Shadow Image)
When you Flashcopy a volume or dataset, depending on the mode of Flashcopy the DASD controller will first set up a bit-map of the source volume or dataset track addresses, then the same for the target volume or dataset. The DASD controller will then begin a 'background copy' of the data from the source to target tracks, ticking them off as it progresses, but from a ZoS or MVS perspective the file has been copied as soon as the bit-map is set up so appears to be near instant. Until the copy is completed, any reference to the target volume or dataset may actually be accessing either the source or target tracks depending on whether they have been copied or not. If before the background copy is completed you update the source volume/dataset, the controller will first copy the unchanged tracks to the target equivalent to maintain the point in time status of the target, and then update the source. Note that there are some variations on this for other modes of Flashcopy, and some restrictions for PPRC mirrors.
SNAPSHOT
Similar principle to Flashcopy, except the controller never actually does the background copy and just maintains the bit-map pointers. Until either source or target change only the capacity of the source will be actually used. However, as either source or target volume/dataset tracks change they are written to new locations and the pointers updated. As both source and target change the actual amount of capacity used increases because each have more new unique tracks using separate locations. Old tracks are invalidated and released for reuse by the automatic 'scrubbing routines' that maintains the NCL (Net Capacity Load) of the controller. This is how the RVA (or Iceberg) controllers can fit larger capacity than is physically available from a ZoS perspective, along with the fact they compress the data at around 2.6 to 1 by default. ~
Warning: Some functions such as ICKDSF REFORMAT and INITIALISE are not recognised by the 'scrubbing routines' so initialising or renaming a large number of volumes for example can see the NCL suddenly climb. If it gets over about 85% you'll start to get degraded performance. To overcome this you should run a batch version of the 'scrubbing process' immediately afterwards which will release the affected tracks.
CONCURRENT COPY
Concurrent Copy uses the SDM (System Data Mover) (can be monitored via modify commands to the ANTASnnn address spacesa). It would set up DASD controller AND Host processor sessions ('side-files') to maintain a bit-map of the source dataset(s) track locations which are then used for copying to the backup copy as a point in time copy. Meanwhile if the source dataset is updated the SDM intercepts those updates and holds them in the side-file until the original source tracks are copied to the backup before destaging and updating the original track.
Note: The SDM can also used by XRC (eXtended Remote Copy or Metro Copy) and XRC also creates sessions (sidefiles) in DASD cache so these can compete with eachother for resources, especially in a very highly write active subsystem. |
|
Back to top |
|
|
Pete Wilson
Active Member
Joined: 31 Dec 2009 Posts: 580 Location: London
|
|
Back to top |
|
|
|