Tuesday, 5 January 2010

Extra Cost Option

Oracle's version of the Hot Standby concept is called Active Data Guard. You may know that Oracle11g was the first release of Oracle to have this functionality, so as of PostgreSQL 8.5, we will be on par. Probably worth adding that IBM DB2 doesn't have anything similar.

Someone just pointed out to me that Active Data Guard is an extra cost option with Oracle. Please point this out to your IT Manager!

Oracle suggests the following benefits for Active Data Guard
  • Increase performance—Offload unpredictable workloads to an up-to-date replica of the production database
  • Simplify operations—Eliminate management complexity that accompanies traditional replication solutions
  • Eliminate compromise—The reporting replica is up to date and online at all times, which is not possible with traditional storage mirroring technology
  • Reduce cost—An Oracle Active Data Guard physical standby database can also provide disaster recovery and/or serve as a test database—no additional storage or servers required
I think the first one definitely applies for PostgreSQL. The second and third depend upon what you're comparing against. I don't really understand the last claim: yes, the standby provides disaster recovery, but then so did Inactive(?) Data Guard/Warm Standby. And this idea about test databases seems a little strange, since the standby is read-only its not going to be a very useful test database.

8 comments:

  1. Anonymous5 January 2010 at 23:53

    I think DB2's HADR option would be the equivalent. Although I think it goes a bit further than a simply "hot standby" as it is more a cluster solution than a (hot) standby solution.

    ReplyDelete
  2. Anonymous6 January 2010 at 01:57

    Oracle had "Hot Standby" since 8i. they just renamed it to "x Data Guard" in 11g. One thing to note is that or version is "better" because you don't need to stop replaying logs while running queries.

    ReplyDelete
  3. Simon Riggs6 January 2010 at 02:28

    Oracle introduced Data Guard in Oracle8i, which allowed a physical standby against which you could run queries if you chose to halt recovery of new changes. Oracle 11g allows queries while recovery is in progress, as Hot Standby allows. Both the Oracle and Hot Standby implementations can have conflicts between queries and recovery, and so both can suffer the "snapshot too old" error. Oracle provides only one mechanism to control this, which is to extend the size of the Undo tablespace. Overall, the Hot Standby feature is broadly similar, though the internal implementation for PostgreSQL is completely original. We're not copying Oracle, it has always been "obvious" that we would one day be able to run queries against the standby, although the implementation was very far from obvious.

    DB2 does provide log shipping using HADR but it is not possible to run queries against the standby server.

    ReplyDelete
  4. Greg Jaskiewicz6 January 2010 at 05:43

    Still, slony replication doesn't suffer from "snapshot too old" error.

    I wonder also, does the Oracle's solution require you to copy whole data/ directory upfront to the slave ? Or is it done automagically ?
    It probably also cares about shipping the logs over its own protocol, which makes management easy.

    ReplyDelete
  5. Simon Riggs6 January 2010 at 06:09

    Copying whole database from Primary to Standby server is Step 1 of creating a Physical Standby database using Oracle Data Guard. Oracle doesn't do this automagically, nor does PostgreSQL because we both wish to provide flexibility and allow a variety of mechanisms for making the base backup.

    There are advantages and disadvantages to both logical and physical replication techniques and both will remain useful for many years to come, in different circumstances.

    ReplyDelete
  6. Mark Callaghan6 January 2010 at 13:28

    This feature is awesome but won't be on par with Oracle Dataguard until it works with synchronous log shipping (synchronous replication).

    ReplyDelete
  7. Jakub Wartak10 January 2010 at 14:27

    Simon,
    by the third option they mean utilising Flashback database option on standby. The feature allows you to open read write standby, apply changes and by using minimum sets of commands to flashback database to previous state (so you can test applying some scripts as in Test Env and switch back to "DR mode" without rebuild). Still DG has other nice things :
    1) Broker + Observer mode
    2) the advised mode for Oracle DG is "LGWR ASYNC" in which log writer process sends data to standby asynchronusly (w/o using intermediate archive logs)
    3) Automatic gaps fetching code (FAL)

    (yes, I'm Oracle guy :)).

    ReplyDelete
  8. Simon Riggs10 January 2010 at 14:47

    Good to have comments from non-Postgres people, thanks.

    Flashback is a good feature, but I wonder whether many people really use it like that in conjunction with DG. It's not anything anyone has asked for as-yet, but let's see.

    Streaming replication will give us (2) and (3), plus synch rep.

    ReplyDelete

Subscribe to: Post Comments (Atom)