Pro Oracle Database 18c Administration: Manage and Safeguard Your Organization’s Data

© Michelle Malcher and Darl Kuhn 2019

Michelle Malcher and Darl KuhnPro Oracle Database 18c Administrationhttps://doi.org/10.1007/978-1-4842-4424-1_1

1. Installing the Oracle Binaries

Michelle Malcher¹  and Darl Kuhn²

(1)

Huntley, IL, USA

(2)

Morrison, CO, USA

Oracle installations of the past can be large, complex, and cumbersome. The Oracle database administrator (DBA) plans and performs the installation because he or she knows how to troubleshoot and address problems as they arise through the steps. There are several configuration and installation options that need to be reviewed, so installing the Oracle software (binaries) is a task that requires proficiency by every DBA. Now with Oracle 18c and even with 12c, Oracle software installations have become more automated, but understanding the steps and configurations of installing is going to be important for the DBA. The installation of the Oracle binaries should be repeatable for large environments, and the DBA needs to set up the installs to be able to provision databases on-demand and consistently.

Tip

DBA tasks are changing and in cloud environments, the DBA tasks might be preparing self-service databases or not even needing to install Oracle binaries. Also, if you’re fairly new to Oracle, some of the overwhelming parts of Oracle installation have been simplified. Chances are that another DBA has probably already installed the Oracle binaries, and databases will just need to be created as needed. However, it is valuable to understand the component of the installation and the next section, Understanding the Optimal Flexible Architecture.

Many DBAs don’t use techniques for automating installations. Some are unaware of these methods; others perceive them as unreliable. Therefore, most DBAs typically use the graphical mode of the Oracle Universal Installer (OUI). Although the graphical installer is a good tool, it doesn’t lend itself to repeatability and automation. Running the graphical installer is a manual process during which you’re presented with options to choose from on multiple screens. Even if you know which options to select, you may still inadvertently click an undesired choice.

The graphical installer can also be problematic when you’re performing remote installations, and the network bandwidth is insufficient. In these situations, you can find yourself waiting for dozens of minutes for a screen to repaint itself on your local screen. You need a different technique for efficient installation on remote servers.

This chapter focuses on techniques for installing Oracle in an efficient and repeatable manner. This includes silent installations, which rely on a response file. A response file is a text file in which you assign values to variables that govern the installation. DBAs often don’t realize the powerful repeatability and efficiency that can be achieved by using response files.

Note

This chapter only covers installing the Oracle software. The task of creating a database is covered in Chapter 2. The cloud also changes the tasks and viewpoints of software and database creation, which will be discussed later in this chapter under the section, Installing in the Cloud and Responsibilities of the DBA.

Understanding the OFA

Before you install Oracle and start creating databases, you must understand Oracle’s Optimal Flexible Architecture (OFA) standard. This standard is widely employed for specifying consistent directory structures and also the file-naming conventions used when installing and creating Oracle databases.

Note

One irony of this ubiquitous OFA standard is that almost every DBA, in some manner, customizes it to fit the unique requirements of his or her environment.

The OFA standard provides ways to understand where log files are available on a consistent basis. If standards are followed, security, migrations, and automations are going to be easier to implement because of consistency across the environments. The consistent locations of the log files allow for the files to be used by other tools as well as being secured. The ORACLE_BASE directory in 18c provides a way to separate the ORACLE_HOME directories for read-only directories and have the writable files in the ORACLE_BASE. Read-only ORACLE_HOME directories allow for implementing separation of installation and configuration, which is important for the cloud and securing the environment. This simplifies patching as one image can be used for a mass rollout and distribute a patch to many servers and reduces downtime for patching and updating of the Oracle software.

Because most shops implement a form of the OFA standard, understanding this structure is critical. Figure 1-1 shows the directory structure and file names used with the OFA standard. Not all the directories and files found in an Oracle environment appear in this figure (there isn’t enough room). However, the critical and most frequently used directories and files are displayed.

Figure 1-1

Oracle’s OFA standard

The OFA standard includes several directories that you should be familiar with:

Oracle inventory directory

Oracle base directory (ORACLE_BASE)

Oracle home directory (ORACLE_HOME)

Oracle network files directory (TNS_ADMIN)

Automatic Diagnostic Repository (ADR_HOME)

These directories are discussed in the following sections.

Oracle Inventory Directory

The Oracle inventory directory stores the inventory of Oracle software installed on the server. This directory is required and is shared among all installations of Oracle software on a server. When you first install Oracle, the installer checks to see whether there is an existing OFA-compliant directory structure in the format /u[01–09]/app. If such a directory exists, then the installer creates an Oracle inventory directory, such as

/u01/app/oraInventory

If the ORACLE_BASE variable is defined for the oracle operating system (OS) user, then the installer creates a directory for the location of Oracle inventory, as follows:

ORACLE_BASE/../oraInventory

For example, if ORACLE_BASE is defined as /ora01/app/oracle, then the installer defines the location of Oracle inventory as

/ora01/app/oraInventory

If the installer doesn’t find a recognizable OFA-compliant directory structure or an ORACLE_BASE variable, then the location for Oracle inventory is created under the HOME directory of the oracle user. For instance, if the HOME directory is /home/oracle, then the location of Oracle inventory is

/home/oracle/oraInventory

Oracle Base Directory

The Oracle base directory is the topmost directory for Oracle software installation. You can install one or more versions of the Oracle software beneath this directory. The OFA standard for the Oracle base directory is as follows:

//app/

Typical names for the mount point include /u01, /ora01, /oracle, and /oracle01. You can name the mount point according to whatever your standard is for your environment. I prefer to use a mount-point name such as /ora01. It is short, and when I look at the mount points on a database server, I can immediately tell which are used for the Oracle database. Also, a short mount-point name is easier to use when you’re querying the data dictionary to report on the physical aspects of your database. Additionally, a shorter mount-point name makes for less typing when you’re navigating through directories via OS commands.

The software owner is typically named oracle. This is the OS user you use to install the Oracle software (binaries). Listed next is an example of a fully formed Oracle base directory path:

/u01/app/oracle

Oracle Home Directory

The Oracle home directory defines the installation location of software for a particular product, such as Oracle Database 18c or Oracle Database 12c. You must install different products or different releases of a product in separate Oracle homes. The recommended OFA-compliant Oracle home directory is as follows:

ORACLE_BASE/product//

