Call (800) 766-1884 for Oracle support & training
Free Oracle Tips


Oracle Consulting Support
Oracle Upgrades
Use New Oracle Features
Oracle Replication Support
Oracle Training
Remote Oracle DBA
System Documentation
Oracle Tips
Oracle Performance
 

Free Oracle Tips


 

HTML Text

BC Oracle tuning

Oracle training

Oracle support

Remote Oracle

 

 

   
 

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.

  
 

Oracle performance tuning software 
 
 
 
 

Oracle performance tuning book

 

 
 
 
Oracle performance Tuning 10g reference poster
 
 
 
Oracle training in Linux commands
 
Oracle training Excel
 
Oracle training & performance tuning books
 

 

   

Copyright © 1996 -  2014 by Burleson. All rights reserved.

Oracle® is the registered trademark of Oracle Corporation. 

Hit Counter