Re: DR Options.

From: Mladen Gogala <>
Date: Mon, 9 Mar 2009 22:09:28 +0000 (UTC)
Message-ID: <gp442o$omt$>

On Mon, 09 Mar 2009 18:54:33 +0000, Preston wrote:

> We're looking into providing an off-site disaster recovery server for
> some of our clients, & I'd appreciate some input on the best way to do
> this.
> All the clients' databases are 11g Standard Edition on Windows servers,
> typically 5 - 10gb, up to 20 concurrent users, & all use archive log
> mode. A full RMAN backup is done every night.
> The plan is to put a server in a datacentre, with one or two databases
> containing a schema for each client. We'll then synchronise each schema
> with the clients' live data every hour or so (it doesn't matter if they
> lose an hour's data). If a client's own server goes into meltdown, they
> can connect to ours using terminal services & carry on working until
> their server's repaired.
> So the question is, what's the best way to keep our DR server
> synchronised (more or less) with the clients' data, bearing in mind most
> of them only have standard ADSL connections?

Hmmm, there are 3 options for that:

  1. Physical standby
  2. Logical standby
  3. Streams replication.

There are quite a few issues to consider:

  1. Physical standby requires the cheapest license. With 11g, you can even use it for testing because 11g can use something called "snapshot open". Essentially, you can open the standby database, do thy testing and, when finished, flash it back to the SCN at which you cancelled the recovery and continue treating it like a physical standby. It's a new feature in 11g. I tested it and it works. I wouldn't use it to run reports on regular basis as this requires quite a bit of manual labor. The entire redo logs are being transmitted accross the link, so if the rate of change is high, the link will be saturated. You should recommend cable modems to your customers, they have much better upload speed then DSL, while being in the same price range.
  2. Logical standby is more advanced type of standby database which uses a full oracle license and can be used to regularly run reports on the standby database. The primary database also sends an entire archive log across the link but, instead of being used for the database recovery as with the physical standby, log miner is used to extract the SQL and apply it to the database. Not only does logical standby require a full license, it is also much more expensive in terms of processing power. Log miner must have its resources.
  3. Streams replication works on the same principle as the logical standby, but it isn't a standby database. It is log miner on steroids, it captures data changes, transforms it into SQL on the recipient side, possibly transforms it in the process, and applies on the recipent side. It's a replication of a schema or table, not a replication mechanism for an entire database. That will help you if you want to replicate several schemas on several databases into several schemas on a single database. This also requires a full license and quite a bit of processing power. There is also an administrative cost because you have to stop capture and propagation before you shut down the database you are replicating. Furthermore, it's harder to diagnose STREAMS problems than it is to diagnose standby problems. You will also need a DBA with considerable experience to configure STREAMS properly.

Also, the main question your clients should be asking yourself is how much data can they afford to lose? With such small databases, backups are really fast, even if you use compression. Maybe a good backup strategy is all that your clients need, which would save them money for buying additional licenses and network capacity. Being that Oracle RDBMS is the mightiest database in the world that can recover from the most failures, you gotta ask yourself one question: do I feel lucky?

Received on Mon Mar 09 2009 - 17:09:28 CDT

Original text of this message