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: Oracle Parallel Server Option

Re: Oracle Parallel Server Option

From: <chrisoc_at_ans.net>
Date: Wed, 23 Jun 1999 18:05:27 GMT
Message-ID: <7kr7kv$dus$1@nnrp1.deja.com>


Excellent thread on OPS. Not sure where to enter it, but I have a question about monitoring OPS configurations.

Can you expect the Intelligent Agent forward info about a node or SID outage onwards ... do you rely upon monitoring the hardware and OS to detect that a failover has occurred ... or what?

Chris O'Connor

In article <7jjkca$r7q$1_at_nnrp1.deja.com>,   RTProffitt_at_beckman.com wrote:
> There are a few downsides to OPS.
>
> We tried to implement a large system for supporting
> a shop floor at my previous job. Oracle 7.3.4, OPS
> on Sequent clustered failover boxes.
>
> 1. In order to do OPS, you must use RAW not COOKED filesystem.
> This means that it is difficult to add more disk space, or
> alter the tablespaces... RAW is difficult to work with and
> requires the intervention of the System Admin.
>
> 2. The clustered failover required a cluster specialist
> to come and write and test all the Unix failover scripts.
>
> 3. high cost. We never realized the original perceived
> need for high availability and failover. In reality, the system
> never needed 24 x 7. And the issue of load balancing, that is,
> putting people on different instances who tend to access different
> tablespaces/tables for best performance, was completely negated
> by the application, in which each person crossed many tablespaces
> at all times.
>
> 4. It's true there are other failover methods that don't involve
> OPS. OPS's biggest strength is the two instances can share the same
> database at the same time....but this is offset by its high cost, and
> manageability.
>
> 5. Our DBA informed us that Oracle no longer recommends OPS, and
> that various companies are moving away from OPS. In the end, we also
> decided that managing RAW was too much trouble, and given the
> opportunity, we would have rebuilt the entire database as Non-OPS,
> using "cooked" Unix filesystem, with alternative manual or scripted
> standby failover.
>
> Robert Proffitt
> formerly Boeing Long Beach
> RTProffitt_at_beckman.com
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
>

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't. Received on Wed Jun 23 1999 - 13:05:27 CDT

Original text of this message

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