Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 
 Home
 E-mail Us
 Oracle Articles
New Oracle Articles


 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog


 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Analysis
 Design
 Implementation
 Oracle Support


 SQL Tuning
 Security

 Oracle UNIX
 Oracle Linux
 Monitoring
 Remote s
upport
 Remote plans
 Remote
services
 Application Server

 Applications
 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S
upport  
 Development  

 Implementation


 Consulting Staff
 Consulting Prices
 Help Wanted!

 


 Oracle Posters
 Oracle Books

 Oracle Scripts
 Ion
 Excel-DB  

Don Burleson Blog 


 

 

 


 

 

 

 

 

Scalability Advantages of the RAC Database

Oracle RAC Cluster Tips by Burleson Consulting

This is an excerpt from the bestselling book Oracle Grid & Real Application Clusters.  To get immediate access to the code depot of working RAC scripts, buy it directly from the publisher and save more than 30%.


As enterprises rely more on organized data and databases, an explosion of data accumulation has occurred in the recent past. This trend will continue as information and data processing is the key to many business operations and business decisions. None of the day-to-day business operations can run without the use of database resources. Dependence on the database is total. As a result, the stress on scalability and performance of database system software is greater than ever. The major benefits of the RAC database system are scalability and high availability.

Scalability

In a dedicated server environment, every connected client is associated with a server process that consumes memory resources and contributes to context switching overhead in a production environment. However, the TP monitors and MTS, now called shared server, features of the Oracle database have been used to reduce the numbers of processes on the server and better utilize these resources. To solve the resource crunch, the RAC database provides additional memory resources as more nodes are added to the clustered database system.

A RAC database system provides excellent scalability options for the users. As the need arises, users can expand or add the number of nodes in the cluster. This enhances the total database engine computing power when the need for high performance arises. With the additional nodes and instances in the database cluster, the system is able to accommodate demands.

Cache fusion technology provides transparency in the way the data blocks are accessed and the results are composed to meet the needs of the SQL query.

Horizontal scalability is generally easy to achieve with the addition of extra nodes at the operating system and at the physical cluster level. Once the cluster is physically expanded, it is relatively easy for the Oracle instance to be created and added into the RAC database system.

Addition of another instance creates the opportunity to support a large number of concurrent users. Any instance introduced into the RAC system opens up new memory buffers and permits more user connections without affecting the performance of the other instances.

In the past, the only way to scale the database server was to scale up by replacing a small system with a larger system. Oracle9i/10G RAC provides another option: the addition of more small systems, also known as scale out. In a typical SMP server, a limit is reached in the number of CPUs and memory buffers. With the addition of extra nodes and instances, the total number of processors in the clusters can be enhanced. For complex database queries, it now becomes possible to achieve higher parallelism, spanning across the multiple nodes. In other words, a higher degree of parallelism for queries can be realized.

If a lot of processing is going on in one of the instances, the applications accessing the database through that instance can be shifted to another instance. Thus, the processing or activity can be dispersed.

Scalability is the ability of a system to handle an increased workload as the number of users increases. When you only have one server, the only way to raise the server?s capacity is to increase the resources available in the server. The server can be outfitted with more CPUs with more cores. Physical memory can be increased. We say that adding resources to a server is scaling up or vertical scaling.
 
One of the biggest problems with vertical scaling is that hard limits exist in any server. You can only add a certain number of CPU cores to the server. The server has a finite number of memory slots that have a physical limit on the size of the memory chips that can be used. If the workload increases sufficiently, a server that is outfitted to the maximum may still be overburdened and not be able to handle the end user demands.
 
Another issue with vertical scaling is the cost. As more and more memory is added to the system, the cost increases very rapidly. As an analogy, think of constructing a building and your requirement is to have 10,000 square feet. Such a large building will cost more if it is built as a ten story structure with each story sized at 1,000 square feet than if it were built as a single story building. The taller the building, the more it costs to create. Similarly, a server outfitted with lots of CPU cores and very large amounts of physical memory will cost more than buying lots of smaller servers together provide the same number of cores and RAM.
 
