This content has been marked as final. Show 5 replies
why do you want to use any storage replication mechanism?
While this seems to work, there is the chance that you may inflict a blockcorruption with this and not noticing it.
What exactly do you try to achieve? Maybe there is a more elegant solution to this, if we know what your goal is.
=> So e.g. Storage Mirroring is not DR. If you have a corrupt block on site 1 it will be mirrored.
=> If it is for testing purposes, then why not use Snapshot Standby, which is also very elegant, and does have less overhead on the network, than storage replication
Last but not least, you simply could use ASM to mirror (instead of storage).
Then simply "split" the diskgroup. While not supported, this works. But that does not matter here, since your above solution is also not supported ;)
And to answer your question: If you take all ASM Lun/Disk as a whole for mirroring, there is no difference to a filesystem being mirrored.
You will find some whitepapers on the ASM side (www.oracle.com/goto/asm) which describe third party storage mirroring solutions like EMC/HP/etc. in
conjunction with ASM.
Still I would like to know your use cases, to see if there doesn't exist a solution, which might be better suited (and maybe also supported).
I have two servers that need to have a replica of the same database with a different name though.
So basically what we managed cause the people who run it don't really allow / want nearly any downtime and since replicating it via Oracle according to them takes too long we are implying a replication method of the Storage itself so basically a quick a quick rundown is that the database is shutdown after the control file being generated, all the disks are "dismounted" and then the storage is "replicated" and then on the other side the control file is used to recreate the file.
This whole process takes about 10 minutes and the database is "good" to go as the storage will continue to replicate in the background.
What it does is on the destination, Oracle will read from the source disks on the other machine but will make the changes in his own disks (Second set of disks on the second server).
Basicly that's it ... it's working with Oracle running on File System ... question is will it be doable via ASM ?
Forgot to tell that once this process helps them have to databases with a point in time allowing for one to be used for development and another for production system.
Cheers and Thanks for Help.
at the bottom of my last post, I did point you to some whitepapers on the ASM side, identifying what needs to be done in case of an ASM diskgroup.
So yes this will work with ASM, you simply have to mirror the whole luns and this should work.
However regarding the other points:
=> Replicating via. Oracle is definitely faster than storage. Just think of it: Oracle only needs to forward the changed of a block (never the whole block) with the help of the redologs, whereas Storage mirroring always has to take the whole block (+Redologs). So this is roughly double the data needed to be transferred than Oracle. Additionally blocks which Oracle does not need to forward (like ASM header/tablespace header information). Hence if you say it is slower, this cannot physically be the case. Only exception is if your infrastructure for network is not configured the same as the storage network is (or you have an error in setup).
=> DR with Oracle Dataguard is way below 5 Minutes if you configure it correctly. If you setup ASM mirroring between both nodes and setup a cluster than you have no downtime at all.
=> For the last point look at Snapshot Standby. This is exactly what they need + it provides DR all the time.
Here is a case study about this:
I do this nightly to replicate production data to a dev server.
SAN storage requires all the luns be in a script for replicating. Put prod database into backup mode. Clone the luns in the script with whatever storage CLI you have (just +DATA luns is fine), startup database on test, open, recover, done. 20 minutes nightly. The prod db is near 3tb, took 4-5 hours first time for full copy, then 20 minutes nightly as its only incremental block changes brought over.
Check your storage to see can you do incrementals and also how to script it. Looks like you know this bit already though, Im just saying the process works fine.
To echo above post, If it was straight replication you're after, you can not/will not beat dataguard for speed. As near real time as you can get can be achieved. Sub 1-2 second. Not sure dataguard is the best method for a nightly replication to a test env though.
Well, the question here isnt using any more software, the only thing at use here is the oracle database everything else is just the Storage for the Replication.
The process is described here as QuickOPC
What it does is basicly the same as Oracle forming a delta.
This works well with the LVM cause its a case of downting the database and so on the real "question" here is if i have a "replica" of the disks from the original server if ;
* Whether or not i can "import" them (ASM Disks) on the destination server cause im almost 100% sure that if you scan for them they will show up
* Will the ASM disk headers need to be "tinkered" with ?
* Do ASM disks have a record of the "Cluster" / "Hostname" where they are at ?
Because if the ASM at the destination can scan the ASM disks that were "replicated" im pretty sure that one way or the other it will be doable to attach them to the database engine and power up the databases there. But then again i might be wrong ?