My first introduction with the Oracle Restart was an accidental one. I installed database 11gr2 with Oracle ASM and when I restarted the host, the database and all related services started up.
Normally, this will not happen, as in order to startup the database and dependent services automatically, we had to setup shell scripts.
I went on to discover that this functionality was available, starting in 11gr2 and the feature was officially called as Oracle Restart.
What else does Oracle Restart do?
It finally turned out that Oracle Restart does more than just restart the database on system reboot!
Oracle Clusterware service is normally installed when you setup a RAC database. The Clusterware service ensures that all components are restarted properly, in the order in which they are supposed to start.
This is mandatory requirement to maintain the high availability of the database and to also ensure that in case of system failure, the database services are brought back up smoothly.
Oracle Restart is a subset of the RAC Clusterware service, and provides similar features for a standalone database as that present for a RAC host.
Oracle Restart relies on OHAS (Oracle High Availability Service) daemon and ensures that in case a system failure happens or system is restarted, all Oracle services are properly started as well. The main components that Oracle
Restart controls the following resources.
• ASM Disk Group
• Oracle Notification Services
You can experiment with the functionality of Oracle Restart by just killing the Oracle PMON processes at the OS level. This will cause the instance failure and will take the database offline.
Before 11gr2 or even 11gr2 databases without restart, the restart will not happen automatically. A manual startup will have to be issued. But once Oracle Restart is used, the instance recovery will resume automatically and all services will be started to make database available again.
The same thing happens when you reboot the host. When the system starts, the OHAS daemon checks if all Oracle services are up and running or not. If not the daemon starts all the services in the order in which they should be started.
So why do you need to have Oracle Restart configured for your database?
Well, the simple answer is that Grid Infrastructure is required for this. Oracle Restart, much like ASM, is not part of database software.
It is part of Grid infrastructure software which will require another Oracle home. However you are not required to configure ASM to use Oracle Restart.
So is it worth installing the Grid Software just to have Oracle Restart? It all depends on your requirement.
If you have a high availability requirement for your standalone database and want Oracle to take care of this then you might want to go the extra mile and have Oracle attempt a restart of the database for you.
If you already have a database up and running and want to install the Clusterware after that then you will have to add the database to the Oracle Restart. However if you install the Clusterware before the database then it will be added automatically.
Oracle provides SRVCTL utility to manage components that Oracle Restart has control over. For example you can use the following command to add database to Oracle Restart.
$ srvctl add -d database -o $ORACLE_HOME
Integration with SQLP*PLUS, LNSRCTL
The best thing about the Oracle Restart is that it is tightly integrated with SQL*PLUS, LSNRCTL etc. So when you perform a shutdown of the database via SQL*PLUS, Oracle Restart realizes that it is deliberate command sent by DBA, so it won’t attempt to restart the database.
Integration with Data Guard
Oracle Restart is integrated with Oracle Data Guard as well. Any database that is Restart enabled and is part of a Data Guard configuration will automatically restart all the components, including parent processes.
Oracle Restart also ensures that if a role change has occurred for database then all dependent services which are required for new role are properly restarted as well.
The following components of any Data Guard configuration are supported.
If a database is part of Data Guard and you want to add it to Oracle Restart it is supported. While adding it to Oracle Restart you can also mention the role of database in Data Guard, e.g. PRIMARY, PHYSICAL_STANDBY, LOGICAL_STANDBY, or SNAPSHOT_STANDBY.
Later on if the role of database is changed via the Dataguard broker then Oracle Restart can also update this configuration automatically on its end. However if the configuration of database is changed manually and not via the Dataguard Broker then a manual update is required.
When adding database services to the Oracle Restart you can specify the role of the database for which this service is to be started.
With this configuration in place, as soon as database switches to that particular role, the service is started automatically as well. It also prevents the service to start when database is in a role not applicable for service.
Integration with Fast Application Notification
Fast Application Notification or simply FAN is a notification mechanism that different Oracle services can use to publish notifications about the service events.
Clients can subscribe to these events and get frequent updates regarding different service events like the UP and DOWN events. Oracle Restart can also publish its own FAN events as well.
When a single database uses Oracle Restart then it knows the current state of database and hence informs the clients if there is restart required on database or there if there is maintenance activity.
Apart from managed maintenance, Oracle Restart can also publish notifications for fallout events to different admins if certain component needs manual recovery.