Fortune 500 companies have embraced Oracle and Red Hat Enterprise Linux, and Linux has become a dominant force in the server industry. More and more Fortune 500 companies have adopted Linux as a corporate standard. With Oracle’s presence over the server space with its engineered systems, Linux has become a norm for DBAs. In the world of engineered systems and virtualized infrastructures, DBAs often perform or share system administration responsibilities. The greatest Real Application Cluster (RAC) DBAs know Linux intimately and know the best practices for tuning it. For larger companies, a true delineation of roles and responsibilities still exists. This chapter is for DBAs who perform software management roles in the Linux world—in particular, Red Hat and Oracle Enterprise Linux (Oracle Linux).

This chapter takes a bare-bones Red Hat Enterprise Linux installation and registers the Red Hat server to Oracle’s Unbreakable Linux Network, leverages Oracle’s RDBMS PreInstall RPM for Oracle Database 11g Release 2 and Oracle Database 12c to preconfigure a Linux server for Oracle installation, performs a silent installation of Oracle Database 11g/12c software, clones a fully patched Oracle installation, performs a silent database creation, and completes the server build by setting up a silent network configuration. Silent mode installations are the foundations of creating an automated server installation procedure.

This chapter demonstrates how to install RPMs, switch to Oracle’s Unbreakable Linux Network from the Red Hat Network, list the contents of an RPM package, correlate OS executables to RPMs, download RPMs, automate with Oracle’s validated install, and remove RPMs.

The database software management portion of this chapter concentrates exclusively on silent installations. While learning how to set up a database server from a soup-to-nuts implementation, you’ll also learn about RPM and YUM package management.

11-1. Installing Packages

Problem

You want to install software components on the Linux server.

Solution #1

By far the easiest way to manage software on the Linux server is with the yum command, as shown in this example:

# yum install screen -y
Loaded plugins: product-id, subscription-manager
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package screen.x86_64 0:4.0.3-16.el6 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

=========================================================================================
 Package             Arch      Version                      Repository              Size
=========================================================================================
Installing:
 screen              x86_64     4.0.3-16.el6                 viscosity              494 k

Transaction Summary
=========================================================================================
Install       1 Package(s)

Total download size: 494 k
Installed size: 795 k
Downloading Packages:
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing : screen-4.0.3-16.el6.x86_64                                             1/1
  Verifying  : screen-4.0.3-16.el6.x86_64                                             1/1

Installed:
  screen.x86_64 0:4.0.3-16.el6

Complete!

Solution #2

Another way to manage software on the Linux server is by executing the rpm command with the -i option (or --install) to install the package.

Here’s an example of installing the screen executable:

# rpm -ihv screen-4.0.3-1.el5.i386.rpm
Preparing...                    ########################################### [100%]
    1:screen                    ########################################### [100%]

The -h option displays hash marks during the installation. The -v option provides verbose output that reports the progress of the installation. The rpm executable can install packages from the local filesystem, CD, or remote server accessible by HTTP or FTP.

How It Works

Yellowdog Updater, Modified (YUM) is a command-line, open-source package management utility for Linux dependent on the RPM Package Manager. YUM is a modified version of the original update command developed for Yellow Dog Linux that relies heavily on package headers. On the header of each package, forward and reverse dependency information is available for installation and rollback of the package. With this information in databases known as repositories, YUM can simplify package installation by determining other packages required to satisfy dependencies.

In a nutshell, RPM is a package management system. RPM originally stood for Red Hat Package Manager because it was designed by Red Hat for Red Hat distributions. Because RPM was intended for Linux distributions and used by many Linux distributions, RPM now stands for RPM Package Manager. The RPM system is composed of a local database, the rpm executable, and the RPM package files. The local RPM database, which is stored in the /var/lib/rpm directory, houses metadata information about installed packages, including package prerequisites and file attributes. Because the local RPM database tracks all the packages and file attributes, removing a package becomes a relatively simple operation.

The RPM package file is composed of compressed archive files and dependency information. The package name or label contains the following attributes:

<name>-<version>-<release>.<architecture>.rpm

Here’s an example of the package label:

unixODBC-2.2.11-7.1.i386.rpm

The unixODBC RPM is a required RPM for Oracle Database 11g. For this example, the RPM version is 2.2.11, and the release of the RPM is 7.1. This particular RPM is designed for a 32-bit Intel IA32 (x86) CPU. The AMD64/Intel em64t RPM has the architecture name x86_64.

RPMs that contain source code show .src before the .rpm suffix. Although you might not find binary RPMs associated with your architecture and flavor of Linux, an equivalent source code RPM may be available for another type of Linux. You can download the source and compile the RPM.

Notice that certain RPMs have the .noarch extension in the file names to denote that the RPM doesn’t have a dependency on your system’s architecture.

11-2. Switching to the Oracle Unbreakable Linux Network

Problem

You installed RHEL 6 or 7, but want to leverage Oracle’s Unbreakable Linux Network (ULN). You want to start performing updates from ULN instead of Red Hat Network (RHN).

Solution

Before you can start taking advantage of ULN, you must download and upgrade to the new version of the up2date and up2date-gnome packages from https://linux.oracle.com/switch.html for your version of Red Hat and server architecture. In addition, you must have a valid CSI and license for Oracle Linux (OL).

You can download the files from the http://linux-update.oracle.com/rpms/ web site. For Red Hat Linux 7 64-bit architecture, download two files: uln_register_ol7.tgz and uln_register-gnome_ol7.tgz. For Red Hat Linux 6 (both 32-bit and 64-bit architectures), download two files: uln_register.tgz and uln_register-gnome.tgz. For updates to switching instructions, please review the steps from the Oracle web site: https://linux.oracle.com/switch.html.

Installing Oracle up2date for Older Releases

Once you download the up2date and up2date-gnome packages, you can upgrade the existing packages as the root user on your Red Hat system using the rpm -Uhv command, as shown here:

# rpm -Uhv up2date-5.10.1-40.8.el5.i386.rpm 
                              up2date-gnome-5.10.1-40.8.el5.i386.rpm
warning: up2date-5.10.1-40.8.el5.i386.rpm: Header V3 DSA signature: NOKEY, key ID
 1e5e0159
Preparing...                ########################################### [100%]
   1:up2date                ########################################### [ 50%]
   2:up2date-gnome          ########################################### [100%]

If you don’t have up2date-gnome installed, you can exclude that RPM. If you’re running on OS versions prior to Red Hat Linux (RHEL) 6, you must import Oracle’s GPG keys by executing the import option:

rpm --import /usr/share/rhn/RPM-GPG-KEY

Registering with ULN

Now you are ready to register the Red Hat server with ULN. Once you register the Red Hat server, you can start using the up2date command to automatically download and install/upgrade packages on the Linux server. The single greatest feature of up2date is that all the dependencies are automatically resolved without the administrator’s intervention.

The biggest frustration with RPM management is dealing with a colloquialism referred to as dependency hell. For example, suppose that RPM X has a dependency on RPMs A, B, and C. RPM B has another dependency on L, M, and N. Not realizing the RPM dependencies, when you try to install RPM N, you encounter another dependency for RPM N that requires RPMs H and I. You simply want to install RPM X, but you stumble into a multitude of other RPM requirements, and the dependency requirements stack on top of each other. You’ll encounter situations in which up2date can significantly simplify the management of a Linux server.

To start the registration process if you are on RHEL 3, RHEL 4, or RHEL 5, you can execute the following command:

up2date --register

You can execute the command up2date --register --nox to launch up2date in non-GUI mode. Without the --nox option, your DISPLAY parameter must be set to a valid X server or the VNC server. Initially, you’ll see the Welcome to ULN Update Agent screen. Click the Forward button to be directed to the ULN Login screen. Because this is the first time you are logging in to up2date, you must provide all the credentials onscreen, including a login ID, a password (twice for verification), and a licensed CSI number.

For RHEL 6 and RHEL 7, execute the uln_register command to switch from RHN to ULN. Carefully follow the onscreen instructions and enter the requested information. The uln_register process also collects machine information and uploads it to the Oracle server. System should be subscribed to the latest OL 7 channel on ULN to perform the YUM update in the case of RHEL 7.

How It Works

Switching from RHN to Oracle’s ULN is straightforward. Once you purchase a license of OL, you can start receiving support from Oracle Support instead of Red Hat. You can start to receive support from a single front end for both the OS and the database from Oracle Support.

Once you have successfully registered your Red Hat server with ULN, you can access the ULN portal via https://linux.oracle.com. In the Login and Password fields, you can provide the login and password credentials that you supplied while registering your Red Hat server.

Whether you are on OL or RHEL, you can leverage Oracle’s public YUM server for package management. Everyone knows that if you are on OL, you can take advantage of Oracle’s public YUM server for Oracle RDBMS PreInstall RPMs. However, few realize that even Red Hat customers can take advantage of Oracle’s public YUM server. To configure the Red Hat for Oracle public YUM server, first download the repository configuration file. Repositories are set up in the /etc/yum.repos.d directories. You can set up more than one YUM repository for a Linux server.

To obtain a listing of available repositories for your server, execute the yum command with the repolist argument:

# yum repolist

Because you’re working with RHEL 6.6, download Oracle’s public YUM repository configuration files for OL 6 and place the file in the /etc/yum.repos.d directory:

# wget http://public-yum.oracle.com/public-yum-ol6.repo
--2015-05-18 15:26:52--  http://public-yum.oracle.com/public-yum-ol6.repo
Resolving public-yum.oracle.com... 67.200.133.11, 67.200.133.9
Connecting to public-yum.oracle.com|67.200.133.11|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 5046 (4.9K) [text/plain]
Saving to: "public-yum-ol6.repo"

100%[==============================================================================>] 5,046       --.-K/s   in 0.002s

2015-05-18 15:26:52 (2.16 MB/s) - "public-yum-ol6.repo" saved [5046/5046]

You have to download the OL GPG key with the same wget command and place the file in the /etc/pki/rpm-gpg directory:

wget http://public-yum.oracle.com/RPM-GPG-KEY-oracle-ol6 -O /etc/pki/rpm-gpg/RPM-GPG-KEY-oracle

