 |
|
Introduction to Oracle
Cluster Server Architecture
Oracle Tips by Burleson
|
The central
concept behind Oracle Parallel Server (Real Application Clusters) is
that a single database can have many database instances accessing the
database at the same point in time, as shown in Figure 13-1.
Figure 13-109: An Oracle Parallel Server (OPS)
architecture
The advantage of having many instances share
the same database should be obvious to anyone who has ever performed
Oracle tuning. Without RAC, each database instance has only one SGA
region, and this SGA region services the whole database, with no
sharing of the Oracle data buffers, shared pool, and library cache. By
isolating these shared pool and data buffer cache components into
separate instances, you can get tremendous increases in performance
because many independent instances share the same centralized
database.
Real Application Clusters was designed to run
on symmetric multiprocessors (SMP) or massively parallel processors (MPP).
In an SMP or MPP environment, many central processing units are
connected with high-speed links.
With Real Application Clusters, several Oracle
instances run within different RAM, and each independent instance
shares access to the same Oracle tables. Within the Real Application
Clusters, this is called the shared-nothing parallel server
configuration.
There is a great deal of confusion about the
difference between Oracle's Parallel Server and Oracle Parallel Query.
While Oracle's Parallel Query can be used with any computer
configuration, including stand-alone processors, SMP, or MPP servers,
Oracle's Parallel Server can only be used on MPP systems.
The MPP architecture links many processors
together, while each server maintains independence. Each MPP server
has its own memory and processors, but shares a common disk resource.
As such, SMP is sometimes called shared memory multiprocessing and MPP
is called shared-nothing multiprocessing.
Real Application Clusters only works with MPP,
because each node on the MPP box requires its own memory area for the
Oracle SGA.
In Parallel Server, careful consideration must
be given to the uses of parallelism, because the resulting system
could often perform slower than a single-node system. For example, in
Parallel Server, the integrated distributed lock manager (IDLM) may
force the Oracle database writer to write transactions to the database
more frequently than a stand-alone Oracle database.
When planning
for Parallel Server tasks, it is important to segregate specific types
of tasks to specific nodes, as shown in Figure 13-2. For example,
common update routines against customer rows could be segregated onto
node 1, while queries against order rows could be segregated onto node
2. Because each Oracle instance has its own complete SGA, a full table
scan on one node will not flush any data out of the buffer pool of
another node.
Figure 13-110: Partitioning data on an OPS
database
Of course, it is not always possible to
segregate all data into separate buffer pools, especially with a
highly denormalized data warehouse. The Oracle designer will be able
to partition the Oracle instances such that similar data queries are
launched from the same instance, thereby improving the probability
that the data will be waiting in the buffer.
NOTE: It is possible to run Oracle Parallel Query
on a Real Application Clusters system. In this case, the MPP system
would allocate the subqueries evenly across the nodes, and the
Concurrency Manager would coordinate the receipt of data from each
subquery. Of course, this type of parallel query would run faster than
a parallel query on an SMP box because the MPP box has isolated buffer
pools. With SMP, the concurrent queries read their data into a common
buffer pool.
Unlike an ordinary Oracle database, the disk devices for
an RAC environment must be configured such that many separate
instances can read from the datafiles that comprise the database. This
involves the allocation of raw devices. As you may know from
your introduction to Oracle tuning, raw devices can be faster in terms
of data access because they bypass the Journal File System (JFS)
buffer cache in AIX UNIX. However, raw devices are much more difficult
to maintain than traditional Oracle files.
This is an excerpt from "Oracle
High Performance tuning with STATSPACK" by Oracle Press.
 |
If you like Oracle tuning, you may enjoy the new book "Oracle
Tuning: The Definitive Reference", over 900 pages of BC's favorite tuning
tips & scripts.
You can buy it direct from the publisher for 30%-off and get instant access to
the code depot of Oracle tuning scripts. |
|
