Oracle Rac Crs Log Files

Log Files in RAC

Clusterware Log Files

The growth of CRS log files in the CRS home is not limited!

$ORA_CRS_HOME/crs/<node name>.log

Oracle Cluster Registry Log Files The Oracle Cluster Registry (OCR) records log information in the following location:


Cluster Synchronization Services (CSS) Log Files You can find CSS information that the OCSSD generates in log files in the following locations:


Event Manager Log Files Event Manager (EVM) information generated by evmd is recorded in log files in the following locations:

$ORA_CRS_HOME/evm/init/<node name>.log

Oracle High Availability Log Files


Enabling Additional Tracing for Real Application Clusters High Availability

Generating Additional Trace Information for a Running Resource

To generate additional trace information for a running resource, set the resource attribute _USR_ORA_DEBUG to the value 1 using one of the following two methods:

For an individual resource, modify the resource profile (a text file named resource_name.cap) that you can generate with the following command:

crs_stat -p resource_name > \
CRS Home/crs/profile/resource_name.cap

Only create .cap files in this directory for resources that are owned by the root user. Use the CRS Home/crs/public/ directory for other resources, which are resources that are owned by the oracle user. Then set the _USR_ORA_DEBUG value to 1 in this .cap file and issue the following command:

crs_register -u resource_name

For all resources, add the following line to the script, racgwrap, in $ORACLE_HOME/bin:


Only node-level resources (VIP and so on) should have their .cap file created in the directory
Verifying Event Manager Daemon Communications The event manager daemons (evmd) running on separate nodes communicate through specific ports. To determine whether the evmd for a node can send and receive messages, perform the test described in this section while running session 1 in the background.

On node 1, session 1 enter:

$ evmwatch -A -t "@timestamp @@"

On node 2, session 2 enter:

$ evmpost -u "hello" [-h nodename]

Session 1 should show output similar to the following:

$ 21-Aug-2002 08:04:26 hello

Ensure that each node can both send and receive messages by executing this test in several permutations.
Enabling Additional Debugging Information for Cluster Ready Services The crsd daemon can produce additional debugging information if you set the variable CRS_DEBUG to the value 1 by performing the following procedures:

In the file /etc/init.d/init.crsd add the entry:

export CRS_DEBUG

Then kill the crsd daemon with the command:

$ kill -9 crsd process id

Allow the init process to restart the crsd. Oracle will write additional information to the standard log files.
Enabling Tracing for Java-Based Tools and Utilities in Real Application Clusters All of the Java-based tools and utilities available in RAC are invoked by executing scripts of the same name as the tool or utility. This includes the Database Configuration Assistant (DBCA), the Net Configuration Assistant (NetCA), the Virtual Internet Protocol Configuration Assistant (VIPCA), Service Control (SRVCTL), and the Global Services Daemon (GSD). For example to run the DBCA, enter the command dbca.

To enable additional debugging information, edit the command file (such as dbca in this example) and add the following parameters to the $JRE_DIR/bin/jre command line:


For example, the file $ORACLE_HOME/bin/dbca contains the line:

-classpath $CLASSPATH oracle.sysman.dbca.Dbca $ARGUMENTS

Change this line to:

-DTRACING.LEVEL=2 -DJDBC_PROTOCOL=thin -mx64 -classpath $CLASSPATH oracle.sysman.dbca.Dbca $ARGUMENTS

When you run the DBCA, trace information will record in the DBCA log file.

To debug SRVCTL, add the argument -D to the command line. For example, to generate tracing information for an add database operation, execute the following command:

$ srvctl -D add database -d mydatabase

Oracle® Real Application Clusters Administrator's Guide 10g Release 1