Installing the Oracle Database - Expert Consolidation in Oracle Database 12c - page 178

These servers are very important for day-to-day information and therefore must also be protected locally. This can
be achieved by using storage array replication or another rsync process to a local clone of the server for example.
Although they should not need mentioning, regular file system backups are of course mandatory.
Once the software is staged, NFS could be used to make the software available for the database servers. In the
following example, it is assumed that the software is stored in /media/oracle/x64/12.1.0.1/grid and database .
In order to stage the software, download the latest version of the binaries and use the unzip command to extract
the binaries on the staging server, as shown in this example:

[root@stagingServer ~] # cd /path/to/nfs/export/oracle/x64/12.1.0.1/
[root@stagingServer ~] # unzip -q V38501-01_1of2.zip
[root@stagingServer ~] # unzip -q V38500-01_1of2.zip
[root@stagingServer ~] # unzip -q V38500-01_2of2.zip

Now change permission of the files to match your environment and configuration. You should ensure that you
are exporting the file system read only and with maximum security settings enabled to prevent users from tampering
with the installation! Standardized (UNIX) user and group IDs work very well toward this goal.

Preparing your environment variables
Whichever way you decided to stage the software—locally or exported via the network—you need to configure the grid
user's environment appropriately before continuing. If you followed the suggestions outlined in Chapter 5, you should
have an OFA-compliant setup of directories with correct permissions. The most common pitfall is to have incorrect
directory permissions for the inventory, usually /u01/app/oraInventory . The grid user must be the directory owner
and the oinstall group should have been assigned.
On systems with small root file systems you might run into problems due to a lack of space in the temp directory.
By default Oracle Universal installer bootstraps parts of itself to the /tmp directory before launching. If there is
insufficient space, this step will fail. Space pressure is added by the fact that unfinished OUI sessions are not cleared
up. Additionally, OUI checks for the existence of 1GiB of free space in that same directory and you are doing well to
respect that requirement. To circumvent the problem you could create a temporary directory on your oracle mount
point, and redirect the TMP and TEMP environment variables at it:

[grid@server1 ~]> mkdir /u01/app/grid/temp
[grid@server1 ~]> export TMP=/u01/app/grid/temp
[grid@server1 ~]> export TEMP=/u01/app/grid/temp

With these settings the Oracle installer will use $TEMP for its bootstrap process.

Configuring your graphical user interface
Oracle Universal Installer on the UNIX platform requires a graphical user interface to start an interactive session. In
the UNIX world, the “GUI” is provided by the X11 software stack. An X-client such as the installer process attaches to
an X-server. For most UNIX software this would be a local-to-local connection on a workstation. Very few database
systems in the real world however will allow the administrator to use the local console to install the Oracle software!
Many even won't have the X11 libraries and binaries which are required for the GUI installed. There are two ways
around this:

• Forward X11 via SSH

• Use the VNC server

Let's have a look at these options in detail.