A Manually Intensive Approach

In Linux/Unix, when you’re using the Bourne, Bash, or Korn shell, you can set OS variables manually from the OS command line with the export command::

$ export ORACLE_HOME=/u01/app/oracle/product/12.1.0.1/db_1
$ export ORACLE_SID=o12c
$ export LD_LIBRARY_PATH=/usr/lib:$ORACLE_HOME/lib
$ export PATH=$ORACLE_HOME/bin:$PATH

For the C or tcsh shell, use the setenv command to set variables:

$ setenv ORACLE_HOME <path>
$ setenv ORACLE_SID <sid>
$ setenv LD_LIBRARY_PATH <path>
$ setenv PATH <path>

Another way that DBAs set these variables is by placing the previous export or setenv commands into a Linux/Unix startup file, such as .bash_profile, .bashrc, or .profile. That way, the variables are automatically set upon login.

However, manually setting OS variables (either from the command line or by hard-coding values into a startup file) isn’t the optimal way to instantiate these variables. For example, if you have multiple databases with multiple Oracle homes on a box, manually setting these variables quickly becomes unwieldy and not very maintainable.

Oracle’s Approach to Setting OS Variables

A much better method for setting OS variables is use of a script that uses a file that contains the names of all Oracle databases on a server and their associated Oracle homes. This approach is flexible and maintainable. For instance, if a database’s Oracle home changes (e.g., after an upgrade), you only have to modify one file on the server and not hunt down where the Oracle home variables may be hard-coded into scripts.

Oracle provides a mechanism for automatically setting the required OS variables. Oracle’s approach relies on two files: oratab and oraenv.

<database_sid>:<oracle_home_dir>:Y|N

o12c:/u01/app/oracle/product/12.1.0.1/db_1:N
rcat:/u01/app/oracle/product/12.1.0.1/db_1:N

$ . oraenv

ORACLE_SID = [oracle] ?
ORACLE_HOME = [/home/oracle] ?

$ export ORACLE_SID=o12c
$ export ORAENV_ASK=NO
$ . oraenv

My Approach to Setting OS Variables

I don’t use Oracle’s oraenvfile to set the OS variables (see the previous section, “Using oraenv,” for details of Oracle’s approach). Instead, I use a script named oraset. The oraset script depends on the oratab file’s being in the correct directory and expected format:

<database_sid>:<oracle_home_dir>:Y|N

As mentioned in the previous section, the Oracle installer should create an oratab file for you in the correct directory. If it doesn’t, then you can manually create and populate the file. In Linux the oratab file is usually created in the /etc directory. On Solaris servers the oratab file is located in the /var/opt/oracle directory.

Next, use a script that reads the oratab file and sets the OS variables. Here is an example of an oraset script that reads the oratab file and presents a menu of choices (based on the database names in the oratab file):

#!/bin/bash
# Sets Oracle environment variables.
# Setup: 1. Put oraset file in /etc (Linux), in /var/opt/oracle (Solaris)
#        2. Ensure /etc or /var/opt/oracle is in $PATH
# Usage: batch mode: . oraset <SID>
#        menu mode:  . oraset
#====================================================
if [ −f /etc/oratab ]; then
  OTAB=/etc/oratab
elif [ −f /var/opt/oracle/oratab ]; then
  OTAB=/var/opt/oracle/oratab
else
     echo 'oratab file not found.'
     exit
fi
#
if [ −z $1 ]; then
  SIDLIST=$(egrep -v '#|*' ${OTAB} | cut -f1 -d:)
  # PS3 indicates the prompt to be used for the Bash select command.
  PS3='SID? '
  select sid in ${SIDLIST}; do
    if [ −n $sid ]; then
      HOLD_SID=$sid
      break
    fi
  done
else
  if egrep -v '#|*' ${OTAB} | grep -w "${1}:">/dev/null; then
    HOLD_SID=$1
  else
    echo "SID: $1 not found in $OTAB"
  fi
  shift
fi
#
export ORACLE_SID=$HOLD_SID
export ORACLE_HOME=$(egrep -v '#|*' $OTAB|grep -w $ORACLE_SID:|cut -f2 -d:)
export ORACLE_BASE=${ORACLE_HOME%%/product*}
export TNS_ADMIN=$ORACLE_HOME/network/admin
export ADR_BASE=$ORACLE_BASE/diag
export PATH=$ORACLE_HOME/bin:/usr/ccs/bin:/opt/SENSsshc/bin/
:/bin:/usr/bin:.:/var/opt/oracle:/usr/sbin
export LD_LIBRARY_PATH=/usr/lib:$ORACLE_HOME/lib

