Thin Cloning

Please consider moving this question as-is (no need to recreate) to the proper forum for maximum visibility.  Questions written to the users' own "Discussions" space don't get the same amount of attention and questions can go unanswered for a long time.

You can do so by selecting "Move" under ACTIONS along the upper-right.  Then search for and select: "Symmetrix Support Forum" which would be the most relevant for this question.

Hi,

"Updates to source data blocks result in the updated blocks to being copied to the thin clones currently active before the source blocks are updated"

Say i have a  Prod Copy .  Created two thin clones from the Prod Copy.

If a refresh my Prod Copy with latest Prod data using concurrent cloning option then

a. What happens to thin clones created.  Is that before refreshing the Prod copy, the  old  blocks to be modified will be copied to thin clone space?

b.If it is modified , then when i ran a query in thin clone space, does it fetch data from thin clone unmodified block or new modified Prod copy blocks?

baskar.l    

Are you Planning to Clone SOURCE LUN A to Target B and Target C. Keeping Target B copy with old data and Refreshing Target B Copy with latest production data ? If that is the case than yes you can achieve it by using Concurrent cloning option.

Make sure target Source LUN A and Target LUN B are paired in one Device Group DG-1 and Source LUN A and Target LUN C are paired in separate Device Group DG-2, While refreshing DG-2 that time specify Concurrent option. To monitor such clone session always use -multi option

Regards,

DP

As per my knowledge if a clone is created with –precopy option and not activated then all changes on source will be copied to target continuously. But when a clone copy is activated the Target/Clone Lun will have Point In Time data with Time stamp of TIME of Activation of clone. So it depends when do you activate the clone. If after refreshing Production Copy you Re-Create and Activate Clone session then clone will get updated with Latest Prod Data and Old block to be modified will be discarded in this case otherwise if Clone Copy is Not Recreated/Activated then old blocks will be copied to Clone Copy Target before source get modified.

Regards.

DP

Still am very confused about this. 

I have uploaded here a ppt of how clones grow

Say tomorrow if one of the thin clones needs a fresh data from Production,   If i refresh the thin clone copy of production again then one thin clone will benefit where as the other thin clone which still needs those old data will get affected right?

I cannot find PPT.

No, other thin clone which have old data will not be affected if that is Paired with same source in Different Device Groups.

Make sure you have both Clone Targets in different Device Groups. When you start a clone operation on one Device group with Concurrent options then operation will be performed only on that DG and will not impact another DG or another clone copy.

Hi Jasonc,

Till one doubt of me is not clear. Say am doing a differential copy of the Prod to the already  present "Full Copy" as per the image i posted.

So new tracks will be updated in the so called Full Copy.  Before updating those new tracks, the old blocks will be copied to thin clone 1 and 2 space. So far am right is it...

Say when someone queries a data, where it has old data in thin clone space and new updated data in the "Full Copy". Which data will be retrieved to the user?

baskar.l

Am not sure why the uploaded file ppt is not showing up . Ok now i posted an image. Look at the image below.  Prod - From prod i did a full copy.  From Full Copy i made two thin clones thin1 and thin2.  If i suppose refresh the full copy with latest data, what will happen to thin1 and thin2 and what happens to the dml statements.

If the refresh of the full copy is another full copy (i.e not a differential copy), all tracks on the copy will be updated. Any tracks on the clones, that have not aready been copied, will also be copied in this operation.

If both thin clones reside in the same pool, the array will not copy the data twice (once for each volume), but each clone will point to the same pre-updated copy of data. In other words, if you take 2VSE clones and thesource is 100 GB. If you completely update every track of that 100 GB, you end up with 100GB of clone data, not 200GB.

When a clone session is created, there is some metadata associated with the session. In the metadata there are pointers for the clone target device. If the data has not been updated since clone activation, the metadata will point to the clone source data, otherwise the clone target data. Whenever the clone target is accessed, the pointers in the metadata work out where the data needs to be accessed.

First of all, i need to say big thank you for all your wonderful help and reply.

Jasonc,

So 1.  Before refreshing the Prod Copy.  the tracks to be modified / updated with new tracks will be copied to thin clone space.

2. When the new data in the tracks are not updated,  then old data in the thin clone space will be referred by session.

3. If a user wants to update the old data in thin clone space ( right now new data is available in Prod Copy), the user will be pointed to new tracks and he will start seeing the new data. Am i right?

baskar.l

So 1.  Before refreshing the Prod Copy.  the tracks to be modified / updated with new tracks will be copied to thin clone space. >>> The pre-updated data is written to the clone as part of the update of the source device. Same for clone update or host update. This is called asychronous copy on write, which you can read about in the symcli documentation.

2. When the new data in the tracks are not updated,  then old data in the thin clone space will be referred by session. >>> Correct

3. If a user wants to update the old data in thin clone space ( right now new data is available in Prod Copy), the user will be pointed to new tracks and he will start seeing the new data. Am i right? >>> The first update of the source or the target device will cause the session pointer to refer to the target device data. This is completely transparent to the host. The host will see the update data just like it is a regular device.

Jasonc,

Thanks again. 

"The first update of the source or the target device will cause the session pointer to refer to the target device data. This is completely transparent to the host. The host will see the update data just like it is a regular device."

So the first update on data will be the data which is copied in the thin clone space.   New data will not be visible to sessions.

What if user later in point of time wants to access the new data in Prod copy and not in the thin clone space?

baskar.l

When you take a clone, the clone target holds a point-in-time copy of what the source volume looked like at the point of the clone activation. If you go ahead and make an update to the target device, you have lost the point-in time of the source. If you have 2 clone targets, like in your diagram and make updates to one, you still have a valid point-in-time of the source on the other clone target. The key is, any time you update the target device, you loose your point-in-time copy of the source device.