Installing IBM DB2 for Linux, UNIX, and Windows transparently with your application

Yasir Warraich and Michael Gao
Published on February 14, 2003/Updated: March 20, 2008

Unlike standard DB2® for Linux, UNIX, and Windows setup utilities, a DB2 response file installation, also known as a silent installation, lets you install DB2 without user input. This is useful not only for large-scale deployments of DB2, but also for embedding the DB2 installation process inside your own application installation. The response file installation is one of the ways DB2 provides a complete solution for your embedded database needs.

A DB2 response file installation is a background installation process that you can embed into an existing application installer and is transparent to end users. It is performed by DB2 setup utilities with user-generated response files. The response files are ASCII text files that contain setup and configuration information. They can be generated using DB2 utilities or by manual editing.

This article describes the complete DB2 response file installation process on Linux, UNIX, and Windows platforms. Response file generation and installation are described in detail, along with special considerations for embedding the DB2 installation process into your own application installer.

When embedding a DB2 installation inside your own installer, it is sometimes desirable to prune the DB2 install image. The standard DB2 image contains a lot of extras such as GUI tools, documentation in several languages, and application development support. These extras inflate your installation program footprint unnecessarily. This article also describes how to safely prune a DB2 installation image.

Generating a response file

The first step involved in the silent installation process is to generate a response file. When installing DB2 using the interactive GUI setup utility, you are prompted to make installation choices and provide necessary configuration data before installation takes place. Response files simply contain these installation choices and configuration data.

There are three methods you can use to generate a response file:

• Using the DB2 Setup wizard
• Using the DB2 response file generator utility (Windows only)
• Creating a response file manually

As previously stated, response files are simply ASCII text files. Listing 1 shows a snippet of sample of a response file.

Listing 1. Sample snippet of a response file

PROD=WORKGROUP_SERVER_EDITION 
LIC_AGREEMENT=ACCEPT
FILE=C:\Program Files\IBM\SQLLIB_03\
INSTALL_TYPE=TYPICAL
 
LANG=EN 
...
INSTANCE=DB2
DB2.NAME=DB2_03
DEFAULT_INSTANCE=DB2
DB2.SVCENAME=db2c_DB2_03
DB2.DB2COMM=TCPIP
DB2.PORT_NUMBER=50003
... 
DB2_COPY_NAME=DB2COPY3
DEFAULT_COPY=NO
DEFAULT_CLIENT_INTERFACE_COPY=NO
...

You can find a complete sample response file on your DB2 installation DVD in the following location:

• db2/<platform>/samples (where platform represents the appropriate Operating System)

The response file is named db2<edition_abbreviation>.rsp . For example, it is db2wse.rsp for DB2 Workgroup Server Edition. Table 1 shows several commonly used edition abbreviations and their descriptions.

Table 1. Commonly used DB2 product edition abbreviations

For a brief description of some of the DB2 response file keywords, see Manually generating a response file.

Using the DB2 Setup wizard

The DB2 Setup wizard is the GUI installation utility available on supported platforms. It is the program that you normally run interactively when you install DB2. Instead of, or in addition to, installing the product, you can also save all of your choices in a response file for later use.

If you have never used the DB2 Setup wizard before and need to locate it, you can find it as follows:

• For Microsoft® Windows, the executable is called setup.exe and is located at the root directory of the installation DVD or image.
• For Linux and UNIX platforms, the executable is called db2setup and is located at the root directory of the installation DVD or image.

Once the DB2 Setup wizard is launched, you can choose any of the installation types as shown in Figure 1.

Figure 1. Choosing the installation type

View image at full size

After you choose the installation type and proceed to the next screen in the wizard (shown in Figure 2), you are presented with the option of saving the installation choices in a response file, performing the installation, or both. You can also specify the location (path) and file name for the response file.

Figure 2. Creating a response file using the DB2 setup wizard

View image at full size

After this step, continue to work through the installation wizard by specifying any additional configuration choices. Once you click Finish on the final screen, all your selections will be saved in the response file you specified. Note that if you are installing in a partitioned environment, that is, an environment using the Database Partitioning Feature (DPF), then two response files are created; one for the instance-owning computer and a second one for the other participating computers.

In a DPF environment, multiple servers are clustered together to form a single logical instance and database. From the application's point of view, it looks like a non-partitioned database, but under the covers, the database gets partitioned to all the machines in the cluster. One of the partitions or servers hosts DB2's metadata, also known as DB2 catalog data. This partition becomes instance owning partition and generally does not contain much user data. Other partitions become participating partitions or servers and these contain the user data. The name of the second response file generated is based on the response file name specified.

Using the DB2 response file generator