You can run the oraset script either from the command line or from a startup file (such as .profile, .bash_profile, or .bashrc). To run oraset from the command line, place the oraset file in a standard location, such as /var/opt/oracle (Solaris) or /etc (Linux), and run, as follows:

$ . /etc/oraset

Note that the syntax to run this from the command line requires a space between the dot (.) and the rest of the command. When you run oraset from the command line, you should be presented with a menu such as this:

1) o12c
2) rcat
SID?

In this example you can now enter 1 or 2 to set the OS variables required for whichever database you want to use. This allows you to set up OS variables interactively, regardless of the number of database installations on the server.

You can also call the oraset file from an OS startup file. Here is a sample entry in the .bashrc file:

. /etc/oraset

Now, every time you log in to the server, you’re presented with a menu of choices that you can use to indicate the database for which you want the OS variables set. If you want the OS variables automatically set to a particular database, then put an entry such as this in the .bashrc file:

. /etc/oraset o12c

The prior line will run the oraset file for the o12c database and set the OS variables appropriately.

Step 1. Set the OS Variables

As mentioned previously, before you run SQL*Plus (or any other Oracle utility), you must set several OS variables. You can either manually set these variables or use a combination of files and scripts to set the variables. Here’s an example of setting these variables manually:

$ export ORACLE_HOME=/u01/app/oracle/product/12.1.0.1/db_1
$ export ORACLE_SID=o12c
$ export LD_LIBRARY_PATH=/usr/lib:$ORACLE_HOME/lib
$ export PATH=$ORACLE_HOME/bin:$PATH

See the section “Setting OS Variables,” earlier in this chapter, for a complete description of these variables and techniques for setting them.

Step 2: Configure the Initialization File

Oracle requires that you have an initialization file in place before you attempt to start the instance. The initialization file is used to configure features such as memory and to control file locations. You can use two types of initialization files:

• Server parameter binary file (spfile)
• init.ora text file

Oracle recommends that you use an spfile for reasons such as these:

• You can modify the contents of the spfile with the SQL ALTER SYSTEM statement.
• You can use remote-client SQL sessions to start the database without requiring a local (client) initialization file.

These are good reasons to use an spfile. However, some shops still use the traditional init.ora file. The init.ora file also has advantages:

• You can directly edit it with an OS text editor.
• You can place comments in it that detail a history of modifications.

When I first create a database, I find it easier to use an init.ora file. This file can be easily converted later to an spfile if required (via the CREATE SPFILE FROM PFILE statement). In this example my database name is o12c, so I place the following contents in a file named inito12c.ora and put the file in the ORACLE_HOME/dbs directory:

db_name=o12c
db_block_size=8192
memory_target=300M
memory_max_target=300M
processes=200
control_files=(/u01/dbfile/o12c/control01.ctl,/u02/dbfile/o12c/control02.ctl)
job_queue_processes=10
open_cursors=500
fast_start_mttr_target=500
undo_management=AUTO
undo_tablespace=UNDOTBS1
remote_login_passwordfile=EXCLUSIVE

Ensure that the initialization file is named correctly and located in the appropriate directory. This is critical because when starting your instance, Oracle first looks in the ORACLE_HOME/dbs directory for parameter files with specific formats, in this order:

• spfile<SID>.ora
• spfile.ora
• init<SID>.ora

In other words, Oracle first looks for a file named spfile<SID>.ora. If found, the instance is started; if not, Oracle looks for spfile.ora and then init<SID>.ora. If one of these files is not found, Oracle throws an error.

This may cause some confusion if you’re not aware of the files that Oracle looks for, and in what order. For example, you may make a change to an init<SID>.ora file and expect the parameter to be instantiated after stopping and starting your instance. If there is an spfile<SID>.ora in place, the init<SID>.ora is completely ignored.

Table 2-1 lists best practices to consider when configuring an Oracle initialization file.

Step 3: Create the Required Directories

Any OS directories referenced in the parameter file or CREATE DATABASE statement must be created on the server before you attempt to create a database. For instance, in the previous section’s initialization file, the control files are defined as

