Oracle Response Files – Part 2

Part
One
of Oracle Response Files covered the basics of using a response file
and provided an example of how to install Developer Suite on a Windows PC. In
Part Two, we will go into more detail about the components of response files.
This part will also discuss some related topics as they pertain to the Oracle
Universal Installer and some Windows-analogous installation concepts.

The Benefits of Using Response Files

To reiterate a key reason why you would want to use a
response file, think "write once, install many." The "write once"
concept has to do with creating a standard response file used for, well,
standard installations. This is especially pertinent to client-server
environments, whether your Oracle product is SQL*Plus or Oracle Forms. The idea
behind "install many" should be obvious and the main benefits of this
has to do with standardizing Oracle product installations and making the installation
process fairly transparent to your user community.

Why shouldn’t Oracle products be installed in a standard
manner? Actually, there is no real reason why they shouldn’t be, and this
applies to Windows PCs as well as UNIX boxes. Within an organization, the only
variables are those concerning the mount points or start of the installation
tree. Most users get their hardware from an IS department, and your
personality-challenged IS employees have an obvious motivation to standardize
formatting of hard drives and installation of products. Product installation is
especially critical with respect to seat or user licenses.

If your company-issued PC comes with C and D drives, and
your UNIX workstations use partitions such as /opt1 and /opt2 for user
installed products, all you have to do is determine the name of the next level.
Use short, descriptive names such as ora10g, oradev6, ias10g, and so on. Your
Developer Suite ORACLE_HOME then becomes D:ids10g on Windows, and
/opt1/ids10g/app/oracle/product/9.0.4 on UNIX.

As a quick aside, Windows does not have the same standards
or guidelines as UNIX does when considering Oracle’s Optimal Flexible
Architecture (OFA). I hate having to watch or be part of a CSI: UNIX episode
when sitting down at a box and wasting time figuring out some obscure
installation methodology. It hurts me to see things installed in the usr
directory. The "usr" partition Solaris (for example) creates has to
do with UNIX system resources. Oracle Forms 6.0 is not a UNIX system resource.
Trust me on that.

Now that your installation paths are standardized and you
know how disks are partitioned, the installation process pretty much comes down
to one step: executing the installer and specifying the response file. On
Windows, C:Program Files is automatically created, so there is no extra step
involved as there is on UNIX, if this is the first Oracle product being
installed. This leads to two potential gotcha’s for UNIX installations.

UNIX systems require you to run the oraInstRoot.sh script as
root the first time an Oracle product is installed. The result is a file named oraInst.loc
in the /var/opt/oracle directory (which is also created). A silent installation
will error out if the oraInst.loc file does not exist. The other potential
gotcha has to do with the DISPLAY environment variable. If you choose to show
any of the OUI GUI windows, DISPLAY must be set accordingly.

The Downside of Using Response Files

None.

The Internal Components of a Response File

The definitive source about what makes up a response file is
the Oracle Universal Installer Concept Guide. Maybe you have seen this
document, maybe not. Either way, there is a good chance you have never read
anything inside.

Oracle’s response file templates follow the sections shown
in the table below. The example I provided in Part One follows this format or
structure, so hopefully the table gives you a better idea of what takes place
where. The part you are most familiar with in an attended installation is the
Session section, that is, the dialogue windows where you enter information or
select options.

Response
File Sections

Function

General

The General Section contains the version number
of the response file.

Include

The Include section contains a list of response
files that are included in this response file.

Session

The Sessions section lists various dialogs of
the Oracle Universal Installer.

Components

Component sections define public variables. They
can also define installer variables.

What is interesting to note is that you can use response
files to de-install Oracle products. If you have ever watched the paint dry in
your office while waiting for the OUI to uninstall a product, then you will
really appreciate this feature or option, especially if you have to repeat this
process on numerous machines.

If you open the installation log (found in the C:Program
FilesOracleInventorylogs directory) for your product installation, you can
verify that response file variables were, in fact, actually used by OUI. Why is
that important? It is important because non-fatal errors (incorrect value, setting,
or format) are ignored. If you made a mistake in your response file, you may be
able to notice it in the installActions<date-time group> text file. A
sample of one is shown below (it is from the installation I performed for the
previous article).

