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.
- 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.
- The clustered failover required a cluster specialist
to come and write and test all the Unix failover scripts.
- 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.
- 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.
- 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.
Received on Tue Jun 08 1999 - 12:37:15 CDT
