Forwarding an X11 session

Most database administrators will use some variant of the Microsoft Windows operating system on their workstations or desktops. For them to use X11 forwarding, they need to install an X server which has to be started up and accepting connections on their workstations. Free/Open Source X Servers include the Cygwin environment for example. In addition to the Open Source X Servers, commercial products are available as well. It is more a matter of personal taste as to which one to choose. To allow X11 forwarding on the database server you need to modify the SSH server daemon configuration file on the database server.

For an OpenSSH implementation, you need to add/modify the following variable in /etc/ssh/sshd_config and reload the configuration. The below example is for Linux, after the variable X11Forwarding has been uncommented out and set to yes:

[root@server1 ∼] # grep X11Forwarding /etc/ssh/sshd_config
X11Forwarding yes
[root@server1 ∼] # service sshd reload
Reloading sshd:                                            [  OK  ]
[root@server1 ∼] #

In your putty configuration, ensure to enable X11 forwarding. For putty’s new connection dialog, navigate to Connection SSH X11, tick the checkbox named “Enable X11 Forwarding” before connecting to the server. Unlike port forwarding you can’t retrospectively enable X11 forwarding. Your next session will show lines similar to these:

login as: grid
[email protected]'s password:
Last login: Fri Sep 6 15:31:29 2013 from jumpbox
/usr/bin/xauth:  creating new authority file /home/grid/.Xauthority
$ echo $DISPLAY
localhost:10.0

You can use the xdpyinfo application to check if your terminal session can connect to the X server, which should be the case. This little utility displays information about the X server. Any output different from the below example indicates you can successfully forward your X11 session:

xdpyinfo:  unable to open display "".

Using the Virtual Network Computing Protocol

An alternative to X-forwarding exists in the form of VNC. It is easiest to picture VNC as an operating system independent equivalent to the Microsoft Terminal Services client. VNC is based on a client/server architecture, and supports many operating systems. It is very common to start a server session on Linux and use a Windows client. The VNC server is slightly easier to configure than X11 forwarding. It does not require a change to the SSH daemon configuration which can be difficult to arrange.

To use VNC you need to install the vnc server on the database server. In Oracle Linux 6, the VNC package to be used is called tigervnc-server. Install it using yum as usual. Once the software is installed, start a VNC server session on the database host. Each of these will create a new display ID, as shown in the example below:

[grid@server1 ∼]$ vncserver
 
You will require a password to access your desktops.
 
Password: <not shown>
Verify: <not shown>
 
New 'server1.example.com:1 (grid)' desktop is server1.example.com:1
 
Creating default startup script /home/grid/.vnc/xstartup
Starting applications specified in /home/grid/.vnc/xstartup
Log file is /home/grid/.vnc/server1.example.com:1.log

As you can see the VNC server is started on display one. Subsequent VNC server sessions started will increment that counter and start on the next available display. To connect to the VNC server process, start a VNC client on your workstation and provide the connection string, such as server1.example.com:1. The RealVNC client which is probably the most widely spread viewer has not been updated for quite some time, and the free edition is still at version 4.1.3 but works even with tigervnc used in Oracle Linux 6. The viewer does not require an installation and comes as a binary executable of only a few hundred KiB in size.

The neat aspect about the use of VNC is that it does not require a lot of bandwidth to work properly, and a network glitch does not ruin your installer session. Just like a Microsoft Terminal Server session you can resume where you left off.

Download Software Updates

The software updates screen is the first one you see after the new Oracle 12c logo indicates that you are on the latest release. Figure 6-1 shows this screen.

You have the option to download software updates such as Patch Set Updates and other fixes recommended by Oracle. By selecting the first radio button you allow a connection to My Oracle support to download patches and updates. You can supply proxy connection information to connect to the Internet. In most security conscious environments a direct connection, even facilitated by a proxy server will not be possible or even desirable. Oracle offers the second solution instead, which enables you to make use of previously downloaded patches. OUI has a command line option, called “-downloadUpdates”. When you start OUI in this mode on a workstation connected to the Internet, a configuration dialog will guide you through the necessary steps for downloading the patches. These can then be transferred to the staging server and referenced in the location text field. In the above example no patches have been selected for download or application. You can ignore the warning window which pops up in this case for now.

