Primary and Secondary Instances
With OPS a primary instance is the active instance to which clients connect as with the
default OPS configuration, however a secondary instance is configured to only accept
client connections in the event of the primary instance failing. This avoids the extra load
being passed on to the other active instances.
While the routing of transactions to specific instances is manually configurable, OPS
Primary/Secondary instance feature is able to perform this operation automatically.
The Primary/Secondary Instance feature provides:
1) A transition path for getting to an N-node configuration.
2) A highly available solution for applications that do not scale beyond one node
Transition Path to N-node Configurations
Using the Primary/Secondary configuration is a gradual way to migrate your application
environment to an Oracle Parallel Server environment. Since all the client transactions
are being performed on only one node at any given time, the Oracle Parallel Server
tuning issues are minimized. Troubleshooting system problems is also simplified because
you tune only one node at a time as opposed to simultaneously tuning two or more
nodes.
Since availability is also dependent on the Database Administrator's ability to manage,
tune, and troubleshoot the environment, the Oracle Parallel Server Primary/Secondary
configuration provides a gradual way to ease the Database Administration staff into using
Oracle Parallel Server.
Availability Solution for Applications That Do Not Scale
Applications may not scale beyond a single instance for a several reasons. The most
common reason is application level serialization points. When the application design
causes it to bottleneck on a single application resource, the application cannot scale
beyond the capacity of that resource.
There may be other reasons why an application cannot scale. Update intensive and nonpartitioned applications, for example, may not scale very well because of Oracle Parallel
Server's disk-based synchronization mechanisms.
In such cases, the cost of synchronization or block pinging can be excessive. However,
the extensions to the Oracle8i Cache Fusion technology will make this issue one of
diminishing importance to consider.
User environments that fit into one of the above two categories may favour the Oracle
Parallel Server Primary/Secondary Configuration.
Oracle 9i RAC
Real Application Clusters (RAC) is a feature in Oracle9i Database that can greatly
enhance an application’s scalability and availability. RAC is an Oracle database that has
two or more instances accessing a shared database via cluster technology. A cluster is a
group of machines (or nodes) that work together to perform the same task.
RAC architecture enables users and applications to benefit from the processing power of
multiple machines. This architecture also achieves redundancy in the case of, for
instance, a system crashing or becoming unavailable; the application can still access the
database on any surviving instances. To support this architecture, two or more machines
that host the database instances are linked by a high speed interconnect to form a
cluster. The interconnect is a physical network used as a means of communication
between each node of the cluster. RAC also provides system redundancy to make an
application more available to provide consistent, uninterrupted service, even during
failures.
Using the cache fusion technology of Oracle9i RAC, applications can achieve near linear
scalability and performance. RAC’s cache fusion technology increases the size of the
available working cache by uniting all the cache's in the cluster database
Cache Fusion
Cache Fusion is a new parallel database architecture for exploiting clustered computers
to achieve scalability of all types of applications. Cache Fusion is a shared cache
architecture that uses high speed low latency interconnects available today on clustered
systems to maintain database cache coherency. Database blocks are shipped across the
interconnect to the node where access to the data is needed. This is accomplished
transparently to the application and users of the system. As Cache Fusion uses at most a
3 point protocol, this means that it easily scales to clusters with a large numbers of nodes
Cache Fusion is a mechanism that gives Real Application Clusters near linear scalability.
By default, a resource is allocated for each data block that resides in the cache of an
instance. Due to Cache Fusion and the elimination of disk writes that occur when other
instances request blocks for modifications, the performance overhead to manage shared
data between instances is greatly diminished. Not only do Cache Fusion's concurrency
controls greatly improve performance, but they also reduce the administrative effort for
Real Application Clusters environments. Cache Fusion can exponentially increase
processing power in a Real Application Clusters databaseEach node of a cluster that is
being used for a clustered database will typically have the RDBMS and RAC software
loaded on it, but not actual datafiles (these need to be available via shared disk). For
example, if you wish to run RAC on 2 nodes of a 4-node cluster, you would need to install
the clusterware on all nodes, RAC on 2 nodes and it would only need to be licensed on
the two nodes running the RAC database. Note that using a clustered file system, or NAS
storage can provide a configuration that does not necessarily require the Oracle binaries
to be installed on all nodes