control_files=(/u01/dbfile/o12c/control01.ctl,/u02/dbfile/o12c/control02.ctl)

From the previous line, ensure that you’ve created the directories /u01/dbfile/o12c and /u02/dbfile/o12c (modify this according to your environment). In Linux/Unix you can create directories, including any parent directories required, by using the mkdir command with the p switch:

$ mkdir -p /u01/dbfile/o12c
$ mkdir -p /u02/dbfile/o12c

Also make sure you create any directories required for data files and online redo logs referenced in the CREATE DATABASE statement (see step 4). For this example, here are the additional directories required:

$ mkdir -p /u01/oraredo/o12c
$ mkdir -p /u02/oraredo/o12c

If you create the previous directories as the root user, ensure that the oracle user and dba groups are properly set to own the directories, subdirectories, and files. This example recursively changes the owner and group of the following directories:

# chown -R oracle:dba /u01
# chown -R oracle:dba /u02

Step 4: Create the Database

After you’ve established OS variables, configured an initialization file, and created any required directories, you can now create a database. This step explains how to use the CREATE DATABASE statement to create a database.

Before you can run the CREATE DATABASE statement, you must start the background processes and allocate memory via the STARTUP NOMOUNT statement:

$ sqlplus / as sysdba
SQL> startup nomount;

When you issue a STARTUP NOMOUNT statement, SQL*Plus attempts to read the initialization file in the ORACLE_HOME/dbs directory (see step 2). The STARTUP NOMOUNT statement instantiates the background processes and memory areas used by Oracle. At this point, you have an Oracle instance, but you have no database.

Listed next is a typical Oracle CREATE DATABASE statement:

CREATE DATABASE o12c
   MAXLOGFILES 16
   MAXLOGMEMBERS 4
   MAXDATAFILES 1024
   MAXINSTANCES 1
   MAXLOGHISTORY 680
   CHARACTER SET AL32UTF8
DATAFILE
'/u01/dbfile/o12c/system01.dbf'
   SIZE 500M REUSE
   EXTENT MANAGEMENT LOCAL
UNDO TABLESPACE undotbs1 DATAFILE
'/u01/dbfile/o12c/undotbs01.dbf'
   SIZE 800M
SYSAUX DATAFILE
'/u01/dbfile/o12c/sysaux01.dbf'
   SIZE 500M
DEFAULT TEMPORARY TABLESPACE TEMP TEMPFILE
'/u01/dbfile/o12c/temp01.dbf'
   SIZE 500M
DEFAULT TABLESPACE USERS DATAFILE
'/u01/dbfile/o12c/users01.dbf'
   SIZE 20M
LOGFILE GROUP 1
        ('/u01/oraredo/o12c/redo01a.rdo',
         '/u02/oraredo/o12c/redo01b.rdo') SIZE 50M,
        GROUP 2
        ('/u01/oraredo/o12c/redo02a.rdo',
         '/u02/oraredo/o12c/redo02b.rdo') SIZE 50M,
        GROUP 3
        ('/u01/oraredo/o12c/redo03a.rdo',
         '/u02/oraredo/o12c/redo03b.rdo') SIZE 50M
USER sys    IDENTIFIED BY foo
USER system IDENTIFIED BY foo;

In this example the script is placed in a file named credb.sql and is run from the SQL*Plus prompt as the sys user:

SQL> @credb.sql

If it’s successful, you should see the following message:

Database created.

If any errors are thrown while the CREATE DATABASE statement is running, check the alert log file. Typically, errors occur when required directories don’t exist, the memory allocation isn’t sufficient, or an OS limit has been exceeded. If you’re unsure of the location of your alert log, issue the following query:

SQL> select value from v$diag_info where name = 'Diag Trace';

The prior query should work even when your database is in the nomount state. Another way to quickly find the alert log file is from the OS:

$ cd $ORACLE_BASE
$ find . -name "alert*.log"

There are few key things to point out about the prior CREATE DATABASE statement example. Note that the SYSTEM data file is defined as locally managed. This means that any tablespace created in this database must be locally managed (as opposed to dictionary managed). Oracle throws an error if you attempt to create a dictionary-managed tablespace in this database. This is the desired behavior.