A click on the “next” button advances to the next screen, as shown in Figure 6-2.

Select Installation Option

Figure 6-2 shows one of the central screens in the whole installation. On this screen you define the further course of the installation, and the next steps depend on the choice you make here. Not all are applicable to the installation of an Oracle Restart environment.

Your choices in Figure 6-2 include the following:

Continue the installation by selecting option 2 “Install and Configure Oracle Grid Infrastructure for a Standalone Server” and click on the “Next” button.

Select Product Language

You can see in Figure 6-3 that Oracle supports a wide range of languages out of the box. The American English language will always be pre-selected, and should not be removed from the selection.

Select any other languages you would like to use with the Oracle Restart installation by highlighting them on the left pane and moving them over to the right pane by clicking the arrow button. Click on “Next” to advance to the ASM disk group creation screen.

Create ASM Disk Group

ASM has been discussed in some detail in Chapter 2. At this stage in the installation process you are going to put theory to practice by defining which LUNs are defined in a disk group, using the screen in Figure 6-4. This screen makes use of the fact that the ASM disks have already been defined on the operating system as discussed in Chapter 5.

For ASM disks to be accessible by Oracle Restart and the database in this separation-of-duties scenario, they must be owned by the grid user. The group has to be set to asmdba and the permissions on the block device must be set to 0660-otherwise the installer won’t be able to attach to the LUNs. If no disks appear, the discovery string could be wrong. In this case, click on the button labeled “Change Discovery Path” and enter an appropriate value. For example, if you are using EMC Power Path on Linux you would use /dev/emcpower* instead. Native Linux device-mapper-multipath devices require a discovery string of /dev/mapper/<some identifier>. Click into the checkboxes in front of the LUNs to select the disks to be added to the disk group. Alternatively, change the default allocation unit if you are expecting the disk group to become very large. The default name of the ASM disk group to be created is named “DATA” (change the name to match your naming standards). When you are happy with the settings continue by clicking on “Next”.

Specify ASM Password

On the screen shown in Figure 6-5 you have the choice to enter passwords for the two ASM users: SYS and ASMSNMP.

The sys account is the ASM-equivalent of the UNIX root account, and its password should therefore be chosen carefully. The ASMSNMP has been introduced in 11g Release 2 and is primarily used for monitoring the ASM instance from Enterprise Manager. Although the installer offers you to share a common password for both accounts this is strongly discouraged. Press “Next” to continue to the “Privileged Operating System Groups” screen.

Specify Privileged Operating System Groups

On the screen shown in Figure 6-6 you map your previously created operating system groups to privileged groups as defined by Oracle.

The mapping of operating system groups to Oracle’s internal groups has been discussed in great detail in Chapter 5. Here is a quick refresher of the discussion:

• Members of the Oracle ASM Administrator Group (OSASM) can connect to the ASM instance using the SYSASM privilege
• Members of the Oracle ASM DBA Group (OSDBA) can connect to the ASM instance using the SYSDBA privilege. The RDBMS owner account (oracle in most cases) must be a member of this group. Otherwise the ASM storage will not be visible to the database
• Members of the optional ASM Operator Group (OSOPER for ASM) can connect using the SYSOPER privilege

Although it is possible to assign the same operating system group to all of the Oracle groups, it is suggested to use the groups as shown in the figure for finer privilege granularity.

If you decide to use only one operating system group in this screen, OUI will flag a warning. Click on “Next” to proceed to step 7.

Specify Installation Location