The DB2 response file generator utility is available on Windows platforms only. The idea is to create a master installation first and then use the response file generator to create a response file that will install the same components and use the configuration as the master. The utility can also generate instance profiles to create and configure a DB2 instance. Figure 3 shows the syntax for the response file generator utility, called db2rspgn.

Figure 3. Syntax for db2rspgn utility

View image at full size

By default, db2rspgn generates profiles for all instances on the master installation along with the response file. You can choose not to create profiles for the control server instance by specifying the -nocltsv option. You can also specify individual instances to create profiles for. Profile files are put in the same directory as the generated response file.

You will have to do some minor editing on the generated response files before they are usable:

• Manually modify the file to accept the license agreement.
• Enter the user ID and password for the target system.

Creating response files manually

Since response files are simply ASCII text files, you can create them manually. You can choose to modify the sample response files provided with the DB2 installation image or type it from scratch. This method requires a solid understanding of the response file structure and keywords. Fortunately, the sample response files are well commented and self-explanatory.

Table 2 provides brief descriptions of some of the more common keywords that you might specify in the response file:

Table 2. Commonly used response file keywords

Other keywords exist to specify DB2 Administration Server settings, DB2 Instance settings, and Database settings. For a complete list of keywords, detailed description and usage information, see the sample response file on your installation DVD or the DB2 Information Center.

Using response files for unattended installation

This section describes:

• The unattended (silent) installation process
• Logging the installation
• Tracing the installation

The unattended installation process

After you generate a response file, unattended (silent) installation is straightforward. You use the same executable that you would use in the GUI installation; however, you must also provide the proper response file name. You can also specify other options such as log file path and name.

Listing 2 shows the syntax for the Setup utility on Windows. Only the response file name with the full path is mandatory for a response file installation.

Listing 2. Syntax for setup utility on Windows platforms

setup [/f] [/i <language>] [/l <log file>] [/u <response file>] [/t <trace file>] 
/? - generates this usage message 
/f - forces any db2 processes to stop before installing 
/i - two letter code for the preferred language 
/l - full path and name of the log file 
/u - full path and name of the response file 
/t - creates a file with install trace information

On Linux and supported UNIX platforms, use the db2setup syntax shown in Listing 3.

Listing 3. Syntax for the db2setup utility on Linux and UNIX platforms

>>-db2setup--+---------------+--+---------------+--------------->
             '- -i--language-'  '- -l--log_file-'   

>--+-----------------+--+--------------------+--+-----+--------><
   '- -t--trace_file-'  '- -r--response_file-'  +- -?-+   
                                                '- -h-'

The unattended installation process runs in the background. No DB2 installation GUI screens appear. When embedded with your own installer, the DB2 installation appears to be part of your installation process. Upon completion, the DB2 installation process returns a return code to your program. You can choose to monitor the return code in your installer. Table 3 and Table 5 contain the primary return codes for Linux, UNIX, and Windows. The primary return codes are the most commonly received and you should code to handle them. There are also secondary return codes, which are less commonly seen. These codes are in Table 4 and Table 6. These four tables can also be found in the DB2 Information Center.

Table 3. Primary response file installation return codes on Windows

Table 4. Secondary response file installation return codes on Windows

Table 5. Primary response file installation return codes on Linux and UNIX

Table 6. Secondary response file installation return codes on Linux and UNIX

Logging the installation

The path and the name of the log file are optional parameters to the DB2 setup program. If you do not specify the name and the path of the log file, default log files are created for you in the default directory:

• On Windows, the default file name is DB2-ProductAbbreviation-DateTime.log For example: DB2-ESE-Wed Jun 21 11_59_37 2006.log. The default location for the installation log is the My Documents\DB2LOG\ directory under the user account which the DB2 installation was performed with.
• On Linux and UNIX platforms, the default file name is db2setup.log is found in the /tmp directory. You may also find some other DB2 generated files in that directory. The db2setup.his log file maintains a history of current and past installations. The db2setup.err log file contains all the error entries. For non-root installations, the default log file is /tmp/db2setup_userID.log, where userID represents the user ID that owns the non-root installation.

Tracing the installation

The path and the name of a trace file are also optional parameters to DB2 setup program. Trace files contain service information for IBM support and are not really meant for users. You can safely remove them after a successful installation. When you do choose to create the trace file, the DB2 installation log files are generated in verbose mode, which means that much more detailed information is generated in the log files.

Special considerations

If you intend to use a response file for deploying DB2 on many machines or for embedding it in an application installer, make sure you check prerequisites, ensure that no DB2 processes are running, and have a plan for handling a failed installation.

Checking prerequisites

