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

 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
 Oracle Support

 SQL Tuning

 Oracle UNIX
 Oracle Linux
 Remote s
 Remote plans
 Application Server

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

 Remote S


 Consulting Staff
 Consulting Prices
 Help Wanted!


 Oracle Posters
 Oracle Books

 Oracle Scripts

Don Burleson Blog 









Shared-Disk Model

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%.

In the Shared-Disk model, all the disks containing data are accessible by all nodes of the cluster. Disk sharing architecture requires suitable lock management techniques to control the update concurrency control. Each of the nodes in the cluster has direct access to all disks on which shared data is placed.  Figure 3.11 shows a typical three node parallel database cluster. Each node has local database buffer cache. IBM Parallel Sysplex and Oracle RAC systems follow this approach of shared-disk.

Advantages of shared-disk systems are as follows:

* Shared-disk systems permit high availability. All data is accessible even if one node fails.

* These systems have the concept of One Database and multiple access points. In other words, one can say it is multi-instance and single database. There is no issue such as data skew as the data is located and accessed at a common location.

* It provides for incremental growth of nodes and thus adds to processing power.

Figure 3.11: Shared Disk Parallel Database Cluster

Disadvantages of shared disk systems are these:

* Inter-node synchronization is required and involves complex lock management and greater dependency on high-speed interconnect.

* If the workload is not partitioned well among the processing nodes, there may be high synchronization overhead.

* There is operating system overhead of running shared disk software.

Other Architectures

There is another interesting architecture as provided by Microsoft SQL-Server Federated Database. SQL Server 2000 shares the database processing load across a group of servers by horizontally partitioning the SQL Server data. These SQL servers are configured and managed independently, but co-operate to process the database requests. Such a cooperative group of SQL Servers is called a federated database.

Federated database tiers can achieve high levels of performance only if the application sends each SQL statement to the member server that has most of the data required by the statement. This is called co-locating the SQL statement with the data required by the statement. Thus, federation of servers presents to the applications as a single database server. However, it requires careful planning and designing for a set of distributed partitioned views that spread the data across the different servers.

This configuration means significantly higher administration costs, since each individual server requires its own separate maintenance operations and prevents access to any data if any server fails. Additionally, the performance of the complete federated database is dependent on how much of the data requested is on a local server and how much is on other servers. This demands careful partitioning of data across the multiple servers to gain performance advantages.

Table 3.2 shows differences between Single Databases and Federated databases



There is one instance of SQL Server on the production server.

There is one instance of SQL Server on each member server.

The production data is stored in one database

Each member server has a member database. The data is spread through the member databases.

Each table is typically a single entity

The tables from the original database are horizontally partitioned into member tables. There is one member table per member database, and distributed partitioned views are used

All connections are made to the single server, and all SQL statements are processed by the same instance of SQL Server.

The application layer must be able to collocate SQL statements on the member server containing most of the data referenced by the statement

Table 3.2: Differences between Single Databases and Federated databases


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.


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