Basic Tools to Use to Manage a Real Application Clusters Installation in Oracle 12c
Oracle 12c supplies several tools for managing a Real Application Cluster (RAC) installation. Some of the tools are RAC specific, but others are also for non-RAC databases. All the tools for both RAC and non-RAC databases become cluster aware when you launch them in the presence of a clustered environment. This means that they will see the cluster and all the nodes in it.
Oracle Universal Installer for grid infrastructure
If you choose Oracle Grid Infrastructure as your clustering software, right off the bat the Oracle Universal Installer (OUI) makes the software stack installation easy.
As long as you meet the following two criteria, the OUI begins by installing the software from one node, and then it replicates across the entire cluster:
Correctly configure the hosts file across all the nodes.
Enable user-equivalence, ssh/rsh, and scp/rcp for the Oracle user across all your nodes.
This way, you have to install the software only once. (You still have to run a couple of configuration scripts on the remaining nodes after the initial install on the primary node.)
Oracle Universal Installer for other software
After you configure the cluster, the OUI is cluster aware for all installs thereafter. That means every time you go to install Oracle software, it asks you to choose the nodes you want to do the install on. This option is very nice when you do your database and agent installations. Furthermore, all patchsets that you apply also give you the option of pushing out to all the nodes.
Of course, if you’re patching in a rolling method, you can apply it one node at a time (hence, roll from one node to the next).
Database Configuration Assistant (DBCA) in Oracle 12c
When the Database Configuration Assistant (DBCA) is launched from a node in a cluster, it too is automatically cluster aware. It begins the database creation and configuration by asking on what nodes you want to perform operations. To create a four-instance cluster across four nodes, you have to log on to only one of the servers and do it all from the DBCA.
Network Configuration Assistant (NETCA) and Oracle 12c
When it comes to managing listeners and tnsnames files, NETCA is also cluster aware. If you need to add a listener or tnsnames entry, any action taken on one node is automatically propagated with appropriate settings across all the nodes. Configuring all the listener.ora and tnsnames.ora files across a multimode cluster would take a week by hand.
Server Control (srvctl) and Oracle 12c
Server Control is probably your day-to-day main command-line tool for managing your RAC environment.
To see an abbreviated list of all the things you can do with this tool, open a command-line prompt on your OS and type this:
You see something like this:
Usage: srvctl <command> <object> [<options>] command: enable|disable|start|stop|relocate|status|add|remove|modify|getenv|setenv|unsetenv|config objects: database|instance|service|nodeapps|asm|listener For detailed help on each command and object and its options use: srvctl <command> <object> -h
The server control utility lets you manage nearly all the resources across the entire cluster from one session. Say you’re logged in to node1 and want to shut down the instance prod31 on node3 for the database prod3. This is what you’d type:
<srvctl stop instance -d prod3 -i prod31>
You should see this:
That’s right: You see nothing if it works correctly. If you get errors, research appropriately.
You can use Server Control to do the following and any combination therein:
Stop all instances of a database.
Stop two of five instances for a database.
Start all instances.
Stop one or all listeners.
You can easily script Server Control into operating scripts. That’s one of its big benefits. Tools such as SQL*Plus and the listener control utility (which require an execution on each node for multinode operations and multiline inputs) make for more complex scripts. With Server Control, everything is contained in one line for whatever operation you want to accomplish.
Cluster Control (crsctl) and Oracle 12c
Cluster Control is another command-line tool that controls the cluster-specific resources. It can start and stop the cluster components on individual nodes.
Type this to launch Cluster Control and get a list of the command options:
You see something like this:
Usage: crsctl check crs - checks the viability of the Oracle Clusterware crsctl check cssd - checks the viability of Cluster Synchronization Services crsctl check crsd - checks the viability of Cluster Ready Services crsctl check evmd - checks the viability of Event Manager crsctl check cluster [-node <nodename>] - checks the viability of CSS across nodes crsctl set css <parameter> <value> - sets a parameter override ...output snipped... crsctl query crs activeversion - lists the Oracle Clusterware operating If necessary any of these commands can be run with additional tracing by adding a 'trace' argument at the very front. Example: crsctl trace check css
Stop all the cluster resources on that particular node with Server Control.
Stop the cluster-specific components:
<crsctl stop crs>
You see this:
Stopping resources. Successfully stopped CRS resources Stopping CSSD. Shutting down CSS daemon. Shutdown request successfully issued.
You might be required to reboot the node once or twice during the OS maintenance; you don’t want the cluster to restart.
Prevent the cluster services on this node from restarting:
<crsctl disable crs>
Do all the reboot you want.
You don’t have to worry about the cluster services interfering.
Re-enable the cluster services:
<crsctl enable crs>
Restart the cluster services:
<crsctl start crs>
All the cluster resources start, including the database-related resources on the node.
Oracle Interface Configuration Tool (OIFCFG)
If you need to change the cluster (changing server name or IP addresses, for instance), you must use the Oracle Interface Configuration Tool (OIFCFG) to reconfigure those changes in the internal cluster configuration.