This post is more than 5 years old
4 Posts
0
1552
Timefinder for Oracle cloning
We use Data Guard across our sites to protect several production databases.
In the site where we keep most of our test and development servers, we have started using EMC
Timefinder to clone copies of the prod databases. This is in a proof-of-concept stage currently,
but looks like a good way to create ad hoc copies. We have cloned several DBs at this point and have
been able to bring them up on test servers. We would like to be able to repeatedly resync these clones
with our standby database source. In order to do that, we bring down the database on the target server,
dismount the ASM diskgroups and run the re-establish process, then remount and startup the database.
In some cases, the database comes up ok, but we see no changes during the cloning. This seems only to happen on
a re-sync...the original copy always looks OK. Is there more that needs to be done in ASM to prepare the disks for re-syncing ?
BartS
46 Posts
0
April 2nd, 2012 07:00
Well - assuming Timefinder works as designed (and configured correctly) then you are basically creating 100% equal clone volumes (LUNs) as compared to the standby. Meaning every bit on those drives is exactly the same. So if data made it to the standby and you're cloning the volumes belonging to the standby, then the data must be on the clones.
Maybe those transactions are rolled back during recovery?
If the storage team mentions there are no changes, then I would try to re-validate the TF config (source/target volumes) because IF something has changed on the standby and you TF-clone those volumes then you should at least see a few changed tracks being updated. If not, something is wrong...
Sure you're not cloning copy1 (unchanged) to copy2 instead of stdby (changed) to copy1 ?
BartS
46 Posts
1
April 2nd, 2012 00:00
Am I correct in understanding that you have a prod database, which you replicate using Data Guard to a standby, and you create TF clone copies from the standby?
Is DG in max availability (sync) or max performance (async) mode?
As far as I know you don't have to do anything else with the ASM disks. They contain data in a certain state and either Oracle mounts and opens it, or it complains that it cannot recover. That's all. If you see no changes in data from before refreshing the clone, then I guess this means the clone source was not changed either (or something went wrong during the clone process).
Maybe the Data Guard replication was down or suspended? Maybe the EMC cli command to perform the clone refresh failed? Maybe your source/target devices for the clone job are incorrect? Maybe the prod database has not received any new updates that made it to the standby?
(just a few suggestions you might want to check)
Regards
Bart
JDrum1
4 Posts
0
April 2nd, 2012 05:00
Bart- Thanks for the reply. Your understanding is correct..we are cloning copies from a DG standby.
There are a few gotchas with doing this..one is that the clone comes up as a standby database and needs to
be changed to a primary to make it writeable. We have worked out a number of issues involving renaming the
ASM diskgroups ( for multiple copies ) and have been able to always bring up the DBs, but this particular test
yielded unexpected results. A table was created on the primary, we then did a select in the standby and saw
the table and data there, so proceeded to re-clone it. The sym commands completed without errors, but the storage team reported they saw no changes being processed. The DB came up OK, but no table. I believe there was most
likely an issue with TimeFinder, but thought the fact we are cloning from a standby may have some bearing.
yd1
15 Posts
1
April 2nd, 2012 08:00
I agree with Bart. TimeFinder clone target image is always a 100% match to the data on the source devices. Like Bart suggested, perhaps the Clone target devices weren't re-established with the source (so they were just unmounted and re-mounted, showing the same old data), or the source devices were not matched correctly. I'd confirm with the storage group the process. Other than that (and assuming the transactions were committed) the Clone target devices will show the same data as the standby since the ASM disk group data will be identical. Note that if you keep the ASM disk group mounted during the clone, it is recommended that you use the -consistent flag during the clone activation to make sure ASM *metadata* is always consistent. Of course if you dismount the ASM disk group prior to the clone activation (optional) then the ASM metadata is consistent.
Thanks,
Yaron
JDrum1
4 Posts
0
April 2nd, 2012 10:00
This has been retested successfully after the storage team remade the device pairs. Not sure of the
exact problem, but it was explained that because the clone devices had been used as both the target
devices and the source ( experimenting with snaps ), that there was a configuration issue. As stated before,
there were no errors recorded doing the cloning, but also no chages seen. We now see changes and the
cloned database does contain them.
At the same time, the DB team did a test with dropping the ASM diskgroup. It's not clear to me why this would
would matter..my experience is that simply dismounting it would provide for re-cloning......at any rate...
Thanks all.
yd1
15 Posts
0
April 2nd, 2012 11:00
Appreciate the update.
Thanks,
Yaron
BartS
46 Posts
0
April 5th, 2012 01:00
Indeed, good to hear that our hunch was correct :-)