Figure 6-7 shows the screen from which you specify the location of the Oracle binaries. If you followed the advice given in Chapter 5 you should not need to change much. The installer detects an Optimum Flexible Architecture file system layout and proposes the installation locations as shown in the screen. It proposes the home directory to /u01/.../12.1.0/grid. It would be better to add the patch set number to the path however to immediately identify the version of the Oracle Restart installation. When patch set two is going to be released you have to perform an out-of-place upgrade anyway. Creating the directory with the patch set number reduces the potential for mistakes.

Should you have different requirements adjust the paths to match your standards and click “Next” to proceed to the following screen.

Create Inventory

The Oracle central inventory is an important location for the maintenance of the Oracle software. It stores, among other items, which Oracle home has been installed and where. Figure 6-8 shows the screen from which you define the inventory location. The location should not be inside the ORACLE_BASE; you typically define the inventory location to be one hierarchy above the ORACLE_BASE for the Oracle account.

If the inventory location is under ORACLE_BASE, the installer will issue a warning which you should not ignore, especially when using different accounts for Grid Infrastructure and the RDBMS binaries. Although you are prompted to run a script after the transfer of the binaries to the hard disk finished OUI insists that the permissions for the inventory directory are as follows:

• Owner:            grid owner-“grid” in this example
• Group:             oinstall
• Permissions: 0770

The inventory group is determined by the grid owner’s primary group-oinstall. Again click “Next” to advance to the next screen.

Running Root Scripts Automatically

A very nice feature has been added to Grid Infrastructure allowing you to have OUI execute the root scripts to be run during the installation automatically. You can either pass the root credentials or provide information needed to use the UNIX sudo-function to execute the root and any other post-installation scripts. Figure 6-9 shows the screen from which you specific these credentials and other login details.

Perform Prerequisite checks

You are getting closer to actually transferring the binaries to disk! The installer ensures in this step that the required prerequisites for the installation are met. Depending on your configuration this can take a little while. After the verification has completed, the results are presented to you. If your preparations have been thorough you should not be met with any errors and the installer will proceed straight to the summary screen as shown in Figure 6-11. If you are curious to see the results of the checks anyway you can use the “Back” button to navigate back, the screen will look similar to Figure 6-10.

In case of errors you can either manually correct the problems by switching to a shell session, or let the installer do the hard work. Beginning with Oracle 11.2 there is an option to let OUI create a so-called fixup script on the server to be executed as root which should correct many common problems with the configuration. If a failed check has “yes” in the fixable column, then OUI can often correct it. Certain issues such as problems with main memory can obviously not be fixed automatically by the installer.

Once you have run the fixup script as root, return to the installer session and acknowledge the script execution. OUI will check the system once more to ensure you are not missing vital configuration steps.

If you opted to modify the system settings yourself, you can use the “Check Again” button to verify the system settings once more. Thankfully you are not left out in the dark with the task of correcting the settings for a failed check.

In the list of problems, click on an entry to display more information, as shown in Figure 6-11. This is the place to get detailed information about the problem by clicking on the hyperlink named “more details”. This opens the pop-up box shown. As you can see Oracle expects you to have a maximum limit of open file descriptors for the grid users set to 65536.

The error messages are helpful in most cases, and usually lead you to the source of the error quite quickly. The most common errors to be corrected are related to missing or invalid kernel parameters, swap space, and shell limits.

Once all the problems are fixed click “Next” to proceed to the summary screen.

Review the Installation Summary

The summary screen shown in Figure 6-12 wraps up all the previously made choices in one place. Review your settings and ensure that the choice made reflects your corporate standards. You can always use the “Back” button or click on the [Edit] link to go back to the relevant screen to make any corrections.

The greyed-out “Next” button indicates that there are no further screens in the installation wizard. A click on “Install” will initiate the transfer of the software to the defined location. Before doing so, take a moment and consider the creation of the response file. The response file will be needed for a silent install, which will be explained in the next section. The default location OUI offers for the response file is in the grid owner’s home directory, and is usually called grid.rsp.

Figure 6-13 shows the progress screen.

The installation proceeds by preparing, copying, and linking binaries. Once these activities are completed, a window opens as shown in Figure 6-14 and prompts you to run the “root scripts”.

