Oracle RAC Administration - Part 7: Starting and Stopping the Database Instances and RAC Databases
October 19, 2006
Talking about syntax and theory is nice. It is good to know the facts and it is fine to know what syntax to use where. I can also assume that you enjoy my articles, but I may be wrong. That is exactly what a polite critique reminded me. (Thanks Solomon!).
Doing a walk-through of syntax and theory is good but if it's not complimented with a demonstration, it will slip out of the mind just about as fast as it came. So I took the advice and will from now on spend more time in demonstrating the syntax (on a running RAC) and going through all of the details. We will in our administration series, attempt to break our Oracle RAC and try to mend it again. My next article will catch up with the real time demo on the commands and syntax.
Starting and Stopping Instances and RAC databases
It's easy to start up and shut down the instances from the Enterprise Manager console, SQL*Plus or SRVCTL utility. The minor difference here is that both the Enterprise Manager and SRVCTL have options to startup and shutdown all instances of your RAC with a single step! Also, note that certain operations can be carried out in either NOMOUNT or MOUNT state while other operations require the database to be OPEN.
We will as usual use the SPFILE and go about the following:
Obviously, you will need your RAC to be operational. The difference of a RAC against a regular database is that you can easily shutdown (even pull out the plug if you are impatient) and still have your services remain operational. That is utility computing; and indeed RAC is a utility appliance.
Starting Up and Shutting Down with Enterprise Manager
Doing this is pretty easy. You can either shut all of the instances down or bring down the individual nodes. Do the following to start up or shut down a cluster database instance:
To bring down or bring up your RAC, meaning all instances that the Enterprise Manager is aware of, you will do the following:
Starting Up and Shutting Down with SQL*Plus
When you need to start or stop a single node with SQL*PLUS, while still connected to the local node, make sure that environment variables are OK. Normally with our RAC setup, we need not worry about that, as with every node reboot the environment variables are reloaded.
CONNECT / AS SYSDBA STARTUP MOUNT
NOTE : You can start multiple instances from a single SQL*Plus session using Oracle Net Services (this is similar to opening a putty console and doing ssh anothermachinename to go to the other machine and jump across machines via one console. The below mentioned example will typically be done via a putty or ssh console of one machine and jump across nodes from that machine).
You must, however, use an alias in your connection string. This is a common practice, which I prefer to do on my local node as well, since I travel so much across consoles that sometimes I forget where I am working. Therefore, you will do this to shutdown a node 3 and 4 say vm3rh4 and vm4rh4:
CONNECT /@vm3rh4 AS SYSDBA SHUTDOWN
Then go to the second node and connect from the SQL*Plus session:
CONNECT /@vm4rh4 AS SYSDBA SHUTDOWN
Also note that there is no one command that will shutdown all of the nodes. You can, however, write a shell script that will do so. Maybe we will try to cook up one and see it in upcoming articles. Or better yet, just stick to the Enterprise Manager for such activities.
Starting Up and Shutting Down with SRVCTL
We have covered SRVCTL before, so we'll do a quick syntax check here, to start an instance:
srvctl start instance -d mydb -i "myinstance_list" [-o start_options] [-c connect_str | -q]
To stop, do the following:
srvctl stop instance -d mydb -i " myinstance_list" [-o stop_options] [-c connect_str | -q]
To start and stop the entire RAC cluster database, meaning all of the instances, you will do the following from your SRVCTL in the command line:
srvctl start database -d mydb [-o start_options] [-c connect_str | -q] srvctl stop database -d mydb [-o stop_options] [-c connect_str | -q]
There are several options and we will look at all of them in upcoming articles in RAC administration.
Time Synchronization: A common problem in a typical VMware RAC Cluster
You must have noticed time synchronization problems during the install process. Your install will fail miserably if there are time sync problems and even during listener creation, you might get time in future related errors. What I encountered during preparation of my Virtual Machines was that a dual or even a quad vCPU Virtual Machine, that the CPU runs wild (mostly faster). I will not get into the detail of time drift, cpuspeed, etc., as there is enough advice from other corners to drive you nuts. However, configuring the ESX Servers ntp file helped me to keep time on a ESX 2.5.x host with 4 dual vCPU Virtual Machines RHEL 4.2 OS and have my RAC run successfully.
In our next article, we will continue by show more realistic examples against what we have discussed in our previous articles. Upcoming articles will try to take a closer look at the Enterprise Manager Console.