HOW TO REMOVE CRS AUTO START AND RESTART FOR A RAC INSTANCE

Subject:  HOW TO REMOVE CRS AUTO START AND RESTART FOR A RAC INSTANCE

  Doc ID:  Note:298073.1 Type:  BULLETIN

  Last Revision Date:  13-MAY-2005 Status:  PUBLISHED

***

This article is being delivered in Draft form and may contain

errors.  Please use the MetaLink "Feedback" button to advise

Oracle of any issues related to this article.

***

PURPOSE

-------

HOW TO REMOVE CRS AUTO START AND RESTART FOR A RAC INSTANCE

with Oracle Database 10g (10.1.0.4)

SCOPE & APPLICATION

-------------------

Anyone with an RAC Database using Oracle Clusterware (CRS) and

Oracle Database 10g.  You must be at 10.1.0.4.

HOW TO REMOVE CRS AUTO START AND RESTART FOR A RAC INSTANCE

-----------------------------------------------------------

OVERVIEW

Oracle Clusterware (CRS) is a new feature of Oracle Database 10g Real

Application Clusters that further differentiates RAC for high availability and

scalability. CRS provides automated management and sophisticated monitoring of

RAC instances and is designed to enhance the overall user experience of cluster

database management.

By default, CRS is configured to auto-start database instances as a part of node

boot and provide lights-out instance failure detection followed by an

auto-restart of the failed instance. However, on some special occasions,

it might be highly desirable to limit the level of protection CRS provides

for a RAC database. Namely, this implies preventing instances from auto-starting

on boot and not auto-restarting failed instances.  The latter, however, may be

relaxed to allow a single attempt to restart a failed instance. This way, CRS

will attempt to restore availability of the instance, but avoid thrashing if a

problem that caused the instance to fail also keeps preventing it from

successfully recovering on restart. Either way, the choice to customize this is

left to the DBA.

Oracle Database 10g Real Application Clusters release 10.1.0.4 and above make

it possible to accomplish the above stated change in CRS behavior. This document

lists the steps necessary to limit the level of CRS protection over a RAC

database.

HIGH LEVEL APPROACH

In a nutshell, the procedure amounts to the following two parts

  1. Identifying a set of CRS resources that affect the behavior

  2. Modifying a few profile attributes to contain special values for the

resources identified in the first step

The following sections will cover both phases in detail.

IDENTIFYING RELEVANT RESOURCES

The automated management of a RAC database is accomplished by modeling various

RAC applications/features as CRS resources. A CRS resource is defined by a

profile, which contains a list of attributes that tell CRS how manage the

resource.  CRS resources created to manage a RAC database can be identified as

belonging to a well-known type. There is a finite and relatively small number

of types. The type may be easily identified given the name of a resource: each

name ends with a <resource_type>. For instance, ora.linux.db is of type db,

which happens to mean database. To display the names of the resources managed

by the CRS, use the crs_stat command from a clustered node.  The output of the

command is a set of names and states of resources registered on the cluster to

which the node belongs.

Figure 1. Example Listing resource names using crs_stat

$ crs_stat

NAME=ora.linux.ar.us.oracle.com.cs

TYPE=application

TARGET=OFFLINE

STATE=OFFLINE

NAME=ora.linux.ar.us.oracle.com.linux.srv

TYPE=application

TARGET=OFFLINE

STATE=OFFLINE

Additional output is available but has been truncated for clarity's sake

The relevant resources are the resources that belong to the following 4 types:

  db - Denotes resources that represent a database

  srv -Denotes resources that represent a service member.

  cs - Denotes resources that represent a service.

  inst - Denotes resources that represent a database instance

The CRS profiles for these resources must be modified for the new CRS behavior

to take effect for all RAC databases installed on the cluster. If, however,

the affect of the change is to be limited to a subset of installed databases,

the list of resources needs to be filtered further. (The rest of this section

should be skipped if the new CRS behavior is to be in effect for all databases

installed on the cluster.)

Please note that since more than one database may be installed on a cluster,

to modify the level of protection for a particular database, one must identify

the resources that represent entities of this database. This may be easily

accomplished since the names of the resources belonging to the above- stated

types always start with ora.<database name>.  For instance, ora.linux.db

means that the resource belongs to the database named linux.  Only resources of

the above-enumerated types that belong to the selected databases will need to

have their profiles modified.

MODIFYING RESOURCE PROFILES

Please note that Oracle strongly discourages any modifications made to CRS

profiles for any resources starting with <ora>. Never make any modifications to

CRS profiles for <ora> resources but the ones explicitly described below in

this document.

To modify a profile attribute for a resource, the following steps must be

followed:

  1.Generate the resource profile file by issuing the following command:

        crs_stat -p resource_name > $CRS_HOME/crs/public/resource_name.cap

  2.Update desired attributes by editing the file created in step 1.

  3.Commit the updates made as a part of the previous step by issuing the

    following command

        crs_register -u resource_name

  4.  Verify the updates have been committed by issuing the following command

        crs_stat -p resource_name

For each of the resources identified as a part of the preceding section, the

following modifications must be made:

  1.Resources of type inst must have the following attributes modified

        AUTO_START must be set to 2

        RESTART_ATTEMPTS must be set to 0 or 1. The former value will prevent

    CRS from attempting to restart a failed instance at all while the latter

    will grant it a single attempt; if this only attempt is unsuccessful,

    CRS will leave the instance as is.

  2.Resources of type db, srv,  cs must have the following attributes modified

    AUTO_START must be set to 2