Oracle RAC Administration - Controlling the Cluster with CRS command

June 1, 2006

Brief intro

Starting with this article, we will begin a discussion on administering our RAC database. Administration can mean many things; think of all that you do as an Oracle DBA--backup, restore, export, import, tuning, benchmark and even some PL/SQL work (It is not just for programmers you know).

Administering your RAC does however bring more challenges. You need solid tools in place (like SoRAC for instance); the new SQL developer can be your friend as well. TOAD is a commonly used tool among DBAs and Developers that does loads of work. And let's not forget the good old sqlplus and OEM.

In Part 5 of our "RACing ahead with Oracle on Vmware" series, we took a brief look at the SRVCTL utility. In this article, we will look at the CRS and CRSCTL utility. We will treat our Oracle documentation as our sole guide.

Introduction to CRS

Let's take a quick look at what CRS is and what it does. Let's also check out the command line paramters and what they are for.

crs_getperm: Checks the permissions that are associated with each resource.

Syntax:

crs_getperm resource_name [-u user|-g group]

Alternatively, you can just type crs_getperm resource_name and you will get the associated permissions.

crs_profile: Creates, validates, deletes, and updates an Oracle Clusterware profile.

You can also use crs_profile to generate a template script. In a profile, we decide how we will have the cluster managed and monitored. Now after you have created an application profile and registered the application with Oracle Clusterware using the crs_register command, you can use other Oracle Clusterware commands, such as crs_stat, crs_start, crs_stop, crs_relocate, and crs_unregister, on the application. This comes in very handy in troubleshooting your resources, as they sometimes go awry. Moreover, an error message asking for “human interference” really needs a human to type in the necessary parameters to check the application's condition. You must register applications using the crs_register command before the other Oracle Clusterware commands are available to manage the application.

Syntax:

Doing the following will create a profile:


crs_profile -create resource_name -t application [-a action_script] 
[-B executable_pathname] [-dir directory] [-d description] 
[-p placement_policy] [-h hosting_nodes] [-r required_resources] 
[-l optional_resources]  [-o option,[...]] 
[attribute_flag attribute_value] [...] [-f] [-q]

Then create an application profile from a template:

crs_profile -create resource_name -I template_file [-f] [-q]

Validating:

crs_profile -validate resource_name [-q]

List one or more application profiles:

crs_profile -print [resource_name [...]] [-q]

Using a template using an existing profile:

crs_profile -template resource_name [-O template_file] [-q]

Updating:

crs_profile -update resource_name [option [...]] [-q]

Deleting an application profile and its associated action program:

crs_profile -delete resource_name [-q]

crs_register: This command registers configuration information for an application with the OCR. The crs_register command registers one or more applications specified with the resource_name parameter for each application. Clearly, before starting, stopping or performing any other operations you need to register an application first. It is important to note that you must have write access to the target location. The CRS daemon must be running; if any of the fields are missing then the profile is merged with the default template. Ownership and permissions are decided at the time of resources registration. Naturally, the user who registered the application is the owner. For both the crs_profile and crs_register, read and write permissions must be available. Then we can use the crs_stat command to check if the applications are registered.

Syntax: You can use the crs_register command to register and update applications.

crs_register resource_name [-dir directory_path] [...] [-u] [-f] [-q]

crs_relocate: Here relocation of an application profile from one node to another takes place. Again, the application to be relocated must be registered first. Upon typing crs_relocate command, Oracle Clusterware transfers the resource to be relocated by effectively stopping it on the source node and then starting it on the destination node. If that does not happen, then you can always do the crs_stop -f command on the resource and restart it with crs_start to return it to the ONLINE state, before you attempt to relocate it again.

All the actions are echoed on the command line. You can, however, also monitor them using the Event Manager (EVM).

Syntax:

crs_relocate resource_name [...] [-c cluster_node] [-f][-q]
crs_relocate resource_name [-c cluster_node] [-q]
crs_relocate [USR_attribute_name=value] [...] resource_name [-c cluster_node] [-q]
crs_relocate -s source_node [-c cluster_node] [-q]

crs_setperm: This command sets and modifies permissions associated with a resource. It is actually the same as our good old chmod command in UNIX/LINUX systems.

Syntax:

crs_setperm resource_name -u aclstring [-q]
crs_setperm resource_name -x aclstring [-q]
crs_setperm resource_name -o user_name [-q]
crs_setperm resource_name -g group_name [-q]

crs_stat : Lists the status of an application profile; I use it often it to check out my resources status. Several times, I have had to start some of the resources individually to get my RAC on my (rather lightweight) VMware setup. As mentioned above the resource must have read and execute permissions except when supplying the -g option, that option is for anyone to use in order to determine if a resource exists or not.

Resources can either be ONLINE or OFFLINE as shown in the STATE attribute. If the resource is online and the cluster node fails then the Clusterware tries to restart the application on another node. It goes without saying that these resources must be ONLINE unless you have a specific reason to FORCE them to stay OFFLINE. They can also be offline if the resource has a failure count higher than the failure threshold, in which case the TARGET is changed to OFFLINE. You can however bring it online again by using the crs_start command.

I personally like the –v (verbose status) option since I like to see what is happening when I am administering the application and when troubleshooting it always comes in handy. The RESTART_COUNT tells us how many times an application resource was restarted on a node. FAILURE_COUNT tells us the failure count of a resource within the FAILURE_INTERVAL as mentioned in the profile when we created it. Once it overshoots the FAILURE_THRESHOLD parameter then it stops. The only time a FAILOVER_STATUS is shown in the verbose mode, is when an application has to wait before being relocated (owing to a cluster node failure on one node) due to the profile's FAILOVER_DELAY attribute. The FAILOVER_STATUS field goes on to show on which node the application failed and the time required for that node to restart before restarting on the other node.

Syntax:

crs_stat [resource_name [...]] [-v] [-l] [-q] [-c cluster_node]
crs_stat [resource_name [...]] -t [-v] [-q] [-c cluster_node]
crs_stat -p [resource_name [...]] [-q]
crs_stat [-a] resource_name -g
crs_stat [-a] resource_name -r [-c cluster_node]
crs_stat -f [resource_name [...]] [-q] [-c cluster_node]
crs_stat -ls resource_name

Conclusion:

CRS_ commands are rather handy during administration and particularly in troubleshooting times. In our next article, we will continue to discuss what can be done to bring all the application profiles back online using the crs_stop, crs_start and other remaining commands.

» See All Articles by Columnist Tarry Singh

Oracle RAC Administration - Controlling the Cluster with CRS command

Brief intro

Introduction to CRS

Conclusion:

Whitepapers and eBooks

Webcasts

Downloads and eKits

Tutorials and Demos