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: <markp7832_at_my-deja.com>
Date: Wed, 09 Jun 1999 14:49:15 GMT
Message-ID: <7jlut7$le1$1@nnrp1.deja.com>


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

Raw partitions are added to a tablespace using the same command as any file is added to a tablespace. It is no more difficult to manage a database built on raw partitions than it is using file systems. Converting an entire database from ufx to raw generally results in about a 5% gain. That isn't much, but it is important. You will find raw partitions easier to work with if you pre-allocate some so you have them available before you need them.

Per Oracle and Unix Performance Tuning by Ahmed Alomari (Oracle Corp. Tuning Specialist) Oracle's prefered I/O method is async. Most Unix systems only support async I/O on raw partitions. Why would build a production database using less than the fastest I/O method available to you?

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

The need to load balance to put updaters on the same machine depends laregely on the application and the amount of update activity on specific objects. Some shops did not know they needed to balance and never run into problems trying to update the same block from multiples users on multiple instances at the same time. We managed to balance fairly well, but some applications are a real problem especially in a client/server based set up.
>
> 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.
>

I have worked with exclusive (traditional) instances of Oracle that have proved harder to manage than OPS. I do not think OPS is difficult to work with if you study it and your application and do some planning. I think it really comes down to how your application works, your user load, your hardware, and the criticality of unplanned downtime. If the machine dies, how long can it be down without hurting the company. If your OPS only for failover you then Oracle's standby database may be another alternate.
>
> 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
>

Mark D. Powell -- The only advice that counts is the advice that  you follow so follow your own advice --

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't. Received on Wed Jun 09 1999 - 09:49:15 CDT

Original text of this message

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