If you don’t download this GPG key, you’ll encounter the following error during any kind of YUM package maintenance:

GPG key retrieval failed: [Errno 14] Could not open/read file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle

Once you download the Oracle GPG key, you can verify the GPG key with the gpg command. A public key fingerprint is a short sequence of bytes used to authenticate a longer public key. You create fingerprints by applying a cryptographic hash function to a public key. With the –with-fingerprint parameter, you can verify the fingerprint associated with the GPG key:

# gpg --quiet --with-fingerprint /etc/pki/rpm-gpg/RPM-GPG-KEY-oracle
pub  2048R/EC551F03 2010-07-01 Oracle OSS group (Open Source Software group) <[email protected]>
      Key fingerprint = 4214 4123 FECF C55B 9086  313D 72F9 7B74 EC55 1F03

11-3. Associating Linux Files with RPM Packages

Problem

One of the servers has an executable you need, but another server doesn’t. You want to identify the RPM package to install on the server.

Solution #1

Look at the yum provides command with the fully qualified path to the pkill executable to see which RPM delivers the executable:

$ yum provides /usr/bin/pkill
Loaded plugins: downloadonly
procps-3.2.8-21.el6.x86_64 : System and process monitoring utilities
Repo        : public_ol6_latest
Matched from:
Filename    : /usr/bin/pkill
...
...

Solution #2

Look for the gedit executable, but this time by passing the –qf parameters to the rpm command:

[root@rac5 bin]# rpm -qf /usr/bin/gedit
gedit-2.16.0-5.el5

The -qf option also works for shared objects. If you happen to be curious about which package the libc.so file came from, you can issue the -qf option, as demonstrated here:

[root@rac5 lib]# rpm -qf libc.so
glibc-devel-2.5-18

How It Works

The yum command has the provides option, which returns the package name if you specify the path of the executable or shared library. The provides option also accepts a wildcard parameter (*) for the path enclosed by double quotes, as shown here:

# yum provides "*bin/gedit"
Loaded plugins: downloadonly
public_ol6_UEKR3_latest/filelists                                                                                      | 8.2 MB     00:21
1:gedit-2.28.4-3.el6.x86_64 : Text editor for the GNOME desktop
Repo        : public_ol6_latest
Matched from:
Filename    : /usr/bin/gedit

rpm provides features to query the RPM database to extract the owning package. You can correlate an executable or library from the OS to an RPM. You can execute rpm with the -qf (-q for -query and -f for -file) option to determine which RPMs are associated with a specified file or executable.

11-4. Listing the Contents of an RPM Package

Problem

You want to look inside the .rpm file to view the contents of the package and peek at the destination in which the files will be extracted.

Solution #1

The repoquery executable provides the capability to view the destination location of files for a package. The repoquery comes with the yum-utils RPM and has to be installed with yum:

# yum install yum-utils

Once the yum-utils package is installed, leverage the repoquery executable with the –l option (or –listing option) against the screen rpm:

# repoquery -l screen
/etc/pam.d/screen
/etc/screenrc
/usr/bin/screen
/usr/share/doc/screen-4.0.3
/usr/share/doc/screen-4.0.3/COPYING
/usr/share/doc/screen-4.0.3/FAQ
/usr/share/doc/screen-4.0.3/NEWS
/usr/share/doc/screen-4.0.3/README
/usr/share/doc/screen-4.0.3/README.DOTSCREEN
/usr/share/info/screen.info.gz
/usr/share/man/man1/screen.1.gz
/usr/share/screen
/usr/share/screen/utf8encodings
/usr/share/screen/utf8encodings/01
/usr/share/screen/utf8encodings/02
/usr/share/screen/utf8encodings/03
/usr/share/screen/utf8encodings/04
/usr/share/screen/utf8encodings/18
/usr/share/screen/utf8encodings/19
/usr/share/screen/utf8encodings/a1
/usr/share/screen/utf8encodings/bf
/usr/share/screen/utf8encodings/c2
/usr/share/screen/utf8encodings/c3
/usr/share/screen/utf8encodings/c4
/usr/share/screen/utf8encodings/c6
/usr/share/screen/utf8encodings/c7
/usr/share/screen/utf8encodings/c8
/usr/share/screen/utf8encodings/cc
/usr/share/screen/utf8encodings/cd
/usr/share/screen/utf8encodings/d6
/var/run/screen

Solution #2

You can execute rpm with the -qlp option to list the destination location for files in a package. Here’s an example in which the contents of the openmotif21 RPM are examined with HTTP:

[root@rac5 up2date]# rpm -qlp http://dbaexpert.com/rpms/openmotif21-2.1.30-
11.RHEL4.6.i386.rpm
warning: http://dbaexpert.com/rpms/openmotif21-2.1.30-11.RHEL4.6.i386.rpm: Header
V3 DSA signature: NOKEY, key ID b38a8516
/usr/X11R6/lib/libMrm.so.2
/usr/X11R6/lib/libMrm.so.2.1
/usr/X11R6/lib/libUil.so.2
/usr/X11R6/lib/libUil.so.2.1
/usr/X11R6/lib/libXm.so.2
/usr/X11R6/lib/libXm.so.2.1
/usr/share/doc/openmotif21-2.1.30
/usr/share/doc/openmotif21-2.1.30/COPYRIGHT.MOTIF
/usr/share/doc/openmotif21-2.1.30/README
/usr/share/doc/openmotif21-2.1.30/RELEASE
/usr/share/doc/openmotif21-2.1.30/RELNOTES

As mentioned in Recipe 11-1, you can execute the previous rpm command against a file on the local filesystem, CD, or remote server with HTTP or FTP access.

How It Works

You can use the repoquery command to list package contents. It will work with installed packages as well as packages not yet installed. The repoquery has numerous options. The –l option lists files in the package in question. The –i option (--info) lists descriptive information from the package.

Here’s an example using the –i option to obtain informative description about the screen package:

# repoquery -i screen

Name        : screen
Version     : 4.0.3
Release     : 16.el6
Architecture: x86_64
Size        : 814092
Packager    : None
Group       : Applications/System
URL         : http://www.gnu.org/software/screen
Repository  : public_ol6_latest
Summary     : A screen manager that supports multiple logins on one terminal
Source      : screen-4.0.3-16.el6.src.rpm
Description :
The screen utility allows you to have multiple logins on just one
terminal. Screen is useful for users who telnet into a machine or are
connected via a dumb terminal, but want to use more than just one
login.

Install the screen package if you need a screen manager that can
support multiple logins on one terminal.

The rpm command has a myriad of options, and the -p option allows you to view information directly from the package. The two commonly executed options with -p are -qip and -qlp. The -qlp option lists all the files that make up the package.

The -qip option provides detailed information about the package. Here, the same command is executing as previously, except with the -qip option:

# rpm -qip http://dbaexpert.com/rpms/openmotif21-2.1.30-
11.RHEL4.6.i386.rpm
warning: http://dbaexpert.com/rpms/openmotif21-2.1.30-11.RHEL4.6.i386.rpm: Header
V3 DSA signature: NOKEY, key ID b38a8516
Name        : openmotif21                  Relocations: /usr/X11R6
Version     : 2.1.30                            Vendor: (none)
Release     : 11.RHEL4.6                    Build Date: Sat 07 Oct 2006 08:45:00
AM CDT
Install Date: (not installed)               Build Host: ca-build10.us.oracle.com
Group       : System Environment/Libraries   Source RPM: openmotif21-2.1.30-
11.RHEL4.6.src.rpm
Size        : 2249149                          License: Open Group Public License
Signature   : DSA/SHA1, Mon 09 Oct 2006 08:24:28 PM CDT, Key ID 2e2bcdbcb38a8516
URL         : http://www.opengroup.org/openmotif/
Summary     : Compatibility libraries for Open Motif 2.1.
Description :
This package contains the compatibility libraries for running Open Motif 2.1
applications.

Notice that the -qip option provides additional details about the packages, such as when the package was built, from which machines, the source RPM, the size, the signature, and even a description of what the package is about. You can also combine these options as -qlip, which shows both detailed information about the package and the list of all files in the package.

11-5. Downloading Packages

Problem

You want to download RPMs from the Linux terminal.

Solution

By installing a package called yum-plugin-downloadonly on RHEL 6, you can start downloading RPMs:

# yum install yum-plugin-downloadonly

After installing the yum-plugin-downloadonly package, you can execute the yum command as if you were actually installing the software, but provide it two additional parameters: --downloadonly and --downloaddir. Here’s the syntax to download the screen package to the /tmp directory:

[root@ika82 ~]# yum install --downloadonly --downloaddir=/tmp screen
Loaded plugins: downloadonly
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package screen.x86_64 0:4.0.3-16.el6 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

=========================================================================================
 Package         Arch        Version      Repository                                 Size
=========================================================================================
Installing:      screen      x86_64       4.0.3-16.el6       public_ol6_latest      494 k

Transaction Summary
=========================================================================================
Install       1 Package(s)

Total download size: 494 k
Installed size: 795 k
Is this ok [y/N]: y
Downloading Packages:
screen-4.0.3-16.el6.x86_64.rpm                                       | 494 kB     00:01

exiting because --downloadonly specified

You can confirm that the screen package successfully downloaded the screen RPMs to the /tmp directory by performing a directory listing:

[root@ika82 ~]# ls -ltr /tmp/*.rpm
-rw-r--r--. 1 root root 505732 Apr 22  2011 /tmp/screen-4.0.3-16.el6.x86_64.rpm

How It Works

By default, the yum-plugin-downloadonly RPM is not installed; you have to install the RPM manually. The greatest benefit of downloading the RPMs with yum is that all dependent packages are automatically downloaded together. For example, the perl RPM has many dependent packages, and all the perl and dependent RPMS can be downloaded with a single command.

11-6. Automating Server Builds with Oracle RDBMS Server PreInstall RPM

Problem

You don’t want to spend time researching RPM requirements to install Oracle Database 11g/12c. You want to take advantage of Oracle’s preconfigured validated installation process.

Solution

If you are running on OL or RHEL (a rebuild from the source RPM is required), you can fully leverage Oracle’s automated preinstallation processes. Oracle’s validated install automates the download of all the required RPMs; the installation of RPMs, including dependency requirements; the setup of the Linux kernel parameters; the creation of the oracle user in the /etc/passwd file; and the creation of entries in the /etc/group file for dba and oinstall. You simply execute the yum command with the following options:

