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

Re: Oracle Parallel Server Option

From: Pete Sharman <psharman_at_us.oracle.com>
Date: Wed, 23 Jun 1999 11:43:39 -0700
Message-ID: <37712ADB.1DCD3328@us.oracle.com>


Chris

When in doubt, just enter the thread. Don't worry about where!

There is a specific tool called Oracle Parallel Server Manager that is used to monitor OPS configurations. It's a sort of add on to OEM. OEM itself has some Parallel Server monitoring capabilities as well (you can see the instances involved in an OPS install etc.)

In addition to this, most of the OS's that run clustered configs have some form of GUI Cluster Manager that can monitor when things break etc.

HTH. Pete

chrisoc_at_ans.net wrote:

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

--

Regards

Pete


Received on Wed Jun 23 1999 - 13:43:39 CDT

Original text of this message

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