Oracle RAC Administration - Part 6: Administering the Database Instances and Cluster Databases
October 5, 2006
Oracle has finally released its Oracle 10G Release 2 database for Solaris 10. I have been waiting for it for quite some time and I hope that they were able to fix the clusterware problems, which had had some issues. Anyway, I will test it on my ESX box, which has three ready baked Solaris 10 U1 Operating Systems.
OK moving ahead with our administration series, we will look at administering our database instances and cluster databases.
Tools needed for administering our instances
For every administration task, you need a steady and reliable set of tools. I have seen many tools (and I mean third party tools) but when it comes to taming the Oracle database, you should have a look at the tools discussed (briefly) below. It really doesnt matter if you are administering a multi-node RAC farm or a single Oracle instance:
Managing Oracle Real Application Clusters with SQL*PLUS
We can all tell tales about the famed SQL*Plus tool, but check into it in the manual labeled Utilities. It's a great utility and is readily available with the installed Oracle base. Try to connect using the proper parameters, such as naming the instance, because by default, the SQL*Plus prompt does not identify the current instance. So you would typically do something like this if you need to connect to a different instance in SQL*PLUS:
If you want to change the SQL*Plus prompt, so that it automatically includes the name of the current instance, you will have to type the following commands in your SQL*Plus:
SET SQLPROMPT '_CONNECT_IDENTIFIER> '
Now, what this command will do is, it replaces the SQL string before the > symbol with the user variable
SET SQLPROMPT '_CONNECT_IDENTIFIER> '
You can also add any other needed text or even a SQL*Plus user variable between the single quotes in the command. We all know that we can have several SQL*Plus sessions to the same instance. To perform any important tasks, you can log on as SYSOPER or SYSDBA. Administrative tasks such as instance shutdown, startup can be carried out with these admin privileges.
Managing Oracle Real Application Clusters with Enterprise Manager
This web-based tool has come of age and offers an enterprise class administration and RAC control, to manage a single Oracle RAC database. Enterprise Manager is the central tool that focuses on all possible aspects of our RAC service, providing a central point of control for the Oracle environment through a graphical user interface (GUI).
Oracle Enterprise Manager can be used to start, stop and monitor databases, RAC instances and the associated Listeners. There are schedule jobs, alert thresholds, altering schema, storage features and much more. We will dedicate more time to the Enterprise Manager, since it is a very useful tool, even for Grid control, meaning when administering a GRID. In addition, Enterprise Manager can perform tasks on the fly, on multiple RAC databases.
Managing Oracle Real Application Clusters with SRVCTL
In a previous article, we did some work with the SRVCTL tool, which we touted as a powerful utility, and it is powerful, for many reasons. SRVCTL is the source to all of the feeds that go into the Enterprise Manager. The configurations, for instance, are all picked up from a list that SRVCTL generates when discovering and monitoring the nodes in our RAC. These configurations are all stored in our Oracle Cluster registry (OCR) file. In addition, Enterprise Manager uses SQL*PLUS to stop and start the instances. Of course, the Enterprise Manager uses many more tools (which we as DBAs and Developers use day to day) than just the above-mentioned tools, to arm you with a robust GUI.
An Example : Starting/Stopping using various tools
We can use all the tools to perform the start/stop tasks, whether it Enterprise Manager, SQL*Plus or SRVCTL. Assuming that we are using the SPFILE, which is advisable anyway, lets do the following:
Make sure that your Clusterware is running. You will not be able to start your RAC (after you have brought it down for this exercise) if your CRS stack is not running properly. All of the processes must be running in place. The procedure for shutting down RAC instances is pretty much the same as performing that kind of exercise on a single-instance Oracle database. There are however some important points to note. Refer to the Admin manual for more information on shutting down the databases. The key differences are:
In our next article, we will continue to perform the shut down and start up task using SQL*PLUS, Oracle Enterprise Manager and SRVCTL.