# yum install oracle-rdbms-server-12cR1-preinstall
...
...
Transaction Summary
=========================================================================================
Install      13 Package(s)

Total download size: 7.5 M
Installed size: 23 M
Is this ok [y/N]: y
Downloading Packages:
(1/13): compat-libcap1-1.10-1.x86_64.rpm                               |  17 kB     00:00
...
(13/13): xorg-x11-xauth-1.0.2-7.1.el6.x86_64.rpm                       |  34 kB     00:00
-----------------------------------------------------------------------------------------
Total                                                         1.7 MB/s | 7.5 MB     00:04
..
Running Transaction
  Installing : libstdc++-devel-4.4.7-11.el6.x86_64                                   1/13
..
  Installing : oracle-rdbms-server-12cR1-preinstall-1.0-13.el6.x86_64               13/13
  Verifying  : compat-libcap1-1.10-1.x86_64                                          1/13
..
  Verifying  : libXmu-1.1.1-2.el6.x86_64                                            13/13

Installed:
  oracle-rdbms-server-12cR1-preinstall.x86_64 0:1.0-13.el6

Dependency Installed:
  compat-libcap1.x86_64 0:1.10-1        compat-libstdc++-33.x86_64 0:3.2.3-69.el6
  gcc-c++.x86_64 0:4.4.7-11.el6
  ksh.x86_64 0:20120801-21.el6_6.3      libXmu.x86_64 0:1.1.1-2.el6
  libXxf86dga.x86_64 0:1.1.4-2.1.el6
  libXxf86misc.x86_64 0:1.0.3-4.el6     libaio-devel.x86_64 0:0.3.107-10.el6
  libdmx.x86_64 0:1.1.3-3.el6
  libstdc++-devel.x86_64 0:4.4.7-11.el6 xorg-x11-utils.x86_64 0:7.5-6.el6
  xorg-x11-xauth.x86_64 1:1.0.2-7.1.el6

Complete!

The output for this RPM installation spans pages of output. For the complete output, visit the following URL: http://www.dbaexpert.com/blog/oracle-rdbms-server-12cr1-preinstall/. For Linux servers that house Oracle Database 11g Release 2 on RHEL (a recompile from the source RPM is required) or OL, you should leverage the oracle-rdbms-server-11gR2-preinstall RPM:

# yum install oracle-rdbms-server-11gR2-preinstall

Starting from Oracle Database 11g Release 2, you no longer use the Oracle-validated install; leverage the new oracle-rdbms-server-11gR2-preinstall instead. The Oracle 12c RDBMS PreInstall RPM also modifies the kernel parameters in the /etc/sysctl.conf kernel configuration file. The following entries are added:

# oracle-rdbms-server-12cR1-preinstall setting for fs.file-max is 6815744
fs.file-max = 6815744

# oracle-rdbms-server-12cR1-preinstall setting for kernel.sem is ’250 32000 100 128’
kernel.sem = 250 32000 100 128

# oracle-rdbms-server-12cR1-preinstall setting for kernel.shmmni is 4096
kernel.shmmni = 4096

# oracle-rdbms-server-12cR1-preinstall setting for kernel.shmall is 1073741824 on x86_64

# oracle-rdbms-server-12cR1-preinstall setting for kernel.shmmax is 4398046511104 on x86_64
kernel.shmmax = 4398046511104

# oracle-rdbms-server-12cR1-preinstall setting for kernel.panic_on_oops is 1 per Orabug 19642132
kernel.panic_on_oops = 1

# oracle-rdbms-server-12cR1-preinstall setting for net.core.rmem_default is 262144
net.core.rmem_default = 262144

# oracle-rdbms-server-12cR1-preinstall setting for net.core.rmem_max is 4194304
net.core.rmem_max = 4194304

# oracle-rdbms-server-12cR1-preinstall setting for net.core.wmem_default is 262144
net.core.wmem_default = 262144

# oracle-rdbms-server-12cR1-preinstall setting for net.core.wmem_max is 1048576
net.core.wmem_max = 1048576

# oracle-rdbms-server-12cR1-preinstall setting for fs.aio-max-nr is 1048576
fs.aio-max-nr = 1048576

# oracle-rdbms-server-12cR1-preinstall setting for net.ipv4.ip_local_port_range is 9000 65500
net.ipv4.ip_local_port_range = 9000 65500

In addition, the preinstall RPM process adjusts the /etc/passwd file to include the oracle user and creates the /home/oracle directory:

oracle:x:54321:54321::/home/oracle:/bin/bash

Furthermore, entries for dba and oinstall are added to the /etc/group file:

oinstall:x:54321:
dba:x:54322:oracle

How It Works

After Linux is installed and the system is released to the DBAs, you have to quickly configure the Linux server for database software provisioning. If the server is installed with OL 6, you can leverage the oracle-rdbms-server-12cR1-preinstall RPM directly from the public YUM repository. Many DBAs don’t realize that the Oracle RDBMS 11g/12c PreInstall RPM installation option exists. With the oracle-rdbms-server-12cR1-preinstall RPM, you can install required packages required by the Oracle Universal Installer with a single command. Executing the command can prepare a majority of your Linux server requirements to install Oracle Database Server, such as the following:

• The user oracle and the groups oinstall (software owner) and dba (for OSDBA), which are used during database installation, are created
• Kernel parameters are modified in /etc/sysctl.conf for shared memory such as semaphores, the maximum number of file descriptors, and so on
• Settings for hard and soft shell resource limits are made in ./etc/security/limits.conf such as the locked-in memory address space, the number of open files, the number of processes, and core file size
• Non-Uniform Memory Access (NUMA) and Transparent Huge Pages (THP) are also disabled in the /etc/grub.conf configuration file

Having Oracle RDBMS Server PreInstall RPM for OL is one the biggest benefits of adopting OL from RHEL or other Linux distributions. With a single command, you can preconfigure the OL environment for OEM 12c Agent, EBS R12, and Oracle Database 11gR2/12c installations. Not only does Oracle configure the Linux environment but many of the best practices are also incorporated in the process.

For Oracle RDBMS Server PreInstall RPMs for Oracle Database 11g Release 2 and Oracle Database 12c Release 1, you can download them from the latest channel of the public-yum repository: http://public-yum.oracle.com/repo/OracleLinux/OL6/latest/x86_64/. You have to scroll down quite a bit; the RPMs that start with capital letters are listed above RPMs that have lowercase letters.

You can also download PreInstall RPMs for Oracle EBS R12 and OEM Agent 12c from the addons channel from the public-yum repository. Oracle provides a separate RPM for each release of OEM 12c. Please visit the following URL for the latest versions of oracle-ebs-server-R12-preinstall-1.0-7.el6.x86_64.rpm and oracle-em-agent-12cR4-preinstall-1.0-7.el6.x86_64.rpm RPMs: http://public-yum.oracle.com/repo/OracleLinux/OL6/addons/x86_64/.

Lots of DBAs aren’t aware that Oracle also provides the source RPMs for each of the preinstall RPMs. For example, you can download the source RPM for the oracle-rdbms-server-12cR1-preinstall.rpm file. The file will be called oracle-rdbms-server-12cR1-preinstall.src.rpm and will exist in the same URL location as other RPMS.

11-7. Upgrading Packages

Problem

You realize that you have older versions of software components. You want to upgrade some of the older packages to the newest release.

Solution #1

To upgrade an existing package and all the dependent packages, you can execute the yum command with the update option:

# yum update perl

Solution #2

To upgrade an existing package, you can execute rpm with the -Uhv option (or --upgrade). For this particular solution, you’ll upgrade the perl RPM. Execute the rpm executable with the -Uhv option to upgrade the perl package:

# rpm -Uhv perl-5.8.8-10.0.1.el5_2.3.i386.rpm
Preparing...                ########################################### [100%]
   1:perl                   ########################################### [100%]

How It Works

The yum command with the update option is the best option for upgrading packages on the Linux server. The update option installs the latest version of a package or group of packages. If you don’t provide the package name(s), yum will attempt to upgrade all the packages. To remove and replace just the obsoleted packages, provide the --obsoletes option.

Optionally, you can upgrade an existing package with the -Uhv option. Behind the scenes, the original package will be removed, and the new package will be installed. The original configuration file will remain but will be renamed with the .rpmsave extension. Because the -U option removes and installs the package(s), you can also use the -U option to install packages. If the package doesn’t exist, the package(s) will be installed.

11-8. Removing Packages

Problem

You want to remove a package from the Linux server.

Solution #1

The preferred method of removing a package is by leveraging the yum command with the erase option. To remove the screen package without a prompt, you can execute the following syntax:

# yum -y erase screen
Loaded plugins: product-id, subscription-manager
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
Setting up Remove Process
Resolving Dependencies
--> Running transaction check
---> Package screen.x86_64 0:4.0.3-16.el6 will be erased
--> Finished Dependency Resolution

Dependencies Resolved

=========================================================================================
 Package          Arch             Version                  Repository               Size
=========================================================================================
Removing:
 screen           x86_64           4.0.3-16.el6             @viscosity              795 k

Transaction Summary
=========================================================================================
Remove        1 Package(s)

Installed size: 795 k
Downloading Packages:
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Erasing    : screen-4.0.3-16.el6.x86_64                                            1/1
  Verifying  : screen-4.0.3-16.el6.x86_64                                            1/1

Removed:
  screen.x86_64 0:4.0.3-16.el6

Complete!

Solution #2

Another way to remove a package is to execute the rpm command with the -e option (or --erase). To remove the screen package, you can execute the following syntax:

rpm -e screen

How It Works

Similar to package installation, software can be removed from the server with the yum command using the erase option. The remove option is an alias to the erase option. The yum erase command will uninstall any packages as well as dependent packages. You can also uninstall a package group such as a Web Server or X Window System with the yum remove command.

Software can also be removed from the server with the rpm command with the -e option. You must provide the installed package name as the second parameter; don’t provide the package file name. The example in the solution removes the screen package from the system. You’ll often not be able to remove an RPM because of dependency requirements; you have to know the dependency order to remove the designated RPM. Although we don’t recommend it, you can avoid the dependency check with the --nodeps option.

