CHAPTER 4

Using Oracle Restart

Exam Objectives

In this chapter, you will learn to

• 62.2.5.1    Use Oracle Restart to Manage Components

This chapter details the use of Oracle Restart, which is the nonclustered version of Grid Infrastructure. It provides the ability to manage a range of Oracle resources. Once placed under GI control, the resources can be started and stopped with the GI utilities and restarted automatically in the event of failure.

Use Oracle Restart to Manage Components

Oracle Restart is a service provided by GI. It consists of a set of processes started and monitored by the operating system. Some of these processes run with root (or Administrator) privileges, and others run as the user under which GI was installed. Oracle Restart can be configured to start automatically or manually.

A resource is, in this context, something that can be managed by GI. All resources are registered in the Oracle Local Registry (OLR). Once registered, they are under the control of Oracle Restart. Some configuration tools will implicitly register resources if they detect the presence of an Oracle Restart configuration; others will not. In the latter case, the resource must be explicitly registered. Once registered, a resource can be started or stopped either with GI utilities (which also will take care of stopping or starting any dependent resources) or with the utilities native to the resource.

Of great importance is the high-availability capability. GI includes an event-monitoring mechanism that will detect any state change for a registered resource, propagate messages regarding state changes, and, if necessary, attempt an automatic restart of failed resources.

Administering the Oracle Restart Processes

Following the installation of GI, the Oracle Restart processes will be started automatically on booting the server. On Linux, the core process is the init.ohasd daemon. This is launched through an rc script, with monitoring and respawn enabled by an entry in the /etc/inittab file. Should the daemon die (or be killed), init will restart it. On Windows, the same function is provided by the OracleOHService Windows service, which launches, monitors, and restarts the ohasd.exe process.

To control Oracle Restart manually, use the crsctl utility. Figure 4-1 shows the use of the most frequently used crsctl commands for administering Oracle Restart on a Windows system. The commands are syntactically identical on Linux. Note that most of these commands can be executed only by a user with Administrator (Windows) or root (Linux) privileges.

Figure 4-1    Using the crsctl utility to manage Oracle Restart (Windows)

These are the commands used in Figure 4-1:

Figure 4-2 shows some more crsctl commands, this time on a Linux system.

Figure 4-2    Using the crsctl utility to manage Oracle Restart (Linux)

These are the commands used in Figure 4-2:

Administering Registered Resources

Resources must be registered with Oracle Restart if it is to provide a high-availability service for them. Some tools will register resources as they are created; others will not. For example, if you create a database with the Database Configuration Assistant (DBCA) utility, it will detect the presence of Oracle Restart and run commands to register the database. You can see these commands in the scripts that DBCA generates. If you create the database with SQL*Plus, you must register it yourself. If you create a listener with the Net Configuration Assistant, it will be registered; if you create one with the Net Manager, it will not be registered. If GI has been installed after other products have already been installed, all previously created resources must be explicitly registered.

It is possible to register resources with the crsctl utility, but this is a general-purpose tool and the syntax for adding a resource is, to put it mildly, awkward. When registering a resource, you need to give Oracle Restart, at a minimum, this information:

•  Exactly how to start, stop, and monitor the resource

•  What to do if the resource fails

•  On what other resources it may depend

Furthermore, the nature of the information needed will be different for different types of resources. A much better alternative when working with Oracle resources is to use the srvctl utility. This is preconfigured with commands for working with all the resources that a DBA is likely to need. It is, however, limited to Oracle resources; you cannot use it to (for example) register an Apache web listener as a managed resource.

The general syntax of the srvctl utility is as follows:

The commonly used commands are as follows:

The commonly used objects are as follows:

The options used in an srvctl command depend on the command and the nature of the object.

To register a database, use a command such as this:

The first option is the DB_UNIQUE_NAME of the database, which will (usually) be the DB_NAME. The second option is the Oracle Home off which the instance that opens the database will run. Other not infrequently used options let you specify required disk groups, nominate the spfile and the password file, and control the automatic start. By default, the database will be configured such that Oracle Restart will start it in OPEN mode automatically. To show the configuration of the database orclz, use this command:

This is how to start, stop, and check the status of a database:

The arguments STARTOPTION and STOPOPTION default to OPEN and IMMEDIATE (as shown). Other possible STARTOPTION values are NOMOUNT, MOUNT, and READONLY. Other STOPOPTION values are NORMAL, TRANSACTIONAL, and ABORT.

The Restart Capability

When a resource is placed under the control of Oracle Restart, it will be monitored by GI and restarted in the event of failure. A controlled shutdown of the resource (whether with the srvctl utility or with a tool native to the resource) will not trigger a restart.

Restart behavior is determined by the POLICY argument passed to the SRVCTL ADD command or to the SRVCTL MODIFY command subsequently. The default value is to enable automatic restart.

Exercise 4-1: Configure a Database for Oracle Restart    In this exercise, you register your database with Oracle Restart. It is assumed that Exercise 3-1 has been completed.

1.  From an operating system prompt, confirm that the OHASD is configured and running. Note that you will need Administrator or root privileges, and ensure that your search path includes the bin directory in the GI home. Then use the crsctl utility as follows:

2.  Demonstrate that the GI process that implements Oracle Restart is itself protected against failure by the operating system. On Linux, as the root user, identify the process number of the daemon and then kill it. Use these commands, substituting whatever the process number of your init.ohasd process is for 12345:

On Windows, use the Task Manager to locate the ohasd.exe process and then click the End Task button to kill it.

Observe that the process is restarted, with a different process ID, within seconds.

3.  Use the srvctl utility to register your database with Oracle Restart. You can rely on defaults for all arguments except the database unique name and the Oracle Home. If you have the ORACLE_HOME environment variable set to the database home, you can use it. Here is an example on Linux with a database named orclz:

4.  Confirm that the database has been successfully registered and then check its status.

The database will be reported as “not running,” whether it is or not. This is because it has not been started since it was registered.

5.  Force GI to perform a reality check by issuing a start command and then check the status again.

The following illustration shows steps 2 through 4 on a Windows system:

6.  Experiment with startup and shutdown commands, both with srvctl and with SQL*Plus. Check the status each time.

7.  While the database is running, demonstrate the restart capability. On Linux, use the ps command to identify the smon background process and then kill it. This will terminate the instance immediately. On Windows, use the Task Manager End Task button to kill the oracle.exe process.

Observe that the instance will restart within seconds.

The following illustration shows the instance restart test on Linux:

Oracle Restart can protect resources other than databases, including both Oracle-supplied services and third-party services. If Oracle Restart is already installed, then most Oracle services installed subsequently will be registered during their installation. If this has not been done, they can be registered later.

Exercise 4-2: Register a Listener as a Managed Resource    Place your database listener under Oracle Restart control and demonstrate its effectiveness. The command you will need (no line breaks) is as follows:

The default values for the arguments assume that the listener is named LISTENER, that the listening endpoint is 1521, and that the Oracle Home is the GI home (which will not be correct if you have followed the exercises so far). Then check its configuration and status, stop and start the listener, and observe the effect of killing the listener process with an operating system utility.

The following are possible commands (with a Windows Oracle Home):

This is one way to simulate a failure on Windows:

On Linux, find the process ID of the tnslsnr process and kill it.

Note that the listener will restart in a few seconds.

Two-Minute Drill

Use Oracle Restart to Manage Components

•  Control Oracle Restart with the crsctl utility.

•  Administer Oracle Restart–managed resources with the srvctl utility.

•  The OHASD process is protected by the operating system.

•  Protected components may be databases, database listeners, the ASM instance, and ASM disk groups.

•  If dependencies have been configured (such as between a database and a disk group), Oracle Restart will stop and start them in an appropriate sequence.

Self Test

1.  Under what circumstances will Oracle Restart restart a database? (Choose two answers.)

A.  If it is stopped with SQL*Plus

B.  If it fails after being started with SQL*Plus

C.  If it fails after being started with the srvctl utility

D.  If it is stopped with the crsctl utility

2.  There are several techniques for registering a database with Oracle Restart. Which of these techniques will not result in a successful registration?

A.  Use the SRVCTL ADD DATABASE command from the database home to add the database to the OLR and then create the database with SQL*Plus.

B.  Create the database with DBCA.

C.  Create a database and leave it running and then install GI and run the GI configuration scripts.

D.  Create the database with SQL*Plus and then use the SRVCTL ADD DATABASE command from the Grid Infrastructure home to add the database to the OLR.

3.  Following a standard installation, the GI processes will start automatically when a machine is booted. How can you change this behavior such that they must be started manually? (Choose the best answer.)

A.  Use the srvctl utility:

B.  Use the crsctl utility:

C.  Edit the /etc/inittab file to remove the entry that launches the OHASD.

D.  Use the DBCA graphical utility to adjust the start mode.

4.  Your database uses the ASM disk groups DATA and FRA for its storage. You register the database with this command:

Which of the following statements is correct? (Choose the best answer.)

A.  If you attempt to use srvctl to start the database before the ASM instance has mounted the disk groups, the database will not start.

B.  If you attempt to use srvctl to start the database before the ASM instance has started, the ASM instance will start automatically.

C.  The $ORACLE_HOME variable must be set to the ASM home so that the database instance can find the ASM instance.

D.  The registration command will fail if the database does not exist.

Self Test Answers

1.      B and C. Oracle Restart will restart automatically after any failure, no matter how the database was started.
    A and D are incorrect. These are incorrect because Oracle Restart will not restart a database that is stopped in an orderly fashion, no matter what utility is used for this.

2.      C. The GI installation and configuration does not include any facility for detecting and registering databases, whether or not they are running at the time.
    A, B, and D are incorrect. B is incorrect because if DBCA detects the presence of GI, it will generate and run appropriate commands. A and D are incorrect because registration in the OLR can be done before or after database creation, running the utility from either home.

3.      B. The crsctl utility is the supported technique for disabling the autostart of the GI processes.
    A, C, and D are incorrect. A is incorrect because the srvctl utility can manage an Oracle Restart–registered resource, not Oracle Restart itself. C is incorrect because although you could hack at the operating system inittab and rc files, it is not a supported technique. D is incorrect because DBCA cannot manage any GI components, only databases.

4.      B. Oracle Restart is aware of dependencies, and it will start ASM and mount any required disk groups.
    A, C, and D are incorrect. A is incorrect because registered dependencies will take care of this. C is incorrect because when you are registering a database, the ORACLE_HOME argument must point to the home off which the RDBMS instance will run. D is incorrect because there is no “reality” check when adding entries to the OLR; the errors will come later.