Running and troubleshooting configuration scripts

There are two scripts to be executed as root for an Oracle Restart installation:

• orainstRoot.sh
• root.sh

Figure 6-14 shows you the pop-up which prompts for the script execution.

The exact path is indicated in the pop-up window, which can be copied into the clipboard. The first script to run, orainstRoot.sh, ensures that the permissions on the central inventory are set correctly. The output of the script execution is shown here:

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.

The next script-root.sh-sets up the foundation for Oracle Restart, and the output from running it is shown below:

[root@server1 ∼]# /u01/app/grid/product/12.1.0.1/grid/root.sh
Performing root user operation for Oracle 12c
 
The following environment variables are set as:
    ORACLE_OWNER= grid
    ORACLE_HOME=  /u01/app/grid/product/12.1.0.1/grid
 
Enter the full pathname of the local bin directory: [/usr/local/bin]:
   Copying dbhome to /usr/local/bin ...
   Copying oraenv to /usr/local/bin ...
   Copying coraenv to /usr/local/bin ...
 
Creating /etc/oratab file...
Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root script.
Now product-specific root actions will be performed.
Using configuration parameter file: /u01/app/grid/product/12.1.0.1/grid/crs/install/crsconfig_params
LOCAL ADD MODE
Creating OCR keys for user 'grid', privgrp 'oinstall'..
Operation successful.
LOCAL ONLY MODE
Successfully accumulated necessary OCR keys.
Creating OCR keys for user 'root', privgrp 'root'..
Operation successful.
CRS-4664: Node server1 successfully pinned.
2013/09/06 18:42:03 CLSRSC-330: Adding Clusterware entries to file 'oracle-ohasd.conf'
 
Server1     2013/09/06 18:42:32     /u01/app/grid/product/12.1.0.1/grid/cdata/server1/backup_20130906_184232.olr
2013/09/06 18:43:18 CLSRSC-327: Successfully configured Oracle Grid Infrastructure
for a Standalone Server

If you see the last line “successfully configured Oracle Grid Infrastructure for a Standalone Server”, all is well you have successfully executed the root.sh script.

In the past it has been difficult to troubleshoot problems with the root.sh script. These have gradually been addressed with the latest releases. A major improvement is the verbose logging created during the execution of the root.sh script. The file you need to consult is in somewhat hidden in $GRID_HOME/cfgtoollogs/crsconfig/roothas.log. Should you run into problems during the execution of root.sh, begin your investigation there. It shows in great detail which steps are performed on your behalf. Studying the contents of the roothas.log file can greatly improve your understanding of how Grid Infrastructure works internally, but has to be left as an exercise to the reader to do so. Unlike the root.sh for a clustered installation, the script does not seem to be restartable.

If you have adhered to the configuration described in Chapter 5, you should not have any problems with the root.sh script. Common problems encountered in the field are mismatches between /etc/hosts and DNS entries, or ignored prerequisites. Usually the error reported in roothas.log is specific enough to point you to the problem.

Finishing the installation

After the successful execution of the root scripts, click the “OK” button to dismiss the dialog. Control will return to the Oracle Universal Installer session, and the final configuration will complete the installation. This is shown in Figure 6-15.

The following steps are performed:

• Update of the inventory
• Configuration of a basic network configuration
• Creation of the ASM instance
• A final pass of the cluster verification utility

All of these operations are logged in detail in $GRID_HOME/cfgtoollogs/. The installer will automatically advance to the next screen and displays a success message. Congratulations! You have installed Oracle ASM! You may proceed by drinking a cup of well-deserved coffee before beginning the installation of the database binaries.

Preparing the RPM build environment

A few additional packages need to be installed on the host on which you are preparing to install the RPM. On Oracle Linux these are:

• rpmlint
• rpmdevtools
• Plus all their dependencies

It is not recommended to build RPMs as root. Often, the “rpmbuild” account is used, and that is the account used in the following example.

If user rpmbuild does not exist, create it:

[root@server1 ∼]# useradd -m -g users -G users rpmbuild
[root@server1 ∼]# passwd rpmbuild
Changing password for user rpmbuild.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.

Now log on as user rpmbuild to complete the process. When building RPMs, a certain directory structure is assumed, such as a top directory ($HOME/rpmbuild) and certain subdirectories:

• BUILD
• BUILDROOT
• RPMS
• SOURCES
• SPECS
• SRPMS

The easiest way to create the required directories is to call the rpmdev-setuptree command in the user’s home directory. Thankfully this is all you need to do, as it will also create a small configuration file in ∼/ .rpmmacros pointing to the newly created directory tree.

The RPM build process is controlled via a specification or “SPEC” file. Documentation of SPEC files isn’t too great, especially since the format has changed over time. The SPEC file describes the steps you would normally follow when compiling a piece of software from a source. The great benefit of the SPEC file is that it puts more structure around the process. Once you understand the SPEC file syntax the process is really powerful, but the initial learning curve is steep. The SPEC file for the Oracle Restart installation has the following content, and resides in the SPEC directory as grid.spec:

[rpmbuild@server1 SPECS]$ cat grid.spec
Name:           GridInfrastructure
Version:        12.1.0.1
Release:        1%{?dist}
Summary:        installation of Grid Infrastructure for Enterprise Linux 6.x
Group:          Applications/Databases
License:        Commercial
URL:            http://engineering.example.com/builds/
BuildRoot:      %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX)
 
Requires:       oracle-rdbms-server-12cR1-preinstall
 
%description
This RPM checks for the required RPMs on Oracle Linux 6.x and adds them
as dependencies when needed.
 
Additionally, the RPM deploys the /etc/oraInst.loc file as per the standard
document, with /u01/app/oraInventory as the central inventory.
 
This RPM is not suitable for a RAC installation, it can only install Oracle
Restart. It will install the software as the grid user.
 
After deploying the files the Oracle Universal Installer is invoked with the
silent response file from /opt/oracle/grid.rsp, and required configuration
assistants are executed. Be patient!
 
%install
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT/etc
mkdir -p $RPM_BUILD_ROOT/opt/oracle
cp oraInst.loc $RPM_BUILD_ROOT/etc/
cp grid.rsp $RPM_BUILD_ROOT/opt/oracle
cp cfgrsp.properties $RPM_BUILD_ROOT/opt/oracle
 
%post
GRID_OWNER=grid
GRID_HOME=/u01/app/grid/product/12.1.0.1/grid
 
# mount the software
umount /mnt
mount -t nfs stagingServer:/export/oracle/x64/ /mnt
 
if [ $? -ne 0 ]; then
  echo "FATAL error trying to mount the binares from the staging server"
  exit 1
fi
 
# Here we invoke the installer. Testing for FATAL errors in the installer
# output. If there is, we abort and say so
 
su - $GRID_OWNER -c 
"/mnt/12.1.0.1/grid/runInstaller -silent -responseFile /opt/oracle/grid.rsp" 
2>&1 | grep FATAL
if [ $? -eq 0 ]; then
  echo "FATAL error occured-installation NOT completed"
  touch /tmp/gridInstall.failed
  exit 2
fi
 
#wait 30x30 seconds for OUI to complete. Increase if needed!
cnt=0
while ! test -e $GRID_HOME/root.sh
do
  echo "waiting for the software installation to complete"
  sleep 30
  cnt=$(( $cnt + 1 ))
  if [ $cnt -eq 30 ]; then break ; fi
done
 
# execute the root.sh script and dependent scripts.
$GRID_HOME/root.sh
 
su - $GRID_OWNER -c  
"$GRID_HOME/cfgtoollogs/configToolAllCommands RESPONSE_FILE=/opt/oracle/cfgrsp.properties"
 
rm /opt/oracle/cfgrsp.properties
rm /opt/oracle/grid.rsp
 
%clean
rm -rf $RPM_BUILD_ROOT
 