11-9. Checking RPM Requirements to Install Oracle Database

Problem

Make sure that your database software installation goes as smoothly as possible. Check to see whether the Linux server has the required list of packages specified by Oracle to install Oracle Database 12c.

Solution

You can execute the following short code snippets called rpm6.ksh (for RHEL/OL 6) and rpm7.ksh (for RHEL/OL 7) to quickly see whether the Linux server complies with the package requirements required to install and configure a database:

$ cat rpm6.ksh
rpm -q --queryformat "%{NAME}-%{VERSION}.%{RELEASE} (%{ARCH})
" 
binutils compat-libcap1 compat-libstdc++-33 gcc gcc-c++ glibc glibc-devel 
ksh libgcc libstdc++ libstdc++-devel libaio libaio-devel 
libXext libXtst libX11 libXau libxcb libXi make sysstat  
unixODBC unixODBC-devel

$ cat rpm7.ksh
rpm -q --queryformat "%{NAME}-%{VERSION}.%{RELEASE} (%{ARCH})
" 
binutils compat-libcap1 gcc gcc-c++ glibc glibc-devel ksh 
libaio libaio-devel libgcc libstdc++ libstdc++-devel libXi libXtst 
make sysstat unixODBC unixODBC-devel

We recommend that the screen RPM be included in every Oracle server, just as Oracle ASMLIB libraries should be part of every server installation. Executing an RPM check with the rpm6.ksh script against an OL 6.6 server yields the following results:

$ ./rpm6.ksh
binutils-2.20.51.0.2.5.42.el6 (x86_64)
compat-libcap1-1.10.1 (x86_64)
compat-libstdc++-33-3.2.3.69.el6 (x86_64)
gcc-4.4.7.11.el6 (x86_64)
gcc-c++-4.4.7.11.el6 (x86_64)
glibc-2.12.1.149.el6 (x86_64)
glibc-devel-2.12.1.149.el6 (x86_64)
ksh-20120801.21.el6_6.3 (x86_64)
libgcc-4.4.7.11.el6 (x86_64)
libstdc++-4.4.7.11.el6 (x86_64)
libstdc++-devel-4.4.7.11.el6 (x86_64)
libaio-0.3.107.10.el6 (x86_64)
libaio-devel-0.3.107.10.el6 (x86_64)
libXext-1.3.2.2.1.el6 (x86_64)
libXtst-1.2.2.2.1.el6 (x86_64)
libX11-1.6.0.2.2.el6 (x86_64)
libXau-1.0.6.4.el6 (x86_64)
libxcb-1.9.1.2.el6 (x86_64)
libXi-1.7.2.2.2.el6 (x86_64)
make-3.81.20.el6 (x86_64)
sysstat-9.0.4.27.el6 (x86_64)
package unixODBC is not installed
package unixODBC-devel is not installed

How It Works

Because you plan to run Oracle databases on a 64-bit Linux OS, check for both 32-bit and 64-bit packages. For example, you have to install both 32-bit and 64-bit components of the compat-db package. You can specify the -qf option (or --queryformat) followed by format options to manipulate the output display. The query string format consists of static strings similar to the printf syntax.

In this solution, the "%{NAME}-%{VERSION}.%{RELEASE} (%{ARCH}) " format is specified to display the architecture. If the output displays (x86_64), you can confirm that the 64-bit package is installed. If the output displays (i386), you have confirmation that the 32-bit version of the package is installed. Here’s the complete RPM requirement for Oracle Database 12c on RHEL and OL 6 and 7: http://www.dbaexpert.com/blog/rpm-requirement-on-red-hat-and-oracle-linux-6-and-7-for-oracle-database-12c-release-1/.

You still have to review the output from the provided scripts to ensure that the output meets or exceeds the level of the package expected. The primary purpose of this script is to provide a single consolidated output to review the RPMs, compared with what is required by Oracle to successfully install Oracle Database 12c.

11-10. Performing Initial Silent Oracle Software Installation with Response Files

Problem

You want to perform an initial install of the Oracle binaries on a new server. You suspect that the network bandwidth will cause issues when trying to run the graphical installer. You want to do a silent install of the Oracle binaries with a response file.

On another note, you want to reduce the amount of time needed to install Oracle Database 12c. You want to automate the installation procedures by performing the installation with the silent option.

Solution #1

In this solution, only Oracle software binaries are installed to the designated target Oracle Home directory. This solution assumes that you have successfully downloaded, copied, and unbundled the Oracle installation software on your database server. After unbundling the installation software, you should see a directory named response in the database directory.

First, change the directory to the response directory and list the files. You should see several response files:

dbca.rsp  db_install.rsp  netca.rsp

For this solution, you’re interested in the db_install.rsp response file to perform a silent installation of the Oracle Database 12c software stack. Before you manipulate this response file, make a backup copy of the file. Open the db_install.rsp response file with an editor such as vi and provide valid values for your environment for various variables within the response file. In this example, the response file is called 12c_db.rsp and is placed in the /tmp directory. Little over a dozen parameters were modified because you’re interested only in installing the software; you don’t want to create a database with the installation. In a typical new implementation, you’ll install Oracle Database 12c and apply the latest PSU. You’ll want to create the database after the PSU is applied.

Let’s review the contents of the response file to install the Oracle Database Software. You’ll filter out all comments and blank lines of the response file with the egrep command. Then you’ll perform another level of filtering and look only at lines that have a value associated after the equal sign. Using the following one–liner code example, you can review all the pertinent variables to the db_install.rsp response file:

$ egrep -v "^#|^$" db_install.rsp |awk -F"=" ’{if ($2)print $1"=" $2}’
oracle.install.responseFileVersion=/oracle/install/rspfmt_dbinstall_response_schema_v12.1.0
oracle.install.option=INSTALL_DB_SWONLY
ORACLE_HOSTNAME=dal66a
UNIX_GROUP_NAME=oinstall
INVENTORY_LOCATION=/u01/app/oraInventory
SELECTED_LANGUAGES=en
ORACLE_HOME=/u01/app/oracle/product/12.1.0.2/dbhome_1
ORACLE_BASE=/u01/app/oracle
oracle.install.db.InstallEdition=EE
oracle.install.db.DBA_GROUP=dba
oracle.install.db.OPER_GROUP=dba
oracle.install.db.BACKUPDBA_GROUP=dba
oracle.install.db.DGDBA_GROUP=dba
oracle.install.db.KMDBA_GROUP=dba
SECURITY_UPDATES_VIA_MYORACLESUPPORT=false
DECLINE_SECURITY_UPDATES=true

The first parameter to review is the oracle.install_ option. This parameter accepts three values: INSTALL_DB_SWONLY, INSTALL_DB_AND_CONFIG, and UPGRADE_DB. You’ll look at INSTALL_DB_SWONLY in this solution to install only the software.

UNIX_GROUP_NAME is usually either dba or oinstall. Depending on the level of delineation you want among various support organizations, you can opt to have different groups. For example, you can create a special Linux group in the /etc/group file have the backup team assigned to this group, and assign this group to the BACKUPDBA_GROUP.

ORACLE_HOSTNAME should be the local hostname on which the installation will occur. The ORACLE_HOME directory must point to the directory location in which you want the Oracle software to be installed, and it should be a directory in which the oracle account has write access. The ORACLE_HOME variable will match the value in the oratab file (usually located in the /etc directory) for your installation. The oratab file contains entries for databases that run locally on the server.

Each line of the oratab file consists of three parameters: database name, database software location (also known as ORACLE_HOME), and startup flag. The last parameter plays a significant role in automating database startups. If the value of the last parameter is set to Y, the dbstart shell script located in the $ORACLE_HOME/bin directory will include the database to start when the server reboots. The ORACLE_HOME_NAME is a unique name for the software home of this installation.

The oracle.install.db.InstallEdition has an option only for the Enterprise Edition (EE). In previous releases, you can specify whether the installation was for the Standard Editor or EE, but because you downloaded the EE software, the response file has this parameter prepopulated with the value of EE.

Set your directory to the database directory (the directory to which the downloaded zip files will extract). In this directory, you’ll find the runInstaller executable. The response directory is a subdirectory of this directory. Now you can install the binaries by executing the runInstaller with the following command-line syntax:

$ ./runInstaller -silent -responseFile /tmp/db_install.rsp
Starting Oracle Universal Installer...

Checking Temp space: must be greater than 500 MB.   Actual 3674 MB    Passed
Checking swap space: must be greater than 150 MB.   Actual 4095 MB    Passed
Preparing to launch Oracle Universal Installer from /tmp/OraInstall2015-05-16_12-53-14PM. Please wait ...[oracle@dal66a database]$ You can find the log of this install session at:
 /u01/app/oraInventory/logs/installActions2015-05-16_12-53-14PM.log
The installation of Oracle Database 12c was successful.
Please check ’/u01/app/oraInventory/logs/silentInstall2015-05-16_12-53-14PM.log’ for more details.

As a root user, execute the following script(s):
      1. /u01/app/oraInventory/orainstRoot.sh
      2. /u01/app/oracle/product/12.1.0.2/dbhome_1/root.sh

Successfully Setup Software.

Once the installation completes successfully, as root execute both the orainstRoot.sh and root.sh scripts. In this example, the orainstRoot.sh script resides in the /u01/app/oraInventory directory, and the root.sh script resides in the /u01/app/oracle/product/12.1.0/dbhome_1 directory:

$ sudo /u01/app/oraInventory/orainstRoot.sh

Changing permissions of /u01/app/oraInventory.
Adding read,write permissions for group.
Removing read,write,execute permissions for world.

Changing groupname of /u01/app/oraInventory to oinstall.
The execution of the script is complete.

$ sudo /u01/app/oracle/product/12.1.0.2/dbhome_1/root.sh
Check /u01/app/oracle/product/12.1.0.2/dbhome_1/install/root_dal66a_2015-05-16_13-22-19.log for the output of root script

You can now start using this new installation of the Oracle software and create a database.

Solution #2

