Re: Oracle Parallel Server Option

There's one point in here that really requires comment. Oracle DOES recommend the use of Parallel Server when it's needed. ANd that's the big point - when it is needed.

[On soap box]

One of the real values in Parallel Server is the scalability beyond the capacity of a single node. Standard Oracle along with things like MC/ServiceGuard amounts to a Mode 2 (= Mutual Takeover) cluster configuration, where a given set of disks and data files are owned, and only visible to the primary node, and ownership shifts to the backup node in the event of a node failure. Parallel Server, combined with things like HP MC/LockManager amounts to a Mode 3 (Distributed Load) cluster configuration where a given set of disks are equally and simultaneously accessible by all nodes in the cluster. This allows us to distribute Oracle workload across multiple nodes for scalability.

Most hardware and OS vendors that I'm aware of (with the exception of Microsoft), offer both a Mode 2 and a Mode 3 clustering solution. (i.e. one for high availability/failover only, and one for H/A AND scalability). Both solutions work very well, so the question is which is right for any given set of requirements.

Parallel Server has a couple of additional benefits:

1. Protection from instance failure as well as node failure
2. Potentially faster failover times
3. No scripting required to configure and maintain the H/A environment for Oracle.

This last point can be significant. Most OS failover solutions like MC/ServiceGuard require some substantial scripting or provide an API for configuring the failover, and will require good coordination between the DBA and Sysadmin to maintain, which, depending on the customer, can be problematic. The benefit is that this type of failover solution can be implemented entirely transparently to the application.

Parallel Server is comparatively simple to set up, configure, and maintain, but the tradeoff in complexity is that you need to understand what it means to design and build scalable applications to leverage a Mode 3 cluster implementation.

[Off soap box]

A couple of other minor comments:

1. Parallel Server does NOT require raw filesystems where the operating system is capable of handling sharing of files across nodes. For example, OPS on VMS (where it originally came from) does not use raw filesystems. The need for raw is thus more of an operating system requirement, not OPS.
2. Raw filesystems are used at a lot of non-OPS sites for perceived performance reasons. I believe this is less the case in NT, but I haven't seen enough figures to reliably quote this.
3. The application mentioned in the earlier message is an obvious problem child for OPS. OPS works best with partitionable applications or read-only data, BUT can still work well with other data sets as well. It may require more work to configure it for optimal performance, and it is best in these cases to use someone who's done it before. Of course, this requirement is being negated to a large extent by Cache Fusion in 8i.

HTH. Pete

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.

--

Regards

Pete

Received on Tue Jun 08 1999 - 15:16:18 CDT