Re: bandwidth for redundancy

On Wed, 10 Mar 1999 08:42:43 -0800, Peter Sharman <psharman_at_us.oracle.com> wrote:

>If you're a newbie to this, get someone else involved who's done it
>before. I've seen a lot of sites run into problems where someone with
>little experience didn't cover all the bases when implementing disaster
>recovery strategies. I'm not saying you'd run into them, but it just makes
>sense to get help with this.

Peter!

Understood ... unfortuantely for now I'll have to rely on what I can initially conjure up as an implementation plan & a disaster recovery plan. I hope that when I'm ready to plunk down the $$$$$ for the hardware, Oracle, & the front end software I will have the authorization to work with someone who's been-there-done-that.

I had a local Oracle integrator come in some time ago ... this was way before this project materialized. I just wanted to see what it will take to run an Oracle machine & convert all our grassroot database (Paradox & Access) to SQL basaed database. Bottom line it was mainly sales talk & I couldn't get much out of the mtg :-(

>In the broadest sense, Oracle is Oracle is Oracle. It doesn't matter what
>platform it runs on, the SQL will be the same etc. I can't make any
>comments about Oracle on NW because I've never run it, but there are often
>nuances in how it is set up that differ from OS to OS. One thing I would
>say is that there are (in my experience anyway) a lot more people out there
>that are familiar with Oracle on NT than NW. If I had to make a choice,
>though, I'd go with Unix rather than NT anyway, because the OS failover
>capabilities have been around in that world a lot longer than they have on
>NT. Don't know about NW.

Yes, although I lack the expertise of running UNIX my choice will be: UNIX, NW, & NT ... in that order. I'm not really concerned about setting up Oracle on NW assuming Oracle will not drop NW platform all together in the near future. As you say "Oracle is Oracle is Oracle" my understanding was functionalities of Oracle are same on whatever platform you run it on. But as I was reading some docs on OTN it looked like some features, like backup(?), are not easily implemented or even not available from Oracle's mgmt programs on some platforms.

>Is the hot spare in the main site a completely separate box? If so, your
>options are replication and standby database, same as they are for the
>remote site. As a newbie, standby is the most straight forward,
>particularly in 8i where it can be opened read-only, and the redo log
>shipping can be automated in the database (sounds of the Alleluia Chorus
>resound throughout the newsgroup!). That's not the only issue in
>determining which approach is best though.

>Data volumes will determine this. How many redo logs are shipping how
>frequently for standby, transaction rates for replication. There are other
>approaches as well, such as SRDF from EMC. I don't know if that is
>available for NW though.

I'll have to check with the front end software developers but they were saying that we should get Oracle 7.x server (I think it was bundled in their proposal). I'm wondering if this will give us less flexibility for the redundancy if the vendor stays at Oracle 7.x for a while?

From your explanation above I take it that "replication" is where a database on another box that is written to at the same time the main database is written? And "standby" is a database in another box that is sync'd when one sends a redo log? Am I right in assuming that a redo log, when sent from one database to another, is just doing the same update to the receiving database?

Let me take another stab at this. In the main site I want a separate box that will failover when something goes wrong in the primary box. This switch over (failover), other than a small delay, should be automatic. Database will be updated frequently ... maybe I should use the word transactions? Other than that we'll want to do a tape back nightly ... that's our most basic requirement for the disaster recovery.

For the remote site we'll send the redo logs at a preset interval. Then I guess the remote site database is sync'd upto the last redo log. Since it's not realtime this should ease up on the dedicated bandwidth requirement between the two sites separated by hundreds of miles.

>We were all newbies once. If I didn't have my questions answered then, I
>couldn't answer yours now.

Thanx for that last comment ... like I said in the beginning I hope to talk to someone in the know during the process. Your help is greatly appreciated.

TIA.
Robert Received on Sun Mar 14 1999 - 22:10:09 CST