Oracle8i Parallel Server

[Frank Seifert]

can I apply the Oracle8i (8.1.7) Parallel Server Option on a system of two HP9000 K210 Boxes (including gigabit interconnect)?
thx
Harald

[Ravi_8]

Hi,
one system can make parallel server, but making 2 systems as parallel server is a waste of resource. instead you can use snapshot

[Alexander M. Ermes]

Hi there.
You can use it, but as the man before me told you, it is a waste of resources. Anyway, my two cents to this :
Parallel server license is more expansive, as far as i know. Don't use it, if it is not absolutely necessary.
Rgds
Alexander M. Ermes

[Frank Seifert]

The requirement of Parallel Server calls HA 99,7% 24x7.
Harald

[Alexander M. Ermes]

Hi there.
why not think about a HA cluster instead of a parallel server ?
Rgds
Alexander M. Ermes

[Jared Westgate_1]

Hello Frank,

I don't see why you wouldn't be able to make a parallel server out of this configuration. Of course, you would get the best performance if your database storage was on a very fast standalone array.

I've never set one up, but I do think there are advantages to having an Parallel Server setup. First of all, I don't think it'd be a waste of resources. If you have two machines serving one database, there should be a performance increase (assuming your disks can keep up). You would probably want to use RAW devices (I think I remember Oracle recommending them with its OPS option).

Of course the main advantage is having the instant failover. I'm sure you can setup something similar using clusters, but you'd still have to setup a standby database. Standby databases can be tricky, they aren't necessarily always a duplicate of the master database (it depends how often you have your log switching taking place).

I'm sorry I'm not more help on your actual question, but I thought you'd like some input from a different viewpoint.

My two cents,

Jared

[Graham Cameron_1]

We have just replaced our OPS config on a pair of V-classes with a conventional installation on a more powerful single N-class box.
The OPS worked well, but needed a very high level of admin. For example, raw file systems are mandatory, and the architecture is complex.
Nevertheless it did give a resilient solution and was popular with the DBA team. The main reason for moving away was the high cost of providing equivalent dev and test environments. Many applications which worked well in the non-OPS test systems, caused lock and latch contention in the OPS production system.
Whilst technically challenging, the business had to take a pragmatic view, so RIP OPS.