Oracle Data Guard or Storage Based Replication, What’s your pick?

No one wants to compromise when it comes to disaster recovery plan for mission critical applications. What could be the best possible solution so keep services available when disaster happen which is unpredictable in nature? What could be the shortest possible downtime without loosing any data?
As We are concentrating here mainly on application which is using Oracle database in backend hence proposed solutions would be looked at are “Oracle DataGuard” or “Storage based Replication”. As this topic is debatable hence it’s desirable to look at what are the pros and cons w.r.t. both the technologies.
People who supports dataguard mainly argue on  data corruptions that may replicate to DR site by Storage based replication without any check is hard to counter on paper however No one answers why all most critical financial application still rely on Storage based replication? Why several big banks do not support Data Guard as their engineered solution. Let’s go through each technology before We make our mind
Oracle Data Guard
Data Guard is a Oracle tool that has evolved over time. It started out in the Oracle version 7 and 8 period (or maybe even before) where customers used scripting and self-made tools to replicate Oracle archive logs, over some kind of network connection (often over TCP/IP using FTP or NFS protocols to transfer files), to keep a standby database more or less in sync with the primary. Starting with version 8, Oracle developed a management toolset – initially called Managed Standby on top of this and eventually this evolved into a separate tool, currently called Oracle Data Guard.
The purpose of Data Guard is primarily Disaster Recovery (D/R) but, in some cases, you can also use it for backup offloading, data distribution and some other things. Bear in mind that database log shipping for Disaster Recovery evolved over time, and was never designed from scratch as a Disaster Recovery tool. It is still depending more or less on the old log shipping method, even though Oracle did some tweaks and changes to the database software to make it more of an enterprise D/R tool.
For example, normally if you perform non-logged transactions (such as creating an index or load tables using the NOLOGGING option) on the primary database, the changes do not get shipped to the standby (thus, you lose data in the event of a fail-over). Oracle solved this by implementing a “force logging” mode which, if set, forces all transactions to be logged (and therefore shipped to the standby) – with the additional penalty on performance and more logging data to be generated and this can have severe impact on things like Data Warehouse Loading and other sorts of business processing – and the effect of this is often not considered during performance Proof-of-concepts as in such POC’s, D/R is almost never part of the key decision factors. This behavior already suggests that Data Guard depends on careful installation, configuration and monitoring – and a minor bug in the software stack or config setting could render the standby database useless until after a full re-sync. Also, it only replicates database data – one database at a time – and does not care at all for non-database application data, host software, middle-ware or anything else.
Storage Based Replication eg. EMC Remote Replication
Tools such as EMC SRDF and EMC Recoverpoint were designed from scratch as business continuity tools (i.e. Disaster Recovery and to support Backup/Restore scenarios) and, by architecture do not depend on any host platform hardware, operating system, driver, database, application, filesystem, network stack, volume manager or any other component on the application host.
Therefore, these replication methods are enterprise level D/R tools that make sure that all data is always consistent at the fail-over location, regardless of how the host stack is configured. Of course, if the host messes up data due to, for example, application bugs, then the D/R copy also suffers data corruption, but this is explicitly the way these tools are architected. They do not even attempt to solve this form of data corruption or data loss, because this is a function that, in my opinion, architecturally needs to be solved – or better, prevented, by other tools (such as backup/recovery management software, storage snapshot/cloning capabilities, disk check-summing, etc). These storage replication tools can replicate any kind of data, independent from platform, database, application, OS level etc. and don’t even require the host to be up and running at either location. Modern D/R tools allow for multi-application consistency. The tools are designed more or less with “fire and forget” in mind, which means, once set up correctly you don’t have to monitor each individual application, but you typically only monitor the logical link “up” or “down” state per “application consistency group”.
A reported “Link up and in sync” state means that D/R is functional and you’re fully protected. You don’t have to worry about wrong application settings or whatever. Enterprise grade tools also can incrementally re-sync even if there have been changes to app data at both locations (by smartly comparing metadata bitmaps that track differences on both locations).
Architectural differences
Storage and SAN based tools are completely independent from anything that happens in servers, operating systems, databases, applications or middle-ware. The concept is very simple and is very similar to RAID protection in storage arrays, but you basically “stretch” the mirrors of a RAID-1 disk set across two different storage systems in different locations. A very interesting EMC feature called “consistency groups” makes it possible to contain multiple disk volumes that span more than one application into one large, write-consistent pool of data. It does not matter if the database or applications use journalling, logging, or anything else. There even does not need to be a server at the target location (unless you want to perform quick and automated recovery).
By nature, storage mirroring is very simple – you only need two storage systems connected together; you define what volumes belong together for consistency and you switch on remote mirroring. As long as the storage tools tell you that the mirrors are “in sync” then you can be certain that you can fail-over in case of a disaster – and all data is there; including (if you want) Operating System data; middle-ware, application binaries, export/dump files, databases, etc. It only takes a bit of time to enable the remote mirror, start up the servers and bring up the databases to use the remote data set.
Database- or application replication (including Oracle Data Guard) work on individual databases only and have the advantage that the standby database is continuously in recovery mode, so in case of a disaster it is very easy and fast to enable the standby database as new primary. The challenge is then to fail over the remaining application servers, middle-ware, monitoring systems, etc. quickly, consistently and in the right order. After bringing up multiple individual databases it might be that there is application (business) inconsistency between the databases. For example; a logistics database might be interacting with an invoice system. An invoice sent out to an end customer should always match a transaction in the logistics system – to avoid sending the same invoice twice, or vice versa, not sending the right product to a customer even if the order is payed. If one database is recovered to time-stamp X and the other to time-stamp X+Y, then the latter could contain transactions not reflected in the first.
refference here.

Be the first to comment

Leave a Reply

Your email address will not be published.