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 


 

 

 


 

 

 

 

 

Shared Storage

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 this chapter and next chapter, preparing shared storage structures, installation of Oracle software with RAC option, and creation of RAC database will be covered.  Shared storage is the main and critical requirement for building and managing the RAC database.

Regardless of the number of nodes and database instances that may exist in the RAC cluster, all of them will have shared access to the underlying storage. Setting up shared storage, creating the hardware level structures, provision of the adequate storage redundancy, and preparation of host level storage logical storage units are very important. For setting up the needed shared storage structures at the host level for the RAC database, there is more than one option. These options use shared storage in terms of cluster file system, raw devices, and Oracle?s Automated Storage Management (ASM)

This chapter will cover these topics. RAC system being a shared architecture and the shared storage being the crucial component overall design and well being,

The relational database system is basically a logical entity that stores and retrieves organized data. The database resides in the storage structures and provides a front end for the data?s use. Thus, the database enjoys a very close connection with the storage units. Channels or paths connect the storage units with the servers and server components. The server, being the main abode of the database system, has to have many robust features to provide continuous service. As shown in Figure 5.1, there are multiple layers in the infrastructure. At the core are the storage units. The storage logical units (LUNS) are presented to the server layer and are usually available for use as raw volumes, as mounted (cluster) file systems and as the ASM  (automatic storage management) resources.

Figure 5.1: Storage Units and other system layers

The next layer consists of the server. Even without clustering, the server has to be designed with robust components. There should be a sense of local resiliency. When one of the components falters, there should be a backup or standby component to provide the desired functionality. The cluster layer lies outside the server layer and deals with the loss of the server by failing over to a backup or standby server. Finally, the outside layer is subject to environmental problems such as client connectivity and network failures, which cause bottlenecks between the client and the database.

Overview of the files and directories required

Bottom line is all the participating instances of an Oracle RAC database require access to the shared data files, redo log files, and control files. At the same time, the physical host level cluster consisting of physical nodes needs to have shared access to the quorum disk, voting disk, and OCR file. The use of a vendor provided cluster manager may still require the appropriate quorum disk as prescribed the cluster manager software. The Oracle provided Cluster Ready Services (CRS) need the voting disk and OCR file. There are other files which may need to be shared. They include the files supporting the external tables. It is also recommended to have the archive log files destination on a shared file system.

Figure 5.2 shows a collection of all the components that make up the RAC file structures. This diagram provides a road-map for how to prepare these structures before creating the database and launching the database instances.

Figure 5.2: All the Physical File Structures of the RAC Database

Of the all files that are shown above, most of them need to be on shared storage. There are some files that can be on a local file system, but it is recommended that they are placed on shared file system. And there are some file structures which can very well reside on a local file system. These three combinations are reviewed next.

The following files reside on Shared Storage and are accessible by all RAC instances at the same time.

* Data Files, which make up the main data storage file structures

* Control Files

* Parameter File (SPFILE) ? Maintain a common spfile located on shared file system which is accessible to all the instances of the RAC database.

* Password File which maintains the authentication privileges

* Voting Disk File and OCR files which are used by the cluster ready services.

The following files reside on Shared Storage and are accessible by a specific instance. However, under certain conditions such as recovery they need to be available for other instances also.

* Redo Log Files which record the instance specific transaction changes.

* Files supporting the Undo Tablespace which is used by a specific instance to maintain the read consistency

* Archive Log Files which are the saved redo log files

* Files supporting the External Tables ? External Tables are logical database objects which are accessible to all the instances.

The following are file structures are created, accessed, and managed by a specific instance.

* Alert Log File which keeps a running log of database changes and events

* Trace Files that provide detailed information about the database events.

* Oracle Executables (Oracle Home Files)

* Oracle Cluster Ready Services (CRS) Home which has all the binaries supporting the CRS.

However, with the use of the cluster file system it is possible to use a Shared Oracle Home and shared CRS Home. When using the cluster file system such as HP?s Tru64 CFS, Veritas CFS, Polyserve Matrix Server, a single Oracle Home can be maintained and shared among all the nodes of the cluster.

There are four combinations when using shared file structures as shown in Figure 5.3.

Figure 5.3: Shared Storage Inputs

* They can be on raw devices

* They can be on a Cluster File System (CFS). CFS is concurrently mounted on all the participating nodes of the cluster.

* They can be on accessed via the Automatic Storage Management (ASM) instance

* They can be located Network File System

Even though only three types of shared storage structures have been reviewed here, it is also possible to mix them where some shared files can be on raw devices, some can be located on CFS, and some can come out of ASM.

 


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