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

Home -> Community -> Usenet -> c.d.o.misc -> Re: simple 2 machine failover configuration

Re: simple 2 machine failover configuration

From: Pete Sharman <psharman_at_us.oracle.com>
Date: Wed, 05 Jan 2000 13:40:47 -0800
Message-ID: <3873BA5F.4E6415E6@us.oracle.com>


Rainer

Comments inline

Pete

Rainer Mager wrote:

> Hi Pete (and all),
>
> Thanks for the info. I'm quite new to Oracle so I'm not sure what type
> of info is needed to make a good decision on this. I've included a bit more
> info below but if there is something critical I need to consider please tell
> me.
>
> We're creating a relatively small DB, maybe a total of 50,000 records.
> About 20,000 of those records will be quite small, less than 100 characters.
> The remaining 30,000 will be larger, possibly a few K bytes.
> The 20,000 group will be updated once per minute (we may be able to
> optimize this so it is not all 20,000 but for now I'll assume all 20k). The
> other 30k are updated much less frequently and should be no problem. All of
> these record updates (writing) will come from a few well-known clients.
>
> Now, what we need to for multiple diverse clients to access the DB
> querrying the above records. The frequency of these queries is much less
> well-defined but can be assumed to be at least a few thousand queries per
> minute.
>
> The end goal here is to make sure the the clients making the queries can
> always contact the DB transparently. For now we have two machines to handle
> this. If one goes down the other should be able to handle everything without
> the clients even knowing there was a failure (well, clients connected at the
> time of failure would know but that's ok). If this is particularly
> difficult, a small down-time is ok if it is on the order of 1 minute or so.
>
> Today we do not have the goal of improving DB performance by using 2
> machines, we only are doing that for the fail-safe configuration. In the
> future we may want to improve performace by adding more machines. This is a
> consideration but not critical...yet.
>
> In regards to your comments:
>
> > 1, Replicate the database in its entirety using Advanced Replication -
> may not
> > be possible with throughput needs, you need to worry about conflict
> resolution
> > etc.
>
> I'm not entirely familar with Advanced Replication but from what I know this
> should be possible on the data side of things. If this is done, however, how
> does the "backup" DB transparently take the primary's place in the case of a
> failure?

You can configure this through your tnsnames.ora entry. Simply give a single alias two addresses. Then if you can't connect to the first one, it will fall through and try to connect to the second. I'm assuming here that both sites are masters in a replication sense, so there is nothing to configure to allow the second site to take the first one's place. The thing you will need to be concerned about is the possible data loss of data that hasn't yet been replicated.

> > 2. Use OPS if you have a clustered configuration - there may be issues
> here
> > with pinging, though this is lessened with 8.1 and cache fusion (in the
> > read-write scenario anyway).
>
> I'm not familar with OPS or cache fusion. Could you give me some more info
> on this?

50,000 ft level. OPS is Oracle Parallel Server. In a clustered configuration, you can have two nodes accessing a single shared database on shared disk. There are separate instances (SGA + background processes) on each node. The main problem with OPS in the past has been active-active access (active from each node). This can cause pinging, where blocks needed on one node are in the SGA of the other node. Prior to 8.1, this caused a disk write, and this could mean applications that didn't understand this would perform badly. In 8.1.5, we have the first release of cache fusion, where if one node wants to write the block and the other wants to read it, the block can be passed through memory between the two nodes instead - much faster, less performance impact. The next release of cache fusion is supposed to help with the write-write scenario.

> > 3. Use cluster failover at the OS level. Script the restart of the
> database
> > on the second node.
>
> I understand the OS level of this but how would the 2 machines maintain
> identical DBs? Using method 1 above?

They don't need to. The database is built on shared disks that are available to both nodes of the cluster.

> > 4. Standby database - may not meet the needs, but in 8.1 you can open the
> > standby database in query only mode.
>
> How does the standby become the main one? How does it then handle the
> queries transparently? This may be a good solution but I don't know enough
> about it.

You would need to write a simple script that would activate the standby. You could do something like getting Enterprise Manager to monitor the two machines, and if one goes down run a fixit job that activates the standby, I suppose. Haven't tried that, but I can't think of any problems with it.

> > There's not enough information in your post to advise you on the best one,
> so
> > investigate these a little further.
> >
> > HTH.
> >
> > Pete
>
> Thanks for the info. Any further advice would be greatly appreciated.
>
> --Rainer


Received on Wed Jan 05 2000 - 15:40:47 CST

Original text of this message

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