This post is more than 5 years old
2 Intern
•
20.4K Posts
1
3361
TF/Clone -precopy and -cycled question
Hello guys,
First question: what is the purpose of checking on -cycled parameter whenever i create clone pairs using -precopy option. If clone pair that was created using "-precopy -differential " is activated right after the session is created why would this be an issues ? Shouldn't it just copy the missing track to the target just like when you created session using "-copy".
Second question: when i activate session that was created using "-copy", target devices are available immediately while data is still copying in the background. If i have a host that starts using target devices right away, will new writes to clone target propagate to clone source ? I am just thinking of BCVs back in the days where you could do protected restore and new writes would not propagate to source devices.
Thanks
SYMCLIGuy
98 Posts
0
June 4th, 2013 12:00
correct.
SYMCLIGuy
98 Posts
1
June 4th, 2013 08:00
Not necessarily answering your questions in order :-)
You are correct, when a clone session is created with -copy, data will be copied from the source to the target when the activation occurs. However, writes to the target, while the data is copying, will never propagate to the source. If the host writes to a track on the target that has not been copied yet, the write will be held in cache (and not acknowleged back to the host) until the original data is copied over from the source to the target. An exception to this is if the host write to the target is a full track write, in which case the write will be destaged to the target without copying it from the source as we would overwrite the entire track anyway.
The reason for using the -cycled parameter on a -precoy session, is so you can verify that every track has been copied from source to target at least once. Performance for the session is typically better if you do precopy and do not activate and access the target until the majority of the data has copied from source to target. Once a cycle has completed, when the session is activated, there will typically only be a small number of tracks still to be copied, and the data will alread be on the target when accessed by a host.
This allows clone users to get similar behavior to the old TimeFiner/Mirror functionality, as is actually used by the TimeFinder/Mirror clone emulation. The BCV is not reported as sychnonized until one precopy cycle has completed.
Make sense?
dynamox
2 Intern
2 Intern
•
20.4K Posts
0
June 4th, 2013 09:00
makes sense the -copy answer, that's what i expected but wanted to double check.
i understand why somebody would use -precopy parameter, we do it all the time when we build new pairs but typically we create pairs and let them "drift" until we activate them. But i am still confused why activating a session that was build with -precopy is not a good idea until it completed one full cycle. When you activate it, it copies track that are still owned to the target ..so who cares that it did not complete one full cycle. Let me give you an example: i have 10TB database, say i build brand new clone relationship using "-precopy -differential", session is created and data is being copied. Let's say 50% into copy process business comes screaming "oh my god, we need this clone right now !". So i activate the clone and make it available to my DB server ..i know i only have 50% of my data on the clone while the other 50% is still copying in the background ..i am ok with possible increase in response time, they said they wanted it NOW, they got it with slightly degraded performance. So is it just the performance or 50% of my data would be garbage ?
Thank you for your time, and no ..i am not kidding about crazy business people running into my cube
SYMCLIGuy
98 Posts
1
June 4th, 2013 10:00
It's performance. When you activate a precopy session it effectively becomes a copy session. So, all the data on the target is good, but you could have an increase in RT if the host accessing the target reads data that has not yet been copied. This is because, in order to provide it to the host, the array has to first copy the data from the source to the target.
SYMCLIGuy
98 Posts
0
June 4th, 2013 11:00
That flag is only pertinent when the state of the session is 'PreCopy' and not when the session has been activated and reached a copied state. At that point, no more data is copying from source to target so the precopy cycle information is no longer relevant. If you issue a recreate -precopy, the flag will get set when the tracks that were changed since the last recreate have been copied to the target at least once. The flag will then get cleared again when you activate the session.
dynamox
2 Intern
2 Intern
•
20.4K Posts
0
June 4th, 2013 11:00
fair enough, for some reason i was under impression that if i activate it before it has completed one full cycle i will have data integrity issue on my clone target.
One interesting data point, look at the status of this clone pair, these clones get re-created every day so they have completed hundreds of "full cycles" yet look at the status of "pre-copy operation has completed one cycle". There is a "x" in the CGDP column, any idea why ?
seancummins
226 Posts
0
June 4th, 2013 11:00
Dynamox,
In that screenshot, you've already activated the sessions so precopy no longer applies. The P flag is only applicable if you're in precopy mode before issuing an activate.
Thanks,
-Sean
dynamox
2 Intern
2 Intern
•
20.4K Posts
0
June 4th, 2013 12:00
Sean and SYMCLIGuy,
Thank you and Thank you ..so consensus is -cycled is to let users know that all tracks have been copied at least once and user should expect only relatively small amount of data to be copied after activation. It has nothing to do with data integrity ..clones activated before status reaches "pre-copy operation has completed one cycle" will be just as valid if i were to use -copy to create my session ?
dynamox
2 Intern
2 Intern
•
20.4K Posts
0
June 4th, 2013 13:00
Thank you