In this solution, you’ll install the Oracle software binaries to the designated target Oracle Home directory and also create a database so that you can get a kick start into Oracle development and deployment. This solution assumes that you have successfully uploaded and unbundled the Oracle install software on your database server.

You’ll manipulate the same db_install.rsp response file as in Solution #1, except you’ll also input values for the Database Configuration Options section and change the oracle.install.option to INSTALL_DB_AND_CONFIG from INSTALL_DB_SWONLY. All the parameters needed to create the database in the Database Configuration Options start with oracle.install.db.xxxxxx.

Let’s review a sample response file that was manipulated to install Oracle Database 12c software and to create a database called DBATOOLS to the /oradata1 filesystem:

$ egrep -v "^#|^$" 12c_db_with_database.rsp |awk -F"=" ’{if ($2)print $1"=" $2}’
oracle.install.responseFileVersion=/oracle/install/rspfmt_dbinstall_response_schema_v12.1.0
oracle.install.option=INSTALL_DB_AND_CONFIG
ORACLE_HOSTNAME=dal66a
UNIX_GROUP_NAME=oinstall
INVENTORY_LOCATION=/u01/app/oraInventory
SELECTED_LANGUAGES=en
ORACLE_HOME=/u01/app/oracle/product/12.1.0/dbhome_2
ORACLE_BASE=/u01/app/oracle
oracle.install.db.InstallEdition=EE
oracle.install.db.DBA_GROUP=dba
oracle.install.db.OPER_GROUP=dba
oracle.install.db.BACKUPDBA_GROUP=dba
oracle.install.db.DGDBA_GROUP=dba
oracle.install.db.KMDBA_GROUP=dba
oracle.install.db.config.starterdb.type=GENERAL_PURPOSE
oracle.install.db.config.starterdb.globalDBName=DBATOOLS
oracle.install.db.config.starterdb.SID=DBATOOLS
oracle.install.db.ConfigureAsContainerDB=true
oracle.install.db.config.PDBName=vna01
oracle.install.db.config.starterdb.characterSet=WE8MSWIN1252
oracle.install.db.config.starterdb.memoryOption=false
oracle.install.db.config.starterdb.memoryLimit=1024
oracle.install.db.config.starterdb.installExampleSchemas=false
oracle.install.db.config.starterdb.password.ALL=oracle123
oracle.install.db.config.starterdb.password.SYS=oracle123
oracle.install.db.config.starterdb.password.SYSTEM=oracle123
oracle.install.db.config.starterdb.password.DBSNMP=oracle123
oracle.install.db.config.starterdb.password.PDBADMIN=oracle123
oracle.install.db.config.starterdb.managementOption=DEFAULT
oracle.install.db.config.starterdb.enableRecovery=true
oracle.install.db.config.starterdb.storageType=FILE_SYSTEM_STORAGE
oracle.install.db.config.starterdb.fileSystemStorage.dataLocation=/oradata1
oracle.install.db.config.starterdb.fileSystemStorage.recoveryLocation=/oradata1
SECURITY_UPDATES_VIA_MYORACLESUPPORT=false
DECLINE_SECURITY_UPDATES=true

Invoking the runInstaller command in silent mode and providing the configuration file mentioned previously produce the following results:

$ ./runInstaller -silent -responseFile /tmp/12c_db_with_database.rsp
Starting Oracle Universal Installer...

Checking Temp space: must be greater than 500 MB.   Actual 3665 MB    Passed
Checking swap space: must be greater than 150 MB.   Actual 4095 MB    Passed
Preparing to launch Oracle Universal Installer from /tmp/OraInstall2015-05-16_01-44-57PM. Please wait ...[oracle@dal66a database]$ [WARNING] [INS-30011] The ADMIN password entered does not conform to the Oracle recommended standards.
   CAUSE: Oracle recommends that the password entered should be at least 8 characters in length, contain at least 1 uppercase character, 1 lower case character and 1 digit [0-9].
   ACTION: Provide a password that conforms to the Oracle recommended standards.
You can find the log of this install session at:
 /u01/app/oraInventory/logs/installActions2015-05-16_01-44-57PM.log
The installation of Oracle Database 12c was successful.
Please check ’/u01/app/oraInventory/logs/silentInstall2015-05-16_01-44-57PM.log’ for more details.

As a root user, execute the following script(s):
      1. /u01/app/oraInventory/orainstRoot.sh
      2. /u01/app/oracle/product/12.1.0/dbhome_2/root.sh

Successfully Setup Software.
As install user, execute the following script to complete the configuration.
      1. /u01/app/oracle/product/12.1.0/dbhome_2/cfgtoollogs/configToolAllCommands RESPONSE_FILE=<response_file>

      Note:
      1. This script must be run on the same host from where installer was run.
      2. This script needs a small password properties file for configuration assistants that require passwords (refer to install guide documentation).

As you can see, the output looks very similar to the output in Solution #1. The primary difference in this output is that you are prompted to execute the $ORACLE_HOME/cfgtoollogs/configToolsAllCommands script with the response file name as an input parameter. The response file that is being requested is not the same as the response file used for the software installation; it is a small password properties file. The db_install.rsp response file doesn’t store any passwords, but the actual installation does prompt you for passwords for SYS, SYSTEM, DBSNMP, PDBADMIN, EMADMIN, and ASMSNMP users to configure the database.

Here’s a sample password properties file needed to configure the database deployment with passwords for the SYS, SYSTEM, DBSNMP, PDBADMIN, EMADMIN, and ASMSNMP accounts:

$ cat cfgrsp.properties
oracle.assistants.server|S_SYSPASSWORD=oracle123
oracle.assistants.server|S_SYSTEMPASSWORD=oracle123
oracle.assistants.server|S_DBSNMPPASSWORD=oracle123
oracle.assistants.server|S_PDBADMINPASSWORD=oracle123
oracle.assistants.server|S_EMADMINPASSWORD=oracle123
oracle.assistants.server|S_ASMSNMPPASSWORD=oracle123

The output to the configToolAllCommands with the password property file is rather verbose and lengthy. Here’s a section of the generated output:

$ /u01/app/oracle/product/12.1.0/dbhome_2/cfgtoollogs/configToolAllCommands RESPONSE_FILE=/home/oracle/cfgrsp.properties
Setting the invPtrLoc to /u01/app/oracle/product/12.1.0/dbhome_2/oraInst.loc

perform - mode is starting for action: configure

May 16, 2015 1:51:21 PM oracle.install.config.common.NetCAInternalPlugIn invoke
INFO: NetCAInternalPlugIn: ... adding </ouiinternal>
May 16, 2015 1:51:21 PM oracle.install.driver.oui.config.GenericInternalPlugIn invoke
INFO: Executing NETCA
May 16, 2015 1:51:21 PM oracle.install.driver.oui.config.GenericInternalPlugIn invoke
INFO: Command /u01/app/oracle/product/12.1.0/dbhome_2/bin/netca /orahome /u01/app/oracle/product/12.1.0/dbhome_2 /orahnam OraDB12Home1 /instype typical /inscomp client,oraclenet,javavm,server,ano /insprtcl tcp /cfg local /authadp NO_VALUE /responseFile /u01/app/oracle/product/12.1.0/dbhome_2/network/install/netca_typ.rsp /silent  /silent   /ouiinternal May 16, 2015 1:51:21 PM
...
...
...

oracle.install.driver.oui.config.GenericInternalPlugIn handleProcess
INFO: Read: 78% complete
May 16, 2015 2:00:17 PM oracle.install.driver.oui.config.GenericInternalPlugIn handleProcess
WARNING: Skipping line: 78% complete
May 16, 2015 2:00:17 PM oracle.install.driver.oui.config.GenericInternalPlugIn handleProcess
INFO: Read: 100% complete
May 16, 2015 2:00:17 PM oracle.install.driver.oui.config.GenericInternalPlugIn handleProcess
WARNING: Skipping line: 100% complete
May 16, 2015 2:00:17 PM oracle.install.driver.oui.config.GenericInternalPlugIn handleProcess
INFO: Read: Look at the log file "/u01/app/oracle/cfgtoollogs/dbca/DBATOOLS/DBATOOLS.log" for further details.
May 16, 2015 2:00:17 PM oracle.install.driver.oui.config.GenericInternalPlugIn handleProcess
WARNING: Skipping line: Look at the log file "/u01/app/oracle/cfgtoollogs/dbca/DBATOOLS/DBATOOLS.log" for further details.

perform - mode finished for action: configure

You can see the log file: /u01/app/oracle/product/12.1.0/dbhome_2/cfgtoollogs/oui/configActions2015-05-16_01-51-20-PM.log

As a final validation, you have to review the log file and check to see whether the database is running. First, review the configuration tools log file to confirm that you have reached 100% progress for DBCA:

$ cat /u01/app/oracle/cfgtoollogs/dbca/DBATOOLS/DBATOOLS.log

Unique database identifier check passed.

/oradata1/ has enough space. Required space is 7665 MB , available space is 61030 MB.
File Validations Successful.
Copying database files
DBCA_PROGRESS : 1%
DBCA_PROGRESS : 2%
DBCA_PROGRESS : 27%
Creating and starting Oracle instance
..
Completing Database Creation
..
Creating Pluggable Databases
DBCA_PROGRESS : 78%
DBCA_PROGRESS : 100%
Database creation complete. For details check the logfiles at:
 /u01/app/oracle/cfgtoollogs/dbca/DBATOOLS.
Database Information:
Global Database Name:DBATOOLS
System Identifier(SID):DBATOOLS

You can perform a couple of basic health checks to validate that the DBATOOLS database is running and the database listener is up by checking on the PMON process and the database listener process. With the ps command, you can filter on the process listing for the keywords pmon and tns, separated by a pipe to denote that you’re looking for both conditions with the egrep command.

You can also introduce a grep command with a –v option to ignore output that has the word grep in the list, as shown here:

$ ps -ef |egrep “pmon|tns” |grep -v grep
oracle    8357     1  0 13:59 ?        00:00:00 ora_pmon_DBATOOLS
root        15     2  0 13:27 ?        00:00:00 [netns]
oracle    7486     1  0 13:51 ?        00:00:00 /u01/app/oracle/product/12.1.0/dbhome_2/bin/tnslsnr LISTENER -inherit