A dictionary-managed tablespace uses the Oracle data dictionary to manage extents and free space, whereas a locally managed tablespace uses a bitmap in each data file to manage its extents and free space. Locally managed tablespaces have these advantages:

• Performance is increased.
• No coalescing is required.
• Contention for resources in the data dictionary is reduced.
• Recursive space management is reduced.

Also note that the TEMP tablespace is defined as the default temporary tablespace. This means that any user created in the database automatically has the TEMP tablespace assigned to him or her as the default temporary tablespace. After you create the data dictionary (see step 5), you can verify the default temporary tablespace with this query:

select *
from database_properties
where property_name = 'DEFAULT_TEMP_TABLESPACE';

Finally, note that the USERS tablespace is defined as the default permanent tablespace for any users created that don’t have a default tablespace defined in a CREATE USER statement. After you create the data dictionary (see step 5) you can run this query to determine the default temporary tablespace:

select *
from database_properties
where property_name = 'DEFAULT_PERMANENT_TABLESPACE';

Table 2-2 lists best practices to consider when you’re creating an Oracle database.

Note that the CREATE DATABASE statement used in this step deviates slightly from the OFA standard in terms of the directory structure. I prefer not to place the Oracle data files, online redo logs, and control files under ORACLE_BASE (as specified by the OFA standard). I instead directly place files under directories named /<mount_point>/<file_type>/<database_name>, because the path names are much shorter. The shorter path names make command line navigation to directories easier, and the names fit more cleanly in the output of SQL SELECT statements. Figure 2-1 displays this deviation from the OFA standard.

It’s not my intention to have you use nonstandard OFA structures. Rather, do what makes sense for your environment and requirements. Apply reasonable standards that foster manageability, maintainability, and scalability.

Step 5. Create a Data Dictionary

After your database is successfully created, you can instantiate the data dictionary by running two scripts. These scripts are created when you install the Oracle binaries. You must run these scripts as the SYS schema:

SQL> show user
USER is "SYS"

Before I create the data dictionary, I like to spool an output file that I can inspect in the event of unexpected errors:

SQL> spool create_dd.lis

Now, create the data dictionary:

SQL> @?/rdbms/admin/catalog.sql
SQL> @?/rdbms/admin/catproc.sql

After you successfully create the data dictionary, as the SYSTEM schema, create the product user profile tables:

SQL> connect system/<password>
SQL> @?/sqlplus/admin/pupbld

These tables allow SQL*Plus to disable commands on a user-by-user basis. If the pupbld.sql script isn’t run, then all non-sys users see the following warning when logging in to SQL*Plus:

Error accessing PRODUCT_USER_PROFILE
Warning: Product user profile information not loaded!
You may need to run PUPBLD.SQL as SYSTEM

These errors can be ignored. If you don’t want to see them when logging in to SQL*Plus, make sure you run the pupbld.sql script.

At this point, you should have a fully functional database. You next need to configure and implement your listener to enable remote connectivity and, optionally, set up a password file. These tasks are described in the next two sections.

Manually Configuring a Listener

When you’re setting up a new environment, manually configuring the listener is a two-step process:

1. Configure the listener.ora file.
2. Start the listener.

The listener.ora file is located by default in the ORACLE_HOME/network/admin directory. This is the same directory that the TNS_ADMIN OS variable should be set to. Here is a sample listener.ora file that contains network configuration information for one database:

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS_LIST =
        (ADDRESS = (PROTOCOL = TCP)(HOST = oracle12c)(PORT = 1521))
       )
     )
    )
  
SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (GLOBAL_DBNAME = o12c)
      (ORACLE_HOME = /u01/app/oracle/product/12.1.0.1/db_1)
      (SID_NAME = o12c)
     )
   )

This code listing has two sections. The first defines the listener name; in this example the listener name is LISTENER. The second defines the list of SIDs for which the listener is listening for incoming connections (to the database). The format of the SID list name is SID_LIST_<name of listener>. The name of the listener must appear in the SID list name. The SID list name in this example is SID_LIST_LISTENER.

Also, you don’t have to explicitly specify the SID_LIST_LISTENER section (the second section) in the prior code listing. This is because the process monitor (PMON) background process will automatically register any running databases as a service with the listener; this is known as dynamic registration. However, some DBAs prefer to explicitly list which databases should be registered with the listener and therefore include the second section; this is known as static registration.

