data from host is written to cache on source, if this data is sent prior to destage to disk only the actual update is sent to the target
data from host is written to cache - destaged from cache to disk freeing up cache slot - full track of data from disk is reread to cache for transfer to target
data from host is written to cache - destaged from cache to disk freeing up cache slot - update to same track is written to cache - update must be destaged to disk - full track read from disk back to cache to send to target.
in the last part you have 3 different tracks updated to send they will be sent in no particular order since they are 3 different tracks of data. They will follow the above rules to ensure the data is valid.
When I`m right you have to use TF with SRDF/DM. First you get an copy of your production using TF and then copy this volumes to your second site by using DM. I think this is the only way to get consistent copy to your target array.
It to be used as a migration tool not so much as a disaster recovery tool. You can start the migration using SRDF/DM in adaptive copy mode. When you are ready to "cut over" you stop the existing host system(s) let the data finish synchronizing and your migration is set.
thanks Robert, so on the target side i will get a consistent copy once the source is stopped ..even though the data was not copied in specific order. For example if my system is up and running and i change block X , then 10 seconds later i change block X again ..is there guarantee that the last change will end up on the R2 side ? I only used adaptive copy to move bulk data but then would always switch to SRDF/S when devices were almost synched.
Even if data is flushed out of cache to disk and there is a second update to the same track; the data will have to be updated to disk read back into cache then sent to the R2. Adaptive copy does not allow the data to ge to the target "out of order" for a particular track. There is no consistency as you would have with synchronous or srdf-a but the data does get there.
i see, so for a particular track , the last update to that track will be the one that ends up on the R2 side. Now if i have tracks X, Y and Z ..and host first writes to X then to Y and then to Z, it's very likely that track Z or Y maybe the first one that gets transferred to the R2 side even though track X was the first one written to , thus inconsistent copy on the R2 side during transfer ? Is my thinking correct ?
RobertDudley
2 Intern
•
448 Posts
0
October 20th, 2009 08:00
data from host is written to cache on source, if this data is sent prior to destage to disk only the actual update is sent to the target
data from host is written to cache - destaged from cache to disk freeing up cache slot - full track of data from disk is reread to cache for transfer to target
data from host is written to cache - destaged from cache to disk freeing up cache slot - update to same track is written to cache - update must be destaged to disk - full track read from disk back to cache to send to target.
in the last part you have 3 different tracks updated to send they will be sent in no particular order since they are 3 different tracks of data. They will follow the above rules to ensure the data is valid.
andreas.scht
2 Intern
•
219 Posts
0
October 14th, 2009 02:00
RobertDudley
2 Intern
•
448 Posts
0
October 15th, 2009 12:00
dynamox
9 Legend
•
20.4K Posts
0
October 17th, 2009 17:00
Thanks
RobertDudley
2 Intern
•
448 Posts
0
October 17th, 2009 22:00
Even if data is flushed out of cache to disk and there is a second update to the same track; the data will have to be updated to disk read back into cache then sent to the R2. Adaptive copy does not allow the data to ge to the target "out of order" for a particular track. There is no consistency as you would have with synchronous or srdf-a but the data does get there.
dynamox
9 Legend
•
20.4K Posts
0
October 18th, 2009 15:00
dynamox
9 Legend
•
20.4K Posts
0
October 20th, 2009 08:00
RobertDudley
2 Intern
•
448 Posts
0
October 20th, 2009 10:00