Tweet
Why RAC need a VIP (Virtual IP address)
Importance of VIP
Real Application Clusters in 10g, however, don’t particularly want you to connect to physical IP address associated with network interface.
Doing so means IP packets are routed to a physical MAC address, so that if that address ever ceases to exist (such as when a server dies), we have to wait for TCP/IP networking protocol itself to work out that packets are undeliverable.
That can take up to 10 minutes, and would mean failover in a RAC can potentially be very slow.
Instead, Oracle wants users to connect to a Virtual IP Address (VIP). That’s an IP address that’s bound to a software-controlled MAC address and since it’s software controlled, the software can arrange for failures to be handled a lot quicker than plain old TCP/IP stack (in seconds, usually).
The VIP for a RAC node is quite often the normal, real IP address plus one so, in my case, that would imply a VIP of 192.168.1.111. I won’t be needing this until it comes time to installing the Oracle software, but it’s good to plan ahead.
Even if check fails you can continue the installation,by configuring vipca seaparately , even if that IP does not exist (no need that you own that ip).
RAC | How to use SRVCTL Command
Check out current configuration information
| srvctl config database | Displays the configuration information of the cluster database. |
| srvctl config service | Displays the configuration information for the services. |
| srvctl config nodeapps | Displays the configuration information for the node applications. |
| srvctl config asm | Displays the configuration for the ASM instances on the node. |
Summary of srvctl commands.
| Command | Targets | Description |
|---|---|---|
| srvctl add srvctl modify srvctl remove |
database instance service nodeapps |
srvctl add / remove adds/removes target‘s configuration information to/from the OCR.srvctl modify allows you to change some of target‘s configuration information in the OCR without wiping out the rest. |
| srvctl relocate | service | Allows you to reallocate a service from one named instance to another named instance. |
| srvctl config | database service nodeapps asm |
Lists configuration information for target from the OCR. |
| srvctl disable srvctl enable |
database instance service asm |
srvctl disable disables target, meaning CRS will not consider it for automatic startup, failover, or restart. This option is useful to ensure an object that is down for maintenance is not accidentally automatically restarted.srvctl enable reenables the specified object. |
| srvctl getenv srvctl setenv srvctl unsetenv |
database instance service nodeapps |
srvctl getenv displays the environment variables stored in the OCR for target.srvctl setenv allows these variables to be set, and unsetenv unsets them. |
| srvctl start srvctl status srvctl stop |
database instance service nodeapps asm |
Start, stop, or display status (started or stopped) of target. |
Adding a Database Service
srvctl add service -d <database_name> -s <5ervice_name> -r “<preferred list>”
londonl$ srvctl add service -6 RAC -s SERVICE2 -i “RACl,RAC2” -a “RAC3,RAC4”
Starting a Database Service
srvctl start service -d <database_name> [-s “<service_name_li$t>” [-1 <in$t_name>]] [-0 <start_options>] [-c <connect_str> | -q]
londonl$ srvctl start service -d RAC -s “SERVICEl,SERVICE2”
Stopping a Database Service
srvctl stop service -d <database_name> [-s “<service_naine_list>” [-1 <inst_name>]] [-C <connect_str> | -q] [-f]
londonl$ srvctl stop service -d RAC -s “SERVICE2,SERVICE3” -f
Checking the Current Database Service Configuration
srvctl config service -d <database_name> [-s <service_name>] [-a] [-S <level>]
londonl$ srvctl config service -d RAC -a
The -a option includes information about the configuration of TAF for the database service
Checking Current Database Service Status
srvctl status service -d <name> -s “<service_name_list>” [-f] [-v] [-S <level>]
londonl$ srvctl status service -d RAC -s “SERVICEl,SERVICE4”
Enabling and Disabling a Database Service
srvctl disable service -d <database_name> -s “<service_name_list>” [-i <in$t_name>]
londonl$ srvctl disable service -d RAC -s SERVICE2 -i RAC4
srvctl enable service -d <database_name> -s “<service_name_list>” [-i <inst_name>]
londonl$ srvctl enable service -d RAC -s SERVICE2 -i RAC4
Removing a Database Service
srvctl remove service -d <database_name> -s <service_name> [ – i <inst_narne>] [-f]
londonl$ srvctl remove service -d RAC -s SERVICE4
Relocating a Database Service
srvctl relocate service -d <database_name> -s <service_name> -i <old_inst_name> -r <new_inst_name> [-f]
londonl$ srvctl relocate service -d RAC -s SERVICES -i RAC2 -t RAC4
Administering Instances
Starting an instance : srvctl start instance -d prod -i “prod1,prod2”
Stopping an instance: srvctl stop instance -d prod -i “prod1,prod2”
Checking the status of an instance : srvctl status instance -d prod – i “prod1,prod2”
Adding a new instance configuration : srvctl add instance -d prod – i prod3 -n prod3_node
Removing an existing instance configuration: srvctl remove instance -d prod3-i prod3_node
Disabling an instance: srvctl disable instance -d prod -i “prod1,prod2”
Enabling an instance : srvctl enable instance -d prod -i “prod1,prod2
