Re: Oracle Parallel Server Option

Billy

Just two comments. Firstly, on the multiple skilled sysadmins. I've worked on a site where we lost the database and had to recover due to a *&&%# sysadmin mounting one of the raw devices containing a datafile. Maybe saying "multiple skilled" is overkill, but better safe than sorry! Secondly, I don't think you'll see any move from Oracle away from parallel processing - as for the DBA who made the comment originally, I'd love to know where he got that from!

Pete

Billy Verreynne wrote:

> 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

--

Regards

Pete

Received on Thu Jun 24 1999 - 10:50:52 CDT