%files
%defattr(0660, grid, oinstall)
/etc/oraInst.loc
/opt/oracle/grid.rsp
%attr(0600, grid, oinstall) /opt/oracle/cfgrsp.properties
%config /etc/oraInst.loc
 
%changelog
* Fri Sep 5 2013 Engineering <[email protected]>
- initial version
- requires more error checking

The SPEC file references three files, which need to be present in the BUILD directory. The grid.rsp file is the same just used for the silent installation and can be used without modification. The oraInst.loc file will be deployed to /etc and contains the pointer to the central inventory. It contains the following familiar lines:

[rpmbuild@server1 BUILD]$ cat oraInst.loc
inventory_loc=/u01/app/oraInventory
inst_group=oinstall

Finally the cfgrsp.properties file contains the ASM and ASMSNMP passwords, and again is identical to the one used for the silent installation.

Building the RPM

With all preparations in place it is time to build the RPM. Change directory to “SPEC” and execute the rpmbuild executable as shown here:

[rpmbuild@server1 SPECS]$ rpmbuild -ba --rebuild grid.spec
Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.gz353e
+ umask 022
+ cd /home/rpmbuild/rpmbuild/BUILD
+ rm -rf /home/rpmbuild/rpmbuild/BUILDROOT/GridInfrastructure-12.1.0.1-0.el6.x86_64
+ mkdir -p /home/rpmbuild/rpmbuild/BUILDROOT/GridInfrastructure-12.1.0.1-0.el6.x86_64/etc
+ mkdir -p /home/rpmbuild/rpmbuild/BUILDROOT/GridInfrastructure-12.1.0.1-0.el6.x86_64/opt/oracle
+ cp oraInst.loc /home/rpmbuild/rpmbuild/BUILDROOT/GridInfrastructure-12.1.0.1-0.el6.x86_64/etc/
+ cp grid.rsp /home/rpmbuild/rpmbuild/BUILDROOT/GridInfrastructure-12.1.0.1-0.el6.x86_64/opt/oracle
+ cp cfgrsp.properties /home/rpmbuild/rpmbuild/BUILDROOT/GridInfrastructure-12.1.0.1-0.el6.x86_64/opt/oracle
+ /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot
+ /usr/lib/rpm/brp-compress
+ /usr/lib/rpm/brp-strip
+ /usr/lib/rpm/brp-strip-static-archive
+ /usr/lib/rpm/brp-strip-comment-note
Processing files: GridInfrastructure-12.1.0.1-0.el6.x86_64
warning: File listed twice: /etc/oraInst.loc
Provides: config(GridInfrastructure) = 12.1.0.1-0.el6
Requires(interp): /bin/sh
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix)
<= 4.0-1
Requires(post): /bin/sh
Conflicts: Database
Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/rpmbuild/rpmbuild/BUILDROOT/GridInfrastructure-12.1.0.1-0.el6.x86_64
Wrote: /home/rpmbuild/rpmbuild/SRPMS/GridInfrastructure-12.1.0.1-0.el6.src.rpm
Wrote: /home/rpmbuild/rpmbuild/RPMS/x86_64/GridInfrastructure-12.1.0.1-0.el6.x86_64.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.3aTrRY
+ umask 022
+ cd /home/rpmbuild/rpmbuild/BUILD
+ rm -rf /home/rpmbuild/rpmbuild/BUILDROOT/GridInfrastructure-12.1.0.1-0.el6.x86_64
+ exit 0

The exit code of each step was 0, indicating success. Two RPMs have been build: the source RPM as well as the one to be deployed. Check the contents of the RPM/x86-64 directory for the result.

Installing the RPM

With the RPM in place it is time to put the procedure to a test. Transfer GridInfrastructure-12.1.0.1-0.el6.x86_64.rpm to the test yum repository server and install it using YUM as shown in this example:

[root@server1 ∼]# yum install GridInfrastructure-12.1.0.1-0.el6.x86_64.rpm

