You want to install software components on the Linux server.

One of the ways you can 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:

[root@rac5 up2date]# 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.

If you do not have a license with either Red Hat Network or Oracle's Unbreakable Linux Network, you can maintain your system with the rpm command. Instead of locating RPMs associated with the executable or determining the dependencies associated with an RPM, administrators can register up2date to pull the RPMs and associated dependencies down from the up2date repository. Here is an example of using up2date to install the screen executable:

# up2date screen

Fetching Obsoletes list for channel: el4_i386_latest...
########################################

Fetching Obsoletes list for channel: el4_i386_oracle...

Fetching Obsoletes list for channel: el4_i386_addons...

Fetching rpm headers...
########################################

Name                                    Version        Rel
----------------------------------------------------------
screen                                  4.0.2          5                 i386


Testing package set / solving RPM inter-dependencies...
########################################
screen-4.0.2-5.i386.rpm:    ########################## Done.
Preparing              ########################################### [100%]

Installing...
   1:screen            ########################################### [100%]

With a single command, up2date downloaded the screen-4.0.2-5.i386.rpm package from the up2date repository and installed the software. If dependencies existed, up2date would have downloaded the dependent package(s) and installed the package(s) in the required order. You can imagine the potential time and frustration you save by not having to deal with dependency nightmares.

Oracle Database 10g/11g requires both 32-bit and 64-bit RPMs to be installed on a 64-bit architecture Linux server. To install 32-bit RPMs on a 64-bit machine with up2date, you can use the --arch option as shown here:

# up2date --arch=i386 glibc-devel

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. Since RPM was intended for Linux distributions and utilized 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 is stored in the /var/lib/rpm directory, and it houses metadata information about installed packages including package prerequisites and file attributes. Since 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 particular example, the version of the RPM is 2.2.11. 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 will have the architecture name x86_64.

RPMs that contain source code will have .src before the .rpm suffix. At times, you may not find binary RPMs associated with your architecture and flavor of Linux. An equivalent source code RPM may be available for another flavor of Linux. You can download the source and compile the RPM.

You will also notice that certain RPMs will have the .noarch extension in the file names to denote that the RPM does not have a dependency on the architecture of your system.

You installed Red Hat Enterprise Linux 4 or 5 but want to leverage Oracle's Unbreakable Linux Network (ULN). You want to start performing updates from ULN instead of Red Hat Network (RHN).

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 Enterprise Linux (OEL).

[root@rac5 Desktop]# 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%]

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 will be able to 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, RPM X will have a dependency on RPMs A, B, and C. RPM B will have 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 wanted 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 will encounter situations where up2date will significantly simplify the management of a Linux server.

Note

The process to register a Red Hat server and an Oracle Enterprise Linux server with ULN is identical. Customers who implement OEL can also register with ULN with the same steps outlined next to start using up2date to maintain their systems.

To start the registration process, you can execute the following command:

up2date --register

Note

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 will be presented with the Welcome to Unbreakable Linux Network Update Agent screen. Click the Forward button to be directed to the Unbreakable Linux Network Login screen. Since this is the first time you are logging in to up2date, you must provide all the credentials on the screen, including a login ID, a password (twice for verification), and a licensed CSI number, as shown in Figure 10-1.

Figure 10.1. Unbreakable Linux Network Login screen

Once you enter all the required credentials, click the Forward button. All the information that is entered will be validated, and the login and CSI information will be validated with Oracle's ULN database. Next, you will be directed to the Activate screen, as shown in Figure 10-2, where you will be prompted to send hardware information and the package list to ULN. You will also have to confirm the name of the server to register. You can click the Details button to review the information that will be sent to ULN. Once you are satisfied with the information, click the Forward button.

A progress dialog box will pop up to display the progress of the information that is being transmitted to ULN. Once all the information is sent to ULN, you will be directed to the Channels screen. During the up2date registration, you can subscribe only to the channel containing the latest software for the architecture and OS revision of the system. You can specify a different channel using the web interface at https://linux.oracle.com, after you complete the register process. Click the Forward button to be routed to the Packages Flagged to Be Skipped screen, as displayed in Figure 10-3.

Figure 10.2. Activate screen

Figure 10.3. Packages Flagged to Be Skipped screen

You will want to skip updating the kernel and kernel-devel packages unless you plan on upgrading the operating system to a newer version. Leave the boxes unchecked, and click the Forward button. You will be directed to the Available Package Updates screen, as shown in Figure 10-4.

Figure 10.4. Available Package Updates screen

You can select one or more packages to update and click the Forward button. On this screen, you may opt to select all the package requirements to install Oracle Database 10g or 11g. up2date will download all the packages on the Retrieving Packages screen. When all the packages that you selected are downloaded, you can click the Forward button to take you to the Installing Packages screen. Once all the packages are successfully installed, click the Forward button again to be directed to the Finish screen. Finally, click the Finish button to exit.

Switching from Red Hat Network to Oracle's ULN is straightforward. Once you purchase a license of OEL, you can start receiving support from Oracle MetaLink instead of Red Hat. You can start to receive support from a single front end for both the operating system and the database from Oracle MetaLink.

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. Once you log in, you should be able to see your server, as displayed in Figure 10-5.

Figure 10.5. Server confirmation on ULN

You identified that one of the servers has an executable you need but another server does not. You want to identify the RPM package to install on the server.

Let's look at an example of the gedit executable and see which RPM delivers this executable:

[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

rpm provides features to query the RPM database to extract the owning package. You can correlate an executable or library from the operating system 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.

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

You can execute rpm with the -qlp option to list the files in a package. Here's an example where the contents of the openmotif21 RPM is 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 a previous recipe, you can execute the previous rpm command against a file on the local filesystem, CD, or remote server with HTTP or FTP access.

The rpm command has a myriad of options. 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 we're executing the same command as previously, except with the -qip option:

[root@rac5 rpm]# 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 what 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 the detailed information about the package and the list of all files in the package.

You want to download RPMs from the Linux terminal.

By far, the easiest way to download RPMs is by executing the up2date command with the -d option (or --download). Here's an up2date example to download the perl RPM from ULN:

[root@rac5 up2date]# up2date -d perl

Fetching Obsoletes list for channel: el5_i386_latest...

Fetching rpm headers...
########################################

Name                                    Version        Rel
----------------------------------------------------------
perl                                    5.8.8          10.0.1.el5_2.3    i386


Testing package set / solving RPM inter-dependencies...
########################################
perl-5.8.8-10.0.1.el5_2.3.i ########################## Done.

Notice that the channel that this server subscribes to happens to be the el5_i386_latest channel. You have options to subscribe to other channels from Oracle's ULN: http://linux.oracle.com.

Let's assume you do not want to download the latest RPMs for a particular server. Instead, you may opt to download only from a specific update patch. You can unsubscribe the latest channel and subscribe to the el5_u2_i386_base channel. The el5_u2_i386_base channel provides all packages released on the Enterprise Linux 5 update 2 (i386) installation media but does not contain updates. For a complete listing of all the channels you are subscribed to, you can pass the --show-channels option to the up2date command, as displayed here:

# up2date --show-channels
el5_i386_latest
el5_i386_ocfs2
el5_i386_oracle

By default, up2date downloads all the RPMs in the /var/spool/up2date directory. In the /var/spool/up2date directory, you can confirm that up2date downloaded the perl header and package:

[root@rac5 /]# cd /var/spool/up2date
[root@rac5 up2date]# ls -l perl*
-rw-r--r-- 1 root root   288104 Jul 29 16:51 perl-5.8.8-10.0.1.el5_2.3.i386.hdr
-rw-r--r-- 1 root root 12159555 Aug  2 14:47 perl-5.8.8-10.0.1.el5_2.3.i386.rpm

You can change the temporary location of the download directory using the --tmpdir option. Here's another example of the up2date command using the --tmpdir option to download the screen RPM to the /tmp directory:

up2date --download screen --tmpdir=/tmp

You do not want to spend time researching RPM requirements to install Oracle Database 10g/11g. You want to take advantage of Oracle's preconfigured validated installation process.

If you are running on Oracle Enterprise Linux or Red Hat Linux and subscribe to Oracle's ULN, you can fully leverage Oracle's validated installation 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. To take advantage of Oracle's validated install, the server must be set up with up2date with Oracle's Linux Network. Once the up2date registration is complete, you can execute up2date with the --install option, as shown here:

[root@rac5 ˜]# up2date --install oracle-validated

Fetching Obsoletes list for channel: el5_i386_latest...

Fetching rpm headers...
########################################

Name                                    Version        Rel
----------------------------------------------------------
oracle-validated                        1.0.0          8.el5             i386


Testing package set / solving RPM inter-dependencies...
########################################
oracle-validated-1.0.0-8.el ########################## Done.
compat-db-4.2.52-5.1.i386.r ########################## Done.
compat-gcc-34-3.4.6-4.i386. ########################## Done.
compat-gcc-34-c++-3.4.6-4.i ########################## Done.
compat-libstdc++-33-3.2.3-6 ########################## Done.
enterprise-release-5-0.0.9. ########################## Done.
libXp-1.0.0-8.1.el5.i386.rp ########################## Done.
libaio-devel-0.3.106-3.2.i3 ########################## Done.
sysstat-7.0.2-1.el5.i386.rp ########################## Done.
unixODBC-2.2.11-7.1.i386.rp ########################## Done.
unixODBC-devel-2.2.11-7.1.i ########################## Done.
Preparing              ########################################### [100%]

Installing...
   1:unixODBC               ########################################### [100%]
   2:compat-gcc-34          ########################################### [100%]
   3:compat-gcc-34-c++      ########################################### [100%]
   4:unixODBC-devel         ########################################### [100%]
   5:sysstat                ########################################### [100%]
   6:libaio-devel           ########################################### [100%]
   7:libXp                  ########################################### [100%]
   8:enterprise-release     ########################################### [100%]
   9:compat-libstdc++-33    ########################################### [100%]
  10:compat-db              ########################################### [100%]
  11:oracle-validated       ########################################### [100%]
The following packages were added to your selection to satisfy dependencies:

Name                                    Version        Release
--------------------------------------------------------------
compat-db                               4.2.52         5.1
compat-gcc-34                           3.4.6          4
compat-gcc-34-c++                       3.4.6          4
compat-libstdc++-33                     3.2.3          61
enterprise-release                      5              0.0.9
libXp                                   1.0.0          8.1.el5
libaio-devel                            0.3.106        3.2
sysstat                                 7.0.2          1.el5
unixODBC                                2.2.11         7.1
unixODBC-devel                          2.2.11         7.1

As mentioned earlier, the validated install process also modifies the /etc/sysctl.conf kernel configuration file. The following entries are added:

fs.file-max=327679
kernel.msgmni=2878
kernel.msgmax=8192
kernel.sem=250 32000 100 142
kernel.shmmni=4096
kernel.shmall=3279547
kernel.sysrq=1
net.core.rmem_default=262144
# For 11g recommended value for net.core.rmem_max is 4194304
net.core.rmem_max=4194304
# For 10g uncomment the following line, comment other entries for this parameter
# and re-run sysctl -p
# net.core.rmem_max=2097152
net.core.wmem_default=262144
net.core.wmem_max=262144
fs.aio-max-nr=3145728
net.ipv4.ip_local_port_range=1024 65000
kernel.shmmax=536870912

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

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

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

dba:x:500:
oinstall:x:501:oracle

Many DBAs do not realize that the validated installation option exists. If you are licensed for Oracle Enterprise Linux and have set up up2date with ULN, you can execute up2date with the --install oracle-validated option to automatically install required packages by the Oracle Universal Installer. Executing the command can single-handedly prepare your Linux server to install Oracle Database, Grid Control, or Oracle Application Server. Most important, the oracle-validated installation also sets up the oracle user and required groups and adjusts the kernel parameters suitable for housing an enterprise database. You can review the /etc/sysconfig/oracle-validated/results/orakernel.log Oracle Validated Configuration RPM log file to review system configuration changes.

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

To upgrade an existing package, you can execute rpm with the -Uhv option (or --upgrade). For this particular solution, you will upgrade the perl RPM. Before you upgrade the perl RPM, let's query the RPM database and determine the current version and release of the perl RPM:

[root@rac5 tmp]# rpm -qa perl
perl-5.8.8-10

Now, let's upgrade the perl package to 10.0.1 release. You will execute the rpm executable with the -Uhv option to upgrade the perl package:

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

Next, you will query the RPM database to display the new perl package release:

[root@rac5 up2date]# rpm -qa perl
perl-5.8.8-10.0.1.el5_2.3

By invoking the rpm executable, we just demonstrated how to upgrade the perl package from version 5.8.8 release 10 to version 5.8.8 release 10.0.1.

You can take advantage of the -Uhv option to upgrade an existing package. 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 utilize the -U option to install packages also. If the package does not exist, the packaged will be installed.

You want to remove a package from the Linux server.

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

rpm -e screen

Software is removed from the server with the -e option. You must provide the installed package name as the second parameter. You do not provide the package file name. For the example in the solution, the screen package is removed from the system. Often, you will not be able to remove an RPM because of dependency requirements. You will have to know the dependency order to remove the designated RPM. Although we do not recommend it, you can avoid the dependency check with the --nodeps option.

You want to make sure your database software installation goes as smoothly as possible. You want to check to see whether the Linux server has all the required list of packages as specified by Oracle to install Oracle Database 10g or Oracle Database 11g.

You can execute the following provided shell script called rpm_check4.ksh to check to see whether the Linux server complies with the package requirements required to install and configure a database:

cat rpm_check4.ksh
function rpmcheck
{
export rpm_module=$1
#echo ""
echo "Found:"
rpm -qa $rpm_module --queryformat "%{NAME}-%{VERSION}.%{RELEASE} (%{ARCH})
"
}

rpmcheck binutils
echo "Checking to see if the server has at least: binutils-2.15.92.0.2-18.x86_64.
rpm "

rpmcheck compat-db
echo "Checking to see if the server has at least: compat-db-4.1.25-9.i386.rpm"
echo "Checking to see if the server has at least: compat-db-4.1.25-9.x86_64.rpm"

rpmcheck control-center
echo "Checking to see if the server has at least: control-center-2.8.0-
12.x86_64.rpm"

rpmcheck gcc
echo "Checking to see if the server has at least: gcc.3.4.3-22.1.x86_64.rpm"

rpmcheck gcc-c++
echo "Checking to see if the server has at least: gcc-c++-3.4.3-22.1.x86_64.rpm"

rpmcheck glibc
echo "Checking to see if the server has at least: glibc-2.3.4-2.9.i686.rpm"
echo "Checking to see if the server has at least: glibc-2.3.4-2.9.x86_64.rpm"

rpmcheck glibc-common
echo "Checking to see if the server has at least: glibc-common-2.3.4-2.9.x86_64.rpm"

rpmcheck gnome-libs
echo "Checking to see if the server has at least: gnome-libs-1.4.1.2.90-44.1.x86_64"

rpmcheck libstdc++
echo "Checking to see if the server has at least: libstdc++-3.4.3-22.1.x86_64"

rpmcheck libstdc++-devel
echo "Checking to see if the server has at least: libstdc++-devel-3.4.3-22.1.x86_64"

rpmcheck make
echo "Checking to see if the server has at least: make-3.80-5.x86_64.rpm"

rpmcheck pdksh
echo "Checking to see if the server has at least: pdksh-5.2.14-30.x86_64.rpm"

rpmcheck sysstat
echo "Checking to see if the server has at least: sysstat-5.0.5-1.x86_64.rpm"

rpmcheck xscreensaver
echo "Checking to see if the server has at least: xscreensaver-4.18-
5.rhel4.2.x86_64.rpm"

echo ""
echo "Found:"
rpm -qa --queryformat "%{NAME}-%{VERSION}.%{RELEASE} (%{ARCH})
"
  |grep -i compat-libstdc
echo "Checking to see if the server has at least: compat-libstdc++-33-3.2.3-
47.3.x86_64.rpm"
echo "Checking to see if the server has at least: compat-libstdc++-33-3.2.3-
47.3.i386.rpm"

rpmcheck glibc-kernheaders
echo "Checking to see if the server has at least: glibc-kernheaders-2.4-
9.1.87.x86_64.rpm"

rpmcheck glibc-headers
echo "Checking to see if the server has at least: glibc-headers-2.3.4-
2.9.x86_64.rpm"

rpmcheck libaio
echo "Checking to see if the server has at least: libaio-0.3.103-3.i386.rpm"
echo "Checking to see if the server has at least: libaio-0.3.103-3.x86_64.rpm"

rpmcheck libgcc
echo "Checking to see if the server has at least: libgcc-3.4.3-22.1.i386.rpm"

rpmcheck glibc-devel
echo "Checking to see if the server has at least: glibc-devel-2.3.4-2.9.x86_64.rpm"
echo "Checking to see if the server has at least: glibc-devel-2.3.4-2.9.i386.rpm"

rpmcheck xorg-x11-deprecated-libs
echo "Checking to see if the server has at least: xorg-x11-deprecated-libs-6.8.2-
1.EL.13.6.i386.rpm"

echo "# ------------------------------------------------------------------------- #"
echo "# For GC "
echo "# ------------------------------------------------------------------------- #"
rpmcheck openmotif21
echo "Checking to see if the server has at least: openmotif21-2.1.30-11"

rpmcheck setarch
echo "Checking to see if the server has at least: setarch-1.6-1"

echo "# ------------------------------------------------------------------------- #"
echo "# For Oracle Database 11g "
echo "# ------------------------------------------------------------------------- #"
rpmcheck unixODBC
echo "Checking to see if the server has at least: unixODBC-2.2.11"

rpmcheck unixODBC-devel
echo "Checking to see if the server has at least: unixODBC-devel-2.2.11"

rpmcheck elfutils-libelf
echo "Checking to see if the server has at least: elfutils-libelf-0.97-5"

rpmcheck elfutils-libelf-devel
echo "Checking to see if the server has at least: elfutils-libelf-devel-0.97-5"

rpmcheck libaio-devel
echo "Checking to see if the server has at least: libaio-devel-0.3.105-2"

If you are planning to run Oracle databases on a 64-bit Linux operating system, you will need to check for both 32-bit and 64-bit packages. For example, you need 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 display of the output. The query string format consists of static strings similar to the printf syntax.

In this solution, we specified the "%{NAME}-%{VERSION}.%{RELEASE} (%{ARCH}) " format 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 a sample output from the rpm4_check.ksh script:

# ./rpm4_check.ksh
Found:
binutils-2.15.92.0.2.22 (x86_64)
Checking to see if the server has at least: binutils-2.15.92.0.2-18.x86_64.rpm
Found:
compat-db-4.1.25.9 (x86_64)
compat-db-4.1.25.9 (i386)
Checking to see if the server has at least: compat-db-4.1.25-9.i386.rpm
Checking to see if the server has at least: compat-db-4.1.25-9.x86_64.rpm
Found:
control-center-2.8.0.12.rhel4.5 (x86_64)
Checking to see if the server has at least: control-center-2.8.0-12.x86_64.rpm
Found:
gcc-3.4.6.8.0.1 (x86_64)
Checking to see if the server has at least: gcc.3.4.3-22.1.x86_64.rpm
Found:
gcc-c++-3.4.6.8.0.1 (x86_64)
Checking to see if the server has at least: gcc-c++-3.4.3-22.1.x86_64.rpm
Found:
glibc-2.3.4.2.36 (x86_64)
glibc-2.3.4.2.36 (i686)
Checking to see if the server has at least: glibc-2.3.4-2.9.i686.rpm
Checking to see if the server has at least: glibc-2.3.4-2.9.x86_64.rpm
Found:
glibc-common-2.3.4.2.36 (x86_64)
Checking to see if the server has at least: glibc-common-2.3.4-2.9.x86_64.rpm
Found:
gnome-libs-1.4.1.2.90.44.2 (x86_64)
Checking to see if the server has at least: gnome-libs-1.4.1.2.90-44.1.x86_64
Found:
libstdc++-3.4.6.8.0.1 (x86_64)
libstdc++-3.4.6.8.0.1 (i386)
Checking to see if the server has at least: libstdc++-3.4.3-22.1.x86_64

Found:
libstdc++-devel-3.4.6.8.0.1 (x86_64)
libstdc++-devel-3.4.6.8.0.1 (i386)
Checking to see if the server has at least: libstdc++-devel-3.4.3-22.1.x86_64
Found:
make-3.80.6.EL4 (x86_64)
Checking to see if the server has at least: make-3.80-5.x86_64.rpm
Found:
pdksh-5.2.14.30.3 (x86_64)
Checking to see if the server has at least: pdksh-5.2.14-30.x86_64.rpm
Found:
sysstat-5.0.5.14.rhel4 (x86_64)
Checking to see if the server has at least: sysstat-5.0.5-1.x86_64.rpm
Found:
xscreensaver-4.18.5.rhel4.12 (x86_64)
xscreensaver-4.18.5.rhel4.14.0.1 (x86_64)
Checking to see if the server has at least: xscreensaver-4.18-5.rhel4.2.x86_64.rpm

Found:
compat-libstdc++-296-2.96.132.7.2 (i386)
compat-libstdc++-33-3.2.3.47.3 (i386)
compat-libstdc++-33-3.2.3.47.3 (x86_64)
Checking to see if the server has at least: compat-libstdc++-33-3.2.3-
47.3.x86_64.rpm
Checking to see if the server has at least: compat-libstdc++-33-3.2.3-47.3.i386.rpm
Found:
glibc-kernheaders-2.4.9.1.100.EL (x86_64)
Checking to see if the server has at least: glibc-kernheaders-2.4-9.1.87.x86_64.rpm
Found:
glibc-headers-2.3.4.2.36 (x86_64)
Checking to see if the server has at least: glibc-headers-2.3.4-2.9.x86_64.rpm
Found:
libaio-0.3.105.2 (x86_64)
libaio-0.3.105.2 (i386)
Checking to see if the server has at least: libaio-0.3.103-3.i386.rpm
Checking to see if the server has at least: libaio-0.3.103-3.x86_64.rpm
Found:
libgcc-3.4.6.8.0.1 (i386)
libgcc-3.4.6.8.0.1 (x86_64)
Checking to see if the server has at least: libgcc-3.4.3-22.1.i386.rpm
Found:
glibc-devel-2.3.4.2.36 (i386)
glibc-devel-2.3.4.2.36 (x86_64)
Checking to see if the server has at least: glibc-devel-2.3.4-2.9.x86_64.rpm
Checking to see if the server has at least: glibc-devel-2.3.4-2.9.i386.rpm

Found:
xorg-x11-deprecated-libs-6.8.2.1.EL.13.37.5.1 (i386)
xorg-x11-deprecated-libs-6.8.2.1.EL.18.0.1 (x86_64)
xorg-x11-deprecated-libs-6.8.2.1.EL.13.37.5.1 (x86_64)
xorg-x11-deprecated-libs-6.8.2.1.EL.18.0.1 (i386)
Checking to see if the server has at least: xorg-x11-deprecated-libs-6.8.2-
1.EL.13.6.i386.rpm
# ------------------------------------------------------------------------- #
# For GC
# ------------------------------------------------------------------------- #
Found:
openmotif21-2.1.30.11.RHEL4.6 (i386)
Checking to see if the server has at least: openmotif21-2.1.30-11
Found:
setarch-1.6.1 (x86_64)
Checking to see if the server has at least: setarch-1.6-1
# ------------------------------------------------------------------------- #
# For Oracle Database 11g
# ------------------------------------------------------------------------- #
Found:
unixODBC-2.2.11.1.RHEL4.1 (i386)
unixODBC-2.2.11.1.RHEL4.1 (x86_64)
Checking to see if the server has at least: unixODBC-2.2.11
Found:
unixODBC-devel-2.2.11.1.RHEL4.1 (x86_64)
Checking to see if the server has at least: unixODBC-devel-2.2.11
Found:
elfutils-libelf-0.97.1.4 (i386)
elfutils-libelf-0.97.1.4 (x86_64)
Checking to see if the server has at least: elfutils-libelf-0.97-5
Found:
elfutils-libelf-devel-0.97.1.4 (x86_64)
Checking to see if the server has at least: elfutils-libelf-devel-0.97-5
Found:
libaio-devel-0.3.105.2 (x86_64)
Checking to see if the server has at least: libaio-devel-0.3.105-2

You still have to review the output to ensure that what the script finds meets or exceeds the level of the package expected. The primary purpose of this script is to provide a single consolidated output to review all the RPMs compared to what is required by Oracle to install and configure a database.

The output to the rpm4_check.ksh script has three sections. The first section lists all the RPMs to install Oracle Database 10g, the second section lists the packages to install Grid Control, and the last section lists the additional packages to install Oracle Database 11g.

Please stay tuned to future updates to the rpm4_check.ksh script and even to the rpm5_check.ksh script for Red Hat 5/OEL 5 at the http://blog.dbaexpert.com web site.

You want to check to see whether Red Hat 4 ES/AS or Oracle Enterprise Linux (OEL) 4 has all the required packages as specified by Oracle to install Grid Control or E-Business Suite Release 12.

You can execute the rpm command with the -qa option followed by the package name. Please note that the package name provided to the -qa option does not have the version or release. Each of the packages needs to be at the level specified or higher than what is listed here to install Grid Control:

xscreensaver-4.18-5.rhel4.2
glibc-2.3.4-2.9
make-3.79
binutils-2.15.92.0.2-13
gcc-3.4.3-22.1
libaio-0.3.96
glibc-common-2.3.4-2.9
setarch-1.6-1
pdksh-5.2.14-30
openmotif21-2.1.30-11
sysstat-5.0.5-1
gnome-libs-1.4.1.2.90-44.1
libstdc++-3.4.3-22.1
libstdc++-devel-3.4.3-22.1
compat-libstdc++-296-2.96-
compat-db-4.1.25-9
control-center-2.8.0-12

Similarly, you must meet or exceed each of the following package requirements to install Oracle E-Business Suite Release 12:

glibc-2.3.4-2.25
glibc-common-2.3.4-2.25
binutils-2.15.92.0.2-21
compat-libstdc++-296-2.96-132.7.2
gcc-3.4.6-3
gcc-c++-3.4.6-3
libgcc-3.4.6-3
libstdc++-3.4.6-3
libstdc++-devel-3.4.6-3
openmotif21-2.1.30-11.RHEL4.6**
pdksh-5.2.14-30.3
setarch-1.6-1

make-3.80-6.EL4
gnome-libs-1.4.1.2.90-44.1
sysstat-5.0.5-11.rhel4
compat-db-4.1.25-9
control-center-2.8.0-12.rhel4.5
xscreensaver-4.18-5.rhel4.11
libaio-0.3.105-2
libaio-devel-0.3.105-2

For specific RPM requirements for other 32-bit Linux operating systems, please review Oracle MetaLink Note 402310.1. In addition to the previously mentioned RPMs, you must also have ar, gcc, g++, ld, ksh, and make executables installed and available in your PATH environment variable on the Linux server.

The last thing you want to experience is not being able to install an Oracle product because the server is missing the required packages. Meeting the minimal version and release of all the required RPMs for a Grid Control or E-Business Suite installation is one of the major hurdles to a successful implementation. You can execute the rpm -qa command followed by the package name and compare the output with the expected version and release numbers. Another way to list all the required RPMs is by typing all the required RPMs in a single command. Here's an example:

rpm -qa xscreensaver glibc make binutils gcc 
        libaio glibc-common setarch pdksh openmotif21 
        sysstat gnome-libs libstdc++ libstdc++-devel 
        compat-libstdc++ compat-db control-center

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

This solution assumes you have successfully copied and unbundled the Oracle install software on your database server. After unbundling the installation software, you should see a directory named response in the database directory:

$ cd database
$ ls
doc  install  response  runInstaller  stage  welcome.html

First, change directories to the response directory, and list the files:

$ cd response
$ ls

You should see several response files:

custom.rsp emca.rsp netca.rsp dbca.rsp enterprise.rsp standard.rsp

This example demonstrates how to perform an enterprise-level silent installation. Before you modify the enterprise.rsp response file, make a backup copy of the file. Now, open the enterprise.rsp response file with an editor such as vi, and provide valid values for your environment for these variables within the response file:

UNIX_GROUP_NAME
FROM_LOCATION
ORACLE_BASE
ORACLE_HOME
ORACLE_HOME_NAME
n_configurationOption

Here's an example of what the parameters can be set to in a typical installation:

UNIX_GROUP_NAME=oinstall
FROM_LOCATION="/apps/oracle/software/database/stage/products.xml"
ORACLE_BASE=/apps/oracle
ORACLE_HOME=/apps/oracle/product/11.1.0/DB
ORACLE_HOME_NAME=11gDBHome1
n_configurationOption=3

The UNIX_GROUP_NAME is usually either dba or oinstall. The FROM_LOCATION variable must point to the products.xml file that is located under the stage directory where you unbundled the Oracle software. The ORACLE_HOME directory must point to the correct setting for your environment. This should match the value in your 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: the database name, the location of the database software (also known as ORACLE_HOME), and the startup flag. The last parameter plays a significant role in automating database startups. If the value of the last parameter is set to Y, then 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 home of this installation. The n_configurationOption variable must be set to 3, which specifies the installer to just install the software. Valid values for n_configurationOption are 1 to create a database, 2 to configure an ASM instance, and 3 to install software only.

Change directories to where the runInstaller file is located. This is one directory up from where the enterprise.rsp file is located:

$ cd ..
$ ls
doc  install  response  runInstaller  stage  welcome.html

Make sure your operating system variables such as ORACLE_HOME match what you have entered in the response file. Now you can install the binaries by running the runInstaller program using the following command-line syntax:

./runInstaller -ignoreSysPrereqs -force -silent -responseFile <path>/rspfilename.rsp

In this solution, the -ignoreSysPrereqs parameter is specified to have the runInstaller program ignore system prerequisite checks. For additional insight into this option, please review recipe 10-12. The -force option allows the silent install into a nonempty directory. When in doubt, you can always specify the -help option to list all the possible arguments.

Make sure you specify the full path and correct name for the response file. In our environment, the command looks like this:

$ ./runInstaller -ignoreSysPrereqs -force -silent -responseFile 
 /apps/oracle/software/database/response/enterprise.rsp

Next you'll see a lot of output (if things go OK). Here is a partial snippet of the output:

Starting Oracle Universal Installer...

Checking Temp space: must be greater than 80 MB.   Actual 116391 MB    Passed
Checking swap space: must be greater than 150 MB.   Actual 1023 MB    Passed
Preparing to launch Oracle Universal Installer from /tmp/OraInstall2008-07-30_02-24-
59PM. Please wait ...[oracle@rac5 database]$ Oracle Universal Installer,
Version 11.1.0.6.0 Production
Copyright (C) 1999, 2007, Oracle. All rights reserved.

You can find the log of this install session at:
 /home/oracle/oraInventory/logs/installActions2008-07-30_02-24-59PM.log
............................................................................ 100%
 Done.


Loading Product
Information................................................................. 100%
 Done.


Starting execution of Prerequisites...
Total No of checks: 14

Performing check for CertifiedVersions
Checking operating system requirements ...
Expected result: One of enterprise-4,enterprise-5,Red Hat-4,Red Hat-5,SuSE-

10,asianux-2,asianux-3
Actual Result: enterprise-5
Check complete. The overall result of this check is: Passed


Check complete: Passed
========================================================

As you can see from the output, a total of 14 checks will be performed. Initially, Oracle performs a check for certified versions to ensure that the operating system is running one of the following certified operating systems:

enterprise-4,enterprise-5,Red Hat-4,Red Hat-5,SuSE-10,asianux-2,asianux-3

Next, packages will be checked to see whether all the required RPMs are installed:

Performing check for Packages
Checking operating system package requirements ...
Checking for make-3.81; found make-1:3.81-1.1-i386.     Passed
Checking for binutils-2.17.50.0.6; found binutils-2.17.50.0.6-5.el5-i386.
Passed
Checking for gcc-4.1.1; found gcc-4.1.2-14.el5-i386.    Passed
[ ... ]

Next, kernel parameters will be evaluated to make sure they are in accordance with the required settings. After checking kernel settings, other settings are scrutinized, including the glibc version, total memory, swap space, DHCP, path for other ORACLE_HOMEs, temp space, LD_LIBRARY_PATH, ORACLE_BASE, space for ORACLE_HOME, invalid ASM HOME, and ORACLE_HOME incompatibilities.

If all checks are passed, then you will see the progress and status of the installation:

Installation in progress (Wed Jul 30 14:25:25 CDT 2008)
...............................................................   7% Done.
...............................................................  14% Done.
...............................................................  21% Done.
...............................................................  28% Done.
...............................................................  35% Done.
...............................................................  43% Done.
...............................................................  50% Done.
...............................................................  57% Done.
...............................................................  64% Done.
...............................................................  71% Done.
...............................................................  78% Done.
.....................................                            83% Done.
Install successful

Linking in progress (Wed Jul 30 14:30:54 CDT 2008)
..                                                               83% Done.
Link successful

Setup in progress (Wed Jul 30 14:32:39 CDT 2008)
..................................                              100% Done.
Setup successful

End of install phases.(Wed Jul 30 14:32:50 CDT 2008)
WARNING:A new inventory has been created in this session. However, it has not yet
been registered as the central inventory of this system.
To register the new inventory please run the script
'/home/oracle/oraInventory/orainstRoot.sh' with root privileges.
If you do not register the inventory, you may not be able to update or patch the
products you installed.
The following configuration scripts need to be executed as the "root" user.
#!/bin/sh
#Root script to run
/home/oracle/oraInventory/orainstRoot.sh
/apps/oracle/product/11.1.0/DB/root.sh
To execute the configuration scripts:
    1. Open a terminal window
    2. Log in as "root"
    3. Run the scripts

The installation of Oracle Database 11g was successful.
Please check '/home/oracle/oraInventory/logs/silentInstall2008-07-30_02-24-59PM.log'
for more details.

Once the installation completes successfully, as root run both the orainstRoot.sh and root.sh scripts. In this example, the orainstRoot.sh script resides in the /home/oracle/oraInventory directory, and the root.sh script resides in the /apps/oracle/product/11.1.0/DB directory:

$ su -
Password:
# /home/oracle/oraInventory/orainstRoot.sh
# /apps/oracle/product/11.1.0/DB/root.sh

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

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 an installation. This technique is desirable in several scenarios. For example, if you often perform remote installs across a wide area network with limited bandwidth, then using the graphical installer may not be an option (because of extremely slow response times and network hang-ups).

You can easily customize the response file for database options required for your environment. You can then reuse the same response file for multiple installations. The silent installation technique allows you to perform repeatable and standardized Oracle installations and upgrades. You can document the exact steps required and have junior DBAs and/or system administrators 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 do not 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.

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

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

OUI-10133:Invalid staging area

Check complete: Failed <<<<
Problem: Oracle Database 10g Release 2 can only be installed in a new Oracle Home
Recommendation: Choose a new Oracle Home for installing this product.

You are trying to install Oracle Database 10g Release 2 on a new Red Hat or OEL server but cannot get past the operating system check error.

When attempting to install Oracle Database 10g Release 2, you instantly receive an error from runInstaller indicating that the version of Red Hat or OEL is not supported, as shown here:

$ ./runInstaller
Starting Oracle Universal Installer...

Checking installer requirements...

Checking operating system version: must be redhat-3, SuSE-9, redhat-4, UnitedLinux-
1.0, asianux-1 or asianux-2
                                      Failed <<<<

Exiting Oracle Universal Installer, log for this session can be found at
/home/oracle/oraInventory/logs/installActions2008-09-05_01-45-15AM.log

If you look at the release of the Linux server by viewing the /etc/redhat-release file, you can determine the version of Red Hat or OEL that the server is running:

$ cat /etc/redhat-release
Enterprise Linux Enterprise Linux Server release 5.2 (Carthage)

In this solution, we are deploying Red Hat 5 that has been migrated to OEL 5 ULN. If you utilize the -ignoreSysPrereqs option, the OUI will ignore the operating system check failure and continue with the installation, as demonstrated here:

$ ./runInstaller -ignoreSysPrereqs
Starting Oracle Universal Installer...

Checking installer requirements...

Checking operating system version: must be redhat-3, SuSE-9, redhat-4, UnitedLinux-
1.0, asianux-1 or asianux-2
                                      Failed <<<<

>>> Ignoring required pre-requisite failures. Continuing...

Preparing to launch Oracle Universal Installer from /tmp/OraInstall2008-09-05_01-45-
40AM. Please wait
Oracle Universal Installer, Version 10.2.0.1.0 Production
Copyright (C) 1999, 2005, Oracle. All rights reserved.

Now, the operating system prerequisite error will be ignored and will proceed to display the OUI screen to the target of the DISPLAY parameter.

The -ignoreSysPrereqs parameter is commonly used when you have a newer release of an operating system that is not on the list of supported versions. You can use this parameter on other Oracle products. In this recipe, this operating system check error is encountered simply because Red Hat 5 or OEL 5 was not available at the time Oracle Database 10g Release 2 became generally available as a production product.

You cannot launch the Database Configuration Assistant (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.

The good news is that you can create a database in silent mode too after you modify the dbca.rsp response file to your desired configuration. For this particular solution, we will demonstrate the simplicity of creating a database after modifying a minimal number of parameters in the dbca.rsp response file. At a minimum, the parameters GDBNAME, SID, SYSPASSWORD, SYSTEMPASSWORD, SYSMANPASSWORD, DBSNMPPASSWORD, DATAFILEDESTINATION, STORAGETYPE, CHARACTERSET, and NATIONALCHARACTERSET should be modified. In this example, we modified all the previously mentioned parameters in the dbca.rsp file after backing up the original file to dbca.rsp.BKUP. Once you make the appropriate changes to the dbca.rsp response file, you can execute the diff command to identify changes that were made to the dbca.rsp file. Here's the output of the diff command:

$ diff dbca.rsp dbca.rsp.BKUP |grep "<"
< GDBNAME = "DEV.dbaexpert.com"
< SID = "DEV"
< SYSPASSWORD = "DigitalSignal123"
< SYSTEMPASSWORD = "DigitalSignal123"
< SYSMANPASSWORD = "oracle123"
< DBSNMPPASSWORD = "oracle123"
< DATAFILEDESTINATION = "/apps/oradata"
< STORAGETYPE=FS
< CHARACTERSET = "AL32UTF8"
< NATIONALCHARACTERSET= "UTF8"

The less-than sign (<) indicates that the changes are from the first file of the diff command, the dbca.rsp file. Now, let's launch dbca in silent mode from $ORACLE_HOME/bin. In this solution, dbca is launched with the -silent parameter and the -responseFile parameter followed by the location of the response file:

[oracle@rac5 bin]$ ./dbca -silent -responseFile
/apps/oracle/software/database/response/dbca.DEV.rsp

Copying database files
1% complete
3% complete
37% complete
Creating and starting Oracle instance
40% complete
45% complete
50% complete
55% complete
56% complete
60% complete
62% complete
Completing Database Creation
66% complete
70% complete
73% complete
77% complete
88% complete
100% complete
Look at the log file "/apps/oracle/cfgtoollogs/dbca/DEV/DEV.log" for further details.

dbca in silent mode provides a progress status to notify you where in the database creation process it is at. During the initial phase, Recovery Manager (RMAN) performs a restore of the datafiles. 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 will also notice an entry in the /etc/oratab file for the new database named DEV:

#
DEV:/apps/oracle/product/11.1.0/DB:N

Nowadays, creating databases with the Database Configuration Assistant is a 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.

With effective utilization of the dbca.rsp response file, 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 just about 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 cannot launch 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.

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

[GENERAL]
RESPONSEFILE_VERSION="11.1"
CREATE_TYPE= "CUSTOM"
LOG_FILE=""/tmp/netca.log""
[Session]
ORACLE_HOME="/apps/oracle/product/11.1.0/DB"
[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 with the modified response file yields this output:

[oracle@rac5 response]$ netca /silent /responsefile $PWD/netca.DEV.rsp

Sun Aug 03 21:50:12 CDT 2008 Oracle Net Configuration Assistant
Parsing command line arguments:
    Parameter "silent" = true
    Parameter "responsefile" = /apps/oracle/software/database/response/netca.DEV.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:
      /apps/oracle/product/11.1.0/DB/bin/lsnrctl start
    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

Notice that netca utilizes / as the parameter prefix. dbca and runInstaller accept - as parameter prefixes. Behind the scenes, netca created three files in the $ORACLE_HOME/network/admin directory: sqlnet.ora, tnsnames.ora, and listener.ora.

DBAs can fully configure Oracle's network topology by launching the Network Configuration Assistant. DBAs often do not realize the potential of automation through response files. With the proper standardization in directory structures and naming conventions, DBAs can script and manipulate the network configuration response files leveraging executables like 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 particular solution, you want every server to have entries for DBATOOLS and RMANPROD. Here are the contents of the tnsnames.ora file:

# tnsnames.ora Network Configuration File:
/apps/oracle/product/11.1.0/DB/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:

# listener.ora Network Configuration File:
/apps/oracle/product/11.1.0/DB/network/admin/listener.ora
# Generated by Oracle configuration tools.

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = rac5.dbaexpert.com)(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)

You need to apply a patch to resolve a database issue or eradicate a bug you encountered in your database.

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

opatch command  [options>] [-h[elp]]

Commonly supplied opatch arguments are as follows:

Let's take, for example, patch number 6455659 to fix stored outlines in Oracle Release 11.1.0.6. We downloaded the patch file p6455659_111060_LINUX.zip to our download directory. We will extract the compressed archived file with the unzip command. If you want to see the contents of the .zip file without extracting the file, you can pass the -l argument to the unzip command. The unzip command will create a directory called 6455659 and extract all the files into the directory.

You should always read the README.txt file located in the base directory of the patch, which is the 6455659 directory in this case. The README.txt file will have 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 patches to be executed.

The README.txt file indicates that this patch application is straightforward. Let's proceed and apply patch 6455659. 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 where the database does not have to be shut down for high availability considerations. You must examine the README.txt file to see whether a particular patch qualifies as an online patch. Since this particular patch requires the database to be shut down, we will 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.

We have already changed our directory to the 6455659 directory. Based on the README.txt file, we can apply this patch with the command opatch apply.

Let's see the opatch process in action relative to this patch:

$ opatch apply
Invoking OPatch 11.1.0.6.0

Oracle Interim Patch Installer version 11.1.0.6.0
Copyright (c) 2007, Oracle Corporation.  All rights reserved.

Oracle Home       : /apps/oracle/product/11.1/DB02
Central Inventory : /home/oracle/oraInventory
   from           : /etc/oraInst.loc
OPatch version    : 11.1.0.6.0
OUI version       : 11.1.0.6.0
OUI location      : /apps/oracle/product/11.1/DB02/oui
Log file location : /apps/oracle/product/11.1/DB02/cfgtoollogs/opatch/opatch2008-09-
05_10-27-17AM.log

ApplySession applying interim patch '6455659' to OH '/apps/oracle/product/11.1/DB02'

Running prerequisite checks...

OPatch detected non-cluster Oracle Home from the inventory and will patch the local
system only.


Please shutdown Oracle instances running out of this ORACLE_HOME on the local system.
(Oracle Home = '/apps/oracle/product/11.1/DB02')


Is the local system ready for patching? [y|n]
y
User Responded with: Y
Backing up files and inventory (not for auto-rollback) for the Oracle Home
Backing up files affected by the patch '6455659' for restore. This might take a
while...
Backing up files affected by the patch '6455659' for rollback. This might take a
while...

Patching component oracle.rdbms, 11.1.0.6.0...
Updating archive file "/apps/oracle/product/11.1/DB02/lib/libserver11.a"  with
"lib/libserver11.a/qol.o"
Running make for target ioracle
ApplySession adding interim patch '6455659' to inventory

Verifying the update...
Inventory check OK: Patch ID 6455659 is registered in Oracle Home inventory with
proper meta-data.
Files check OK: Files from Patch ID 6455659 are present in Oracle Home.

The local system has been patched and can be restarted.

OPatch succeeded.

Notice that the patching process prompts you to confirm that the local system is ready for patching. You can alternatively supply the -silent parameter to apply this patch in silent mode. The -silent parameter suppresses the user prompt to confirm that the system is ready. Here's a snippet of the opatch output utilizing the -silent parameter:

[ ...]

Please shutdown Oracle instances running out of this ORACLE_HOME on the local system.
 (Oracle Home = '/apps/oracle/product/11.1/DB02')


Is the local system ready for patching? [y|n]
Y (auto-answered by -silent)
User Responded with: Y
Backing up files and inventory (not for auto-rollback) for the Oracle Home
[ ... ]

Notice that the Y answer is autoanswered from the -silent parameter. Now, let's 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@rac5 6455659]$ opatch lsinventory
Invoking OPatch 11.1.0.6.0

Oracle Interim Patch Installer version 11.1.0.6.0
Copyright (c) 2007, Oracle Corporation.  All rights reserved.


Oracle Home       : /apps/oracle/product/11.1/DB02
Central Inventory : /home/oracle/oraInventory
   from           : /etc/oraInst.loc
OPatch version    : 11.1.0.6.0
OUI version       : 11.1.0.6.0
OUI location      : /apps/oracle/product/11.1/DB02/oui
Log file location : /apps/oracle/product/11.1/DB02/cfgtoollogs/opatch/opatch2008-09-
05_10-34-54AM.log

Lsinventory Output file location :
/apps/oracle/product/11.1/DB02/cfgtoollogs/opatch/lsinv/
lsinventory2008-09-05_10-34-54AM.txt

--------------------------------------------------------------------------------
Installed Top-level Products (1):

Oracle Database 11g                                                  11.1.0.6.0
There are 1 products installed in this Oracle Home.

Interim patches (1) :

Patch  6455659      : applied on Fri Sep 05 10:27:56 CDT 2008
   Created on 17 Oct 2007, 23:22:33 hrs PST8PDT
   Bugs fixed:
     6455659



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

OPatch succeeded.

You can execute the command opatch lsinventory -detail to produce a detailed output of all the patches.

OPatch is a collection of Perl scripts and Java classes providing the capability to apply and roll back 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 the MetaLink Note 224346.1.

OPatch requires a Java Runtime Environment (JRE) to be available on the Linux server. In addition, OPatch also 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 like 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 our next example, we will roll back the same patch that we applied in our solution:

$ opatch rollback -id 6455659
Invoking OPatch 11.1.0.6.0

Oracle Interim Patch Installer version 11.1.0.6.0
Copyright (c) 2007, Oracle Corporation.  All rights reserved.


Oracle Home       : /apps/oracle/product/11.1/DB02
Central Inventory : /home/oracle/oraInventory
   from           : /etc/oraInst.loc
OPatch version    : 11.1.0.6.0
OUI version       : 11.1.0.6.0
OUI location      : /apps/oracle/product/11.1/DB02/oui
Log file location : /apps/oracle/product/11.1/DB02/cfgtoollogs/opatch/opatch2008-09-
05_10-35-34AM.log

RollbackSession rolling back interim patch '6455659' from OH
'/apps/oracle/product/11.1/DB02'

Running prerequisite checks...

OPatch detected non-cluster Oracle Home from the inventory and will patch the local
system only.

Please shutdown Oracle instances running out of this ORACLE_HOME on the local
system.
(Oracle Home = '/apps/oracle/product/11.1/DB02')


Is the local system ready for patching? [y|n]
y
User Responded with: Y
Backing up files affected by the patch '6455659' for restore. This might take a
while...

Patching component oracle.rdbms, 11.1.0.6.0...
Updating archive file "/apps/oracle/product/11.1/DB02/lib/libserver11.a"  with
"lib/libserver11.a/qol.o"
Running make for target ioracle
RollbackSession removing interim patch '6455659' from inventory

The local system has been patched and can be restarted.


OPatch succeeded.

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

Oracle also offers what is known as merge label request (MLR) patches. Basically, MLRs are multiple patches for multiple bugs that have been bundled together and presented as a single patch. In the RAC world, Oracle also provides what it calls CRS bundle patches. CRS bundle patches are collections of patches specifically intended for Oracle Clusterware. For a list of all CRS bundle patches, please refer to MetaLink Note 405820.1. CRS bundle patches are more complex to apply because numerous steps have to be executed as the root user and as the oracle user. With thorough analysis and careful execution, though, you can easily apply the CRS bundle patch to your RAC environment.

Your company continues to copy the Oracle Home binaries from one server to another. You encounter upgrade issues because the Oracle Home is not registered in oraInventory.

If you happen to be one of the DBAs who still creates tar copies of the Oracle binaries, you can continue to, as the saying goes, have your cake and eat it too. It's much easier to copy the Oracle binaries than it is to install the software from the CD or unzipped media software. You can accomplish in one command what could possibly take hours if you have a slow wide area network (WAN) connectivity between your desktop and the Linux server. If you are not comfortable with the silent installation option, you also need to find an X server or VNC server to set the DISPLAY environment variable to. In this solution, we show you how to attach an Oracle Home after you transfer the binaries from another server using the rcp/scp, tar, or rsh/ssh command. You must first set your 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 /apps/oracle/product/11.1.0/ASM. Next, change your directory to the oui/bin subdirectory:

cd $ORACLE_HOME/oui/bin

From the oui/bin directory, execute the runInstaller command as shown here to attach the new Oracle Home to oraInventory:

./runInstaller -silent -attachHome -invPtrLoc /etc/oraInst.loc 
ORACLE_HOME="/apps/oracle/product/11.1.0/ASM" ORACLE_HOME_NAME="11gASM"

Upon a successful attach of the Oracle Home, you will receive a message stating that AttachHome was successful, as shown here:

Starting Oracle Universal Installer...

Checking swap space: must be greater than 500 MB.   Actual 952 MB    Passed
Preparing to launch Oracle Universal Installer from /tmp/OraInstall2008-09-05_02-01-20PM. Please wait ...
[oracle@rac5 txt]$ The inventory pointer is located at /etc/oraInst.loc
The inventory is located at /home/oracle/oraInventory
'AttachHome' was successful.

The invPtrLoc parameter specifies the fully qualified file name that contains the location of the oraInventory. The oraInst.loc file is located in the /etc directory in the Linux operating system and looks like this:

inventory_loc=/home/oracle/oraInventory
inst_group=oinstall

By default, the inventory_loc will point to the $HOME directory of the oracle user account. As a precautionary measure, we recommend you back up the oraInventory directory prior to attaching an Oracle Home.

You can even attach RAC Oracle Homes. For RAC Oracle Homes, you must specify an additional parameter called CLUSTER_NODES. This parameter needs to be enclosed by curly brackets, as shown here:

CLUSTER_NODES={rac3,rac4}

You just need to execute the runInstaller command with the -attachHome option from one RAC node. oraInventory will be updated across all the RAC nodes.

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 quality assurance (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/11.1.0; 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 do not have to incur double storage to store a local and remote copy of the tar archive.

Once you have successfully attached the new Oracle Home, you can view the contents of the /home/oracle/oraInventory/ContentsXML/inventory.xml file to confirm that the new Oracle Home is listed. Here's what the inventory.xml file looks like:

<?xml version="1.0" standalone="yes" ?>
<!-- Copyright (c) 1999, 2006, Oracle. All rights reserved. -->
<!-- Do not modify the contents of this file by hand. -->
<INVENTORY>
<VERSION_INFO>
   <SAVED_WITH>11.1.0.6.0</SAVED_WITH>
   <MINIMUM_VER>2.1.0.6.0</MINIMUM_VER>
</VERSION_INFO>
<HOME_LIST>
<HOME NAME="11gDBHome1" LOC="/apps/oracle/product/11.1.0/DB" TYPE="O" IDX="1"/>
<HOME NAME="11gDBHome2" LOC="/apps/oracle/product/11.1/DB02" TYPE="O" IDX="2"/>
<HOME NAME="11gASM" LOC="/apps/oracle/product/11.1.0/ASM" TYPE="O" IDX="3"/>
</HOME_LIST>
</INVENTORY>

You can see that 11gASM HOME_NAME is listed as a member in the XML inventory file.