Re: creative use of storage snapshots.
- From: Nuno Souto <dbvision@xxxxxxxxxxxx>
- To: Oracle L <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 22 Dec 2010 21:59:12 +1100
That is an argument often invoked to support DG, but it doesn't take into
account how replication is done in most modern SAN devices.
For example: in our EMC we replicate the FRA with the last RMAN backup, then
every 2 hours we archive redo logs to FRA and replicate them using asynchronous
command-line initiated replication. Due to the way EMC does replication, any
potential disparity between blocks will get corrected on the next send. And it
has not happened once in nearly 2 years we've been doing it!
Oh, BTW: it's not the disk controller that does that, it's a completely
different mechanism than the SAN disk io. I suspect whoever came up with that
"danger" really hasn't used a late generation SAN.
I'll wear the risk of two consecutive transmission errors on FC - recall that it
is subjected to parity and ECC as well - against what it'd cost us to get an
IP-based connection resilient and performant enough to do DG at our volume and
performance point. In fact, I know exactly what it'd cost us and it's simply
not feasible or cost-effective.
What Oracle should do is make DG independent of the transport layer. IE, if I
want to use Oracle's IP-based transport, or ftp, or scp, or a script, or
navicli, or dark fibre non-IP, or carrier pigeons/smoke signs, it's entirely up
to me and let me do it. There is really no reason why DG has to be IP-only.
--
Cheers
Nuno Souto
dbvision@xxxxxxxxxxxx
David Roberts wrote,on my timestamp of 22/12/2010 6:17 AM:
One point, that I don't see mentioned (unless I missed it) is if you are using
some form of block level replication as a DR solution, what happens when the
disaster is the disk controller writing garbage to your disk.
If you are using DG, then depending on the type you will
get varying early opportunities to spot the corruption or opportunities to
recover from it. Opportunities that are lacking when you blindly have
hardware copping data blocks.
I agree that these are fine solutions to providing development and testing
environments, but I would suggest caution with regards adopting these
technologies for DR purposes.
--
//www.freelists.org/webpage/oracle-l
Other related posts:
