Re: Oracle Parallel Server Option

Apologies for jumping in this late, but I just happen to see this thread now. And of course I can not keep quite when OPS is discussed. :-)

>In article <7jjkca$r7q$1_at_nnrp1.deja.com>,
> RTProffitt_at_beckman.com wrote:

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

I disagree. RAW is not difficult to work with. In fact, in many ways it is easier to work with it. One RAW device = one single Oracle datafile. One COOKED device = multiple directories and multiple Oracle datafiles.

RAW devices do not need to be mounted, so no /etc/fstab, mount and fschk problems.

To configure a RAW device on a Reliant cluster - vdconfig. Pretty simple and straight forward. And I'm not UNIX sysadmin myself.

My biggest beef about using RAW is overheards. I lost 10MB per GB. And this adds up if you're running a VLDB.

IMHO that statement in the Oracle Server Manual about not using RAW devices unless you are or have dedicated UNIX sysadm's or experts is bull. And I base this on personal experience.

>> 2. The clustered failover required a cluster specialist
>> to come and write and test all the Unix failover scripts.

Disagree. Maybe this is vendor specific. All the scripts and stuff we wrote were done in-house. The only time we really really needed outside help (after initial installation and setup) was with the configuring of the DLM (Distributed Lock Manager).

>> 3. high cost. We never realized the original perceived
>> need for high availability and failover. In reality, the system
>> never needed 24 x 7.

Very, very true.

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

We used Distributed TCP/IP that perform some basic load balancing. Disk i/o access should not be a problem ever on a cluster - if it is, then the data spread is wrong and the database incorrectly setup IMHO. Or there's something wrong with the cluster. It should not matter if a Oracle session on node 1 is accessing raw disks on the SCSI controller of node 4, or accesing local raw devices on its own SCSI controller. MPP clusters are specifically designed at hardware level to deal with this.

To achieve a proper load balance does require manual intervention - and with load balance I refer to spreading the of CPU loads. Data should be "load balanced" already by spreading the data across as many disks as possible.

The manual intervention we used was a bit primtive - basically all we could do was play around with the PARALLEL clause of tables in order to try and spread the PQ processing evenly. Most times it work OK. A few times not.

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

Yes and no. High cost yes. Manageability? It's easier to administrate a 10 node OPS cluster than 10 Oracle databases on 4 SMP boxes IMO. What lacks are proper OPS admin tools - or lacked. I'm refering to OPS 7.x which I worked with. OPS 8.x supports new global views and stuff that makes it a bit easier.

Even so, we developed a small set of scripts to administer the cluster and OPS and rdist them to our heart's content.. :-)

>> 5. Our DBA informed us that Oracle no longer recommends OPS, and
>> that various companies are moving away from OPS.

And you actually believed your DBA! ;-) Hey, OPS is GREAT. I was very privileged to have been able to cut my teeth on it when I first got into Oracle. And I believe that Oracle will make a MAJOR mistake if OPS is not a corner stone of their future strategy. Parallel processing is the -only- way to handle VLDBs.

regards,
Billy Received on Thu Jun 24 1999 - 10:05:09 CEST