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