Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: bandwidth for redundancy

Re: bandwidth for redundancy

From: Peter Sharman <psharman_at_us.oracle.com>
Date: Mon, 15 Mar 1999 10:04:56 -0800
Message-ID: <36ED4BC8.AB6E7C78@us.oracle.com>


Robert

Comments inline.

Pete

> 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.

I don't know what document you saw here. Generically, the backup functionality until Oracle8 was to rely on an OS tool to perform the backup. You would either shut the database down for a cold backup or turn the tablespaces into backup mode for hot backup, then simply copy the files somewhere else using whatever backup tool was available at the OS level (again my ignorance of NW means I don't know what tool was available here). In 8.0, rman became available. It integrates with media management software such as Legato. If the media management software is not available on a particular OS, then rman obviously can't integrate with it.

Having said that, I've heard nothing internally or externally to say Oracle is moving away from NW. In fact, quite the opposite, as there have been some joint press releases between the two companies recently.

> 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?

I wouldn't say less flexibility. You just may not be able to take advantage of the enhancements in the new releases. For example, replication in Oracle7 was generally thought to be capable of handling up to 10-15 tps (depending on your app). In Oracle8, the throughput can be much higher (up to 20-100 tps). In 8i, the redo shipping of standby is automated, if you run 7.3 then you need to script it.

> 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?

Replication in Oracle is trigger based at the transaction level. When a DML operation takes place, triggers on the table fire to copy the changed information to a queue. At user defined intervals the queue is pushed to another database, usually on another machine. Because it's transaction based, and the other database is available for DML at the same time, you may need to handle conflicts, where two users, one on each database, change the same row. Conflict detection is performed automatically, and Oracle provides you with a number of resolution methods you can use, or you can write your own. It's more complex to configure and maintain than standby.

Standby is provided in 7.3 and up using redo log shipping. Once the redo log is filled up, it is copied to the remote machine (by Oracle in 8i, by something you set up before then), where another database is mounted, and permanently in recovery mode. You apply the redo log in exactly the same way as a normal database recovery. Because this database is mounted but not open, other users aren't connected, hence you don't have the issues of conflict detection and resolution, and it's easier to maintain.

> 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.

This is what standby is used for, rather than replication. If you're running 7.3 or 8.0, you need to put some smarts in your ftp script to only copy full logs and so on.

> >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

No problems.

--

Regards

Pete


Peter Sharman                             Email: psharman_at_us.oracle.com
WISE Course Development Manager           Phone: +1.650.607.0109 (int'l)
Worldwide Internal Services Education            (650)607 0109 (local)
San Francisco

SQL> select standard_disclaimer, witty_remark   2 from company_requirements;

Opinions are mine and do not necessarily reflect those of Oracle Corporation

"Controlling application developers is like herding cats." Kevin Loney, ORACLE DBA Handbook
"Oh no it's not! It's much harder than that!" Bruce Pihlamae, long term ORACLE DBA



Received on Mon Mar 15 1999 - 12:04:56 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US