It will download and install the dependent packages from your repository and install Grid Infrastructure using the silent response file. If anything goes wrong at any phase, warnings are printed on the screen pointing you to the correct log file to check. It is recommended to try the procedure in a (virtual?) test environment first before running live builds.

Security updates

Figure 6-16 shows the security updates screen, which is very similar to the wizard shown with Oracle Restart. The database installer prompts you to enter your My Oracle Support credentials. For some time now you are prompted to provide your email address for Oracle to receive security updates and other information from Oracle. Do this at your own discretion. If you decline the option by unchecking the “I wish to receive security updates via My Oracle Support” you will be prompted once more to confirm you really want to stay uniformed of advisories. You can normally safely ignore the warning. Your enterprise monitoring solution should prompt you for security updates anyway (OEM 12 does this for example).

Proceed to the next screen by clicking the “Next” button.

Downloading updates

As with the Grid Infrastructure installation you are offered the option to download and install updates as part of the installation process. See Figure 6-17.

The options are exactly the same as shown earlier in this chapter for Grid Infrastructure. Please refer to section “Download Software Updates” for a more detailed explanation.

Selecting Installation Options

When installing the Oracle database binaries you are offered three options shown in Figure 6-18. The first is to install the binaries and then install a database. The second option, which I recommend, is to install the database software only. The final option is to upgrade an existing database as part of the installation process. It is strongly recommended not to perform that step at this stage! Take your time to plan the installation and upgrade in your own time. Please refer to Chapter 12 which is all about upgrading to Oracle 12c.

A safe way to proceed with the installation is to limit yourself to the installation of the binaries only. This makes patching significantly easier without an existing database. This is especially true in a Grid Infrastructure/RDBMS combination as proposed here. Recommended patches are most often bundled together as Patch Set Updates. These are very easy to install using the automatic detection of Oracle homes and the “opatch auto” feature. If you decided to create a database as part of the installation process you will see a few additional screens presenting a cut-down version of the database configuration assistant (dbca). It is slightly less flexible than invoking dbca directly, which is why I suggest you run it separately after the installation.

To follow the print screens, check the “Install database software only” radio button and click on “Next”.

Picking a Grid Installation Option

The screen shown in Figure 6-19 allows you to configure whether you want a single instance database installation, a Real Application Cluster, or alternatively a RAC One Node database installation. All but the single instance database installation option are not applicable unless you have a Grid Infrastructure configuration for RAC.

Leave the “Single instance database installation” radio button selected and proceed to the next screen by clicking on “Next”.

Installing Product Languages

The Oracle database comes with lots of supported languages out of the box, as shown in Figure 6-20. These should make it easy for anyone to get localized messages on the screen. You can select a language from the left-hand side, highlight it by clicking on it, and then use the single arrow to add it to the list of selected languages.

It is strongly recommended not to remove English! Once you are happy with your selection, click on “Next” to continue the installation process.

Choosing a Database Edition

The Oracle database can be licensed in many forms. On the screen in Figure 6-21 you have the option to install the Enterprise Edition, Standard Edition, and Standard Edition One. The choice depends directly on your license agreement with Oracle. Don’t be tempted to install Enterprise Edition if there is no license for it. Not only is that a breach of your contract with Oracle (which is bound to be noticed), but there is also a lot of work involved in downgrading from Enterprise Edition to Standard Edition.

In this example Enterprise Edition has been selected.

Defining the Installation Location

Figure 6-22 is the next screen in the installation wizard, and prompts you for the installation locations. You need to pick a suitable location for the Oracle base as well as the software binaries. There is no real restriction to directories, except that the software location should be in the path of the ORACLE_BASE. The Oracle base directory contains many important files, among them the admin directory. It contains the audit trail files per database. By default the Automatic Diagnostic Repository (ADR) is also located underneath the $ORACLE_BASE variable.

If you followed the instructions in Chapter 5 about the OFA, then Oracle’s installer should have picked up the directories on its own. You should consider changing the software location path to include the patch set number just as with Oracle Restart. At the time of writing only the base release was available. As a result your path should refer to 12.1.0.1 instead of just 12.1.0. Using the patch set number makes it easier to differentiate Oracle homes.