In the previous line of code, possible versions include 18.1.0.1 and 12.2.0.1. Possible install_name values include db_1, devdb1, test2, and prod1. Here is an example of an Oracle home name for a 18c database:

/u01/app/oracle/product/18.1.0.1/dbhome_1/db1

Note

Some DBAs dislike the db1 string on the end of the ORACLE_HOME directory and see no need for it. The reason for the db1 is that you may have two separate installations of binaries: a development installation and a test installation. If you don’t require that configuration in your environment, feel free to drop the extra string (db1).

Oracle Network Files Directory

Some Oracle utilities use the value TNS_ADMIN to locate network configuration files. This directory is defined as ORACLE_HOME/network/admin. It typically contains the tnsnames.ora and listener.ora Oracle Net files. The listener.ora files are now typically with the Oracle Grid installation and not in the database home. The listeners are normally maintained by the system that manages the grid, cluster, and ASM software. The tnsnames provide ways to connect to other databases so these files are part of the centralized directory or part of the database network files.

Tip

Sometimes DBAs will set TNS_ADMIN to point at one central directory location (such as /etc or /var/opt/oracle). This allows them to maintain one set of Oracle network files (instead of one for each ORACLE_HOME). This approach also has the advantage of not requiring the copying or moving of files when a database upgrade occurs, potentially changing the location of ORACLE_HOME.

Automatic Diagnostic Repository

Starting with Oracle Database 11g, the ADR_HOME directory specifies the location of the diagnostic files related to Oracle. These files are crucial for troubleshooting problems with the Oracle database. This directory is defined as ORACLE_BASE/diag/rdbms/lower(db_unique_name)/instance_name. You can query the V$PARAMETER view to get the values of db_unique_name and instance_name.

For example, in the next line, the lowercase database unique name is db18c, and the instance name is DB18C:

/u01/app/oracle/diag/rdbms/db18c/DB18C

Or with a clustered environment, the lowercase database unique name is db18c, and the instance name is DB18C01:

/u01/app/oracle/diag/rdbms/db18c/DB18C01

You can verify the location of the ADR_HOME directory via this query:

SQL> select value from v$diag_info where name='ADR Home';

Here is some sample output:

VALUE

------------------------------------------------------------

/u01/app/oracle/diag/rdbms/db18c/DB18C

Now that you understand the OFA standard, you’ll next see how it’s used when installing the Oracle binaries. For instance, you’ll need to specify directory values for the ORACLE_BASE and ORACLE_HOME directories when running the Oracle installer.

Tip