After you have a listener.ora file in place, you can start the listener background process with the lsnrctl utility:

$ lsnrctl start

You should see informational messages, such as the following:

Listening Endpoints Summary.  .  .
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=oracle12c)(PORT=1521)))
Services Summary.  .  .
Service "o12c" has 1 instance(s).

You can verify the services for which a listener is listening via

$ lsnrctl services

You can check the status of the listener with the following query:

$ lsnrctl status

For a complete listing of listener commands, issue this command:

$ lsnrctl help

Implementing a Listener with the Net Configuration Assistant

The netca utility assists you with all aspects of implementing a listener. You can run the netca tool in either graphical or silent mode. Using the netca in graphical mode is easy and intuitive. To use the netca in graphical mode, ensure that you have the proper X software installed, then issue the xhost + command, and check that your DISPLAY variable is set; for example,

$ xhost +
$ echo $DISPLAY
:0.0

You can now run the netca utility:

$ netca

Next, you will be guided through several screens from which you can choose options such as name of the listener, desired port, and so on.

You can also run the netca utility in silent mode with a response file. This mode allows you to script the process and ensure repeatability when creating and implementing listeners. First, find the default listener response file within the directory structure that contains the Oracle install media:

$  find . -name "netca.rsp"
./12.1.0.1/database/response/netca.rsp

Now, make a copy of the file so that you can modify it:

$ cp 12.1.0.1/database/response/netca.rsp mynet.rsp

If you want to change the default name or other attributes, then edit the mynet.rsp file with an OS utility such as vi:

$ vi mynet.rsp

For this example I haven’t modified any values within the mynet.rsp file. In other words, I’m using all the default values already contained within the response file. Next, the netca utility is run in silent mode:

$ netca -silent -responsefile /home/oracle/orainst/mynet.rsp

The utility creates a listener.ora and sqlnet.ora file in the ORACLE_HOME/network/admin directory and starts a default listener.

Connecting to a Database through the Network

Once the listener has been configured and started, you can test remote connectivity from a SQL*Plus client, as follows:

$ sqlplus user/pass@'server:port/service_name'

In the next line of code, the user and password are system/foo, connecting the oracle12c server, port 1521, to a database named o12c:

$ sqlplus system/foo@'oracle12c:1521/o12c'

This example demonstrates what is known as the easy connect naming method of connecting to a database. It’s easy because it doesn’t rely on any setup files or utilities. The only information you need to know is username, password, server, port, and service name (SID).

Another common connection method is local naming. This method relies on connection information in the ORACLE_HOME/network/admin/tnsnames.ora file. In this example the tnsnames.ora file is edited, and the following Transparent Network Substrate (TNS) (Oracle’s network architecture) entry is added:

o12c =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = oracle12c)(PORT = 1521))
    (CONNECT_DATA = (SERVICE_NAME = o12c)))

Now, from the OS command line, you establish a connection by referencing the o12c TNS information that was placed in the tnsnames.ora file:

$ sqlplus system/foo@o12c

This connection method is local because it relies on a local client copy of the tnsnames.ora file to determine the Oracle Net connection details. By default, SQL*Plus inspects the directory defined by the TNS_ADMIN variable for a file named tnsnames.ora. If not found, then the directory defined by ORACLE_HOME/network/admin is searched. If the tnsnames.ora file is found, and if it contains the alias specified in the SQL*Plus connection string (in this example, o12c), then the connection details are derived from the entry in the tnsnames.ora file.