How It Works

Using a response file allows you to fully automate the installation and configuration of Oracle software. The Oracle Universal Installer reads the values you specify in the response file to perform the installation. This technique is desirable in several scenarios. For example, if you often perform remote installs across a WAN with limited bandwidth, using the graphical installer may not be an option (because of extremely slow response times and network hangups).

You can easily customize the response file for database options required for your environment. You can then reuse the same response file for future installations. The silent installation technique allows you to perform repeatable and standardized Oracle installations and even upgrades. You can document the exact steps required and have junior DBAs and/or SAs install the oracle binaries using a response file.

As a surprise to some DBAs, you can create your own custom response file with the runInstaller program and the -record option. In essence, your selections during the runInstaller session will be recorded into the specified response file name. The syntax to create a custom response file looks like this:

./runInstaller -record -destinationFile /tmp/custom_db_install.rsp

The -destinationFile option specifies the location of the target response file. You don’t have to actually perform an install to create a response file. As long as you navigate to the Summary screen of the installation process, the response file will be created.

Make sure that the value you specify for ORACLE_HOME doesn’t conflict with an already existing home in the oraInst.loc file. This file is usually located in the /etc directory. For ORACLE_HOME_NAME, review the contents of the inventory.xml file located in the OraInventory subdirectory, which is usually located in the $ORACLE_BASE/../oraInventory/ContentsXML directory (i.e., /u01/app/oraInventory/ContentsXML directory).

11-11. Creating a Database with a Response File

Problem

You can’t launch the DBCA in GUI mode because your network connectivity is extremely slow or because you are behind multiple firewalls in an extremely secure data center. You want to create a database with the DBCA in silent mode.

You want to automate your database builds and to build databases with consistent configurations and initialization parameters.

Solution

The good news is that you can create a database in silent mode after you modify the dbca.rsp response file to your desired configuration. This particular solution demonstrates the simplicity of creating a database after modifying a minimal number of parameters in the dbca.rsp response file. At a minimum, the parameters OPERATION_TYPE, GDBNAME, SID, TEMPLATE_NAME, SYSPASSWORD, SYSTEMPASSWORD, DATAFILEDESTINATION, STORAGETYPE, CHARACTERSET, and NATIONALCHARACTERSET should be modified.

Oracle Database 12c has the multitenancy option to create pluggable databases (PDBs). You can enable PDBs by setting the CREATEASCONTAINERDATABASES to yes and then specifying the NUMBEROFPDBS, PDBPREFIX, and PDBADMINPASSWORD parameters. In this example, all the previously mentioned parameters in the dbca.rsp file were modified after the original file was backed up to dbca.rsp.BKUP.

Here’s a sample dbca.rsp response file in the /tmp directory that has been manipulated to create a database called TOOLSDEV with two pluggable databases. To reveal just the modified responses, leverage the egrep command with the –v option to ignore all lines that start with a comment and blank lines:

$ cat /tmp/dbca.rsp |egrep -v "^#|^$"
[GENERAL]
RESPONSEFILE_VERSION = "12.1.0"
OPERATION_TYPE = "createDatabase"
[CREATEDATABASE]
GDBNAME = "TOOLSDEV"
SID = "TOOLSDEV"
CREATEASCONTAINERDATABASE =yes
NUMBEROFPDBS =2
PDBNAME =vna
PDBADMINPASSWORD = "oracle123"
TEMPLATENAME = "General_Purpose.dbc"
SYSPASSWORD = "oracle123"
SYSTEMPASSWORD = "oracle123"
EMCONFIGURATION = "NONE"
DATAFILEDESTINATION =/oradata1
RECOVERYAREADESTINATION=/oradata1
STORAGETYPE=FS
CHARACTERSET = "AL32UTF8"
NATIONALCHARACTERSET= "AL16UTF16"
DATABASETYPE = "MULTIPURPOSE"
AUTOMATICMEMORYMANAGEMENT = "FALSE"
TOTALMEMORY = "1024"

Because the software is already installed, you have to launch dbca in silent mode from $ORACLE_HOME/bin directory. In this solution, dbca is launched with the -silent parameter and the -responseFile parameter, followed by the location of the response file:

 $ dbca -silent -responseFile /tmp/dbca.rsp
Cleaning up failed steps
5% complete
Copying database files
7% complete
9% complete
41% complete
Creating and starting Oracle instance
43% complete
48% complete
53% complete
57% complete
58% complete
59% complete
62% complete
64% complete
Completing Database Creation
68% complete
71% complete
75% complete
85% complete
96% complete
100% complete
Look at the log file "/u01/app/oracle/cfgtoollogs/dbca/TOOLSDEV/TOOLSDEV0.log" for further details.

In silent mode, dbca provides a progress status to notify you where it is in the database-creation process. During the initial phase, RMAN performs a restore of the data files. Once the restore is complete, dbca creates and starts the instance. Finally, post–database configuration steps are executed.

After the database is created, you can view the log file in the $ORACLE_BASE/cfgtoollogs/dbca/$ORACLE_SID directory. You’ll also notice an entry in the /etc/oratab file for the new database named TOOLSDEV:

TOOLSDEV:/apps/oracle/product/11.1.0/DB:N

How It Works

Nowadays, creating databases with the DBCA is standard in many organizations. Many DBAs launch the DBCA and configure databases in GUI mode, but a few exploit the options available to them using the response file. By effectively leveraging DBCA with the silent option, you can automate database creation and create databases consistently across the organization. You can modify the dbca.rsp file to build databases on ASM and even create RAC databases. You can control almost every aspect of the response file similar to launching the DBCA in GUI mode. Your DBA organization should seriously consider standardizing on creating databases in silent mode using the dbca.rsp response file.

You can also leverage DBCA without a response file and fully supply all the parameters to create databases. The following dbca code example creates a general-purpose database called oraprod on the /oradata01 filesystem with the recovery area destination to the /fra01 filesystem. We’re also creating redo logs that are 500MB in size and multiplexing the redo logs across the /oradata01 and /fra01 filesystems. We have disabled Enterprise Manager Express configuration in favor of the Oracle Enterprise Manager Cloud Control 12c configuration to be done in the future. We have set pertinent initialization parameters with the initparams parameters.

Here’s the dbca code example that creates a database, including setting pertinent initialization parameters:

./dbca -silent 
-createDatabase 
-templateName General_Purpose.dbc 
-gdbName oraprod 
-createAsContainerDatabase false 
-emConfiguration none 
-datafileDestination ’/oradata01’ 
-recoveryAreaDestination ’/fra01’ 
-storageType FS 
-sid oraprod 
-SysPassword oracle123 
-SystemPassword oracle123 
-emConfiguration none 
-redoLogFileSize 500 
-listeners LISTENER 
-registerWithDirService false 
-characterSet WE8ISO8859P1 
-nationalCharacterSet AL16UTF16 
-databaseType MULTIPURPOSE 
-initparams audit_file_dest=’/app/oracle/admin/oraprod/adump’ 
-initparams compatible=’12.1.0.2’ 
-initparams db_create_file_dest=’/oradata01’ 
-initparams db_create_online_log_dest_1=’/oradata01’ 
-initparams db_create_online_log_dest_2=’/fra01’ 
-initparams db_recovery_file_dest=’/fra01’ 
-initparams pga_aggregate_target=1024 
-initparams diagnostic_dest=’/app/oracle’ 
-initparams parallel_max_servers=20 
-initparams processes=500 
-initparams sga_target=10240 
-initparams control_files=’/oradata01/oraprod/control01.ctl’ 
-initparams db_recovery_file_dest_size=25000

11-12. Creating a Network Configuration with a Response File

Problem

You struggle to launch Oracle Network Configuration Assistant (NETCA) in GUI mode because your network connectivity is extremely slow or because you are behind multiple firewalls in an extremely secure data center. You want to create a database listener with NETCA in silent mode.

Solution

You can launch NETCA in silent mode by using a response file. Here’s a sample response file with modifications called netca.rsp:

$ cat /tmp/net.rsp
[GENERAL]
RESPONSEFILE_VERSION="12.1"
CREATE_TYPE= "CUSTOM"
LOG_FILE=“”/tmp/netca.log“”
[Session]
ORACLE_HOME="/u01/app/oracle/product/12.1.0/dbhome_2"
[oracle.net.ca]
INSTALLED_COMPONENTS={"server","net8","javavm"}
INSTALL_TYPE=“”custom“”
LISTENER_NUMBER=1
LISTENER_NAMES={"LISTENER"}
LISTENER_PROTOCOLS={"TCP;1521"}
LISTENER_START=“”
NAMING_METHODS={"LDAP","TNSNAMES","HOSTNAME"}
NSN_PROTOCOLS={"TCP;HOSTNAME;1521"}
NSN_NUMBER=3
NSN_NAMES={"DEV","DBATOOLS","RMANPROD"}
NSN_SERVICE = {"DEV","DBATOOLS","RMANPROD"}
NSN_PROTOCOLS={"TCP;rac5.dbaexpert.com;1521","TCP;rac6.dbaexpert.com;1521","TCP;rac7.dbaexpert.com;1521"}

Executing NETCA in silent mode and passing the modified response file /tmp/net.rsp yields the following output:

$ netca -silent -responseFile /tmp/net.rsp

Sun May 17 07:20:03 CDT 2015 Oracle Net Configuration Assistant
Parsing command line arguments:
    Parameter "silent" = true
    Parameter "responsefile" = /tmp/net.rsp
    Parameter "log" = /tmp/netca.log
Done parsing command line arguments.
Oracle Net Services Configuration:
Configuring Listener:LISTENER
Listener configuration complete.
Oracle Net Listener Startup:
    Running Listener Control:
      /u01/app/oracle/product/12.1.0/dbhome_2/bin/lsnrctl start LISTENER
    Listener Control complete.
    Listener started successfully.
Default local naming configuration complete.
    Created net service name: DEV
Default local naming configuration complete.
    Created net service name: DBATOOLS
Default local naming configuration complete.
    Created net service name: RMANPROD
Profile configuration complete.
Oracle Net Services configuration successful. The exit code is 0

