How to Use Oracle Restart in Oracle 11gR2

Oracle Restart is a new feature in 11g Release 2. This feature could probably be best described as a
single-instance version of the RAC command-line interface. To install Oracle Restart, you need to install
Grid Infrastructure for a single node. Unlike clustered Grid Infrastructure, there is no prohibition against
installing the software in the same Oracle base. Also, the administrator is free to install the software with
different accounts for Grid Infrastructure and the database binaries. However, we’ve found that many

administrators choose not do this, instead, they typically opt to use the oracle account to install both
Oracle Restart and the database binaries.
ASM is only available as part of Grid Infrastructure. If you want to use it, then you must install
Oracle Restart as well, in which case you might as well make most of it. From a database administrator’s
point of view, Oracle Restart is a blessing because it offers a single command-line interface into Oracle
single-instance deployments and RAC. The automatic startup of resources registered with Oracle Restart
solves a very old problem of having to provide startup scripts. This is a great advantage for companies
running Oracle on many different hardware platforms. It is literally impossible to find a listener not
started after a database server rebooted. Also, the administrator does not have to worry about the ASM
instance or disk group not being mounted—this is also accomplished automatically.
After a fresh installation of Grid Infrastructure for a single server, you will find resources that are
automatically managed by Oracle Restart. The resources managed by Oracle Restart after a fresh
installation include the following:
• The CSS daemon
• The diskmon daemon
• Any ASM disk group(s)
• The listener
• The ASM instance
Identical to what you find in a full RAC installation, the aforementioned resources will automatically
be protected from failure by the Grid Infrastructure software stack. In contrast to a RAC installation,
Oracle Restart does not create resources for ONS and eONS daemons by default. If you would like to
benefit from FAN events in an Oracle Restart environment, then you need to manually add and start
these two processes, as in the following example:
[root@london1 ~]# srvctl add ons
[root@london1 ~]# srvctl start ons
[root@london1 ~]# srvctl add eons
[root@london1 ~]# srvctl start eons
Note that you can use server callouts the same way you do with RAC once the ONS/eONS processes
are started (please refer to the “Defining Server-Side Callouts” section earlier in this chapter for more
information about server callouts).
As with RAC, the Oracle High Availability Services daemon starts through the init process at system
boot. And again, as with RAC, the OHAS daemon does not adhere to the standards of Red Hat’s rc system
in the 11.2.0.1 base release. This means that, even though a kill script is configured to stop OHASD in the
relevant run level, the absence of a lock file in /var/lock/subsys/ means that the kill script is never
invoked, which results in a database crash. The startup process from this point on differs from clustered
Grid Infrastructure. For example, there are no cluster components started by CRSD (in fact there is no
CRSD at all); instead, all you need to do is start ASM and the defined database resources, as well as any
potentially registered services. In comparison with the clustered start sequence in RAC, you do not see a
cssdmonitor process; rather, cssdagent will have to monitor ocssd.bin without the help of its clustered
cousin. The OHAS daemon uses the OLR to read configuration information and resource dependencies;
however, Oracle Restart does not use a GPnP profile.
All resources managed by Oracle Restart should preferably be controlled by the srvctl commandline
tool. This ensures that the dependencies defined in the resource profile can be respected. This
especially applies to the listener, database, and services. The main assistants—dbca, netca, and asmca—
are Oracle Restart aware, and they will modify resource profiles. Any database created with dbca will

 

automatically be registered in Oracle Restart, and it will have a dependency on the ASM disk group(s) it
uses. With Oracle Restart, it is finally no longer necessary to modify the database service_name
initialization parameter; indeed, it is actually no longer recommended. Instead, database services should
be defined using the srvctl add service command. Neither should you use the deprecated
CREATE_SERVICE in DBMS_SERVICE procedure.
You can query Oracle Restart meta-information much as you can with RAC. Many of the commands
mentioned in the “Managing Oracle Clusterware” section can also be used for Oracle Restart. For
example, the crsctl and srvctl command-line utilities support Oracle Restart with a non-clustered
subset of their command-line arguments.
Troubleshooting Oracle Restart is almost identical to troubleshooting RAC; the daemons started in
Oracle Restart use the same log file locations as their RAC counterparts. Thus, the primary location for
troubleshooting log files is $GRID_HOME/log/hostname.