The other connection-naming methods that Oracle uses are external naming and directory naming. See the Oracle Net Services Administrator’s Guide, which can be freely downloaded from the Technology Network area of the Oracle web site (http://otn.oracle.com), for further details.

Understanding OS Authentication

OS authentication means that if you can log in to a database server via an authorized OS account, you’re allowed to connect to your database without the requirement of an additional password. A simple example demonstrates this concept. First, the id command is used to display the OS groups to which the oracle user belongs:

$ id
uid=500(oracle) gid=506(oinstall) groups=506(oinstall),507(dba),508(oper)

Next, a connection to the database is made with SYSDBA privileges, purposely using a bad (invalid) username and password:

$ sqlplus bad/notgood as sysdba

I can now verify that the connection as SYS was established:

SYS@o12c> show user
USER is "SYS"

How is it possible to connect to the database with an incorrect username and password? Actually, it’s not a bad thing (as you might initially think). The prior connection works because Oracle ignores the username/password provided, as the user was first verified via OS authentication. In that example the oracle OS user belongs to the dba OS group and is therefore allowed to make a local connection to the database with SYSDBA privileges without having to provide a correct username and password.

See Table 1-1, in Chapter 1, for a complete description of OS groups and the mapping to corresponding database privileges. Typical groups include dba and oper; these groups correspond to sysdba and sysoper database privileges, respectively. The sysdba and sysoper privileges allow you to perform administrative tasks, such as starting and stopping your database.

In a Windows environment an OS group is automatically created (typically named ora_dba) and assigned to the OS user that installs the Oracle software. You can verify which OS users belong to the ora_dba group as follows: select Start ➤ Control Panel ➤ Administrative Tools ➤ Computer Management ➤ Local Users and Groups ➤ Groups. You should see a group with a name such as ora_dba. You can click that group and view which OS users are assigned to it. In addition, for OS authentication to work in Windows environments, you must have the following entry in your sqlnet.ora file:

SQLNET.AUTHENTICATION_SERVICES=(NTS)

The sqlnet.ora file is usually located in the ORACLE_HOME/network/admin directory.

Starting the Database

Starting and stopping your database is a task that you perform frequently. To start/stop your database, connect with a sysdba- or sysoper- privileged user account, and issue the startup and shutdown statements. The following example uses OS authentication to connect to the database:

$ sqlplus / as sysdba

After you’re connected as a privileged account, you can start your database, as follows:

SQL> startup;

For the prior command to work, you need either an spfile or init.ora file in the ORACLE_HOME/dbs directory. See the section  “Step 2: Configure the Initialization File,” earlier in this chapter, for details.

When your instance starts successfully, you should see messages from Oracle indicating that the system global area (SGA) has been allocated. The database is mounted and then opened:

ORACLE instance started.
  
Total System Global Area  313159680 bytes
Fixed Size                  2259912 bytes
Variable Size             230687800 bytes
Database Buffers           75497472 bytes
Redo Buffers                4714496 bytes
Database mounted.
Database opened.

From the prior output the database startup operation goes through three distinct phases in opening an Oracle database:

1. Starting the instance
2. Mounting the database
3. Opening the database

You can step through these one at a time when you start your database. First, start the Oracle instance (background processes and memory structures):

SQL> startup nomount;

Next, mount the database. At this point, Oracle reads the control files:

SQL> alter database mount;

Finally, open the data files and online redo log files:

SQL> alter database open;

This startup process is depicted graphically in Figure 2-2.

When you issue a STARTUP statement without any parameters, Oracle automatically steps through the three startup phases (nomount, mount, open). In most cases, you will issue a STARTUP statement with no parameters to start your database. Table 2-3 describes the meanings of parameters that you can use with the database STARTUP statement.

Stopping the Database

Normally, you use the SHUTDOWN IMMEDIATE statement to stop a database. The IMMEDIATE parameter instructs Oracle to halt database activity and roll back any open transactions:

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.

Table 2-4 provides a detailed definition of the parameters available with the SHUTDOWN statement. In most cases, SHUTDOWN IMMEDIATE is an acceptable method of shutting down your database. If you issue the SHUTDOWN command with no parameters, it’s equivalent to issuing SHUTDOWN NORMAL.

Starting and stopping your database is a fairly simple process. If the environment is set up correctly, you should be able to connect to your database and issue the appropriate STARTUP and SHUTDOWN statements.

You should rarely need to use the SHUTDOWN ABORT statement. Usually, SHUTDOWN IMMEDIATE is sufficient. Having said that, there is nothing wrong with using SHUTDOWN ABORT. If SHUTDOWN IMMEDIATE isn’t working for any reason, then use SHUTDOWN ABORT.

On a few, rare occasions the SHUTDOWN ABORT will fail to work. In those situations, you can use ps -ef | grep smon to locate the Oracle system-monitor process and then use the Linux/Unix kill command to terminate the instance. When you kill a required Oracle background process, this causes the instance to abort. Obviously, you should use an OS kill command only as a last resort.

SQL> alter database close;

SQL> alter database open;
ERROR at line 1:
ORA-16196: database has been previously opened and closed