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 


 

 

 


 

 

 

 

 

Partitions Within the Server

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 an example, the Sun Enterprise 10K Server includes Dynamic System Domains, which allow a single machine to be divided into logical partitions, with each partition totally electrically isolated from the others.

The features mentioned above, as well as others, help maintain redundancy levels, which indirectly avoids server down time and service disruption to the application user.

Network Services and Accessing RAC

The next topic is the accessing the RAC database. The SQL*Net process controls the RAC instance access. Access to any Oracle instance can be through either a dedicated server connection or through a shared server connection. If access is through a shared server connection, then the instance is set up for shared server (multi-threaded server - MTS). If the connection is a dedicated server, then either the user process required a dedicated connection or the instance is not using MTS. The configuration of SQL*Net for RAC can be quite simple. Essentially only two files need to be configured for basic access, the SQL*Net listener control file, listener.ora, and the instance names file, tnsnames.ora. In a basic configuration, each server has a listener.ora and a tnsnames.ora file, and each client has a tnsnames.ora file. A third file, sqlnet.ora, is also present on both server and client which control the access behavior.

listener.ora File

The listener.ora file contains the information needed by the SQL*Net listener file to identify the instances for which connection requests are being serviced. If no instances are listed in the listener.ora, the listener process will wait for the instances to self-register since instances have been capable of self-registering since Oracle8i. Shown below is a basic listener.ora file for use with RAC.

LISTENER=
(DESCRIPTION=
(ADDRESS=
(PROTOCOL=tcp)
(HOST=aultlinux1)
(PORT=1521)))

If advanced features such as load balancing and automatic failover are desired, there are optional sections of the listener.ora file that must be present. For example, to configure load balancing, the listener.ora file shown below would be appropriate. The listener file must be the same on the servers that are participating in the load balancing for RAC. The second listener, listener_test1 allows use of Oracle Enterprise Manager with the instance.

Another example is that the global_dbname parameter should not be configured if Oracle RAC connect time failover or transparent application failover are going to be used. Setting this parameter will disable these capabilities.

Chapter 10 covers the setup for automatic failover. For the second server, the second listener would be called listener_test2, and all instance specific references would be changed to test2, while all server specific references would be changed to testlinux2.

Listener_Test=
(description=
(load_balance=on)
(address=(protocol=tcp)(host=testlinux1)(port=1521)
(address=(protocol=tcp)(host=testlinux2)(port=1521)
(connect_data=
(service_name=test)))
listener_test1=
(description=
(address=(protocol=tcp)(host=testlinux1)(port=1521)
sid_list_listener_test1=
(sid_list=
(sid_desc=
(oracle-home=/u01/app/oracle/product/9.2.0.2)
(sid_name=test1)))

If a port other than 1521 is utilized, then the local_listener parameter in that instances local init.ora file must be set to the same port value. For example, if port 1525 was used instead of 1521, all references to port 1521 in the listener.ora would be changed to 1525 in and the following entry would have to be added to the local init.ora:

local_listener="(address=(port=1525)(protocol=tcp)(host=testlinux1))"

More examples of listener.ora files for various RAC failover scenarios are included in Chapter 10, Transparent Application Failover.

tnsnames.ora File

Unless Oracle Names or LDAP is used, each client and server that participates in the RAC environment must have a tnsnames.ora file. The tnsnames.ora file provides the local SQL*Net process a map to all available instances. The tnsnames.ora file also provides failover and load balance information. Failover is automatically set if a list of addresses is placed in the tnsnames.ora file. However, the failover method should be explicitly set using the failover_mode tnsnames.ora parameter. More detail about the tnsnames.ora file will be provided in Chapter 10, Transparent Application Failover.

A basic tnsnames.ora file for a load-balancing RAC setup is shown below:

TEST =
(DESCRIPTION =
(LOAD_BALANCE = ON)
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = testlinux1)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = testlinux2)(PORT = 1521)))
(CONNECT_DATA =
(SERVICE_NAME = TEST))))
TEST1 =
(DESCRIPTION =
(ADDRESS_LIST =
(LOAD_BALANCE = ON)
(ADDRESS = (PROTOCOL = TCP)(HOST = testlinux1)(PORT = 1521)))
(CONNECT_DATA =
(SERVICE_NAME = TEST)(INSTANCE_NAME = TEST1)))
TEST2 =
(DESCRIPTION =
(ADDRESS_LIST =
(LOAD_BALANCE = ON)
(ADDRESS = (PROTOCOL = TCP)(HOST = testlinux2)(PORT = 1521)))
(CONNECT_DATA =
(SERVICE_NAME = TEST)(INSTANCE_NAME = TEST2)))
EXTPROC_CONNECTION_DATA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC)))
(CONNECT_DATA =
(SID=PLSExtProc)(PRESENTATION = RO)))

LISTENERS_TEST =
(ADDRESS = (PROTOCOL = TCP)(HOST = testlinux1)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = testlinux2)(PORT = 1521))

If a list of listener addresses is provided in the tnsnames.ora file, load balancing will be done automatically and there is no need to specify the load_balance parameters. They are shown here for example purposes only. The tnsnames.ora file provides the information needed to register the service names and instance-level information with the listener process. In addition, it specifies whether load balancing and application failover are desired, and specifies the method of failover if desired. This is a very important file for RAC.

More examples of RAC tnsnames.ora files for various failover scenarios are included in Chapter 10, Transparent Application Failover.

In addition to access to the database and also to the specific instance, now users can access to the Service directly by using the Virtual IP or Virtual IP host name. Virtual IP Configuration Assistant (VIPCA) helps to create services and associate the Virtual IP. Virtual IP is the public address through which a specific RAC database service can be accessed. More details on the Service Configuration and VIP configuration are covered in the Chapter 6 and Chapter 20.
 


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