See the Oracle Database Installation Guide for full details on OFA. This document can be freely downloaded from the Technology Network area of the Oracle web site ( http://otn.oracle.com ).

Installing Oracle

Suppose you’re new on the job, and your manager asks you how long it will take to install a new set of Oracle Database 18c software on a server. You reply that it will take less than an hour. Your boss is incredulous and states that previous DBAs always estimated at least a day to install the Oracle binaries on a new server. You reply, Actually, it’s not that complicated, but DBAs do tend to overestimate installations, because it’s hard to predict everything that could go wrong.

When you’re handed a new server and are given the task of installing the Oracle binaries, this usually refers to the process of downloading and installing the software required before you can create an Oracle database. This process involves several steps:

1.

Create the appropriate OS groups. In Oracle Database 18c, there are several OS groups that you can form and use to manage the level of granularity of SYSDBA permissions. Minimally, you’ll need to create an OS dba group and the OS oracle user.

2.

Ensure that the OS is configured adequately for an Oracle database.

3.

Obtain the database installation software from Oracle.

4.

Unzip the database installation software.

5.

If using the silent installer when first installing Oracle software on the box, create an oraInst.loc file. This step only needs to be done once per server. Subsequent installations do not require this step to be performed.

6.

Configure the response file and run the Oracle silent installer.

7.

Troubleshoot any issues.

8.

Apply any additional patches.

These steps are detailed in the following sections.

Note

Any version of the database that Oracle designates as a base release (10.1.0.2, 10.2.0.1, 11.1.0.6, 11.2.0.1, 12.1.0.1, 18.1.0.1, and so on) can be freely downloaded from the Technology Network area of the Oracle web site ( http://otn.oracle.com ). However, be aware that any subsequent patch downloads require a purchased license. In other words, downloading base software requires an Oracle Technology Network (OTN) login (free), whereas downloading a patch set requires a My Oracle Support account (for fee).

Step 1. Create the OS Groups and User

If you work in a shop with a system administrator (SA), then steps 1 and 2 usually are performed by the SA. If you don’t have a SA, then you have to perform these steps yourself (this is often the case in small shops, where you may be required to perform many different job functions). You need root access to accomplish these steps.

In the old days, a typical Oracle installation would contain one OS group (dba) and one OS user (oracle). You can still install the Oracle software, using this minimalistic, one-group, one-user approach; it works fine. If there is just one DBA in your shop, and you don’t need a more granular division of privileges among team members, then go ahead, and create only the dba group and the oracle OS user. There is nothing wrong with this method.

Nowadays, there are multiple OS groups that Oracle recommends you create—the idea being that you can add different OS users and assign them to groups on an as-needed basis, depending on the job function. When an OS user is assigned to a group, that assignment provides the user with specific database privileges. Table 1-1 documents the OS groups and how each group maps to corresponding database privileges. For example, if you have a user that is only responsible for monitoring a database and that only needs privileges to start up and shut down the database, then that user would be assigned the oper group (which ensures that subsequent connections to the database can be done with sysoper privileges).

Table 1-1

Mapping of OS Groups to Privileges Related to Backup and Recovery

Table 1-1 contains recommended group names. You don’t have to use the group names listed; you can adjust per your requirements. For example, if you have two separate groups using the same server, you may want to create two separate Oracle installations, each managed by different DBAs; the development DBA group might create and install the Oracle binaries with a group named dbadev, whereas a test group using the same box might install a separate set of Oracle binaries managed with a group named dbatest. Each group would have permissions to manipulate only its set of binaries. Or, as mentioned earlier, you may decide to use just one group (dba) for everything. It all depends on your environment.

Once you decide which groups you need, then you need access to the root user to run the groupadd command . As root, add the OS groups that you need. Here, I add the three groups that I foresee will be needed:

# groupadd oinstall

# groupadd dba

# groupadd oper

If you don’t have access to the root account, then you need to get your SA to run the previous commands. You can verify that each group was added successfully by inspecting the contents of the /etc/group file. Here are typical entries created in the /etc/group file:

oinstall:x:500:

dba:x:501:

oper:x:502:

Now, create the oracle OS user. The following example explicitly sets the group ID to 500 (your company may require use of the same group ID for all installations), establishes the primary group as oinstall, and assigns the dba and oper groups to the newly created oracle user:

# useradd -u 500 -g oinstall -G dba,oper oracle

You can verify user account information by viewing the /etc/passwd file. Here is what you can expect to see for the oracle user:

oracle:x:500:500::/home/oracle:/bin/bash

If you need to modify a group, as root, use the groupmod command . If, for any reason, you need to remove a group (as root) use the groupdel command .

If you need to modify a user, as root, use the usermod command . If you need to remove an OS user, use the userdel command . You need root privileges to run the userdel command . This example removes the oracle user from the server:

# userdel oracle

Step 2. Ensure That the OS Is Adequately Configured

The tasks associated with this step vary somewhat for each database release and OS. You must refer to the Oracle installation manual for the database release and OS vendor to get the exact requirements. To perform this step, you’re required to verify and configure OS components such as these:

Memory and swap space

System architecture (processor)

Free disk space (Oracle now takes almost 5GB of space to install)

Operating system version and kernel

Operating system software (required packages and patches)

Run the following command to confirm the memory size on a Linux server:

$ grep MemTotal /proc/meminfo

To verify the amount of memory and swap space, run the following command:

$ free -t

To verify the amount of space in the /tmp directory, enter this command:

$ df -h /tmp

To display the amount of free disk space, execute this command:

$ df -h

To verify the OS version, enter this command:

$ cat /proc/version

To verify kernel information, run the following command:

$ uname -r

To determine whether the required packages are installed, execute this query, and provide the required package name:

$ rpm -q

Again, database server requirements vary quite a bit by OS and database version. You can download the specific installation manual from the Documentation page of the Oracle web site ( www.oracle.com/documentation ).

Note

The OUI displays any deficiencies in OS software and hardware. Running the installer is covered in step 6.

Step 3. Obtain the Oracle Installation Software

Usually, the easiest way to obtain the Oracle software is to download it from the Oracle web site. Navigate to the software download page ( www.oracle.com/technology/software ), and download the Oracle database version that is appropriate for the type of OS and hardware on which you want to install it (Linux, Solaris, Windows, and so on).

Step 4. Unzip the Files

For previous versions, it was recommended to unzip the files in a standard directory where you can place the Oracle installation media. Now with Oracle 18c, there are different ways that the media is presented, imaged based or by RPM. The image software must now be extracted in the directory of the ORACLE_HOME. The zipped file can be placed in a temporary directory but extracted to the ORACLE_HOME. The runInstaller will run from the ORACLE_HOME directory for installation.

Create the directories for the ORACLE_HOME:

$ mkdir -p /u01/app/oracle/product/18.1.0/dbhome_1

$ chown oracle:oinstall /u01/app/oracle/product/18.1.0/dbhome_1

The zip files can be downloaded or copied over to a temporary directory such as /tmp or /home/oracle.

Use the unzip command to the newly created ORACLE_HOME directory to the newly created ORACLE_HOME directory:

$ cd /u01/app/oracle/product/18.1.0/dbhome_1

$ unzip -q /tmp/db_home.zip

RPM can now be used with Oracle 18c to perform the installation for a single database instance. The RPM was used before as a preinstallation check and is now available for installations, even of the Oracle client. This will need to be performed as root.

$ yum -y install oracle-database-server-18c-preinstall

$ ls -lt /opt

$ chown -R oracle:oinstall /opt

Now go to the directory for the rpm and run the command to perform the RPM-based install. The ORACLE_HOME directory will be created in /opt/oracle/product/18.1.0.0.0-1/dbhome_1.

$ cd /tmp/rpm

$ rpm -ivh oracle-ee-db-18.1.0.0.0-1.x86_64.rpm  -- rpm name may vary based on version

Tip

On some installations of previous versions of Oracle, you may find that the distribution file is provided as a compressed cpio file. You can uncompress and unbundle the file with one command, as follows: $ cat 10gr2_db_sol.cpio.gz | gunzip | cpio -idvm

Step 5. Creating oraInst.loc File

If an oraInst.loc file already exists on your server, then you can skip this step. Creating the oraInst.loc file only needs to be performed the first time you install binaries on a server, using the silent install method. If you’re using the OUI graphical installer, then the oraInst.loc file is created automatically for you.

On Linux servers the oraInst.loc file is usually located in the /etc directory. On other Unix systems (such as Solaris), this file is located in the /var/opt/oracle directory. The oraInst.loc file contains the following information:

Oracle inventory directory path

Name of OS group that has permissions for installing and upgrading Oracle software

The Oracle inventory directory path is the location of files associated with managing Oracle installations and upgrades. Typically, there is one Oracle inventory per host. Within this directory structure is the inventory.xml file, which contains a record of where various versions of Oracle have been installed on the server.

The Oracle inventory OS group has the OS permissions required for installing and upgrading Oracle software. Oracle recommends that you name this group oinstall. You’ll find that sometimes DBAs assign the inventory group to the dba group. If your environment doesn’t require a separate group (such as oinstall), then using the dba group is fine.

You can create the oraInst.loc file with a utility such as vi. Here are some sample entries in the file:

inventory_loc=/u01/app/oraInventory

inst_group=oinstall

As root, ensure that the response file is owned by the oracle OS user and that it has the proper file access privileges:

# chown oracle:oinstall oraInst.loc

# chmod 664 oraInst.loc

Step 6. Configure the Response File, and Run the Installer

You can run the OUI in one of two modes: graphical or silent. Typically, DBAs use the graphical installer. However, I strongly prefer using the silent install option for the following reasons:

Silent installs don’t require the availability of X Window System software.

You avoid performance issues with remote graphical installs, which can be extremely slow when trying to paint screens locally.

Silent installs can be scripted and automated. This means that every install can be performed with the same, consistent standards, regardless of which team member is performing the install (I even have the SA install the Oracle binaries this way).

The key to performing a silent install is to use a response file.

After unzipping the Oracle software, navigate to the ORACLE_HOME directory; for example,

$ cd /u01/app/oracle/product/18.1.0/dbhome_1

Next, find the sample response files that Oracle provides:

$ find . -name *.rsp

Depending on the version of Oracle and the OS platform, the names and number of response files that you find may be quite different. The next two sections show two scenarios: an Oracle Database 12c Release 1 silent install and an Oracle Database 18c Release 1 silent install.

Keep in mind that the format of response files can differ quite a bit, depending on the Oracle database version. For example, there are major differences between Oracle Database 11g and 12c even between release 2 of these versions. When you install a new release, you must inspect the response file and determine which parameters must be set. Be sure to modify the appropriate parameters for your environment. If you’re unsure what to set the ORACLE_HOME and ORACLE_BASE values to, see the section Understanding the Optimal Flexible Architecture, earlier in this chapter, for a description of the OFA standard directories.

There are sometimes idiosyncrasies to these parameters that are specific to a release. For instance, if you don’t want to specify your My Oracle Support (MOS) login information, then you need to set the following parameter as follows:

DECLINE_SECURITY_UPDATES=true

If you don’t set DECLINE_SECURITY_UPDATES to TRUE, then you will be expected to provide your MOS login information. Failure to do so will cause the installation to fail. After you’ve configured your response file, you can run the Oracle installer in silent mode. Note that you have to enter the entire directory path for the location of your response file.

Note

On Windows the setup.exe command is equivalent to the Linux/Unix runInstaller command .

If you encounter errors with the installation process, you can view the associated log file. Each time you attempt to run the installer, it creates a log file with a unique name that includes a timestamp. The log file is located in the oraInventory/logs directory. You can stream the output to your screen as the OUI writes to it:

$ tail -f

Here is an example of a log file name:

installActions2012-04-33 11-42-52AM.log

Oracle Database 12c Release 1 Scenario

Navigate to the database directory and issue the find command to locate sample response files. Here are the response files provided with an Oracle Database 12c Release 1 on a Linux server:

$ find . -name *.rsp

./response/db_install.rsp

./response/netca.rsp

./response/dbca.rsp

Copy one of the response files so that you can modify it. This example copies the db_install.rsp file to the current working directory and names the file inst.rsp:

$ cp response/db_install.rsp inst.rsp

Modify the inst.rsp file. Here is a partial listing of an Oracle Database 12c Release 1 response file (the first two lines are actually a single line of code but have been placed on two lines in order to fit on the page). The lines of code are the only variables that I modified. I removed the comments so that you could more clearly see which variables were modified:

oracle.install.responseFileVersion=/oracle/install/rspfmt_dbinstall_response_schema_v12.1.0

oracle.install.option=INSTALL_DB_SWONLY

ORACLE_HOSTNAME=oraserv1

UNIX_GROUP_NAME=oinstall

INVENTORY_LOCATION=/home/oracle/orainst/12.1.0.1/database/stage/products.xml

SELECTED_LANGUAGES=en

ORACLE_HOME=/u01/app/oracle/product/12.1.0.1/db_1

ORACLE_BASE=/u01/app/oracle

oracle.install.db.InstallEdition=EE

oracle.install.db.DBA_GROUP=dba

oracle.install.db.OPER_GROUP=oper

oracle.install.db.BACKUPDBA_GROUP=dba

oracle.install.db.DGDBA_GROUP=dba

oracle.install.db.KMDBA_GROUP=dba

DECLINE_SECURITY_UPDATES=true

Be sure to modify the appropriate parameters for your environment. If you’re unsure what to set the ORACLE_HOME and ORACLE_BASE values to, see the section Understanding the Optimal Flexible Architecture, earlier in this chapter, for a description of the OFA standard directories.

After you’ve configured your response file, you can run the Oracle installer in silent mode. Note that you have to enter the entire directory path for the location of your response file:

$ ./runInstaller -ignoreSysPrereqs -force -silent -responseFile \

 /home/oracle/orainst/12.1.0.1/database/inst.rsp

The previous command is entered on two lines. The first line is continued to the second line via the backward slash (\).

If you encounter errors with the installation process, you can view the associated log file. Each time you attempt to run the installer, it creates a log file with a unique name that includes a timestamp. The log file is created in the oraInventory/logs directory. You can stream the output to your screen as the OUI writes to it:

$ tail -f

Here is an example of a log file name:

installActions2012-11-04_02-57-29PM.log

If everything runs successfully, in the output you’re notified that you need to run the root.sh script as the root user:

/u01/app/oracle/product/12.1.0.1/db_1/root.sh

Run the root.sh script as the root OS user. Then, you should be able to create an Oracle database (database creation is covered in Chapter 2).

Oracle Database 18c Release 1 Scenario

Navigate to the database directory and issue the find command to locate sample response files. Here are the response files provided with an Oracle Database 18c Release 1 on a Linux server:

$ find . -name *.rsp

./response/db_install.rsp

./response/netca.rsp

./response/dbca.rsp

Copy one of the response files so that you can modify it. This example copies the db_install.rsp file to the current working directory and names the file inst.rsp:

$ cp response/db_install.rsp inst.rsp

Modify the inst.rsp file. Here is a partial listing of an Oracle Database 18c Release 1 response file (the first two lines are actually a single line of code but have been placed on two lines in order to fit on the page). The lines of code are the only variables that I modified. I removed the comments so that you could more clearly see which variables were modified:

oracle.install.responseFileVersion=/oracle/install/rspfmt_dbinstall_response_schema_v18.0.0

oracle.install.option=INSTALL_DB_SWONLY

ORACLE_HOSTNAME=oraserv1

UNIX_GROUP_NAME=oinstall

INVENTORY_LOCATION=/home/oracle/orainst/18.1.0.1/database/stage/products.xml

SELECTED_LANGUAGES=en

ORACLE_HOME=/u01/app/oracle/product/18.1.0.1/db_1

ORACLE_BASE=/u01/app/oracle

oracle.install.db.InstallEdition=EE

oracle.install.db.DBA_GROUP=dba

oracle.install.db.OPER_GROUP=oper

oracle.install.db.BACKUPDBA_GROUP=dba

oracle.install.db.DGDBA_GROUP=dba

oracle.install.db.KMDBA_GROUP=dba

DECLINE_SECURITY_UPDATES=true

Be sure to modify the appropriate parameters for your environment. If you’re unsure what to set the ORACLE_HOME and ORACLE_BASE values to, see the section Understanding the Optimal Flexible Architecture, earlier in this chapter, for a description of the OFA standard directories.

After you’ve configured your response file, you can run the Oracle installer in silent mode. Note that you have to enter the entire directory path for the location of your response file:

$ ./runInstaller -ignoreSysPrereqs -force -silent -responseFile \

 /home/oracle/orainst/18.1.0.1/database/inst.rsp

The previous command is entered on two lines. The first line is continued to the second line via the backward slash (\).

If you encounter errors with the installation process, you can view the associated log file. Each time you attempt to run the installer, it creates a log file with a unique name that includes a timestamp. The log file is created in the oraInventory/logs directory. You can stream the output to your screen as the OUI writes to it:

$ tail -f

Here is an example of a log file name:

installActions2017-11-04_02-57-29PM.log

If everything runs successfully, in the output you’re notified that you need to run the root.sh script as the root user:

/u01/app/oracle/product/18.1.0.1/db_1/root.sh

Run the root.sh script as the root OS user. Then, you should be able to create an Oracle database (database creation is covered in Chapter 2). The configuration assistants can run in the response file or silent mode to run the Net Configuration and Database Configuration Assistant.

Step 7. Troubleshoot Any Issues

If you encounter an error, using a response file, 90 percent of the time it’s due to an issue with how you set the variables in the file. Inspect those variables carefully and ensure that they’re set correctly. Also, if you don’t fully specify the command-line path to the response file, you receive errors such as this:

OUI-10203: The specified response file ... is not found.

Here is another common error when the path or name of the response file is incorrectly specified:

OUI-10202: No response file is specified for this session.

Listed next is the error message you receive if you enter a wrong path to your products.xml file within the response file’s FROM_LOCATION variable:

OUI-10133: Invalid staging area

Also, be sure to provide the correct command-line syntax when running a response file. If you incorrectly specify or misspell an option, you may receive a misleading error message, such as DISPLAY not set. When using a response file, you don’t need to have your DISPLAY variable set. This message is confusing because, in this scenario, the error is caused by an incorrectly specified command-line option and has nothing to do with the DISPLAY variable. Check all options entered from the command line and ensure that you haven’t misspelled an option.

Problems can also occur when you specify an ORACLE_HOME, and the silent installation thinks the given home already exists:

Check complete: Failed <<<<

Recommendation: Choose a new Oracle Home for installing this product.

Check your inventory.xml file (in the oraInventory/ContentsXML directory), and make sure there isn’t a conflict with an already existing Oracle home name.

There are log files that are generated with the installation, along with the files that are part of the inventory. The /tmp directory is going to have log files based on the timestamp of when the installation was performed. Make sure that all log files are examined when trying to troubleshoot; even system logs are useful if there were processes or memory issues hit during the process. When you’re troubleshooting issues with Oracle installations, remember that the installer uses two key files to keep track of what software has been installed, and where: oraInst.loc and inventory.xml. Table 1-2 describes the files used by the Oracle installer.

Table 1-2

Useful Files for Troubleshooting Oracle Installation Issues

Step 8. Apply Any Additional Patches

As already stated before the first step, the Oracle software is available in the base releases. However, if there are additional releases, patch sets, and security patches available, these should all be applied before rolling out a new set of Oracle binaries. The installation is going to be for a different reason on the server or in the environment, and the installation should be the same as the other environments with a possible exception of security patching.

Sections later in this chapter, Upgrading Oracle Software and Applying Interim Patches, have the details to apply the patches, but it is important to have this step here to get to the latest version of the software before releasing it for use. Right after the install of the binaries is a good time to make sure everything has been updated and ready for the database to be created.

Installing with a Copy of an Existing Installation

DBAs sometimes install Oracle software by using a utility such as tar to copy an existing installation of the Oracle binaries to a different server (or a different location on the same server). This approach is fast and simple (especially compared with downloading and running the Oracle installer). This technique allows DBAs to easily install the Oracle software on multiple servers, while ensuring that each installation is identical.

The new ways of delivering the media files provide ways to unzip in the ORACLE_HOME directory, or just run the rpm package that will run the installation. The advantage of using this method is be able to copy over a patched set of the binaries. There cannot be any databases running during this time or Oracle processes during this time of copying the files to provide a static copy of the files.

Installing Oracle with an existing copy of the binaries is a two-part process:

1.

Copy the binaries, using an OS utility.

2.

Attach the Oracle home.

These steps are detailed in the next two sections.

Tip

See MOS note 300062.1 for instructions on how to clone an existing Oracle installation.

Step 1. Copy the Binaries, Using an OS Utility

You can use any OS copy utility to perform this step. The Linux/Unix tar, scp, and rsync utilities are commonly used by DBAs to copy files. This example shows how to use the Linux/Unix tar utility to replicate an existing set of Oracle binaries to a different server. First, locate the target Oracle home binaries that you want to copy:

$ echo $ORACLE_HOME

/ora01/app/oracle/product/18.1.0.1/db_1

In this example the tar utility copies every file and subdirectory in or below the db_1 directory:

$ cd $ORACLE_HOME

$ cd ..

$ tar -cvf orahome.tar db_1

Now, copy the orahome.tar file to the server on which you want to install the Oracle software. In this example, the tar file is copied to the /u01/app/oracle/product/18.1.0.1 directory on a different server. The tar file is extracted there and creates a db_1 directory as part of the extract:

$ cd /u01/app/oracle/product/18.1.0.1

Make sure you have plenty of disk space available to extract the files. A typical Oracle installation can consume at least 3–4GB of space. Use the Linux/Unix df command to verify that you have enough space:

$ df -h | sort

Next, extract the files:

$ tar -xvf orahome.tar

When the tar command db_1 directory beneath the /u01/app/oracle/product/18.1.0.1 directory. directory.

Tip

Use the tar -tvf command to preview which directories and files are restored without restoring them.

Listed next is a powerful one-line combination of commands that allows you to bundle the Oracle files, copy them to a remote server, and have them extracted remotely:

$ tar -cvf - | ssh cd ; tar -xvf -

For instance, the following command copies everything in the dev_1 directory to the remote ora03 server /home/oracle directory:

$ tar -cvf - dev_1 | ssh ora03 cd /home/oracle; tar -xvf -

Absolute Paths vs. Relative Paths

Some older, non-GNU versions of tar use absolute paths when extracting files. The next line of code shows an example of specifying the absolute path when creating an archive file:

$ tar -cvf orahome.tar /home/oracle

Specifying an absolute path with non-GNU versions of tar can be dangerous. These older versions of tar restore the contents with the same directories and file names from which they were copied. This means that any directories and file names that previously existed on disk are overwritten.

When using older versions of tar, it’s much safer to use a relative pathname. This example first changes to the /home directory and then creates an archive of the oracle directory (relative to the current working directory):

$ cd /home

$ tar -cvf orahome.tar oracle

The previous example uses the relative pathname.

You don’t have to worry about absolute vs. relative paths on most Linux systems. This is because these systems use the GNU version of tar. This version strips off the forward slash (/) and restores files relative to where your current working directory is located.

Use the man tar command if you’re not sure whether you have a GNU version of the tar utility. You can also use the tar -tvf command to preview which directories and files are restored to what locations.

Step 2. Attach the Oracle Home

One issue with using a copy of an existing installation to install the Oracle software is that if you later attempt to upgrade the software, the upgrade process will throw an error and abort. This is because a copied installation isn’t registered in oraInventory. Before you upgrade a set of binaries installed via a copy, you must first register the Oracle home so that it appears in the inventory.xml file. This is called attaching an Oracle home.

To attach an Oracle home, you need to know the location of your oraInst.loc file on your server. On Linux servers this file is usually located in the /etc directory. On Solaris this file can generally be found in the /var/opt/oracle directory.

After you’ve located your oraInst.loc file, navigate to the ORACLE_HOME/oui/bin directory (on the server on which you installed the Oracle binaries from a copy):

$ cd $ORACLE_HOME/oui/bin

Now, attach the Oracle home by running the runInstaller utility, as shown:

$ ./runInstaller -silent -attachHome -invPtrLoc /etc/oraInst.loc \

ORACLE_HOME=/u01/app/oracle/product/18.1.0.1/db_1 ORACLE_HOME_NAME=ONEW

You should see this as the last message in the output, if successful:

'AttachHome' was successful.

You can also examine the contents of your oraInventory/ContentsXML/inventory.xml file. Here is a snippet of the line inserted into the inventory.xml file as a result of running the runInstaller utility with the attachHome option:

ONEW LOC=/u01/app/oracle/product/18.1.0.1/db_1 TYPE=O IDX=2/>

Installing Read-Only Oracle Home

A new feature of Oracle 18c is to have a read-only Oracle Home for the binaries. The database tools and processes will be under the ORACLE_BASE path instead of ORACLE_HOME path. The ORACLE_HOME directory will have the database configurations and logs for the databases created.

A read-only Oracle binary home will separate the software from the database information and allows for sharing the software across different deployments. This enables seamless patching and updating of the binaries to minimize database downtime and allows for applying patches to one image in order to distribute to several servers. This separation also simplifies the provisioning because the focus can be on the database configuration.

There are now additional environment variables that will contain the directory path for the Oracle Home, ORACLE_BASE_HOME, ORACLE_BASE_CONFIG.

To enable a read-only Oracle home, the software needs to be install as described with the binaries only and not the configuration assistants. Then run the following:

$ cd /u01/app/oracle/product/18.1.0.1/dbhome18c/bin

$ roohctl -enable

After enabling the read-only home, the DBCA can be run to create databases. There is a check to know if the database is in a read-only home:

$ cd $ORACLE_HOME/bin

$ ./orabasehome

If a directory is returned, the Oracle home is in read-only.

Upgrading Oracle Software

You can also upgrade a version of the Oracle software, using the silent installation method. Begin by downloading the upgrade version from the MOS web site ( http://support.oracle.com ) (you need a valid support contract to do this). Read the upgrade documentation that comes with the new software. The upgrade procedure can vary quite a bit, depending on what version of Oracle you’re using.

For the most recent upgrades that I’ve performed, the procedure was much like installing a new set of Oracle binaries. You can use the OUI in either graphical or silent mode to install the software. See the section Installing Oracle, earlier in this chapter, for information on using the silent mode installation method.

Database migrations to new version are successful using the Database Upgrade Assistant (DBUA). This will perform a migration to the latest version of the database and upgrade the services. New with 18c the services must be upgraded with this method, install the latest version of the software and then to complete the migration run the DBUA.

Note

Upgrading the Oracle software isn’t the same as upgrading an Oracle database. This section only deals with using the silent install method for upgrading the Oracle software. Additional steps are involved for upgrading a database. See MOS note 730365.1 for instructions on how to upgrade a database.

Depending on the version being upgraded, you may be presented with two different scenarios. Here is scenario A:

1.

Shut down any databases using the Oracle home to be upgraded.

2.

Upgrade the Oracle home binaries.

3.

Start up the database and run any required upgrade scripts.

Here are the steps for the scenario B approach to an upgrade:

1.

Leave the existing Oracle home as it is—don’t upgrade it.

2.

Install a new Oracle home that is the same version as the old Oracle home.

3.

Upgrade the new Oracle home to the desired version.

4.

When you’re ready, shut down the database using the old Oracle home; set the OS variables to point to the new, upgraded Oracle home; start up the database; and run any required upgrade scripts.

Which of the two previous scenarios is better? Scenario B has the advantage of leaving the old Oracle home as it is; therefore, if, for any reason, you need to switch back to the old Oracle home, you have those binaries available. Scenario B has the disadvantage of requiring extra disk space to contain two installations of Oracle home. This usually isn’t an issue, because after the upgrade is complete, you can delete the old Oracle home when it’s convenient.

Databases can also be upgraded to a new container database in a multitenant environment. This will be discussed more in Chapter 22, but the pluggable databases can be moved to a container database that has already been upgraded.

Tip

Consider using the Database Upgrade Assistant (DBUA) to upgrade an Oracle database.

Reinstalling After Failed Installation

You may run into a situation in which you’re attempting to install Oracle, and for some reason the installation fails. You correct the issue and attempt to rerun the Oracle installer. However, you receive this message:

   CAUSE: The chosen installation conflicted with software already

          installed in the given Oracle home.

   ACTION: Install into a different Oracle home.

In this situation, Oracle thinks that the software has already been installed, for a couple of reasons:

Files in the ORACLE_HOME directory are specified in the response file.

An existing Oracle home and location in your oraInventory/ContentsXML/inventory.xml file match what you have specified in the response file.

Oracle doesn’t allow you to install a new set of binaries over an existing Oracle home. If you’re sure you don’t need any of the files in the ORACLE_HOME directory , you can remove them (be very careful—ensure that you absolutely want to do this). This example navigates to ORACLE_HOME and then removes the db_1 directory and its contents:

$ cd $ORACLE_HOME

$ cd ..

$ rm -rf db_1

Also, even if there are no files in the ORACLE_HOME directory, the installer inspects the inventory.xml file for previous Oracle home names and locations. In the inventory.xml file, you must remove the entry corresponding to the Oracle home location that matches the Oracle home you’re trying to install to. To remove the entry, first, locate your oraInst.loc file, which contains the directory of your oraInventory. Next, navigate to the oraInventory/ContentsXML directory. Make a copy of inventory.xml before you modify it:

$ cp inventory.xml inventory.xml.old

Then, edit the inventory.xml file with an OS utility (such as vi), and remove the line that contains the Oracle home information of your previously failed installation. You can now attempt to execute the runInstaller utility again.

Applying Interim Patches

Sometimes, you’re required to apply a patch to resolve a database issue or eradicate a bug. You can usually obtain patches from the MOS web site and install them with the opatch utility . Here are the basic steps for applying a patch:

1.

Obtain the patch from MOS (requires a valid support contract).

2.

Unzip the patch file.

3.

Carefully read the README.txt file for special instructions.

4.

Shut down any databases and processes using the Oracle home to which the patch is being applied.

5.

Apply the patch.

6.

Verify that the patch was installed successfully.

A brief example will help illustrate the process of applying a patch. Here, the patch number 14390252 is applied to an 11.2.0.3 database on a Solaris box. First, download the p14390252_112030_SOLARIS64.zip file from MOS ( https://support.oracle.com ). Next, unzip the file on the server to which the patch is being applied:

$ unzip p14390252_112030_SOLARIS64.zip

The README.txt instructs you to change the directory, as follows:

$ cd 14390252

Make sure you follow the instructions included in the README.txt, such as shutting down any databases that use the Oracle home to which the patch is being applied:

$ sqlplus / as sysdba

SQL> shutdown immediate;

Next, apply the patch. Ensure that you perform this step as the owner of the Oracle software (usually the oracle OS account). Also make sure your ORACLE_HOME variable is set to point to the Oracle home to which you’re applying the patch. In this example, because the opatch utility isn’t in a path included in the PATH directory, you specify the entire path:

$ $ORACLE_HOME/OPatch/opatch napply -skip_subset -skip_duplicate

Finally, verify that the patch was applied by listing the inventory of patches:

$ $ORACLE_HOME/OPatch/opatch lsinventory

Here is some sample output for this example:

Patch  13742433     : applied on Sun Nov 04 13:49:07 MST 2012

Unique Patch ID:  15427576

Tip

See MOS note 242993.1 for more information regarding the opatch utility.

Installing Remotely with the Graphical Installer

The installation can be performed once using the GUI for a Read-Only Oracle Home. In today’s global environment, DBAs often find themselves tasked with installing Oracle software on remote Linux/Unix servers. In these situations, I strongly suggest that you use the silent installation mode with a response file (as mentioned earlier). However, if you want to install Oracle on a remote server via the graphical installer, this section of the chapter describes the required steps.

Note

If you’re in a Windows-based environment, use the Remote Desktop Connection or Virtual Network Computing (VNC) to install software remotely.

One issue that frequently arises is how to run the Oracle installer on a remote server and have the graphical output displayed to your local computer. Figure 1-2 shows the basic components and utilities required to run the Oracle graphical installer remotely.

Figure 1-2

Components needed for a remote Oracle graphical installation

Listed next are the steps for setting up your environment to display the graphical screens on your local computer while remotely running the Oracle installer:

1.

Install software on the local computer that allows for X Window System emulation and secure networking.

2.

Start an X session on the local computer and issue the startx command.

3.

Copy the Oracle installation files to the remote server.

4.

Run the xhost command.

5.

Log in to the remote computer from an X terminal.

6.

Ensure that the DISPLAY variable is set correctly on the remote computer.

7.

Execute the runInstaller utility on the remote server.

8.

Troubleshoot.

These steps are explained in the following sections.

Step 1. Install X Software and Networking Utilities on the Local PC

If you’re installing Oracle on a remote server, and you’re using your home personal computer (PC), then you first need to install software on your PC that allows you to run X Window System software and to run commands such as ssh (secure shell) and scp (secure copy). Several free tools are available that provide this functionality. One such tool is Cygwin, which you can download from the Cygwin web site ( http://x.cygwin.com ). Be sure to install the packages that provide the X emulation and secure networking utilities, such as ssh and scp.

Step 2. Start an X Session on the Local Computer

After you install on your local computer the software that allows you to run X Window System software, you can open an X terminal window and start the X server via the startx command:

$ startx

Here is a snippet of the output:

xauth:  creating new authority file /home/test/.serverauth.3012

waiting for X server to begin accepting connections.

When the X software has started, run a utility such as xeyes to determine whether X is working properly:

$ xeyes

Figure 1-3 shows what a local terminal session looks like, using the Cygwin X terminal session tool.

Figure 1-3

Running xeyes utility on a local computer

If you can’t get a utility such as xeyes to execute, stop at this step until you get it working. You must have correctly functioning X software before you can remotely install Oracle, using the graphical installer.

Step 3. Copy the Oracle Installation Media to the Remote Server

From the X terminal, run the scp command to copy the Oracle installation media to the remote server. Here is the basic syntax for using scp:

$ scp @:

The next line of code copies the Oracle installation media to a remote Oracle OS user on a remote server in the home directory oracle:

$ scp linux_18cR1_database_1of2.zip oracle@shrek2:.

Step 4. Run the xhost Command

From the X screen, enable access to the remote host via the xhost command . This command must be run from your local computer:

$ xhost +

access control disabled, clients can connect from any host.

The prior command allows any client to connect to the local X server. If you want to enable remote access specifically for the remote computer on which you’re installing the software, provide an Internet protocol (IP) address or hostname (of the remote server). In this example, the remote hostname is tst-z1.central.sun.com:

$ xhost +tst-z1.central.sun.com

tst-z1.central.sun.com being added to access control list

Step 5. Log In to the Remote Computer from X

From your local X terminal, use the ssh utility to log in to the remote server on which you want to install the Oracle software:

$ ssh -Y -l oracle

Step 6. Ensure that the DISPLAY Variable Is Set Correctly on the Remote Computer

When you’ve logged in to the remote box, verify that your DISPLAY variable has been set:

$ echo $DISPLAY

You should see something similar to this:

localhost:10.0

If your DISPLAY variable is set to localhost:10.0, then proceed to the next step. Otherwise, follow the next set of recommendations.

If your DISPLAY variable isn’t set, you must ensure that it’s set to a value that reflects your local home computer location. From your local home computer, you can use the ping or arp utility to determine the IP address that identifies your local computer. Run the following command on your home computer:

C:\> ping

Tip

If you don’t know your local home computer name, on Windows you can look in the Control Panel, then System, then reference the Computer name.

Now, from the remote server, execute this command to set the DISPLAY variable to contain the IP address of the local computer:

$ export DISPLAY=129.151.31.147:0.0

Note that you must append the :0.0 to the end of the IP address. If you’re using the C shell, use the setenv command to set the DISPLAY variable:

$ setenv DISPLAY 129.151.31.147:0.0

If you’re unsure which shell you’re using, use the echo command to display the SHELL variable:

$ echo $SHELL

Step 7. Execute the runInstaller Utility

Navigate to the directory where you copied and unzipped the Oracle software on the remote server. Locate the runInstaller utility , and run it, as shown:

$ ./runInstaller

If everything goes well, you should see a screen appear in order to walk through the steps of the installation.

From here, you can point and click your way through an Oracle installation of the software. Many DBAs are more comfortable installing the software through a graphical screen. This is a particularly good method if you aren’t familiar with Oracle’s installation process and want to be prompted for input and presented with reasonable default values.

Step 8. Troubleshoot

Most issues with remote installations occur in steps 4, 5, and 6. Make sure you’ve properly enabled remote-client access to your local X server (running on your home computer) via the xhost command. The xhost command must be run on the local computer on which you want the graphical display presented. Using the + (plus sign) with the remote hostname adds a host to the local access list. This enables the remote server to display an X window on the local host. If you type the xhost command by itself (with no parameters), it displays all remote hosts that can display X sessions on the local computer:

$ xhost

access control disabled, clients can connect from any host

Setting the DISPLAY OS variable on the remote server is also crucial. This allows you to log in to another host remotely and display an X application back to your local computer. The DISPLAY variable must be set on the remote database server to contain information that points it to the local computer on which you want the graphical screen displayed.

Installation in the Cloud

Oracle 18c is a database released for the cloud first. Oracle 18c for server installation became available several months after the use in the cloud and being able to perform installs in the cloud. Oracle provides a couple of different options for databases in the cloud, and a common one is Infrastructure as a Service (IaaS). IaaS provides the infrastructure, server, OS, and users that are needed to be able to install your own software and then create databases. Database provisioning is another option, Platform as a Service (PaaS) can provide the Oracle binaries, and just the databases will need to be created on that cloud service.

Since we have been discussing the software installation on a server and existing OS, this will be an install on IaaS in the cloud. The database binaries would walk through the same steps as described throughout this chapter. Configuration of the cloud service provided would be based on the amount of storage, CPU, and memory requested. There is flexibility of numbers of CPUs and memory that can be requested and then expanded for future needs quickly and efficiently in the cloud.

Oracle is also available in AWS where it can be selected as an AMI from the store and installed. Along with this option in other platforms, Oracle can be installed as part of an IaaS. IaaS is available in the different cloud offerings, AWS, and others, but some of the server configurations are going to be optimized on the Oracle Cloud and different options of the licensing might be available. These are discussions with the Oracle sales team to get licenses and requirements planned, but a decision to go to the cloud needs to be discussed with the business and decide if the flexible resources and the time to deployment are going to be of value.

In the Oracle Cloud, the database deployment is chosen, with an available Domain and shape of the bare-metal machines based on the CPU and other resources for the IaaS server. The software edition is the next choice, which is also the same with non-cloud installations of the binary. Using IaaS in the cloud, their ssh keys, root access, and other access such as SYS that is just for the customer and not accessible by the Oracle cloud provider. This is just for the server that has been requested. The configuration assistants can be run later after the binary install or select to run immediately after the binaries are installed.

After these basic choices, the installation happens in the cloud. The server is then ready for use to create databases and set up for management and monitoring. These steps will be discussed later in the following chapters to include how to also manage the databases in the cloud.

Summary

This chapter detailed techniques for efficiently installing the Oracle binaries. Oracle 18c provides new ways to deploy the Oracle binaries including a Read-Only Oracle Home. These methods are especially useful if you work in environments in which you are geographically separated from the database servers. The Oracle silent installation method is efficient because it doesn’t require graphical software and uses a response file that helps enforce consistency from one installation to the next. When working in chaotic and constantly changing environments, you should benefit from the installation tips and procedures described here.

The Oracle binaries are installed in cloud environments when using Infrastructure as a Service (IaaS), and this makes provisioning of servers and databases very efficient. IaaS allow for the DBAs to have full access of the provisioned server to perform database creation, but the installation of the database binaries is simplified and similar to a response file install. Many DBAs feel more comfortable using Oracle’s graphical installer for installing the database software. However, the graphical installer can be troublesome when the server is in a remote location or embedded deeply within a secure network. A slow network or a security feature can greatly impede the graphical installation process. In these situations, make sure you correctly configure the required X software and OS variables (such as DISPLAY).

It’s critical as a DBA to be an expert in Oracle installation procedures. If the Oracle installation software isn’t correctly installed, you won’t be able to successfully create a database. Once you have properly installed Oracle, you can go on to the next step of starting the background processes and creating a database. The topics of starting Oracle and issuing and creating a database are discussed next, in Chapter 2.

© Michelle Malcher and Darl Kuhn 2019

Michelle Malcher and Darl KuhnPro Oracle Database 18c Administrationhttps://doi.org/10.1007/978-1-4842-4424-1_2

2. Creating a Database

Michelle Malcher¹  and Darl Kuhn²

(1)

Huntley, IL, USA

(2)

Morrison, CO, USA

Chapter 1 detailed how to efficiently install the Oracle binaries. After you’ve installed the Oracle software, the next logical task is creating a database. There are a few standard ways for creating Oracle databases:

Use the Database Configuration Assistant (dbca) utility.

Run a CREATE DATABASE statement from SQL*Plus.

Clone a database from an existing database.

Oracle’s dbca utility has a graphical interface from which you can configure and create databases. This visual tool is easy to use and has a very intuitive interface. If you need