The other day I had a client that when planning his backup solution he wanted to take snapshots of his DG environment and from that clone to his Dev/QA environments. So below is the result of that, which is probably really nothing you have not seen.
Even though I am using the DG broker, for the purpose of this exercise I will do it via the sqlplus interface, but I did wanted to show you before, the environment in the DGMGRL.
For this, I’m going to use as the standby orclstby and for the duplicate orcltest
For this to work and not have any problems, we have to make sure that the Standby DB is consistent , and for this we have to stop the DG environment for the snapshot to happen.I also stopped the DB through this process, even though is not necessary, but it was the client’s request to do so during this process (Probably ease of mind).
The snapshot is taken during this process, and for this exercise, it was put in the following directory /u02/app/oracle/oradata/orcltest/, in the same server, but it can be put in another server. You can emulate this with an scp (scp -r /u01/app/oracle/oradata/orclstby/ /u02/app/oracle/oradata/orcltest/)
Also once the snapshot finished, the Standby orclstby is brought up as well
So now the next thing to do, is create a pfile for the orcltest database changing the location of the files corresponding to the new location
Now, we just need to create the controlfile with the location of the snapshot datafiles and the new name of the database orlctest
And as you can see, the new DB is up and running from a snapshot of the Standby Database
This is not the recommended way to do it, but it doesn’t mean it can’t be done. Also you can have loss of data as the Primary might not be fully synchronised with the standby, so you have to be sure what was the last log applied. Just make sure that this doesn’t have an impact on your DG , as for a minute there, the DG replication will be inactive so you can have a consistent database.