Oracle Response Files - Part 2
October 13, 2004
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
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.
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 Files\Oracle\Inventory\logs 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:\DS10g\Disk1\install\win32\oraparam.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:\oracle\product\10.1.0\Db_1\bin; 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 188.8.131.52.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:\DS10g\Disk1\stage\products.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,184.108.40.206.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/
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?
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.