Database Journal
MS SQL Oracle DB2 Access MySQL PostgreSQL Sybase PHP SQL Etc SQL Scripts & Samples Links Database Forum

» Database Journal Home
» Database Articles
» Database Tutorials
MS SQL
Oracle
DB2
MS Access
MySQL
» RESOURCES
Database Tools
SQL Scripts & Samples
Links
» Database Forum
» Sitemap
Free Newsletters:
DatabaseDaily  
News Via RSS Feed


follow us on Twitter
Database Journal |DBA Support |SQLCourse |SQLCourse2
 

Featured Database Articles

Oracle

Posted Dec 22, 2006

Oracle RAC Administration - Part 11:The RAC DBA continued

By Tarry Singh

Brief intro

In this article, we will continue our discussion of Oracle RAC DBA essentials. We have already looked at Enterprise Linux and will continue to build our “Oracle RAC Appliance” on the Oracle Enterprise Linux layer.

There is nothing more gratifying than an email Saying the series has helped someone solve a problem. I'm really excited to see that people all around the world are enjoying and benefiting from our RAC series, be it installation or RAC administration.

RAC DBA refresher

In our last article, we looked at a few important parameters. We will continue to do the same in this article and have a brief look at oifcfg, as promised. So without further ado, let's get started again.

RAC specific parameters continued:

Let's check out a few more parameters that are present in our RAC environment (there are, however, many more that we will get in touch with in future articles):

MAX_COMMIT_PROPAGATION_DELAY

The MAX_COMMIT_PROPAGATION_DELAY parameter is deprecated in Release 10g R2, but for those who are on 10g R1, it is still crucial to know what it means. The MAX_COMMIT_PROPAGATION_DELAY parameter actually defines the maximum amount of time that the SCN (System Change Number) is captured in the local instance’s SGA (System Global Area) before being overwritten by the Log writer process (LGWR). This value must be same across all instances.Allowable, a delay of 700 milliseconds (7 seconds thus) is generally fine. However, in certain high intensive OLTP environments this value can be set to a much lower value, such as “0”. A typical example is of a high intensive OLTP environment where many inserts, updates, deletes are taking place, which means a lot of DMLs, all on one node. This is then propagated to all of the other cluster nodes immediately, ensuring that the SCN on all the nodes are same. A typical alert log entry like this is evident of the fact the the propagation was almost instantaneous.

This instance was first to open
Picked broadcast on commit scheme to generate SCNs

Any other value greater than 0, say 1 or 2 will reflect a typical entry in the alert log file as such. A Lamport Scheme is used to generate the SCNs:

This instance was first to open
Picked Lamport scheme to generate SCNs

Obviously, the downside of it all is that it may have an impact on your performance; this might not seem like a nice idea, especially with your VMware ESX ready RAC. I already get enough emails from users asking advice on countering all kinds of errors on their RACs to keep it up all the time. The LGWR, in this case, has to refresh the values of the SCNs across the RAC cluster nodes frequently, to keep them all in sync. If you are a consultant, or even a DBA, with limited resources in your test environment or at home, I'd advise you to keep this parameters value on the higher side. It goes without saying; if you’re using the 10G R2 version then you don’t have to worry. Remember that the parameters values must be same across all nodes.

BACKGROUNG PROCESSES

Getting a list of all of the background processes is also handy if you are a DBA and as a RAC DBA, you will come across some additional processes, which are available in your RAC environment.

SQL> select name, description from v$bgprocess where PADDR <> '00';
PMON  process cleanup
DIAG  diagnosibility process
LMON  global enqueue service monitor
LMD0  global enqueue service daemon 0
LMS0  global cache service process 0
LMS1  global cache service process 1
MMAN  Memory Manager
DBW0  db writer process 0
LGWR  Redo etc.
LCK0  Lock Process 0
CKPT  checkpoint
SMON  System Monitor Process
RECO  distributed recovery
.
.
.
.
.

The additional RAC centric processes are DIAG, LCK, LMON, LMDn, and LMSn processes. We will give a brief description of each and discuss how they interact in a RAC environment next.

DIAG: This is a diagnostic daemon. It constantly monitors the health of the instances across the RAC and possible failures on the RAC. There is one per instance.

LCK: This lock process manages requests that are not cache-fusion requests. Requests like row cache requests and library cache requests. Only a single LCK process is allowed for each instance.

LMD: The Lock Manager Daemon. This is also sometimes referred to as the GES (Global Enqueue Service) daemon since its job is to manage the global enqueue and global resource access. It also detects deadlocks and monitors lock conversion timeouts.

LMON: The Lock Monitor Process. It is the GES monitor. It reconfigures the lock resources adding or removing nodes. LMON will generate a trace file every time a node reconfiguration takes place. It also monitors the RAC cluster wide and detects a node’s demise and trigger a quick reconfiguration.

LMS: This is the Lock Manager Server Process or the LMS process, sometimes also called the GCS (Global Cache Services) process. Its primary job is to transport blocks across the nodes for cache-fusion requests. If there is a consistent-read request, the LMS process rolls back the block, makes a Consistent-Read image of the block and then ship this block across the HSI (High Speed Interconnect) to the process requesting from a remote node. LMS must also check constantly with the LMD background process (or our GES process) to get the lock requests placed by the LMD process. Up to 10 such processes can be generated dynamically.

Conclusion:

In the next article, we will continue our RAC DBA essentials. We were supposed to talk about the conversion of your physical RAC to the development and test RAC environments on top of your ESX server in this article, but will take it up next time. It may not be easy (since the physical shared disks and NICs will be sensitive to the VMware environment but it sure is worth a try.

» See All Articles by Columnist Tarry Singh



Oracle Archives

Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 




Latest Forum Threads
Oracle Forum
Topic By Replies Updated
Oracle Data Mining: Classification jan.hasller 0 July 5th, 07:19 AM
Find duplicates - Unique IDs Lava 5 July 2nd, 08:30 AM
no matching unique or primary key rcanter 1 April 25th, 12:32 PM
Update values of one table based on condition of values in other table using Trigger Gladiator 3 February 29th, 06:01 PM