Oracle clusterware is made up of components like voting disk and Oracle Cluster Registry(OCR).

Having ASM is the Oracle recommended storage option for RAC databases as the ASM maximizes performance by managing the storage configuration across the disks.ASM does this by distributing the database file across all of the available storage within our cluster database environment.

It is a good practice to have ASM home seperate from the database hom(ORACLE_HOME).This helps in upgrading and patching ASM and the Oracle database software independent of each other.Also,we can deinstall the Oracle database software independent of the ASM instance.

Fast application Notification as it abbreviates to FAN relates to the events related to instances,services and nodes.This is a notification mechanism that Oracle RAc uses to notify other processes about the configuration and service level information that includes service status changes such as,UP or DOWN events.Applications can respond to FAN events and take immediate action.

FAN UP and DOWN events:

FAN UP and FAN DOWN events can be applied to instances,services and nodes.

Use of FAN events in case of a cluster configuration change:

During times of cluster configuration changes,Oracle RAC high availability framework publishes a FAN event immediately when a state change occurs in the cluster.So applications can receive FAN events and react immediately.This prevents applications from polling database and detecting a problem after such a state change.

Issue the following query from any one node connecting through SQL*PLUS.
$connect sys/sys as sysdba

SQL>select * from V$ACTIVE_INSTANCES;
The query gives the instance number under INST_NUMBER column,host_:instancename under INST_NAME column.

VIP – Virtual IP address in RAC

VIP is mainly used for fast connection in failover.

Until 9i RAC faileover we used physical IP address of another server. When the connection request come from a client to server, then failure of first server listener then RAC redirect the connection request to second available server using physical IP address. Hence it is physical IP address rediretion to second physical IP address is possible only after we get timeout error from First Physical IP address. So connection should wait a while for getting TCP connection timeout.

From RAC 10g we can use the VIP to save connection timeout wait, Because ONS (Oracle Notification Service) maintains communication between each nodes and listeners. Once ONS found any listener down or node down, it will notify another nodes and listeners. While new connection is trying to establish connection to failure node or listener, virtual IP of failure node automatically divert to surviving node. This Process will not wait for TCP/IP timeout event. So new connection will be faster even one listener/node failed.

A virtual IP address or VIP is an alternate IP address that the client connections use instead of the standard public IP address. To configure VIP address, we need to reserve a spare IP address for each node, and the IP addresses must use the same subnet as the public network.

If a node fails, then the node’s VIP address fails over to another node on which the VIP address can accept TCP connections but it cannot accept Oracle connections.

Situations under which VIP address failover happens:-

VIP addresses failover happens when the node on which the VIP address runs fails, all interfaces for the VIP address fails, all interfaces for the VIP address are disconnected from the network.

Significance of VIP address failover:-

When a VIP address failover happens, Clients that attempt to connect to the VIP address receive a rapid connection refused error .They don’t have to wait for TCP connection timeout messages.

It is little difficult to tell because Let us assume a RAC have Two nodes. Instance running on Node1 is failed and restarted on Monday but Instance running on Node2 is active. So if you look at GV$INSTANCE it will tell NODE1 Startup Time is Monday and NOD2 Startup time is different. On the other day if instance on Node2 went down and restarted, but Instance on Node1 is up and running. So if you look at now in GV$INSTANCE will say Node started on Monday and Node2 started on Tuesday but actually database was not down for long time.
So you have to check DBA_HIST_DATABASE_INSTANCE to know the actual Database Uptime

GV$INSTANCE – Instance Name and Startup Time

DBA_HIST_DATABASE_INSTANCE – Instance Start/Stop History