Oracle10g Tuning with RAC Oracle Tips by Burleson Consulting

Introduction to Tuning with RAC

The use of Oracle Real Application Clusters (RAC) is a complex and robust Oracle solution that provides infinite scalability and instant failover.  Originally, this approach was named Oracle Parallel Server (OPS).

Oracle RAC is the flagship Oracle product, designed to provide high availability and scalability for large, mission-critical applications. Oracle RAC technology is the foundation of Oracle Grid computing.  Grid computing contributes the “g” in Oracle 10g. When combined with the Transparent Application Failover (TAF) option, Oracle RAC can reconnect failed connections to a failover node without the client even being aware of a server failure.

Highly available and scalable server- based computer systems and applications are an essential part of today’s internet-based business environment. This availability and scalability are achieved by clustering technology and fault tolerant systems that allow seamless addition of computing resources to Oracle.  This chapter will provide a closer look at high performance computing trends for Oracle RAC database systems.

Oracle RAC and Oracle10g Grid are unique and complex technologies and have very different tuning procedures.  This chapter will cover the following RAC tuning topics:

§         RAC and Grid in a nutshell

§         Inside Oracle 10g Grid computing

§         Configuring RAC and Grid for top performance

§         RAC node load balancing for optimal performance

§         RAC parallelism for high performance

§         Monitoring RAC performance

A quick look into the Oracle10g RAC and Grid architecture is presented in the next section.

Oracle RAC in a Nutshell

In a nutshell, Oracle RAC is a complex database architecture where multiple RAM memory regions and processes and Oracle instances share a common set of database files.  Figure 20.1 is an illustration of the complex RAC structure in Oracle. 

Because there are many Oracle instances sharing the same data files, a large component of Oracle RAC is managing concurrency between the database instances.  These concurrencies are called nodes in RAC terminology.  In order for the multiple Oracle instances to share data from the caches, a special set of processes called cache fusion” manage the pinging of data blocks back and forth between the instances.

The essential differences between a RAC cluster and a non-RAC Oracle database are very simple.  These differences pose unique challenges for the Oracle tuning professional, and this chapter will be dedicated to understanding these differences and learning to tune a massively parallel database:

§         Multiple servers:  Because RAC has many database servers, each server is totally independent.  When an Oracle system becomes CPU-bound and all tuning has been completed, a new RAC node can be added to the cluster.

§         Sharing data blocks between instances: Because many Oracle databases have a working set of commonly referenced rows, such as lookup tables and shipping codes, Oracle RAC uses cache fusion processes to transfer these data blocks between multiple instances. Cache fusion is used to provide read consistency to the application. In many non-Oracle databases, read consistency is ensured by using locks. In contrast to that, main mantra of the Oracle RDBMS is that readers do not block writers. On a single instance, this is achieved by reading blocks from the undo segments.  It is less obvious how to do that when multiple instances are accessing the database. The process that creates the image of the block up to requested point in time and ships it to the requesting instance over the private interconnect is called the cache fusion. An alternative is the process by which the requesting database would force the database which owned the locks on the requested blocks to release them and flush the requested blocks to the disk. The requesting database would then read the blocks from the disk. That was the case in the predecessor of RAC, called OPS (an abbreviation for “Oracle Parallel Server”).

§         Dynamic resource allocation: This ability to have many instances allows the RAC DBA to add additional servers, with a new instance on each server, whenever Oracle requires more processing power.  Oracle10g Grid technology is all about the intelligent allocation of RAC server resources via the Oracle10g Enterprise Manager Grid control screens.

These differences appear simple on the surface, but there are some extremely complex techniques that are used to ensure the top performance of a RAC or Grid database. 

It is critical to understand that Oracle RAC is not for every Oracle database, and it is almost always used in super large, mission-critical systems and web database that must support thousands of transactions per second.  Oracle RAC is primarily used in these types of shops:

§         Low tolerance for downtime: By having many servers, a failure on one node will not cause an outage because Oracle Transparent Application Failover (TAF) will resume all transactions on surviving nodes.  This continuous availability feature is used by shops where downtime cost is greater than $100k per minute, and shops with more tolerance for downtime may use other Oracle failover technologies such as Oracle Streams and Oracle Data guard.

§         High scalability:  For smaller databases, scale up scalability is best using a large monolithic server with 32 or 64 processors and hundreds of gigabytes of RAM.  However, super large Oracle shops need more horsepower, and RAC provides them with the ability to scale out, adding additional servers to RAC cluster whenever they need more hardware resources.

For many systems, Oracle RAC and Grid allows the DBA true transparent scalability. In order to increase the number of servers in OPS, data and application changes were required and the scaling was far from transparent. 

The following advantages come with Oracle10g RAC and Grid:

§         No physical data partitioning is required

§         Vendor applications (SAP, Peoplesoft) will scale without modification.

This automatic, transparent scaling is due almost entirely to the cache fusion layer and the unique parallel architecture of RAC and Grid.  Table 20.1 summarizes the main features of the single instance stand alone database and the multi-instance RAC database.

By providing the multiple instances such as a host and its associated resources to access the same database, a RAC System creates multiple database computing centers and improves scalability, but it is done at the cost of additional complexity. 

---

This is an excerpt from my latest book "Oracle Tuning: The Definitive Reference".  You can buy it direct from the publisher for 50%-off and get instant access to the code depot of Oracle tuning scripts:

Expert Remote DBA BC is America's oldest and largest Remote DBA Oracle support provider.  Get real Remote DBA experts, call BC Remote DBA today.