BC remote Oracle DBA - Call (800) 766-1884  
Oracle Consulting Oracle Training Development

Remote DBA

Remote DBA Plans  

Remote DBA Service

Remote DBA RAC

Remote DBA Oracle Home
Remote DBA Oracle Training
Remote DBA SQL Tuning Consulting
Remote DBA Oracle Tuning Consulting
Remote DBA Data Warehouse Consulting
Remote DBA Oracle Project Management
Remote DBA Oracle Security Assessment
Remote DBA Unix Consulting
Burleson Books
Burleson Articles
Burleson Web Courses
Burleson Qualifications
Oracle Links
Remote DBA Oracle Monitoring
Remote DBA Support Benefits
Remote DBA Plans & Prices
Our Automation Strategy
What We Monitor
Oracle Apps Support
Print Our Brochure
Contact Us (e-mail)
Oracle Job Opportunities
Oracle Consulting Prices





Remote DBA services

Remote DBA Support

Remote DBA RAC

Remote DBA Reasons

Remote Oracle Tuning

Remote DBA Links

Oracle DBA Support

Oracle DBA Forum

Oracle Disaster

Oracle Training

Oracle Tuning

Oracle Training

 Remote DBA SQL Server

Remote MSSQL Consulting

Oracle DBA Hosting

Oracle License Negotiation









  Putting Load Balancing into Action in 11g

Oracle Tips by Burleson Consulting

Oracle 11g SQL New Features Tips

Bringing all these features together primarily involves configuration of services to interact with the Load Balancing Advisory.  One of the great features of Oracle 11g is that many clients (JDBC, ODP.NET, OCI) are now fully integrated with FAN and FCF through connection pools. In order to configure services to work with the Load Balancing Advisory, first a Load Balancing Goal (CLB_GOAL) must be set.


A “long” load balancing goal is primarily for connections that will remain connected for long periods of time.  Batch jobs, dedicated applications, and client-side connection pools are good examples of this category.  By default, LONG is the load balancing goal.  However, it can be configured for a service (in this case called ‘example_service’) specifically with the following code:

exec dbms_service.modify_service (service_name => ‘example_service’, clb_goal dbms_service.clb_goal_long); 


A goal of “short” is appropriate for short lived connections.  Examples include standard OLTP applications that connect directly to Oracle.  In order to configure a service (in this case, called ‘example_service’) to a goal of “short,” the following code can be used:

exec dbms_service.modify_service(service_name => ‘example_service’, clb_goal => dbms_service.clb_goal_short); 

Another important goal is the way that services would be measured.  The Load Balancing Advisory can be configured to respond based upon THROUGHPUT or SERVICE TIME.


When the service-level goal is set to throughput, Oracle will attempt to direct the request to the proper node based upon the rate at which work is completed on that node and the available bandwidth of the service.  This goal is best used in batch environments where jobs require a large amount of resources in order to succeed.  This goal can be set for a service with the following code:

exec dbms_service.modify_service(service_name => ‘example_service’, goal => dbms_service.goal_throughput); 


A service-level goal of service time will produce load balancing recommendations based on response time.  This is perfect for OLTP applications where connections seek a quick result.  This goal can be set for a service with this code:

exec dbms_service.modify_service(service_name => ‘example_service’, goal => dbms_service.goal_throughput); 


To disable load balancing for services completely, the load balancing goal can be set to NONE.  This is done (in this case, as before, on a service called ‘example_service’) with this code:

exec dbms_service.modify_service(service_name => ‘example_service’, goal => dbms_service.goal_none); 

Cloning a Cluster to another Cluster

Once a RAC cluster with ASM is successfully installed, the ASM and RAC setup can now be cloned to a new cluster.  While it was possible before 11g to clone RAC and ASM to a new node in the same cluster, there is now the capability to clone entire clusters for easy deployment.  This is a scripted method of quickly deploying RAC clusters across the grid.

In order to clone ASM and RAC configurations, a new script called ‘clone.pl’ is used along with pre-scripted silent runs of NetCA and DBCA.  The perl script clone.pl can be used to clone both ASM homes and Oracle Database homes.  Software is deployed between nodes using the standard tar and gzip commands.

Here are the steps involved in cloning RAC instances with ASM to another cluster:

1.      Install Oracle Clusterware on the new nodes

2.      Take a ‘tar’ backup of the Oracle 11g software

3.      Backup the ASM Home

4.      Backup the DB Home

5.      Restore the ASM ‘tar’ backup onto the new cluster nodes

6.      Run the clone.pl perl script on each node for ASM

7.      Run the root.sh script on each node as root for ASM

8.      Run NetCa in silent mode to create listeners on each node

9.      Run DBCA in silent mode to create the ASM instance on each node

10.  Restore the DB ‘tar’ backup onto the new cluster nodes

11.  Run the clone.pl perl script on each node for the DB Home

12.  Run the root.sh script as root on each node for the DB Home

13.  Run DBCA to create the RAC instances

Full instructions on how to do this can be found in Oracle’s documentation at the following URL:


Scalability Conclusion

Oracle 11g’s new scalability features extend those given in Oracle 10g and 10gR2, allowing Oracle to properly balance connections across multiple instances.  In addition, true grid environments can be created by cloning the clusters.


This is an excerpt from the new book Oracle 11g New Features: Expert Guide to the Important New Features by John Garmany, Steve Karam, Lutz Hartmann, V. J. Jain, Brian Carr.

You can buy it direct from the publisher for 30% off.

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.



Remote DBA Service

Oracle Tuning Book


Advance SQL Tuning Book 

BC Oracle support

Oracle books by Rampant

Oracle monitoring software







BC Remote Oracle Support

Remote DBA

Remote DBA Services

Copyright © 1996 -  2013 by Burleson. All rights reserved.

Oracle® is the registered trademark of Oracle Corporation.

Hit Counter