Note: some lines are truncated for presentation here.


Using paramFile: C:DS10gDisk1installwin32oraparam.ini

Checking requirements…

Checking operating system version: must be 4.0, 5.0, 5.1 or 5.2.
Actual 5.1 Passed

Checking monitor: must be configured to display at least 256 colors.
Actual 4294967296 Passed

All requirements met.

Checking if CPU speed is above 300 MHz.
Actual 2519MHz Passed
Environment Variables:
ORACLE_HOME =
PATH = C:oracleproduct10.1.0Db_1bin;
CLASSPATH =
Username:Steve
This installation is being performed using response file
C:/DS10g/Disk1/stage/Response/oracle.ids.toplevel.development.BI.rsp.

Oracle Universal Installer version is 2.3.0.10.0

This installation is being performed using response file
C:/DS10g/Disk1/stage/Response/oracle.ids.toplevel.development.BI.rsp.
Setting variable ‘FROM_LOCATION’ to ‘C:DS10gDisk1stageproducts.jar’.
Received the value from response file.
Setting variable ‘FROM_LOCATION_CD_LABEL’ to ‘LABEL1’. Received the value
from response file.
Setting variable ‘ORACLE_HOME_NAME’ to ‘DS10g_HOME’. Received the value
from response file.
Setting variable ‘ORACLE_HOME’ to ‘C:DS10g’. Received the value
from response file.
Setting variable ‘COMPONENT_LANGUAGES’ to ‘en,’. Received the value
from response file.
Setting variable ‘TOPLEVEL_COMPONENT’ to
‘oracle.ids.toplevel.development,9.0.4.0.1,’. Received the value
from response file.
Setting variable ‘INSTALL_TYPE’ to ‘BI’. Received the value from response
file.
Setting variable ‘SHOW_SPLASH_SCREEN’ to ‘false’. Received the value from
response file.
Setting variable ‘SHOW_WELCOME_PAGE’ to ‘false’. Received the value from
response file.

Oracle product installation on UNIX leaves a similar
footprint. You can use the install log to validate an installation. A
successful installation does not necessarily mean everything you wanted to have
happen took place, so it behooves you to validate and verify your response file
inputs.

Similarities with Windows

Microsoft makes extensive use of response files. Like Oracle’s
free online documentation at http://tahiti.oracle.com,
you can see (also free) Windows technical information at http://www.microsoft.com/technet.
The following link takes you to a very good discussion of why you would want to
use a particular installation method, and you can see the shadow of the Windows
approach in Oracle’s limited, but practical response files (http://www.microsoft.com/technet/prodtechnol/Windows2000Pro/
deploy/w2koffice/dep03.mspx
).

Why do we care about how Windows is installed? If you can
get your IS department to use Oracle response files, the installation of an
Oracle product can be performed right after the Windows installation process.
You simply tell Windows to run another script after the PC’s OS and other
Windows products or applications are installed. Isn’t that the ideal situation
– getting someone else to do your work for you? Moreover, what happens when
your company decides to upgrade to XP from NT or 2000? Doesn’t it make sense to
have your Oracle products installed at the same time?

In Closing

Response files may be an untapped resource for you and your
organization. You can be certain your Windows administrator uses some form of
them, and it is fairly likely your UNIX admin uses them as well. If you provide
a step-by-step installation guide for Oracle products (because your application
uses Oracle), consider using a response file on your next release. If your
organization is planning to move to XP, talk to your IS counterparts, (if you
are not part of that department), and arrange to have the Windows "installer"
take care of installing Oracle for you.

»


See All Articles by Columnist
Steve Callan

Steve Callan
Steve Callan
Steve is an Oracle DBA (OCP 8i and 9i)/developer working in Denver. His Oracle experience also includes Forms and Reports, Oracle9iAS and Oracle9iDS.

Latest Articles