Behind the scenes, NETCA created three files in the $ORACLE_HOME/network/admin directory: sqlnet.ora, tnsnames.ora, and listener.ora. The output to NETCA is logged in the /tmp/netca.log file.

How It Works

Although DBAs often don’t realize the potential of automation through response files, they can configure Oracle’s network topology in a single command by launching NETCA. With the proper standardization in directory structures and naming conventions, DBAs can script and manipulate the network configuration response files by leveraging executables such as awk and sed.

You can specify an alternate location for the netca log file by modifying the LOG_FILE parameter. Similar to the other silent installations, you must specify a valid ORACLE_HOME directory. The other portions of the netca response file that require explanation are the NSN_ parameters (NSN stands for number of service names). The parameter NSN_PROTOCOLS defines the protocol and associated parameters for each service name. The parameter NSN_NUMBER defines the number of service names to create. For this particular solution, the response file defines three service names to create in the tnsnames.ora file. The names of the TNSNAMES connect strings are defined to be DEV, RMANPROD, and DBATOOLS. All three of the TNSNAMES connect strings leverage service names. For this solution, you want every server to have entries for DBATOOLS and RMANPROD.

Here’s the contents of the tnsnames.ora file:

$ cat tnsnames.ora
# tnsnames.ora Network Configuration File: /u01/app/oracle/product/12.1.0/dbhome_2/network/admin/tnsnames.ora
# Generated by Oracle configuration tools.

RMANPROD =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = rac7.dbaexpert.com)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = RMANPROD)
    )
  )

DEV =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = rac5.dbaexpert.com)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = DEV)
    )
  )

DBATOOLS =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = rac6.dbaexpert.com)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = DBATOOLS)
    )
  )

Likewise, NETCA generated the following entries in the listener.ora file:

$ cat listener.ora
# listener.ora Network Configuration File: /u01/app/oracle/product/12.1.0/dbhome_2/network/admin/listener.ora
# Generated by Oracle configuration tools.

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = dal66a)(PORT = 1521))
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
    )
  )

Finally, NETCA produces the sqlnet.ora file, which contains this single entry to define the directory path:

NAMES.DIRECTORY_PATH= (LDAP, TNSNAMES, HOSTNAME)

11-13. Applying Patch Set Updates (PSUs) and Interim Patches

Problem

You have to apply a patch set update (PSU) or interim patches to resolve a database issue or eradicate a bug you encountered in your database.

Solution

Most of the time, applying a patch is simple with the opatch command-line interface, which accepts numerous arguments. The syntax for opatch is as follows:

$ ./opatch -help
Oracle Interim Patch Installer version 12.1.0.1.7
Copyright (c) 2015, Oracle Corporation. All rights reserved.

 Usage: opatch [ -help ] [ -report ] [ command ]

            command := apply
                   compare
                       lsinventory
                       lspatches
                       napply
                       nrollback
                       rollback
                       query
                       version
                       prereq
                       util

The most common supplied opatch arguments are these:

• apply
• lsinventory
• rollback
• version

Let’s take, for example, the April 2015 Patch 20299023—Database Patch Set Update 12.1.0.2.3 (includes CPUApr2015). You can download the patch file p20299023_121020_Linux-x86-64.zip to your download directory and extract the compressed archived file with the unzip command. If you want to see the contents of the .zip file without extracting the file, pass the -l argument to the unzip command. The unzip command will create a directory called 20299023 and extract all the files into the directory.

If this is the first PSU going on the Oracle Home, or if you have not patched in a while, you also have to download and apply patch 6880880, which happens to be the patch update for OPatch. You have to download patch 6880880 from support.oracle.com or follow the download link from https://updates.oracle.com/download/6880880.html.

This patch is extremely simple to apply. Simply download the patch, upload the zip file to your server, unzip the contents of the patch, and replace the contents of the $ORACLE_HOME/OPatch directory with the OPatch unzipped directory from this patch. If you are applying this patch for the Grid Infrastructure (GI) home, you must replace the contents of the OPatch directory as root.

For most patches, you can read the README.txt file located in the base directory of the patch, which has explicit directions on how to apply the patch. Although the majority of patches require a simple apply parameter, some patches have prerequisite and postpatch steps. Some patches may even require multiple dependent patches to be executed.

The README.txt file for PSUs will indicate that you have to read the README.html file. As a general rule, prior to applying any patch, the database must be shut down. Oracle does provide what is known as an online patch for which the database doesn’t have to be shut down for high availability considerations. You must examine the README.txt (or in this case, the README.html file) to see whether a particular patch qualifies as an online patch. Because this particular PSU requires the database to be shut down, you’ll incur an outage window to apply the patch.

The opatch executable is located in the $ORACLE_HOME/OPatch directory. The easiest way to apply a patch is to include the opatch executable to your PATH environment variable. To do so, simply export your PATH environment variable as $ORACLE_HOME/OPatch:$PATH.

The directory is already changed to 20299023. Based on the README.html file, you can apply this patch with the command opatch apply.

Here’s the OPatch process in action to apply this PSU:

$ opatch apply
Oracle Interim Patch Installer version 12.1.0.1.7
Copyright (c) 2015, Oracle Corporation.  All rights reserved.

Oracle Home       : /u01/app/oracle/product/12.1.0/dbhome_2
Central Inventory : /u01/app/oraInventory
   from           : /u01/app/oracle/product/12.1.0/dbhome_2/oraInst.loc
OPatch version    : 12.1.0.1.7
OUI version       : 12.1.0.2.0
Log file location : /u01/app/oracle/product/12.1.0/dbhome_2/cfgtoollogs/opatch/opatch2015-05-16_17-48-29PM_1.log

Verifying environment and performing prerequisite checks...
OPatch continues with these patches:   19769480  20299023

Do you want to proceed? [y|n]
y
User Responded with: Y
All checks passed.
Provide your email address to be informed of security issues, install and
initiate Oracle Configuration Manager. Easier for you if you use your My
Oracle Support Email address/User Name.
Visit http://www.oracle.com/support/policies.html for details.
Email address/User Name:

You have not provided an email address for notification of security issues.
Do you wish to remain uninformed of security issues ([Y]es, [N]o) [N]:  Y

Please shutdown Oracle instances running out of this ORACLE_HOME on the local system.
(Oracle Home = ’/u01/app/oracle/product/12.1.0/dbhome_2’)

Is the local system ready for patching? [y|n]
y
User Responded with: Y
Backing up files...
Applying sub-patch ’19769480’ to OH ’/u01/app/oracle/product/12.1.0/dbhome_2’

Patching component oracle.rdbms.deconfig, 12.1.0.2.0...
Patching component oracle.xdk, 12.1.0.2.0...
Patching component oracle.tfa, 12.1.0.2.0...
Patching component oracle.rdbms.util, 12.1.0.2.0...
Patching component oracle.rdbms, 12.1.0.2.0...
Patching component oracle.rdbms.dbscripts, 12.1.0.2.0...
Patching component oracle.xdk.parser.java, 12.1.0.2.0...
Patching component oracle.oraolap, 12.1.0.2.0...
Patching component oracle.xdk.rsf, 12.1.0.2.0...
Patching component oracle.rdbms.rsf, 12.1.0.2.0...
Patching component oracle.rdbms.rman, 12.1.0.2.0...
Patching component oracle.ldap.rsf, 12.1.0.2.0...
Patching component oracle.ldap.rsf.ic, 12.1.0.2.0...

Verifying the update...
Applying sub-patch ’20299023’ to OH ’/u01/app/oracle/product/12.1.0/dbhome_2’
ApplySession: Optional component(s) [ oracle.has.crs, 12.1.0.2.0 ]  not present in the Oracle Home or a higher version is found.

Patching component oracle.tfa, 12.1.0.2.0...
Patching component oracle.rdbms.deconfig, 12.1.0.2.0...
Patching component oracle.rdbms.rsf, 12.1.0.2.0...
Patching component oracle.rdbms, 12.1.0.2.0...
Patching component oracle.rdbms.dbscripts, 12.1.0.2.0...
Patching component oracle.rdbms.rsf.ic, 12.1.0.2.0...
Patching component oracle.ldap.rsf, 12.1.0.2.0...
Patching component oracle.ldap.rsf.ic, 12.1.0.2.0...

Verifying the update...
Composite patch 20299023 successfully applied.
Log file location: /u01/app/oracle/product/12.1.0/dbhome_2/cfgtoollogs/opatch/opatch2015-05-16_17-48-29PM_1.log

OPatch succeeded.

Now check the inventory to see whether the patch exists. To view the patch list, pass the lsinventory argument to the opatch command, as shown here:

[oracle@dal66a 20299023]$ opatch lsinventory |grep ^Patch
Patch  20299023  : applied on Sat May 16 17:49:12 CDT 2015
Patch description:  "Database Patch Set Update : 12.1.0.2.3 (20299023)"

In this inventory listing, you are filtering on the output and are looking for a line that starts with the word Patch to determine applied patches.

You can see from the output that 12.0.1.2.3 PSU is applied to the Oracle Home. You can execute the command opatch lsinventory -detail to produce a detailed output of all the patches.

You are not quite finished. You still have to perform the postpatch operations against each database that leverages this Oracle Home. In Oracle Database 11g with the PSU, the database is patched by executing the catbundle.sql SQL script:

SQL> @catbundle.sql psu apply

Starting in Oracle Database 12c, you have to execute the datapatch script from the $ORACLE_HOME/OPatch directory:

$ cd $ORACLE_HOME/OPatch
$ ./datapatch –verbose

datapatch replaces the need to execute the catbundle.sql script to apply the database portion of the database.

How It Works

OPatch is a collection of Perl scripts and Java classes providing the capability to apply and roll back PSUs and interim (one-off) patches to an Oracle database environment. opatch is the primary driver that calls the Perl modules and Java classes. Although the minimum perl requirement is 5.005_03, Oracle recommends the perl version to be at least 5.6 or greater. You can download OPatch from MetaLink from the Patches & Updates tab by performing a simple search on patchset 6880880. For additional information, please review MetaLink Note 224346.1.

OPatch requires a Java Runtime Environment (JRE) to be available on the Linux server. In addition, it has requirements for system commands such as jar, fuser, ar, and make on the Linux servers. Patch information and backups reside in the $ORACLE_HOME/.patch_storage/{patch_file} directory.