Like the DB2 GUI setup wizard does, make sure that all prerequisites are met in your own installation script before starting the DB2 response file installation process. Prerequisites include both user privileges and system configuration. DB2 installation prerequisites are well documented in both the DB2 documentation and the readme files on the installation DVDs. If you are performing a non-root installation(Linux/UNIX only), then there are further requirements and restrictions that apply. See the DB2 Information Center for more details.

Killing DB2 processes before starting an installation

A DB2 installation cannot occur when there are active DB2 processes running. On Windows only, you could use either the KILL_PROCESSES keyword in the response file or the /F option on with the setup command to kill active DB2 processes. However, killing DB2 processes can cause loss of data. You might want to issue db2stop on each instance instead. See the DB2 Information Center for complete syntax before using the db2stop command.

User program intervention

User program intervention is not possible during the DB2 response file installation. After the installation process has started, it will run on its own. All your installation program must do is monitor the final return code.

Failed installation

When the installation fails, the DB2 installation process normally cleans up any partially installed component. Your own installation program could parse and check the log files or check the return codes to pinpoint the problem. If the problems can be remedied, you can try to install DB2 again.

Creating and setting up databases

After you have DB2 installed and configured, the next logical steps are:

1. Create your database.
2. Create your database objects, such as tables, views, triggers, functions and procedures.
3. Populate your tables with data.

While these tasks are beyond the scope of this article, they are discussed here briefly for completeness. How you create and set up your databases largely depends on the programming languages you use. You can do this setup with scripts, or with programs written in C, Java^TM and many other programming languages of your choice. You can even do it with a combination of scripts and programs. The simplest way to create a database is to manually add a database section in the response file. A database will be created for you at the end of the installation. Listing 4 shows a snippet of a response file that creates a database called MY_DB1 in the DB2INST1 instance.

Listing 4. Sample database section in response file

...
DATABASE = MY_DB
MY_DB.INSTANCE = DB2INST1 
MY_DB.DATABASE_NAME = MY_DB1
MY_DB.LOCATION = LOCAL
MY_DB.ALIAS = MY_DB1
MY_DB.USERNAME = username
MY_DB.PASSWORD = password
...

You can also create databases with scripts or with DB2 native C APIs. After the database is created, the database objects can be created and tables can be loaded. Again you can use many programming languages and their corresponding APIs for loading data, such as C and ODBC/CLI, or Java and JDBC. If you have a large amount of data to load, consider using the DB2 IMPORT or LOAD utilities. For syntax and usage of IMPORT and LOAD, see the DB2 Information Center.

Uninstalling DB2

You can also embed DB2 uninstallation in your own uninstallation program. The following sections describe the uninstall process step-by-step.

Uninstalling DB2 on Windows

On Windows systems, you need to perform the following steps, in this order:

1. Drop all databases by entering the following command:

   DROP DATABASE database-alias

2. Disconnect all applications by entering the following command:

   FORCE APPLICATION ALL

3. Stop all DB2 processes and services by entering the following commands:
   

   db2stop

   
   and

   db2admin stop

4. Remove DB2 product. To do this programmatically, use the db2unins command. For example, to uninstall DB2 Enterprise Server Edition(ESE), you would use:
   

   db2unins -p "ESE"

   
   To uninstall DB2 silently using a response file, you would use:

   db2unins -u <response file>

For more information about the above commands, refer to the DB2 Information Center.

Uninstalling DB2 on Linux and UNIX

On Linux and UNIX, you need to perform the following steps, in this order:

1. Drop all databases by entering the following command:
   DROP DATABASE database_alias.
2. Stop the DB2 Administration Server by logging in as the DB2 administration server owner and issuing the db2admin stop command.
3. Stop all DB2 instances by repeating the following steps for each instance you created:
   1. Log in as the instance owner.
   2. Severe all database connections by entering the FORCE APPLICATION ALL command.
   3. Stop the DB2 database manager by entering the db2stop command.
4. Remove the Administration Server:
   1. Log in as root.
   2. Issue the command:
      /opt/ibm/db2/V9.5/instance/dasdrop.
5. Remove DB2 instances by repeating the following steps for each instance you created:
   1. Log in as root.
   2. Issue the /opt/ibm/db2/V9.5/instance/db2idrop InstanceName command.
   3. Remove the instance owner's user ID and group if you created them during installation and if they are used only by your program.
6. Remove DB2. You must have root authority for uninstalling.
   • Use the db2_deinstall command in the root directory of the DB2 DVD or image.

The commands given in the steps above are the same for all Linux and UNIX platforms. However, the install paths vary depending on the operating system. In the previous example, we have shown installation paths for Linux. For more information on above installation paths and DB2 commands, refer to the DB2 Information Center.

Pruning DB2 install images