Obviously, you should adhere to your corporate standards if they contradict the OFA. You will notice that the ORACLE_BASE is different from the Grid Infrastructure installation because there was a separate account used to install Oracle Restart. Had you used “oracle” to install Grid Infrastructure and the database, then the ORACLE_BASE would have been /u01/app/oracle for both. By convention, the Oracle base variable is defined as /u01/app/user. Review the settings one last time and click on the “Next” button to continue.

Mapping Privileged Operating System Groups

The screen shown in Figure 6-23 is one of the few really new screens when comparing Oracle 12c to 11g Release 2. Previous releases only used the OSDBA and OSOPER groups, whereas Oracle 12c adds some new ones to worry about. These groups allow an even finer separation of duties. Refer back to Chapter 5 for a complete discussion of their roles and purposes.

It is of course still possible to use the “dba” operating system group exclusively for all the different groups available in Oracle, but doing so negates the advantages offered by the new system. I recommend the creation of the backupdba, dgdba, and kmdba groups on the operating system, and the Oracle user should have these assigned as its secondary groups. At the risk of repeating myself: you should create the operating system groups and map the Oracle user to them even if you are not planning to use them straight away. Configuring the database software in the new way gives you the flexibility of gradually adding functionality without having to reinstall the binaries. In the screen above the Oracle user had all of the default groups assigned, and the installer picked those up.

Review your settings and click on “Next” to proceed.

Checking the Prerequisites

Oracle will check for the required settings before starting the installation. This step is not new and has been performed in previous releases. If all prerequisites are met, the installer will bypass the screen shown in Figure 6-24 and move to the summary page. If the installer detects any problems, it will report them.

The process of fixing problems is identical to the Grid Infrastructure installation. Highlight the entry and click on the link labelled “more details” to find out what Oracle expects. If the problem reported is “Fixable”, you can make use of the fixup scripts to save yourself some time. Alternatively, correct the problem yourself on the command line, return to the OUI session and click on “Check Again” to instruct the software to reconsider.

Once you are confident that all requirements have been met, click on “Next” to proceed. If the “Next” button is greyed-out you need to check the “Ignore All” checkbox in the top-right corner of the screen after careful consideration of the impact. Be warned that ignoring requirements can lead to installation failures!

Reviewing the Installation Summary

The summary screen in Figure 6-25 presents all your choices made previously on one screen. It also allows you to save the response file, which is recommended. Carefully review all the information presented and check against your corporate standard.

Initiate the software installation by clicking on “Install”, or use the “Back” button to go back in the wizard to make any changes to the parameters you provided.

Waiting for the Installation to Complete

Congratulations, you may go and get a cup of coffee while the installation proceeds. Depending on the speed of your NFS mount, DVD drive and hard disks you may have to wait a few minutes for the software to be transferred to the server, linked and ready for use. Figure 6-26 shows the installation status screen that will keep you apprised of progress.

When the installer has almost finished its work, it presents the familiar pop-up window shown in Figure 6-27 to run the root.sh script. This will take considerably less time to execute compared with the one executed during the Grid Infrastructure installation.

The output of the root script is shown here for your reference:

[root@server1 ∼]# /u01/app/oracle/product/12.1.0.1/dbhome_1/root.sh
Performing root user operation for Oracle 12c
 
The following environment variables are set as:
    ORACLE_OWNER= oracle
    ORACLE_HOME=  /u01/app/oracle/product/12.1.0.1/dbhome_1
 
Enter the full pathname of the local bin directory: [/usr/local/bin]:
The contents of "dbhome" have not changed. No need to overwrite.
The contents of "oraenv" have not changed. No need to overwrite.
The contents of "coraenv" have not changed. No need to overwrite.
 
Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root script.
Now product-specific root actions will be performed.
[root@server1 ∼]#

This completes the interactive installation of the Oracle database 12c.