This content has been marked as final. Show 10 replies
1 person found this helpful
Hi, I am currently building a standby site. DB version is 126.96.36.199 and OS is aix.You should put database in backup mode before and then can replicate it with OS/hardware tool.
Our Storage team offered to use their replication tool to replicate the production data over to standby host.
I am not sure if this is a possible way other than RMAN duplicate.
Thanks for help.
I want to know what is backup mode?
if I build this db as standby db by creating a controlfile from prod as standby controlfile, what else I have to do?
I want to know what is backup mode?alter database begin backup;
if I build this db as standby db by creating a controlfile from prod as standby controlfile, what else I have to do?create parameter file, password file and mount standby database
You can use SAN replication as a DR strategy for your database instead of dataguard which is setup using RMAN duplicate.1 person found this helpful
However with SAN replication the database is a copy of your production and there is no concept of primary/standby in the sense that the secondary database control files would be the same the primary and the database would not be mounted on the secondary site.
Before you open your database on the secondary site you would have to shut down your database on the primary, open on the secondary and switch your SAN replication to go the other way. Typically all file systems , disk groups etc are closed on the site which is being replicated to.
However, saying that, dataguard is much the preferred option as it is fully supported by Oracle. With SAN replication in the case of any issues you would be looking at your SAN provider to give you support if you have issues opening your database at your secondary site.
Dataguard is also much much faster to failover then failing over compared to using SAN replication.
Why no just copy over files yourself over the network...much less hassle.
THanks. This is what I need to know OS replication seems can cause the production reboot.
Is there any official document to support this?
THe reason has been the storage offerred this replication and we need to find solid document to prove it.
Every good storage vendor (EMC, Hitachi , IBM etc) has tested their storage replication with Oracle and published white papers on how to configure storage replication for oracle. If your vendor does not have such a white paper, do not use it for replicating Oracle --- that would be my advice.
Oracle cannot help you if your database is corrupted (e.g. writes to the remote storage done "out-of-order", "fractured blocks" because of a block size mismatch, archivelogs not properly replicated with database backups etc).
Storage replication is used for two purposes :
1. As a DR environment
2. To allow Oracle backups (to tape) to be taken from snapshots / clones of the production volumes
How you configure the replication can and will differ between the two implementations.
Hemant K Chitale
You mention both OS and SAN replication.
When you say OS replication I would understand that to mean os level commands like scp etc. For this you would need to put your database in backup mode and then copy across your datafiles etc to your standby site.
If you do actually mean SAN replication then you don't need to reboot production to start your sync. The sync happening at the SAN level is completely transparent to the database. Opening the database on the standby site is a separate issue.
As mentioned by Hemant any documentation on the methodology on how to setup SAN replication with your database should be provided by your SAN vendor.
I'm still unclear on what you are doing. Are you using SAN replication as your DR strategy or dataguard?
Sorry, it is SAN replication.
Okay so in the case of SAN replication you don't need to stop your production database as the replication will be transparent to the database.
To test the replication is working okay and to ensure the reverse replication occurs you will have to stop the database and unmount the filesystems etc before you start the database at the secondary site. Your SAN vendor should be able to give you the details on the procedure.
However this sort of DR strategy is more complex than dataguard.
Thank you Freddie for your continuous help.