Category: oracle rac

 To check if an Oracle database is RAC (Real Application Clusters) enabled, you can use several methods. Here are the most common ways to verify if your Oracle database is running in a RAC environment:

1. Check Using srvctl (Server Control Utility)

If Oracle Grid Infrastructure is installed, the srvctl utility can provide information about the RAC configuration.

srvctl config database -d <dbname>

• If the database is RAC-enabled, this command will show the instances that are part of the RAC environment.

• Example output for a RAC-enabled database:

  Database name: <dbname>
  Database is running.
  Instance(s):
  <instance1> <instance2>
  

If it shows multiple instances, then the database is RAC-enabled.

2. Check with ps or top Command (Unix/Linux)

You can check if multiple instances are running on different nodes by using the ps or top command.

ps -ef | grep pmon

• In a RAC environment, you will typically see one pmon (process monitor) for each instance of the database.

• For example, if the database is running in RAC, you might see something like:

  
  oracle    1234     1  0 09:00 ?        00:00:00 ora_pmon_<inst1>
  oracle    5678     1  0 09:01 ?        00:00:00 ora_pmon_<inst2>
  

Each pmon_<inst> corresponds to an individual instance in the RAC cluster.

3. Check the v$database View

You can query the v$database view to check if the database is configured in a RAC environment.

SELECT name, open_mode, cluster_database FROM v$database;

• If the cluster_database column returns TRUE, the database is RAC-enabled.

• Example output:

  
  NAME      OPEN_MODE      CLUSTER_DATABASE
  --------- -------------- -----------------
  ORCL      READ WRITE     TRUE
  

If CLUSTER_DATABASE is TRUE, this indicates the database is part of a RAC configuration.

4. Check the crsctl Command (Cluster Resource Service)

If Oracle Grid Infrastructure is used for RAC, you can also check the status of the database service using the crsctl command.

crsctl status resource -t

• This will show the resources managed by Oracle Clusterware, including databases, listeners, and services.
• For a RAC database, you’ll see resources like ora.<dbname>.<inst_name>, where <dbname> is your database name, and <inst_name> refers to the individual instance names in the RAC configuration.

5. Check the listener.ora File

If the database is using multiple instances in a RAC setup, the listener.ora file on each node should contain entries for all instances.

cat $ORACLE_HOME/network/admin/listener.ora

You should see multiple listener configurations for different instances in the RAC, typically defined with the SID_LIST directive.

6. Check the dbs Directory for Instance-Specific Files

If you are on the server where the Oracle RAC instances are running, you can look for individual initialization parameter files (spfile or init.ora) for each RAC instance. These files are typically located in the $ORACLE_HOME/dbs/ directory.

For example:

• spfile<dbname>_<inst_name>.ora
• init<dbname>_<inst_name>.ora

Each RAC instance will have its own configuration file.

7. Check the Clusterware Logs

The clusterware logs can also provide information about the RAC configuration. You can check the Oracle Grid Infrastructure logs or the Oracle alert logs for entries related to RAC.

bash
Copy code
$GRID_HOME/log/<hostname>/alert*.log

These logs will contain details about RAC node registrations, instance startup, and other cluster-related events.

• If multiple database instances are configured on different servers and share the same storage, it’s likely a RAC environment.
• The primary indicators include the cluster_database column in v$database, multiple pmon processes, and usage of tools like srvctl and crsctl to manage resources.

What is node eviction?

Node eviction in RAC is done when a heartbeat indicates that a node is not responding, 

and the evicted node is re-started to make it a part of cluster.

Causes for RAC node eviction:

Node eviction on Oracle RAC environment can be due to any of the below reasons. 

– A failure of any of the major hardware components (CPU, RAM, network interconnect).

– A server that is experiencing RAM swapping.

– When communications to the voting disk is interrupted, causing the disconnected node to be evicted and re-boot.

– Database or ASM hang condition.

Below is the list of important log files to review in case of a node eviction

– Clusterware alert log

– Database alert log

– CSSD agent logs

– CSSD monitor logs

– System Message logs (/var/log/messages)