It can be useful to prune DB2 install image to remove unecessary components for large-scale deployments of the DB2 product, as well as for embedding DB2 within an application. Pruning can give you a smaller installation image footprint, that is faster to transfer and install. After pruning the install image, it is highly recomended that you thoroughly test the pruned image to make sure that no required items have been taken out and all the features you need are available. If you choose to prune the install image, you should choose the CUSTOM installation type, as shown in Figure 1. It allows you to uncheck any components that you have removed from the installation image. If you choose a TYPICAL or COMPACT installation with a pruned install image, you may get an eror message about missing files.

Pruning a DB2 install image on Windows

The db2iprune utility is available on Windows only to automate the process of pruning the install image. It removes the Windows cabinet(.cab) files associated with those features as well as any languages that are marked for pruning based on the pruning input file. There is a sample input file (.prn file) available on the installation DVD at db2\Windows\utilities\db2iprune. The input file, which resembles a response file, allows you to specify which features and languages you would like to remove from the installation image. The result is a new, smaller DB2 installation image that can be installed using the regular DB2 installation methods. There is a two step process to prune the DB2 installation image on Windows:

1. Open the sample input .prn file provided in the installation image. Uncomment the features or languages that you want to remove by removing the asterik(*). Input file contains three keywords:
   • PROD specifies the product to be installed
   • LANG specifies the languages
   • COMP specifies the features
2. Once you have a customized .prn file ready you can run db2iprune command. Syntax for db2iprune command is as follows:

   db2iprune -r input_file_path -p root_directory_path -o destination_directory_path

   
   where "-r" specifies the input .prn file, "-p" specifies the location of source image and "-o" specifies the output location for the pruned installation image.

If you are using the response file installation method, do not specify any languages or features in the response file that are not available in the pruned image, otherwise the installation will fail.

Pruning DB2 install images on Linux and UNIX

On non-Windows platforms, there is no utility available to prune installation images. Included with this article are two scripts (db2lnx32.sh and db2lnx64.sh) that can be used to prune DB2 images for supported 32 bit and 64 bit Linux distributions, respectively. This sample script removes the following:

• Documentation files for all languages except English and Japanese
• GUI installer (After removing this component, you can only use response file installation)
• License files for all languages except English and Japanese
• Language locales except English and Japanese
• Samples directory

The script should be run from the root directory of the installation image where the db2 and doc subdirectories exist. These scripts simply issue "rm" commands to remove the files and subdirectories corresponding to the components listed above. You should review and customize the sample scripts before using them.

Further pruning can be performed by removing some of the components. For Linux and UNIX platforms, a file called ComponentList.htm is located in the db2/linux directory on the DB2 product DVD. It lists components by three categories:

• REQUIRED
• TYPICAL
• OPTIONAL

The REQUIRED components should not be removed, but TYPICAL and OPTIONAL ones can be removed if you do not need them. There is one compressed archive file per component. File names corresponding to the components are also listed and these files are located in the db2/<platform>/FILES/ directory. Some components show up in multiple sections, e.g. a component may show up in both the REQUIRED and TYPICAL sections. A component cannot be removed as long as it is listed in REQUIRED section. As mentioned earlier, you should use the CUSTOM installation type (see Figure 1) when installing from a pruned image. This allows you to uncheck any components that you have removed from the installation image. You should test the pruned installation image thoroughly to ensure that DB2 installs and functions properly.

Conclusion

By using a DB2 response file installation, you can transparently install DB2 in your own application installer. This method of installation eliminates the need for user input and provides you with detailed and timely installation progress information through log files. You also have the option of pruning the installation image size in order to reduce its size. Using a response file installation is great for performing large-scale DB2 deployments or for embedding DB2 in your application's installation process.

Acknowledgements

The authors express their gratitude for the help received from Darin McBride of the IBM Toronto Lab.

Downloadable resources

• PDF of this content
• Sample DB2 pruning scripts for Linux (db2linuxprune.zip | 3KB)

Related topics

• "Leverage data partitioning for scalability and high performance on Linux" (developerWorks, Jan 2006) explores the performance and scalability advantages of the IBM DB2 Universal Database Data Partitioning Feature (DPF) in DB2 UDB for Linux, UNIX, and Windows.
• DB2 9.5 Online Information Center: The DB2 online (and searchable) documentation is your source for information on DB2 for Linux, UNIX, and Windows.
• Download a free trial version of DB2 Enterprise 9.
• Now you can use DB2 for free. Download DB2 Express-C, a no-charge version of DB2 Express Edition for the community that offers the same core data features as DB2 Express Edtion and provides a solid base to build and deploy applications.
• Visit the developerWorks resource page for DB2 for Linux, UNIX, and Windows to read articles and tutorials and connect to other resources to expand your DB2 skills.
• Download IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.