A few years back, I worked with a junior DBA who was asked to create a new instance on a brand new machine. He created the instance using DBCA and everything went smoothly – or so he thought. A few weeks later, after the system became production, a planned maintenance rebooted that Linux server, and once the machine came back up – the database and listener processes were nowhere to be found.

So that junior DBA, stressed because he thought the database was lost called me in the middle of the night. My first sleepy question for him was “did you even start the database?” and his panicked reply was “of course not – it should be done automatically, I used DBCA!”…

Well, one of the things new DBA’s find hard to realize is that after installing and creating a database (even if we’re using DBCA), it will not start automatically. I’ve seen too many new DBA’s being puzzled by the logic behind automatic startup of Oracle databases on Linux (and UNIX in general) than I care to admit so I decided to put it here for their reference…

In this article I will describe the building blocks for automatic startup, and in my next post I will show the Linux commands needed to put everything together.

Starting the database manually

The mistake the junior DBA did was to assume that the DBCA would setup some kind of a method of automatically starting the database once the server is started. This does not happen, at least not in the way we think about it. Oracle is creating everything we need in order to setup automatic startup, but it is our job to put things together in order for it to work.

Let’s begin with the basics. In order for a database to start, we need to use the Oracle owner (or any of the DBA or OPER group), set the ORACLE_HOME and ORACLE_SID environment variables and use SQL*Plus “startup” command.

[oracle@lnx-oracle-1 ~]$ export ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_11204
[oracle@lnx-oracle-1 ~]$ export ORACLE_SID=orcl
[oracle@lnx-oracle-1 ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.4.0 Production on Mon Mar 7 16:34:21 2016

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> startup
ORACLE instance started.

This is the basic and one of the more common ways to do it. Another way to set the ORACLE_HOME and ORACLE_SID is using Oracle’s script “oraenv”. Here we use “.” (dot) the shortcut to Linux “source” command in order to set the variables. If we don’t source the script, the variables will not change.

[oracle@lnx-oracle-1 ~]$ . oraenv
ORACLE_SID = [orcl] ? orcl
The Oracle base has been set to /u01/app/oracle
[oracle@lnx-oracle-1 ~]$

How does that work? Since we created the database with DBCA, Oracle will automatically update a file storing all the instances on that server: /etc/oratab. We can also manually edit the files if we need.

[oracle@lnx-oracle-1 ~]$ cat /etc/oratab
#
# This file is used by ORACLE utilities.  It is created by root.sh
# and updated by either Database Configuration Assistant while creating
# a database or ASM Configuration Assistant while creating ASM instance.

# A colon, ':', is used as the field terminator.  A new line terminates
# the entry.  Lines beginning with a pound sign, '#', are comments.
#
# Entries are of the form:
#     $ORACLE_SID:$ORACLE_HOME:<N|Y>:
#
# The first and second fields are the system identifier and home
# directory of the database respectively.   The third filed indicates
# to the dbstart utility that the database should , "Y", or should not,
# "N", be brought up at system boot time.
#
# Multiple entries with the same $ORACLE_SID are not allowed.
#
#
orcl:/u01/app/oracle/product/11.2.0/dbhome_11204:N
[oracle@lnx-oracle-1 ~]$

This file holds a list of the instances on the server will also store their respective Oracle home director, and whether they should be automatically be started or not. But wait a second, we just said that Oracle is not automatically starting database – what is going on?

The dbstart and dbshut scripts

As I mentioned before, Oracle is providing us with everything we need in order to have automatic start and stop of the database – the only thing it doesn’t do is to put everything together. The dbstart and dbshut scripts are Oracle’s automatic script for starting and stopping the database. They use the /etc/oratab in order to understand which instances needs to be started or stopped (based on the last parameter) and with which Oracle Home it should be done.

These scripts are been with us for quite some time – and work very nicely. The dbstart script can handle regular instances, ASM instances (if the SID include ‘+’ in it), and instances that are dependent on ASM (when setting the parameter to ‘W’ – for wait). The script can also handle the starting up of the Listener – but only one listener at a time so we have multiple listeners, we need to take care of them in another method.

The usage of the dbstart and dbshut is very simple

[oracle@lnx-oracle-1 bin]$ dbstart /u01/app/oracle/product/11.2.0/dbhome_11204/
Processing Database instance "orcl": log file /u01/app/oracle/product/11.2.0/dbhome_11204/startup.log

[oracle@lnx-oracle-1 ~]$ dbshut $ORACLE_HOME
Processing Database instance "orcl": log file /u01/app/oracle/product/11.2.0/dbhome_11204/shutdown.log

The shutdown and startup processes are being logged into log files for future references. The logs are being stored in $ORACLE_HOME/startup.log and $ORACLE_HOME/shutdown.log and they keep a record of all previous shutdown and startups.

Oracle Restart

In Oracle 11g, the Oracle team decided to tried to replace the old scripting methods with a more robust and “easy” way. They suggested that people that have a single instance might benefit from the Grid infrastructure as well, and setup it to control their database instances. The idea was that since the GI is so good when using it with the complex environment of Real Application Cluster (RAC), it would be good for single instances as well.

When Installing the grid infrastructure, we provides a new layer of managing the database resources – the crsctl (for crs based operations) and srvctl (for more service based operations) would give the database administrators the ability to setup their resources in the clusterware, and then stop and start it from there. Using this method, we can setup a listener, ASM instance, and a database instance on the same machine and create dependencies between them.

Another major benefit was that since there is another layer that monitor our instance, if the database will crush, the new layer would automatically start it (hence the name “restart”).

Even though this was part of Oracle 11g DBA training, most of the DBA’s I know didn’t adopt this method. It was too complicated (especially for those who didn’t use RAC), it required maintenance for the new management layer (logs, patches, etc.), and was a bit of a resource consumer.

It was removed in Oracle 12cR1.

Update: Matt Miller commented on Linkedin that it was not removed, and he’s absolutely right – it was not removed from the software, just from the Oracle Administration Workshop course. In any case, it’s doesn’t appear to be the recommended way for single instances any more. In Oracle 11g, the dbshut and dbstart were to noted to be deprecated in the future. In Oracle 12c this commend was removed. See in the documentation for more details.

Summary

In this article, I described some of the building blocks of the automatic startup and shutdown of the database. In my next post, I will show how to setup automatic startup in Oracle Linux 6 and 7 (which is the same as Red Hat Enterprise Linux 6 and 7) from the Linux perspective.