Skip to Main Content
  • Questions

  • Advantages and disadvantages of using Shareplex vs Dataguard for disaster recovery

Breadcrumb

Question and Answer

Connor McDonald

Thanks for the question, Babu.

Asked: February 21, 2017 - 12:08 am UTC

Last updated: March 07, 2017 - 11:34 pm UTC

Version: Enterprise version of 11204

Viewed 1000+ times

You Asked

Hi AskTom,

Just need some advise on the setup of our database environment. We will have production instances A and B. A is live for external business and B is an exact copy of A but is used as operation data storage (B is live datawarehouse env). We are using shareplex to replicate data from A to B real time. We are also using shareplex to replicate data from A to A_DR (a disaster recovery env for A in a different datacenter).

The reason to use Shareplex for DR (A to A_DR) is that there is a need for some tables in A_DR to not to replicate data from A. Those few tables are very small and are tables that store non-persistent data about application servers and they dont need that data on DR site. So it was designed before me, to use shareplex to replicate the remaining tables to the DR environment.

How ever, by using shareplex, I am worried about the lag between A and A_DR. Instead I am proposing to use dataguard (physical standby) for DR and when the DR (test) happens, fail over A to A_DR, truncate the tables in A_DR that doesn't need data to replicated and open it for business. So baiscally I am trying to find the pros and cons of using shareplex vs dataguard for DR.

I have the following advantages, can you pls list any other disadvantages of using shareplex for DR.
No cost, supported by oracle, over head on primary db is less, near zero data loss etc.
Is there any added advantage in terms of corruption check with dataguard that cannot be done thru shareplex ?

Pls also verify if it is a good option to use dataguard and truncate the list of tables that doesn't need data from primary site. (If necessary we can setup a daily export dump of those few tables in A and make the dump available in A_DR in case they need it for later revision)


and Connor said...

Benefits of DataGuard

- You can run your production backups off the standby node, so your production database cpu is used for users, not for backups

- Block recovery can be done automatically, ie, a bad block on production can be fixed by accessing the standby copy

- Snapshot standby, you can open the standby read/write but then trivially flick back into recovery mode, and guarantee that it is back in sync with Production

- Other forms of recovery (datafile etc) can be done using the standby as a source

- Standby can support transparent application failover, yielding near zero-time outages in the event of a switchover.

- A constant validation of the integrity of your redo logs as they are applied to the standby

All of which are good... but of course, the real selling point is that once you've committed to having a DR database, DataGuard is zero cost option.

I see no issue with your strategy of truncating the tables etc.


Rating

  (2 ratings)

Is this answer out of date? If it is, please let us know via a Comment

Comments

Babu, March 07, 2017 - 3:24 am UTC

Mr McDonald, Thankyou very much for the answer. A followup question pls.

In general, in high oltp systems, which would be faster? shareplex or dataguard ? Shareplex will extract sql from the redologs, ship and apply them on destination, while dataguard will ship the redolog and apply it. Can you please touch on the performance in both the scenarios ?

If shareplex is used for DR, it opens the DR db in read write mode and that scares me very much. Any inadvertent changes to the data is only recognized when the disaster (or a test) happens and we bring up the application on DR database.

What about corruption ? How can dataguard help with corruption that shareplex cannot ?

Please share your thoughts. Thankyou
Connor McDonald
March 07, 2017 - 11:34 pm UTC

DataGuard (DG) will be more efficient because it does not need to resurrect the commands from redo, it simply applies the redo.

I prefer DG because it gives you in effect binary copy of the source database - it is (by definition) an exact replica. It is also adding the bonus of testing the integrity of your redo logs, because it is going through the exact same recovery operations that you would need to do on your primary database.

In terms of corruption, a DG database can be used to source a correct block and then use it repair a corrupted block on the source.

Babu Madala, March 08, 2017 - 3:54 am UTC

Thankyou
more

Connor and Chris don't just spend all day on AskTOM. You can also catch regular content via Connor's blog and Chris's blog. Or if video is more your thing, check out Connor's latest video and Chris's latest video from their Youtube channels. And of course, keep up to date with AskTOM via the official twitter account.