Oracle DataGuard VS Storage Replication
Recently, I was involved in various projects on the design of the DR solution for Oracle databases. This question popped up at almost every time. I strongly believe that Oracle DataGuard is the correct solution for any Oracle DR solution.
Oracle DataGuard comes free with Oracle Enterprise Edition (EE)! The only reason why a company might NOT use Oracle DataGuard is because they are not on EE and the cost of upgrading to EE just to use DataGuard does not justify the price.
Lower Bandwidth Utilisation
An insert to a table in Oracle generates alot of IO activities.
- 8k insert into table
- update of leaf indexes
- 8k block of undo generated
- redo log generated
- archive log generated
All these unnecessary IOs are replicated to your DR site. If you are using DataGuard, only the stream of redo will be sent over to the DR 🙂 Link
Lower Complexities and easier to manage.
During DR implementation.
The steps to create an Oracle DataGuard configuration are very well documented and straightforward. It is especially so if you are an Oracle DBA. If you find that the manual configuration (link) are too difficult, you can always create the physical standby using Oracle Enterprise Manager (OEM).
However, for storage replication, the LUN configuration must be extremely precise. All the LUNs used by the same database should be in the same consistency group. If it is a RAC database, then the OCR diskgroup must not be mirrored.
During DR exercise.
In Oracle DataGuard, to switchover to the standby database, you will only need to run a single command through the DataGuard broker.
DGMGRL> switchover to 'standby';
However, if we were to use storage replication, we will have to perform the following. Do note that all these steps are manual unless you can script them to run automatically.
- Break mirrored LUN
- Mount LUN onto standby database
- Startup database (Database will perform automatic instance recovery)
Data Block Corruption Detection
DataGuard is able to detect block corruption automatically as long as you have the parameters configured in the SPFile.
Storage replication does not have such capability because it does not have visibility in the Oracle database. To the storage layer, everything is in OS data block.
Oracle DataGuard Rolling Upgrade
Oracle DataGuard has a feature called rolling upgrade. It is part of the Oracle Maximum Availability Architecture (MAA). The purpose of rolling upgrade is to reduce/prevent planned downtime.
The concept of rolling upgrading is simple;
- Patch the standby database first
- Test if the patch is working
- Switchover to standby database
- Upgrade primary database
- Switchback to primary database
- DBA saves the day!!
If you are a more paranoid DBA, you could do the following prior to the steps above to further test the patch/upgrade;
- Snapshot the primary database LUNs
- Mount the snapshot as a test database
- Run a test patch on the test database
- Destroy the test database
I am an Oracle DBA by nature and an Oracle DBA likes full control. By using DataGuard, I have absolute control over the DR solution. I will not have to depend on the storage engineer and system engineer during the DR exercise. This is precisely why ASM technology was created, to allow DBA to have control over the database filesystems. Why would you want to have multiple stakeholders in the DR exercise when you can have a single person to do everything (hint:DBA!).
Of course, all the reasons above are pertaining to Oracle database. Storage replication is still a major advantage to have in your DR solution arsenal. It is perfect for non-clustered application.