Just as you can install a patch with the apply parameter, you can uninstall a patch with the rollback parameter. The rollback parameter accepts an additional parameter, -id, to specify the patch number to roll back.

In this example, you roll back the same patch that was applied in the solution:

$ opatch rollback -id 20299023

Oracle offers a cumulative quarterly patch of the most critical fixes of known bugs and issues in PSUs. Customers are encouraged to apply PSUs to avoid many of the known problems. We recommend that customers apply N-1 on PSUs. For the month of April, customers should apply January’s PSUs. If your go-live date is far in the future, you can apply the most recent PSU.

Oracle provides its quarterly security patch updates (SPUs)—formerly known as critical patch updates (CPUs)—to address security vulnerabilities to the database and application server products. Nonsecurity patches are often included in the CPU because they are dependent patches. You probably receive e-mail updates telling you when they are available for download. We recommend that you closely scrutinize the quarterly SPUs and apply them in a timely manner.

11-14. Cloning an Oracle Home

Problem

You want to easily clone a fully patched Oracle software installation from one database server to another database server. You want the cloning process to be a simple zip and unzip of the software to a new server and to fully benefit from all the patches that were applied on the original server.

Solution

If you happen to be a DBA who still creates tar archives of the Oracle binaries, you can continue to, as the saying goes, have your cake and eat it too. It is much easier to copy the Oracle binaries than it is to install the software from the CD or unzipped media software, especially if the source Oracle software is fully patched with the latest release of Oracle PSUs/one-off patches or with a set of patches that has been fully vetted by the quality assurance (QA) team.

You can accomplish in one command what can take hours if you have slow WAN connectivity between your desktop and the Linux server. With one command, you can provide an Oracle software stack that is fully patched that might take you days to deliver if your Oracle Home has lots of patches installed. If you are not comfortable with the silent installation option, you also have to find an X server or VNC server to which you set the DISPLAY environment variable.

In this solution, you see how to clone an Oracle Home after you transfer the binaries from another server using the rcp/scp, tar, zip/unzip, or rsh/ssh command. First, set the ORACLE_HOME environment variable to the new directory you just copied over. For example, the ORACLE_HOME environment variable for this solution is set to /app/oracle/product/12.1.0.2/db. From the $ORACLE_HOME/clone/bin directory, execute the perl command as shown here to clone the Oracle Database Software to the new database server:

$ perl clone.pl ORACLE_HOME=/app/oracle/product/12.1.0.2/db ORACLE_HOME_NAME=12102_home_base ORACLE_BASE=/app/oracle/product -ignoreSysPrereqs -invPtrLoc /etc/oraInst.loc
./runInstaller -clone -waitForCompletion  "ORACLE_HOME=/app/oracle/product/12.1.0.2/db" "ORACLE_HOME_NAME=12102_home_base" "ORACLE_BASE=/app/oracle/product" -ignoreSysPrereqs  -invPtrLoc  /etc/oraInst.loc  -silent -paramFile /app/oracle/product/12.1.0.2/db/clone/clone_oraparam.ini
Starting Oracle Universal Installer...

Checking Temp space: must be greater than 500 MB.   Actual 29399 MB    Passed
Checking swap space: must be greater than 500 MB.   Actual 3967 MB    Passed
Preparing to launch Oracle Universal Installer from /tmp/OraInstall2015-02-12_02-57-31PM. Please wait ...You can find the log of this install session at:
 /app/oracle/oraInventory/logs/cloneActions2015-02-12_02-57-31PM.log
..................................................   5% Done.
..................................................   10% Done.
..................................................   15% Done.
..................................................   20% Done.
..................................................   25% Done.
..................................................   30% Done.
..................................................   35% Done.
..................................................   40% Done.
..................................................   45% Done.
..................................................   50% Done.
..................................................   55% Done.
..................................................   60% Done.
..................................................   65% Done.
..................................................   70% Done.
..................................................   75% Done.
..................................................   80% Done.
..................................................   85% Done.
..........
Copy files in progress.

Copy files successful.

Link binaries in progress.

Link binaries successful.

Setup files in progress.

Setup files successful.

Setup Inventory in progress.

Setup Inventory successful.

Finish Setup successful.
The cloning of 12102_home_base was successful.
Please check ’/app/oracle/oraInventory/logs/cloneActions2015-02-12_02-57-31PM.log’ for more details.

Setup Oracle Base in progress.

Setup Oracle Base successful.
..................................................   95% Done.

As a root user, execute the following script(s):
        1. /app/oracle/product/12.1.0.2/db/root.sh

..................................................   100% Done.

As part of the prerequisite checks, the cloning process will determine whether you have enough space in the /tmp directory and sufficient swap space is available for Oracle. The cloning process will reset various shell scripts and modify metadata information with the local host information.

invPtrLoc is an optional parameter that specifies the fully qualified file name that contains the location of the oraInventory. The invPtrLoc parameter should not be used in a RAC environment. The oraInst.loc file, by default, is located in the /etc directory in the Linux OS and looks like this:

inventory_loc=/u01/app/oraInventory
inst_group=oinstall

By default, inventory_loc will point one level below the $ORACLE_BASE directory of the oracle user account (/u01/app/oraInventory when ORACLE_BASE is /u01/app/oracle). As a precautionary measure, you should back up the oraInventory directory prior to attaching an Oracle Home. When you execute root.sh, it will also execute root.sh in silent mode.

How It Works

DBAs still continue to tar and un-tar the Oracle binaries from one server to another. In some companies, especially in non-RAC environments, DBAs copy the binaries from development database servers to QA and production database servers with a command such as tar piped to ssh.

Here’s a popular one-liner script that you can leverage to copy Oracle binaries from one directory level above the Oracle Home to the target node:

tar cvf - {DIR_NAME} |ssh {target_node} "cd /apps/oracle/product/12.1.0.2; tar xvf -"

The tar command piped to ssh ensures that symbolic links get copied over as symbolic links. The best thing about this approach is that you don’t have to incur double storage to store a local and remote copy of the tar archive.

Perl version 5.6 or higher is required when cloning Oracle Database 12c. When cloning Oracle software to a new server, make sure that all the prerequisite requirements are met as the perl clone.pl process doesn’t validate them.

Starting from Oracle Database 10g, Oracle supports cloning of Oracle Homes from source and target servers. The target server has to have all the Linux prerequisites and packages installed to ensure that the cloning process will be successful. You can clone the production Oracle Home to the lower environments, such as QA or DEV environments, to ensure that all the patches are identical from source and target Oracle Homes. You can strategically position the cloning process to upgrade a database from the current release to a higher release. For example, you can clone a newer version of the Oracle Home to the production database server. During the cutover window, you can simply switch Oracle Homes to the newer version and execute the post installation scripts to upgrade the database catalog.

11-15. Attaching an Oracle Home

Problem

You want to merge multiple Oracle inventories or rebuild/re-create the central inventory of all the Oracle Homes because the inventory is corrupt.

Solution

From the $ORACLE_HOME/oui/bin directory, you can execute the attachHome.sh shell script. Oracle provides a shell script to attach the Oracle Home to the oraInventory. The attachHome.sh script has the following content:

$ cat attachHome.sh
#!/bin/sh
OHOME=/u01/app/oracle/product/12.1.0/dbhome_2
OHOMENAME=OraDB12Home1
CUR_DIR=`pwd`
cd $OHOME/oui/bin
./runInstaller -detachhome ORACLE_HOME=$OHOME ORACLE_HOME_NAME=$OHOMENAME $* > /dev/null 2>&1
./runInstaller -attachhome ORACLE_HOME=$OHOME ORACLE_HOME_NAME=$OHOMENAME $*
cd $CUR_DIR

Executing the attachHome.sh script yields the following results:

$ ./attachHome.sh
Starting Oracle Universal Installer...

Checking swap space: must be greater than 500 MB.   Actual 4095 MB    Passed
The inventory pointer is located at /etc/oraInst.loc
’AttachHome’ was successful.

According to the attachHome.sh shell script, the script first detaches the Oracle Home from the oraInventory prior to attaching the new Oracle Home. In previous releases of Oracle, the runInstaller program was executed with the –attachHome option and provided the Oracle Home location and the Oracle Home name, as shown here:

$ ./runInstaller -silent -attachHome ORACLE_HOME="/u01/app/oracle/product/12.1.0/dbhome_2" ORACLE_HOME_NAME=" OraDB12Home1"
Starting Oracle Universal Installer...

Checking swap space: must be greater than 500 MB.   Actual 8174 MB    Passed
The inventory pointer is located at /etc/oraInst.loc
’AttachHome’ was successful.

You can even attach RAC Oracle Homes by specifying an additional parameter called CLUSTER_NODES, which has to be enclosed in curly brackets, as shown here:

CLUSTER_NODES={rac3,rac4}

How It Works

Execute the attachHome.sh shell script to attach the Oracle Home to the central Oracle inventory. You have to execute the attachHome.sh script from each of the Oracle Homes. Once you have successfully attached the new Oracle Home, you can view the contents of the inventory.xml file to confirm that the new Oracle Home is listed.

As stated earlier, the oraInventory directory location resides one level below $ORACLE_BASE. Here’s what the inventory.xml file looks like:

$ cat $ORACLE_BASE/../oraInventory/ContentsXML/inventory.xml
<?xml version="1.0" standalone="yes" ?>
<!-- Copyright (c) 1999, 2014, Oracle and/or its affiliates.
All rights reserved. -->
<!-- Do not modify the contents of this file by hand. -->
<INVENTORY>
<VERSION_INFO>
   <SAVED_WITH>12.1.0.2.0</SAVED_WITH>
   <MINIMUM_VER>2.1.0.6.0</MINIMUM_VER>
</VERSION_INFO>
<HOME_LIST>
<HOME NAME="OraDB12Home1" LOC="/u01/app/oracle/product/12.1.0/dbhome_2" TYPE="O" IDX="1"/>
</HOME_LIST>
<COMPOSITEHOME_LIST>
</COMPOSITEHOME_LIST>
</INVENTORY>

You can see that the ORACLE_HOME_NAME of OraDB12Home1 is listed as a member in the XML inventory file.