Oracle RAC offers the ability to scale out, or perform horizontal scaling. Horizontal scaling is normally much cheaper than vertical scaling. Back to the analogy, in scaling out, we can erect ten 1,000 square foot single story buildings to achieve our total resource requirement. A ten-story building is much, much more expensive than ten smaller one-story buildings even if the end result is the same square footage. Oracle RAC horizontal scaling is typically accomplished by implementing low-cost commodity hardware. Today?s data centers are now filled with inexpensive servers rather than the big iron systems of the past. We typically scale our Oracle RAC configurations by adding a new server rather than buying a larger server. Back to our analogy, if the workload dictates that we need to grow from 10,000 square feet to 12,000 square feet, we do that by creating two more 1,000 square foot buildings. Similarly, if our Oracle RAC cluster needs to scale to meet demands, we simply add another low-cost server to the cluster.
 
Oracle RAC offers the ability to both scale up and scale out. You are not limited to one or the other. This gives the company great flexibility is designing their database infrastructure to suit their specific needs. It is possible to incorporate high-end servers into a RAC cluster. However, this is rarely done in practice as the company often saves money by using commodity hardware, but it is always nice to have options and not be constrained in a single direction.
 
Another option is to have some nodes in the cluster with more resources than other nodes. In this way, we can mix and match nodes to specific needs across the cluster. Be very careful in architecting your RAC systems where nodes may have different resources. If you use any application failover within the cluster, you may find that sessions connecting to a different node in the cluster do not have enough resources to be able to perform adequately.  A node in the cluster should not only have enough resources to handle a normal workload, it should have enough resources to handle the additional demands placed on it when the number of sessions increases due to failure in another node. For this reason, it is rare to have an Oracle RAC cluster where nodes do not have all the same resources available to it.  While possible to have nodes with different configurations, doing so would be rare and requires a proper understanding of the risks involved. 
 
This first chapter provided an introduction to Oracle RAC performance tuning. The chapter started with a discussion of using testbeds to understand the effect of a change on a system, made even easier with today?s virtualization techniques. The conversation turned to tuning the application for a single instance. Oracle RAC is not a silver bullet for an application?s performance woes. A properly tuned, scalable application can be taken to the next level with Oracle RAC, but it is possible to have worse performance on Oracle RAC.
 
Next, we discussed scale up and scale out. Oracle RAC is primarily a scale out solution, often leveraging commodity hardware to scale with reasonable costs. Yet Oracle RAC does not limit the infrastructure to one scaling direction as the systems can be configured to scale up as well.
 
This chapter also discussed a tuning methodology that works for single-instance as well as Oracle RAC databases. Tune the application first, the database second, and the server last. Bottlenecks always exist in any system and it is impossible to eliminate them all. Response time is defined as service time plus wait time. Oracle?s wait events tell us where processes are spending their time.
 
In the next chapter we will discuss Cache Fusion, the secret sauce to make Oracle RAC databases perform very well. The Cache Fusion operations discussed will be important, as those operations will be illustrated throughout the remainder of the book.


This is an excerpt from the bestselling book Oracle Grid & Real Application Clusters, Rampant TechPress, by Mike Ault and Madhu Tumma.

You can buy it direct from the publisher for 30%-off and get instant access to the code depot of Oracle tuning scripts.

http://www.rampant-books.com/book_2004_1_10g_grid.htm


 

 
��  
 
 
Oracle Training at Sea
 
 
 
 
oracle dba poster
 

 
Follow us on Twitter 
 
Oracle performance tuning software 
 
Oracle Linux poster
 
 
 

 

Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


                    









Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


 

Copyright © 1996 -  2017

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.

Remote Emergency Support provided by Conversational