Db2 Step by Step Installation Guide

IBM DB2 9.
7 for Linux, UNIX, and Windows
Installing DB2 Servers
GC27-2455-00
IBM DB2 9.7 for Linux, UNIX, and Windows
GC27-2455-00
Note Before using this information and the product it supports, read the general information under Appendix C, Notices, on page 291.
Edition Notice This document contains proprietary information of IBM. It is provided under a license agreement and is protected by copyright law. The information contained in this publication does not include any product warranties, and any statements provided in this manual should not be interpreted as such. You can order IBM publications online or through your local IBM representative. v To order publications online, go to the IBM Publications Center at www.ibm.com/shop/publications/order v To find your local IBM representative, go to the IBM Directory of Worldwide Contacts at www.ibm.com/ planetwide To order DB2 publications from DB2 Marketing and Sales in the United States or Canada, call 1-800-IBM-4YOU (426-4968). When you send information to IBM, you grant IBM a nonexclusive right to use or distribute the information in any way it believes appropriate without incurring any obligation to you. Copyright International Business Machines Corporation 1993, 2009. US Government Users Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Contents
Part 1. Installing DB2 Servers . . . . 1
Chapter 1. Before you install . . . . . . 3
DB2 servers and IBM data server clients . . . . . DB2 installation methods . . . . . . . . . . Supported DB2 interface languages . . . . . . . Displaying the DB2 Setup wizard in your national language (Linux and UNIX) . . . . . . . . Language identifiers for running the DB2 Setup wizard in another language . . . . . . . . Changing the DB2 product interface language (Windows) . . . . . . . . . . . . . . Changing the DB2 interface language (Linux and UNIX) . . . . . . . . . . . . . . . 3 3 5 5 6 7 8 DB2 users and groups (Linux and UNIX) . . . . Centralized user-management considerations (Linux and UNIX) . . . . . . . . . . . . . . Preparing to install DB2 for Linux on zSeries . . . Creating group and user IDs for a DB2 database installation (Linux and UNIX) . . . . . . . . OS user limit requirements (Linux and UNIX) . . . DB2 products in a workload partition (AIX) . . . Kernel parameters (Linux and UNIX) . . . . . . Modifying kernel parameters (HP-UX) . . . . Recommended kernel configuration parameters (HP-UX) . . . . . . . . . . . . . . Modifying kernel parameters (Linux) . . . . . Modifying kernel parameters (Solaris Operating System) . . . . . . . . . . . . . . . Additional partitioned database environment pre-installation tasks (Linux and UNIX) . . . . . Updating environment settings for a partitioned DB2 installation (AIX) . . . . . . . . . . Setting up a working collective to distribute commands to ESE workstations (AIX) . . . . Verifying port range availability on participating computers (Linux and UNIX) . . . . . . . Creating a DB2 home file system for a partitioned database environment . . . . . . Verifying that NFS is running (Linux and UNIX) 36 37 38 39 40 41 43 43 43 43 45 45 45 47 48 49 56
Chapter 2. Installation requirements for DB2 database products . . . . . . . . 9

Disk and memory requirements . . . . Java software support for DB2 products . . Installation requirements for DB2 servers and data server clients (Windows) . . . . . Installation requirements for DB2 servers and data server clients (AIX) . . . . . . . Installation requirements for DB2 servers and data server clients (HP-UX) . . . . . . Installation requirements for DB2 servers and data server clients (Linux) . . . . . . Installation requirements for DB2 servers and data server clients (Solaris) . . . . . . . . . . IBM . . IBM . . IBM . . IBM . . IBM . . . 10 . 11 . 14 . 16 . 17 . 20 . 21
Chapter 6. Mounting product CDs or DVDs on Linux or UNIX . . . . . . . 59

Mounting Mounting Mounting Mounting CDs or CDs or the CD CDs or DVDs (AIX) . . . . . . . . DVDs (HP-UX) . . . . . . . or DVD (Linux) . . . . . . . DVDs (Solaris Operating System) 59 59 60 60
Chapter 3. Password rules . . . . . . 23 Chapter 4. Additional Windows requirements . . . . . . . . . . . . 25

DB2 services running on your system (Windows) . Required user accounts for installation of DB2 server products (Windows) . . . . . . . . Setting up Windows elevated privileges before installing a DB2 product (Windows) . . . . . Preparing the environment for a partitioned DB2 server (Windows) . . . . . . . . . . . Granting user rights (Windows) . . . . . . Fast communications manager (Windows) . . . Extending the Active Directory Schema for LDAP directory services (Windows) . . . . . . . Verifying port range availability on participating computers (Windows) . . . . . . . . . . . 25 . 26 . 29 . 31 . 32 . 33 . 33 . 34
Chapter 7. Installing on Windows . . . 63

An overview of installing your DB2 server product (Windows). . . . . . . . . . . . . . . 63 Installing DB2 servers (Windows) . . . . . . . 63 Multiple DB2 copies on the same computer (Windows). . . . . . . . . . . . . . . 66
Chapter 8. Installing on Linux and UNIX 73

An overview of installing your DB2 server product (Linux and UNIX) . . . . . . . . . . . . Installing as a root user . . . . . . . . . . Installing DB2 servers using the DB2 Setup wizard (Linux and UNIX) . . . . . . . . Installing as a non-root user . . . . . . . . . Non-root installation overview (Linux and UNIX) Differences between root installations and non-root installations . . . . . . . . . . Limitations of non-root installations . . . . . Installing a DB2 product as a non-root user. . . Enabling root-based features in non-root installations with db2rfe . . . . . . . . . 73 74 74 77 77 77 78 81 82
Chapter 5. Additional Linux and UNIX requirements . . . . . . . . . . . . 35

Multiple DB2 copies on the same computer (Linux and UNIX) . . . . . . . . . . . . . . 35 Fast communications manager (Linux and UNIX) . 36
Copyright IBM Corp. 1993, 2009
iii
Chapter 9. Setting up a partitioned database environment . . . . . . . . 85

Setting up a partitioned database environment . . 85 Installing database partition servers on participating computers using a response file (Windows) . . . . 87 Verifying access to the registry on the instance-owning computer (Windows) . . . . . 88
Part 2. Installation methods that require manual configuration (Linux and UNIX) . . . . . . . . . 127
Chapter 12. Installing a DB2 product using the db2_install or doce_install command (Linux and UNIX) . . . . . 129 Chapter 13. Installing DB2 products with payload files (Linux and UNIX) . . 133 Chapter 14. Manually configuring DB2 servers after installation. . . . . . . 137
Creating group and user IDs for a DB2 database installation (Linux and UNIX) . . . . . . . Creating group and user IDs in a partitioned database environment . . . . . . . . . Creating required users for a DB2 server installation in a partitioned database environment (AIX) . . . . . . . . . Creating required users for a DB2 server installation in a partitioned database environment (HP-UX) . . . . . . . . Creating required users for a DB2 server installation in a partitioned database environment (Linux) . . . . . . . . . Creating required users for a DB2 server installation in a partitioned database environment (Solaris Operating System) . . Creating the DB2 Administration Server (Linux and UNIX) . . . . . . . . . . . . . Creating an instance using db2icrt . . . . . Creating links for DB2 files . . . . . . . . Configuring TCP/IP communications for a DB2 instance . . . . . . . . . . . . . . . 137 . 139
Chapter 10. Response file installation
89
Response file install basics . . . . . . . . . 89 Response file uninstall basics . . . . . . . . 89 Response file considerations . . . . . . . . . 91 Creating a response file using the DB2 Setup wizard 92 Response file installation of DB2 overview (Linux and UNIX) . . . . . . . . . . . . . . 93 Creating a response file using the sample response file (Linux and UNIX) . . . . . . . 93 Installing a DB2 product using a response file (Linux and UNIX) . . . . . . . . . . . 94 Installing database partition servers on participating computers using a response file (Linux and UNIX) . . . . . . . . . . . 95 Response file error codes (Linux and UNIX) . . 95 Uninstalling a DB2 product, feature, or language using a response file (Linux and UNIX) . . . . 96 Response file installation of DB2 overview (Windows). . . . . . . . . . . . . . . 97 Making the DB2 installation files available for a response file installation (Windows) . . . . . 97 Setting up shared access to a directory (Windows). . . . . . . . . . . . . . 98 Editing a response file (Windows) . . . . . . 98 Installing a DB2 product using a response file (Windows). . . . . . . . . . . . . . 99 Installing DB2 products using Microsoft Systems Management Server (SMS) . . . . . . . . 100 The response file generator . . . . . . . . 106 Response file error codes (Windows) . . . . 106 Response file installation using a batch file (Windows) . . . . . . . . . . . . . 107 Available sample response files . . . . . . . 108 Response file keywords . . . . . . . . . . 108 Embedding the DB2 installation image (Linux and UNIX) . . . . . . . . . . . . . . . . 120 Exporting and importing a profile . . . . . . 121 Stopping DB2 processes during an interactive installation (Windows) . . . . . . . . . . 121 Stopping DB2 processes during a response file installation (Windows) . . . . . . . . . . 121
. 139
. 140
. 142
. 143 . 144 . 145 . 146 . 147
Part 3. After you install a DB2 Server product . . . . . . . . . . 149

Chapter 15. Verifying your installation 151
Verifying the installation of DB2 servers using First Steps (Linux and Windows) . . . . . . . . Verifying the installation using the command line processor (CLP) . . . . . . . . . . . . Verifying a partitioned database environment installation (Windows) . . . . . . . . . . Verifying a partitioned database server installation (Linux and UNIX) . . . . . . . . . . . . Directory structure for your installed DB2 database product (Windows) . . . . . . . . . . . Directory structure for your installed DB2 database product (Linux) . . . . . . . . . . . . 151 152 152 153 154 159
Chapter 11. Changing DB2 product editions . . . . . . . . . . . . . . 123

Moving between and UNIX) . . Moving between (Windows) . . DB2 database products (Linux . . . . . . . . . . . DB2 database products . . . . . . . . . . . . 123 . 124
Chapter 16. Post-installation tasks

Validating your DB2 copy . . . . . . . . Listing DB2 database products installed on your system (Linux and UNIX) . . . . . . . .
165
. 165 . 165
iv
First Steps interface . . . . . . . . . . . Deleting a Firefox browser profile . . . . . . Adding your user ID to the DB2ADMNS and DB2USERS user groups (Windows) . . . . . . Updating your 32-bit DB2 instances to 64-bit instances (Windows) . . . . . . . . . . . Setting up notification and contact lists . . . . . Changing the default DB2 and default IBM database client interface copy after installation (Windows) . . . . . . . . . . . . . . IBM data server client connectivity using multiple copies . . . . . . . . . . . . . . . . Working with existing DB2 copies . . . . . . Checking for DB2 updates . . . . . . . . . Main menu entries for DB2 tools (Linux) . . . . Applying fix packs . . . . . . . . . . . Applying fix packs to a non-root installation . . . Reducing the size of your DB2 fix pack installation image . . . . . . . . . . . . . . . . Partitioned database environment . . . . . . Format of the DB2 node configuration file . . . Updating the node configuration file (Linux and UNIX) . . . . . . . . . . . . . . . Enabling communications between database partition servers (Linux and UNIX) . . . . . Enabling the execution of remote commands (Linux and UNIX) . . . . . . . . . . . Enabling Control Center administration (Linux)
167 168 168 169 169
Chapter 21. Setting communication protocols for a DB2 instance . . . . . 221 Chapter 22. Configuring DB2 server communications (TCP/IP) . . . . . . 223
Configuring TCP/IP communications for a DB2 instance . . . . . . . . . . . . . . . 223 Updating the database manager configuration file on the server for TCP/IP communications . . . . 224 Updating the services file on the server for TCP/IP communications . . . . . . . . . . . . 224
170 180 182 183 184 185 187 187 188 188 194 196 197 199
Chapter 23. DB2 license files. . . . . 227

Applying DB2 licenses . . . . . . . . . Updating a Trial license . . . . . . . . . Registering a DB2 product or feature license key using the db2licm command . . . . . . . Registering a DB2 product or feature license key using the License Center . . . . . . . . Setting the DB2 license policy using the db2licm command . . . . . . . . . . . . . Setting the DB2 license policy using the License Center . . . . . . . . . . . . . . . Checking DB2 license compliance . . . . . . 229 . 230 . 230 . 231 . 231 . 232 . 232
Part 6. Installing Tivoli System Automation for Multiplatforms . . . 235

Chapter 24. Installing and upgrading the SA MP with the DB2 installer . . . 237
IBM Tivoli System Automation for Multiplatforms (SA MP) . . . . . . . . . . . . . . . Installing IBM Tivoli System Automation for Multiplatforms (SA MP) . . . . . . . . . . Installing IBM Tivoli System Automation for Multiplatforms (SA MP) using the DB2 installer . Installing IBM Tivoli System Automation for Multiplatforms (SA MP) using the installSAM install script . . . . . . . . . . . . . Upgrading IBM Tivoli System Automation for Multiplatforms (SA MP) . . . . . . . . . . Upgrading IBM Tivoli System Automation for Multiplatforms (SA MP) using the DB2 installer . Upgrading IBM Tivoli System Automation for Multiplatforms (SA MP) using the installSAM install script . . . . . . . . . . . . . Uninstalling IBM Tivoli System Automation for Multiplatforms (SA MP) . . . . . . . . . . Uninstalling IBM Tivoli System Automation for Multiplatforms (SA MP) using the DB2 installer . Uninstalling IBM Tivoli System Automation for Multiplatforms (SA MP) using the uninstallSAM uninstall script . . . . . . . . . . . . Installing, updating, and uninstalling DB2 High Availability Disaster Recovery (HADR) scripts for the IBM Tivoli System Automation for Multiplatforms (SA MP) . . . . . . . . . . 237 238 238
Part 4. Installing the DB2 Information Center . . . . . . . . 201

Chapter 17. DB2 Information Center installation options . . . . . . . . . 203 Chapter 18. Installation tasks . . . . 205
. 205 . 207 . 209
Installing the DB2 Information Center using the DB2 Setup wizard (Windows) . . . . . . . Installing the DB2 Information Center using the DB2 Setup wizard (Linux) . . . . . . . . Installing a DB2 product using the db2_install or doce_install command (Linux and UNIX) . . .
240 240 241
213
Starting or stopping the Information Center (Linux and Windows) . . . . . . . . . . . . . 213
242 243 244
Part 5. Configuring . . . . . . . . 215

Chapter 20. Configuring DB2 server communications using the Control Center . . . . . . . . . . . . . . 217
Configuring communication protocols for a local DB2 instance . . . . . . . . . . . . . 217 Configuring communication protocols for a remote DB2 instance . . . . . . . . . . . . . 218 DB2 server communications configuration using the Control Center. . . . . . . . . . . . 219
244
245
Contents
Installing, updating, and uninstalling DB2 High Availability Disaster Recovery (HADR) scripts for the IBM Tivoli System Automation for Multiplatforms (SA MP) using DB2 installer . . Installing, updating, and uninstalling DB2 High Availability Disaster Recovery (HADR) scripts for the IBM Tivoli System Automation for Multiplatforms (SA MP) manually . . . . . IBM Tivoli System Automation for Multiplatforms (SA MP) install and uninstall logs . . . . . . License terms for using IBM Tivoli System Automation for Multiplatforms (SA MP) integrated with IBM Data Server . . . . . . . . . . Supported software and hardware for IBM Tivoli System Automation for Multiplatforms (SA MP) . .
Removing DB2 products using the db2_deinstall or doce_deinstall command (Linux and UNIX) . . . 263 246
Chapter 28. Uninstalling non-root DB2 products (Linux and UNIX) . . . . . 265
Stopping non-root instances (Linux and UNIX) . Removing non-root DB2 products using db2_deinstall (Linux and UNIX) . . . . . . . 265 . 265
247 247
248 248
Chapter 29. Uninstalling DB2 copies and IBM database client interface copies . . . . . . . . . . . . . . 267 Chapter 30. Uninstalling fix packs . . 275
Part 7. IBM Tivoli Monitoring for Databases: DB2 Agent . . . . . . 251

Chapter 25. IBM Tivoli Monitoring for Databases: DB2 Agent . . . . . . . 253
Installing IBM Tivoli Monitoring for Databases: DB2 Agent with the DB2 installer . . . . . . 253 Uninstalling IBM Tivoli Monitoring for Databases: DB2 Agent with the DB2 installer . . . . . . 255
Part 9. Appendixes . . . . . . . . 277

Appendix A. DB2 database product and packaging information . . . . . 279 Appendix B. Overview of the DB2 technical information . . . . . . . . 281
DB2 technical library in hardcopy or PDF format Ordering printed DB2 books . . . . . . . . Displaying SQL state help from the command line processor . . . . . . . . . . . . . . . Accessing different versions of the DB2 Information Center . . . . . . . . . . . Displaying topics in your preferred language in the DB2 Information Center . . . . . . . . . . Updating the DB2 Information Center installed on your computer or intranet server . . . . . . . Manually updating the DB2 Information Center installed on your computer or intranet server . . DB2 tutorials . . . . . . . . . . . . . DB2 troubleshooting information . . . . . . . Terms and Conditions . . . . . . . . . . 281 284 285 285 285 286 287 289 289 290
Part 8. Uninstalling . . . . . . . . 257

Chapter 26. Uninstalling your DB2 product (Windows) . . . . . . . . . 259
Uninstalling your DB2 product (Windows) . . Uninstalling a DB2 product, feature, or language using a response file (Windows) . . . . . . . 259 . 260
Chapter 27. Uninstalling your DB2 product (Linux and UNIX) . . . . . . 261
Stopping the DB2 administration server (Linux and UNIX) . . . . . . . . . . . . . . . . Removing the DB2 administration server (Linux and UNIX) . . . . . . . . . . . . . . Stopping root instances (Linux and UNIX) . . . Removing DB2 instances (Linux and UNIX) . . . 261 261 262 262
Appendix C. Notices . . . . . . . . 291 Index . . . . . . . . . . . . . . . 295
vi
Part 1. Installing DB2 Servers
Chapter 1. Before you install

DB2 servers and IBM data server clients
A DB2 database system consists of a DB2 server and IBM data server clients. A DB2 server is a relational database management system (RDBMS) that delivers data to its IBM data server clients. If you plan to use a database that resides on this computer, install a DB2 server. For more information about DB2 servers, go to http://www.ibm.com/software/data/db2/9/editions.html An IBM data server client is an application that allows you to run commands and SQL statements against a DB2 server, connect to a remote DB2 server, and access its databases.
DB2 installation methods

This topic provides information about DB2 installation methods. The following table shows the installation methods that are available by operating system.
Table 1. Installation method by operating system. Installation method DB2 Setup wizard Response file installation db2_install command Payload file deployment Windows Yes Yes No No Linux or UNIX Yes Yes Yes Yes
The following list describes DB2 installation methods. DB2 Setup wizard The DB2 Setup wizard is a GUI installer available on Linux, UNIX, and Windows operating systems. The DB2 Setup wizard provides an easy-to-use interface for installing DB2 products and for performing initial setup and configuration tasks. The DB2 Setup wizard can also create DB2 instances and response files that can be used to duplicate this installation on other machines. Note: For non-root installations on Linux and UNIX platforms, only one DB2 instance can exist. The DB2 Setup wizard automatically creates the non-root instance. On Linux and UNIX platforms, an X server is required to display the DB2 Setup wizard. Response file installation A response file is a text file that contains setup and configuration values. The file is read by the DB2 setup program and the installation is performed according to the values that have been specified. A response file installation is also referred to as a silent installation. Another advantage to response files is that they provide access to parameters that cannot be set using the DB2 Setup wizard.
On Linux and UNIX operating systems, if you embed the DB2 installation image in your own application, it is possible for your application to receive installation progress information and prompts from the installer in computer-readable form. This behavior is controlled by the INTERACTIVE response file keyword. There are a number of ways to create a response file: Using the response file generator You can use the response file generator to create a response file that replicates an existing installation. For example, you might install an IBM data server client, fully configure the client, then generate a response file to replicate the installation and configuration of the client to other computers. Using the DB2 Setup wizard The DB2 Setup wizard can create a response file based on the selections you make as you proceed through the DB2 Setup wizard. Your selections are recorded in a response file that you can save to a location on your system. If you select a partitioned database installation, two response files will be generated, one for the instance-owning computer and one for participating computers. One benefit of this installation method is that you can create a response file without performing an installation. This feature can be useful to capture the options required to install the DB2 product. The response file can be used at a later time to install the DB2 product according to the exact options you specified. You can export a client or server profile with the db2cfexp command to save your client or server configuration, and then easily import the profile using the db2cfimp command. A client or server profile exported with the db2cfexp command can also be imported during a response file installation using the CLIENT_IMPORT_PROFILE keyword. You should export the client or server profile after performing the installation and cataloging any data sources. Customizing the sample response files that are provided for each DB2 product An alternative to using the response file generator or the DB2 Setup wizard to create a response file is to manually modify a sample response file. Sample response files are provided on the DB2 product DVD. The sample response files provide details about all the valid keywords for each product. db2_install command (Linux and UNIX platforms only) The db2_install command installs all components for the DB2 product you specify with the English interface support. You can select additional languages to support with the -L parameter. You cannot select or deselect components. Although the db2_install command installs all components for the DB2 product you specify, it does not perform user and group creation, instance creation, or configuration. This method of installation might be preferred in cases where configuration is to be done after installation. To configure your DB2 product while installing it, consider using the DB2 Setup wizard.
On Linux and UNIX operating systems, if you embed the DB2 installation image in your own application, it is possible for your application to receive installation progress information and prompts from the installer in computer-readable form. This installation methods requires manual configuration after the product files are deployed. Payload file deployment (Linux and UNIX only) This method is an advanced installation method that is not recommended for most users. It requires the user to physically install payload files. A payload file is a compressed tarball that contains all of the files and metadata for an installable component. This installation methods requires manual configuration after the product files are deployed. Note: DB2 product installations are no longer operating system packages on Linux and UNIX platforms. As a result, you can no longer use operating system commands for installation. Any existing scripts that you use to interface and query with DB2 installations must change.
Supported DB2 interface languages

DB2 language support for DB2 interfaces can be categorized into server group languages and client group languages. Server group languages will translate most messages, help, and DB2 graphical interface elements. Client group languages will translate the IBM Data Server Runtime Client component, which will include most messages and certain help documentation. Server group languages include: Brazilian Portuguese, Czech, Danish, Finnish, French, German, Italian, Japanese, Korean, Norwegian, Polish, Russian, Simplified Chinese, Spanish, Swedish, and Traditional Chinese. Client group languages include: Arabic, Bulgarian, Croatian, Dutch, Greek, Hebrew, Hungarian, Portuguese, Romanian, Slovak, Slovenian, and Turkish. Do not confuse languages supported by the DB2 product with languages supported by the DB2 interface. Languages supported by the DB2 product means the languages in which data can exist. These languages are a superset of languages supported by the DB2 interface.
Displaying the DB2 Setup wizard in your national language (Linux and UNIX)
The db2setup command queries the operating system to determine the existing language settings. If the language setting of your operating system is supported by db2setup, then that language will be used when displaying the DB2 Setup wizard. If your system uses the same code pages but different locale names than those supported by the DB2 interface, you can still see the translated db2setup by setting your LANG environment variable to the appropriate value by entering the following command: bourne (sh), korn (ksh), and bash shells:
LANG=<locale> export LANG
C shell:
setenv LANG <locale>
where locale is a locale supported by the DB2 interface.
Language identifiers for running the DB2 Setup wizard in another language
If you want to run the DB2 Setup wizard in a language different from the default language on your computer, you can start the DB2 Setup wizard manually, specifying a language identifier. The language must be available on the platform where you are running the installation. On Windows operating systems, you can run setup.exe with the -i parameter to specify the two-letter language code of the language the installation is to use. On Linux and UNIX operating systems, it is recommended that you set the LANG environment variable to display the DB2 Setup wizard in your national language.
Table 2. Language identifiers Language Arabic (available on Windows platforms only) Brazilian Portuguese Bulgarian Chinese, Simplified Chinese, Traditional Croatian Czech Danish Dutch English Finnish French German Greek Hungarian Italian Japanese Korean Norwegian Polish Portuguese Romanian Russian Slovak Slovenian Language identifier ar br bg cn tw hr cz dk nl en fi fr de el hu it jp kr no pl pt ro ru sk sl
Table 2. Language identifiers (continued) Language Spanish Swedish Turkish Language identifier es se tr
Changing the DB2 product interface language (Windows)

The DB2 interface language is the language that appears in messages, help, and graphical tool interfaces. When installing your DB2 product, you have the option of installing support for one or more languages. After installation, you can change the DB2 interface language to one of the other installed interface languages. Do not confuse languages supported by a DB2 product with languages supported by the DB2 interface. Languages supported by a DB2 product means the languages in which data can exist. These languages are a superset of languages supported by the DB2 interface. The DB2 interface language you want to use must be installed on your system. The DB2 product interface languages are selected and installed when you install a DB2 product using the DB2 Setup wizard. If you change the interface language of a DB2 product to a supported interface language that has not been installed, the DB2 product interface language will default to the operating system language first, and if that is not supported, English. Changing the interface language for a DB2 product on Windows requires that you change the default language setting for your Windows operating system. To change the DB2 product interface language on Windows operating systems: 1. Through the Control Panel, select Regional and Language Options. 2. On the Regional Options tab under Standards and formats, select the appropriate language. On Windows 2008 and Windows Vista or higher, use the Formats tab for this step. 3. On the Regional Options tab under Location, select the location that corresponds to the appropriate language. 4. On the Advanced tab under Language for non-Unicode programs select the appropriate language. On Windows 2008 and Windows Vista or higher, on the Administrative tab, under Language for non-unicode programs, click Change system locale and select the appropriate language. You will then be asked to reboot, click Cancel. 5. On the Advanced tab under Default user account settings, check the Apply all settings to the current user account and to the default user profile box. On Windows 2008 and Windows Vista or higher, on the Administrative tab under reserved accounts, click Copy to reserved accounts and check the accounts that you want to copy the language settings to. 6. You will be asked to reboot before these changes come into effect. Refer to your operating system help for additional information about changing the default system language.
Changing the DB2 interface language (Linux and UNIX)

The interface language of the DB2 product is the language that appears in messages, help, and graphical tool interfaces. When installing your DB2 product, you have the option of installing support for one or more languages. If, at some time after installation, you want to change the interface language to one of the other installed interface languages, use the steps outlined in this task. Do not confuse languages supported by the DB2 product with languages supported by the DB2 interface. Languages supported by the DB2 product, that is, languages that data can exist in, are a superset of languages supported by the DB2 interface. Support for the DB2 interface language you want to use must be installed on your system. DB2 interface language support is selected and installed when you install DB2 using the DB2 Setup wizard. If you change the interface language of the DB2 product to a supported interface language that has not been installed, the DB2 interface language will default to the operating system language. If the operating system language is not supported, English is used as the DB2 interface language. DB2 interface language support is selected and installed when you install your DB2 product using the DB2 Setup wizard or by using the National Language Package. To check which public locales are available in your system, run the $ locale -a command. To change the DB2 interface language, set the LANG environment variable to the locale you want. For bourne (sh), korn (ksh), and bash shells:
LANG=<locale> export LANG
For C shell:
setenv LANG <locale>
For example, to interface with the DB2 product in French, you must have the French language support installed and you must set the LANG environment variable to a French locale, for example, fr_FR.
Chapter 2. Installation requirements for DB2 database products

Before you install your DB2 product, ensure that the system you choose meets the necessary operating system, hardware, software, communications, disk and memory requirements. Disk and memory requirements on page 10 The disk space required for your product depends on the type of installation you choose and the type of file system you have. Likewise, memory requirements are affected by the size and complexity of your database system. DB2 database and IBM data server client products There is a list of operating system, software, and hardware that must be met for each operating system, as follows: v Installation requirements for DB2 servers and IBM data (AIX) on page 16 v Installation requirements for DB2 servers and IBM data (HP-UX) on page 17 v Installation requirements for DB2 servers and IBM data (Linux) on page 18 v Installation requirements for DB2 servers and IBM data (Solaris) on page 21 prerequisites server clients server clients server clients server clients
v Installation requirements for DB2 servers and IBM data server clients (Windows) on page 14 Installation requirements for DB2 Connect products There is a list of operating system, software, and hardware prerequisites that must be met for each operating system, as follows: v Installation requirements for DB2 Connect Personal Edition (Windows) in Installing and Configuring DB2 Connect Personal Edition v Installation requirements for DB2 Connect Personal Edition (Linux) in Installing and Configuring DB2 Connect Personal Edition v Installation requirements for DB2 Connect products (Solaris Operating System) in Installing and Configuring DB2 Connect Servers v Installation requirements for DB2 Connect server products (Windows) in Installing and Configuring DB2 Connect Servers v Installation requirements for DB2 Connect server products (Linux) in Installing and Configuring DB2 Connect Servers v Installation requirements for DB2 Connect server products (AIX) in Installing and Configuring DB2 Connect Servers v Installation requirements for DB2 Connect server products (HP-UX) in Installing and Configuring DB2 Connect Servers Java software support for DB2 products on page 11 You require the appropriate level of IBM Software Development Kit (SDK) for Java to use Java-based tools and to create and run Java applications, including stored procedures and user-defined functions.
Virtualization support For details about virtualization technology supported by DB2 products, see http://www.ibm.com/developerworks/wikis/display/im/ DB2+Virtualization+Support. Installation requirements for the DB2 National Language Pack (NLPACK) On Linux and UNIX operating systems, before installing the DB2 NLPACK, a DB2 server or client product must already be installed. This list of qualified servers or clients include: v DB2 Enterprise Server Edition v DB2 Workgroup Server Edition v DB2 Personal Edition v DB2 Express Edition v DB2 Express-C v DB2 Connect Enterprise Edition v DB2 Connect Personal Edition v Data Server Client v Data Server Runtime Client Installation requirements for DB2 Query Patroller products v Installing Query Patroller server using the DB2 Setup wizard ( Windows ) in Query Patroller Administration and Users Guide v Installing Query Patroller server using the DB2 Setup wizard ( Linux and UNIX ) in Query Patroller Administration and Users Guide Installation requirements for DB2 Spatial Extender v System requirements for installing Spatial Extender in Spatial Extender and Geodetic Data Management Feature Users Guide and Reference Installation requirements for InfoSphere Federation Server products v http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/ com.ibm.swg.im.iis.prod.install.core.doc/topics/iiypisrq-sys.html v http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/ com.ibm.swg.im.iis.prod.install.core.doc/topics/iiypirrq-sys.html Installation requirements for Net Search Extender v Net Search Extender installation system requirements in Net Search Extender Administration and Users Guide
Disk and memory requirements

Disk requirements
The disk space required for your product depends on the type of installation you choose and the type of file system you have. The DB2 Setup wizard provides dynamic size estimates based on the components selected during a typical, compact, or custom installation. Remember to include disk space for required databases, software and communication products. On Linux and UNIX operating systems, 2 GB of free space in the /tmp directory is recommended.
10
Memory requirements
At a minimum, a DB2 database system requires 256 MB of RAM. For a system running just a DB2 product and the DB2 GUI tools, a minimum of 512 MB of RAM is required. However, 1 GB of RAM is recommended for improved performance. These requirements do not include any additional memory requirements for other software that is running on your system. When determining memory requirements, be aware of the following: v DB2 products that run on HP-UX Version 11i for Itanium-based systems require 512 MB of RAM at a minimum. v For IBM data server client support, these memory requirements are for a base of five concurrent client connections. You will need an additional 16 MB of RAM per five client connections. v Memory requirements are affected by the size and complexity of your database system, and the extent of database activity and the number of clients accessing your system. For DB2 server products, the self-tuning memory feature simplifies the task of memory configuration by automatically setting values for several memory configuration parameters. When enabled, the memory tuner dynamically distributes available memory resources among several memory consumers including sort, the package cache, the lock list and buffer pools. v On Linux and UNIX operating systems, SWAP space at least twice as large as RAM is recommended.
Java software support for DB2 products

You require the appropriate level of IBM Software Development Kit (SDK) for Java, listed later in this section, to use Java-based tools and to create and run Java applications, including stored procedures and user-defined functions. If the IBM SDK for Java is required by a component being installed and the SDK for Java is not already installed in that path, the SDK for Java will be installed if you use either the DB2 Setup wizard or a response file to install the product. The SDK for Java is not installed with IBM Data Server Runtime Client or IBM Data Server Driver Package. The following table lists the installed SDK for Java levels for DB2 products according to operating system platform:
Operating System Platform AIX HP-UX for Itanium-based systems Linux on x86 Linux on AMD64/EM64T Linux on zSeries

SDK for Java level SDK 6 HP SDK for J2SE HP-UX 11i platform, adapted by IBM for IBM Software, Version 6 Service Release 3 SDK 6 Service Release 3 SDK 6 Service Release 3 SDK 6 Service Release 3 SDK 6 Service Release 3 SDK 6 Service Release 3 SDK 6 Service Release 3
Linux on POWER
Solaris Operating System Windows x86
Chapter 2. Requirements for DB2 products
11
Operating System Platform Windows x64
SDK for Java level SDK 6 Service Release 3
Note: 1. The SDK for Java software can be downloaded from the developerWorks Web page at: http://www.ibm.com/developerworks/java/jdk/index.html . For a list of the supported levels of the SDK for Java, see the table later in this section entitled DB2 Database for Linux, UNIX, and Windows support for SDKs for Java. Note: For Windows operating system platforms, use the IBM Development Package for Eclipse downloads. 2. DB2 GUI tools only run on Linux on x86, Linux on AMD64/EM64T, Windows x86, and Windows x64. 3. On Windows x86 and Linux on x86: v the 32-bit SDK is installed v 32-bit applications and Java external routines are supported 4. On all supported platforms (except Windows x86, and Linux on x86): v 32-bit applications are supported v 32-bit Java external routines are not supported v 64-bit applications and Java external routines are supported
Supported Java application development software

The following table lists the supported levels of the SDK for Java. The listed levels and forward-compatible later versions of the same levels are supported. Because there are frequent SDK for Java fixes and updates, not all levels and versions have been tested. If your database application has problems that are related to the SDK for Java, try the next available version of your SDK for Java at the given level. Non-IBM versions of the SDK for Java are supported only for building and running stand-alone Java applications. For building and running new Java stored procedures and user-defined functions, only the IBM SDK for Java that is included with the DB2 Database for Linux, UNIX, and Windows product is supported. For running Java stored procedures and user-defined functions that were built by prior DB2 releases, refer to Table 1, column Java Stored Procedures and User Defined Functions for details.
Table 3. DB2 Database for Linux, UNIX, and Windows supported levels of SDKs for Java Java applications using JDBC driver db2java.zip or db2jcc.jar AIX HP-UX for Itanium-based systems Linux on POWER Linux on x86 1.4.2 to 6 1.4.2 to 6
1
Java applications using JDBC driver db2jcc4.jar 6 6

1
Java Stored Procedures and User Defined Functions 1.4.26 on page 13 to 6 1.4.26 on page 13 to 6
5
DB2 Graphical Tools N/A N/A
1.4.2 to 63,4 1.4.2 to 6

2,3,4
63,4 6
2,3,4
1.4.26 on page 13 to 6 1.4.26 on page 13 to 6
N/A 5 to 6
12
Table 3. DB2 Database for Linux, UNIX, and Windows supported levels of SDKs for Java (continued) Java applications using JDBC driver db2java.zip or db2jcc.jar Linux on AMD64 and 1.4.2 to 6 Intel EM64T processors Linux on zSeries Solaris operating system Windows on x86 Windows on x64, for AMD64 and Intel EM64T processors
2,3,4
Java applications using JDBC driver db2jcc4.jar 6

2,3,4
Java Stored Procedures and User Defined Functions 1.4.26 to 6
DB2 Graphical Tools N/A
1.4.2 to 63,4 1.4.2 to 6

2
63,4 6
2
1.4.26 to 6 1.4.26 to 6 1.4.62 to 6 1.4.26 to 6
N/A N/A 5 to 6 5 to 6
1.4.2 to 62 1.4.2 to 6
2
62 6
2
Note: 1. The same levels of the SDK for Java that are available from Hewlett-Packard are supported for building and running stand-alone client applications that run under the IBM Data Server Driver for JDBC and SQLJ. 2. The same levels of the SDK for Java that are available from Sun Microsystems are supported for building and running stand-alone client applications that run under the IBM Data Server Driver for JDBC and SQLJ. 3. A minimum level of SDK for Java 1.4.2 SR6 is required for SUSE Linux Enterprise Server (SLES) 10. A minimum level of SDK for Java 1.4.2 SR7 is required for Red Hat Enterprise Linux (RHEL) 5. 4. SDK for Java 6 support on Linux requires SDK for Java 6 SR3 or later. 5. If SDK for Java 6 SR2 or later is used, set DB2LIBPATH=java_home/jre/lib/ppc64. 6. Support for Java stored procedures and user-defined functions built by IBM SDK for Java 1.4.2 has been deprecated in Version 9.7 and might be removed in a future release. IBM SDK for Java 1.4.2 has an End of Service date of September 2011. It is recommended to remove SDK for Java 1.4.2 dependency well before this date. Removing this dependency can be done by rebuilding Java stored procedures and user-defined functions with the SDK for Java included in DB2 Version 9.1, DB2 Version 9.5, or DB2 Version 9.7. The following table lists the versions of the IBM Data Server Driver for JDBC and SQLJ that are available with DB2 database products.
Table 4. Versions of IBM Data Server Driver for JDBC and SQLJ and DB2 Database for Linux, UNIX, and Windows fix pack levels DB2 version and fix pack level DB2 Version 9.1 DB2 Version 9.1 Fix Pack 1 DB2 Version 9.1 Fix Pack 2 DB2 Version 9.1 Fix Pack 3 DB2 Version 9.1 Fix Pack 4 DB2 Version 9.1 Fix Pack 5 DB2 Version 9.5 IBM Data Server Driver for JDBC and SQLJ version1 3.1.xx 3.2.xx 3.3.xx 3.4.xx 3.6.xx 3.7.xx 3.50.xx, 4.0.xx
13
Table 4. Versions of IBM Data Server Driver for JDBC and SQLJ and DB2 Database for Linux, UNIX, and Windows fix pack levels (continued) DB2 version and fix pack level DB2 Version 9.5 Fix Pack 1 DB2 Version 9.5 Fix Pack 2 DB2 Version 9.5 Fix Pack 3 DB2 Version 9.7 IBM Data Server Driver for JDBC and SQLJ version1 3.51.xx, 4.1.xx 3.52.xx, 4.2.xx 3.53.xx, 4.3.xx 3.57.xx, 4.7.xx
Note: All driver versions are of the form n.m.xx. n.m stays the same within a GA level or a fix pack level. xx changes when a new version of the IBM Data Server Driver for JDBC and SQLJ is introduced through an APAR fix.
Installation requirements for DB2 servers and IBM data server clients (Windows)
Before you install a DB2 database product on Windows operating systems, ensure that the system you choose meets the necessary operating system, hardware, and software requirements.
Table 5. Windows workstation platforms Operating System Prerequisites Hardware All Intel and AMD processors capable of running the supported Windows operating systems (32bit and 64bit based systems)
Windows XP Professional (32bit Windows XP Service and 64bit) Pack 2 or later Windows Vista Business (32bit and 64bit) IBM Data Server Provider for .NET client applications Windows Vista Enterprise (32bit and CLR server-side and 64bit) procedures require .NET 2.0 framework Windows Vista Ultimate (32bit runtime. and 64bit) 64-bit IBM data server provider for .NET applications are supported. All Windows Vista service packs are supported.
14
Table 6. Windows server platforms Operating System Windows 2003 Datacenter Edition (32bit and 64bit) Windows 2003 Enterprise Edition (32bit and 64bit) Windows 2003 Standard Edition (32bit and 64bit) Prerequisites Service Pack 2 or later. R2 is also supported IBM data server provider for .NET client applications and CLR server-side procedures require .NET 2.0 framework runtime. 64-bit IBM data server provider for .NET applications are supported. Windows Server 2008 Datacenter IBM data server provider for Edition (32bit and 64bit) .NET client applications and CLR server-side procedures Windows Server 2008 Enterprise require .NET 2.0 framework Edition (32bit and 64bit) runtime. Windows Server 2008 Standard Edition (32bit and 64bit) 64-bit IBM data server provider for .NET applications are supported. All Windows Server 2008 service packs are supported. Hardware All Intel and AMD processors capable of running the supported Windows operating systems (32bit and 64bit based systems).
Note: DB2 database products support the hardware-enforced Data Execution Prevention (DEP) feature that is built into some Windows operating systems. Additional software considerations v Windows Installer 3.0 is required. It will be installed by the installer if is it not detected. v IBM Data Server Provider for .NET client applications and CLR server-side procedures require .NET 2.0 framework runtime. In an x64 environment, 32-bit IBM data server provider for .NET applications will run in the WOW64 emulation mode. v MDAC 2.8 is required. The DB2 Setup wizard will install MDAC 2.8 if it is not already installed. Note: If a previous version of MDAC (for example, 2.7) is already installed, DB2 install will upgrade MDAC to 2.8. For a typical install, MDAC 2.8 is installed. For a custom install, MDAC 2.8 is installed but only if you have not deselected the default which is to install it. If you deselect MDAC as part of a custom install, it will not be installed. v If you plan to use LDAP (Lightweight Directory Access Protocol), you should use either a Microsoft LDAP client or the IBM Tivoli Directory Server v6 client (also known as the IBM LDAP client which is included with DB2 database products). Before installation of the Microsoft Active Directory, you will need to extend your directory schema using the db2schex utility, which can be found on the installation media under the db2\Windows\utilities directory. The Microsoft LDAP client is included with Windows operating systems. v One of the following browsers is required to view online help, run the DB2 install launchpad (setup.exe), and to run First Steps (db2fs):
15
Firefox 2.0 and later Internet Explorer 6.0 and later Mozilla-based browsers 1.7 and later Safari 3.0 and later
Installation requirements for DB2 servers and IBM data server clients (AIX)
Before you install DB2 database products on AIX operating systems, ensure that the system you choose meets the necessary operating system, hardware, software, and communications requirements. To install a DB2 database product, the following requirements must be met:
Table 7. AIX installation requirements Operating System AIX Version 5.3 v 64-bit AIX kernel is required v AIX 5.3 Technology Level (TL) 9 and Service Pack (SP) 2 v Minimum C++ runtime level requires the xlC.rte 9.0.0.8 and xlC.aix50.rte 9.0.0.8 (or later) filesets. These filesets are included in the June 2008 IBM C++ Runtime Environment Components for AIX package. AIX Version 6.12 v 64-bit AIX kernel is required v AIX 6.1 TL 2 v Minimum C++ runtime level requires the xlC.rte 9.0.0.8 and xlC.aix61.rte 9.0.0.8 (or later) filesets. These filesets are included in the June 2008 IBM C++ Runtime Environment Components for AIX package. Hardware 64-bit Common Hardware Reference Platform (CHRP) architecture1 All processors that are capable of running the supported AIX operating systems.
To verify that it is a CHRP architecture system, issue the command lscfg and look for the following output: Model Architecture: chrp v 2In AIX 6.1 there are two types of Workload Partitions (WPARs): system WPARs and application WPARs. DB2 installation is supported only on a system WPAR. AIX 6.1 also supports the ability to encrypt a JFS2 file system or set of files. v Note: If the minimum operating system requirements were applied using an operating system upgrade rather than using a new operating system installation, you must install I/O completion ports (IOCP) separately. You can obtain the IOCP libraries from the AIX installation CD. Then, configure IOCP on the DB2 server or data server client. For more information, see .
Software considerations
v For application development and runtime considerations, see the topics in Supported programming languages and compilers for database application development.
16
v You can download the latest IBM C++ Runtime Environment Components for AIX at the IBM AIX XL C and C++ support Web site. v (Clients only) If you plan to use Kerberos Authentication, you require IBM Network Authentication Service client v1.4 or later. The NAS client can be downloaded from https://www6.software.ibm.com/dl/dm/dm-nas-p. v Use the bosboot command to switch to the 64-bit kernel. To switch to a 64-bit kernel, you require root authority and enter the following commands:
ln -sf /usr/lib/boot/unix_64 /unix ln -sf /usr/lib/boot/unix_64 /usr/lib/boot/unix bosboot -a shutdown -Fr
v One of the following browsers is required to view online help and to run First Steps (db2fs): Firefox 2.0 and later Mozilla-based browsers 1.7 and later v An X Window System software capable of rendering a graphical user interface is required if: you want to use the DB2 Setup wizard to install a DB2 product on Linux or UNIX operating systems v For details regarding known AIX issues, see www.ibm.com/support/ docview.wss?&uid=swg21165448
Installation requirements for DB2 servers and IBM data server clients (HP-UX)
To install a DB2 product, the following operating system, hardware, and communications requirements must be met:
Table 8. HP-UX installation requirements Operating System DB2 products are supported on: v HP-UX 11iv2 (11.23.0505) with: May 2005 Base Quality (QPKBASE) bundle May 2005 Applications Quality (QPKAPPS) bundle v HP-UX 11iv3 (11.31) Hardware Itanium based HP Integrity Series Systems
Kernel configuration considerations

A system restart is required if you update the kernel configuration parameters. The kernel configuration parameters are set in /etc/system. Depending on the values of your kernel configuration parameters, modify some of them before you install the Version 9 client or DB2 server products. If the kernel parameter being modified is not listed as dynamic, a system reboot is required to make the changes to /etc/system take effect.
v One of the following browsers is required to view online help and to run First Steps (db2fs):
17
Firefox 2.0 and later Mozilla-based browsers 1.7 and later v An X Window System software capable of rendering a graphical user interface is required if: you want to use the DB2 Setup wizard to install a DB2 product on Linux or UNIX operating systems v For details regarding known HP-UX issues, see www.ibm.com/support/ docview.wss?&uid=swg21257602
Installation requirements for DB2 servers and IBM data server clients (Linux)
Before you install DB2 database products on Linux operating systems, ensure that the system you choose meets the necessary operating system, hardware, software, and communications requirements. DB2 database products are supported on the following hardware: v x86 (Intel Pentium, Intel Xeon, and AMD) 32-bit Intel and AMD processors v x64 (64-bit AMD64 and Intel EM64T processors) v POWER (IBM eServer OpenPower, iSeries, pSeries, System i, System p, and POWER Systems that support Linux) v eServer System z or System z9 The minimum supported operating systems for Linux include: v Red Hat Enterprise Linux (RHEL) 5 Update 2 v SUSE Linux Enterprise Server (SLES) 10 Service Pack 2 v SUSE Linux Enterprise Server (SLES) 11 v Ubuntu 8.0.4.1 For the latest information about supported Linux distributions, point your browser to http://www.ibm.com/software/data/db2/linux/validate/.
Multithreaded architecture limitations

If you are installing a DB2 32-bit database product on a Linux operating system, consider upgrading to a 64-bit operating system and installing the DB2 64-bit database product instead. The multithreaded architecture generally simplifies memory configuration. However, this could affect the memory configuration of 32-bit DB2 database servers. For example: v Private memory for agent threads is allocated within a single process. The aggregate of all private memory allocations for database agents might not fit in a single process memory space. v Support for multiple databases is limited because all database shared memory segments for all databases are allocated in a single process. You might need to reduce the memory usage for some databases in order to activate all databases successfully at the same time. However, the database manager performance might be impacted. Another alternative is to create multiple instances and catalog the databases across the instances. However, sufficient system resources is required to support this configuration.
18
Distribution Requirements
You should update your kernel configuration parameters before installing a DB2 database product. The default values for particular kernel parameters might not be sufficient when running a DB2 database system. You might also have other products or applications that require Linux system resources. You should modify the kernel configuration parameters based on the needs of your Linux system working environment. The kernel configuration parameters are set in /etc/sysctl.conf. Refer to your operating system manual for information about setting and activating these parameters using the sysctl command.
Package requirements
The following tables list the package requirements for SLES and RHEL distributions: v libaio.so.1 is required for DB2 database servers using asynchronous i/o. v libstdc++so.6 is required for DB2 database servers and clients. However, if IBM Tivoli System Automation for Multiplatforms, or, IBM Tivoli Monitoring for Databases: DB2 Agent is used, libstdc++so.5 is needed.
Package requirements for SLES and RHEL Package name libaio compat-libstdc++ Description Contains the asynchronous library required for DB2 database servers. Contains libstdc++so.6 (not required for Linux on POWER)
The following tables list the package requirements for SUSE Linux and Red Hat distributions for DB2 partitioned database servers. v The ksh93 Korn shell is required for SUSE10 and RHEL5 systems. The pdksh Korn Shell package is required for all other DB2 database systems. v A remote shell utility is required for partitioned database systems. DB2 database systems support the following remote shell utilities: rsh ssh By default, DB2 database systems use rsh when executing commands on remote DB2 nodes, for example, when starting a remote DB2 database partition. To use the DB2 database system default, the rsh-server package must be installed (see table below). More information about rsh and ssh is available in the DB2 Information Center. If you choose to use the rsh remote shell utility, inetd (or xinetd) must be installed and running as well. If you choose to use the ssh remote shell utility, you need to set the DB2RSHCMD communication variable immediately after the DB2 installation is complete. If this registry variable is not set, rsh is used. v The nfs-utils Network File System support package is required for partitioned database systems. All required packages should be installed and configured before continuing with the DB2 database system setup. For general Linux information, see your Linux
19
distribution documentation.
Package requirements for SUSE Linux Package name pdksh or ksh93 openssh Description Korn Shell. This package is required for partitioned database environments. This package contains a set of server programs which allow users to run commands on (and from) remote computers via a secure shell. This package is not required if you use the default configuration of DB2 database systems with rsh. This package contains a set of server programs which allow users to run commands on remote computers, login in to other computers, and copy files between computers (rsh, rexec, rlogin, and rcp). This package is not required if you configure DB2 database systems to use ssh. Network File System support package. It allows access to local files from remote computers.
rsh-server
nfs-utils
Package requirements for Red Hat Directory /System Environment/Shell /Applications/Internet Package name pdksh or ksh93 openssh Description Korn Shell. This package is required for partitioned database environments. This package contains a set of client programs which allow users to run commands on a remote computer via a secure shell. This package is not required if you use the default configuration of DB2 database systems with rsh. This package contains a set of server programs which allow users to run commands from a remote computer via a secure shell. This package is not required if you use the default configuration of DB2 database systems with rsh. This package contains a set of programs which allow users to run commands on a remote computer. Required for partitioned database environments. This package is not required if you configure DB2 database systems to use ssh. Network File System support package. It allows access to local files from remote computers.
/System Environment/ Daemons
openssh-server
rsh-server
nfs-utils
v (Clients only) If you plan to use Kerberos Authentication, you require IBM Network Authentication Service client v1.4 or later. The NAS client can be downloaded from https://www6.software.ibm.com/dl/dm/dm-nas-p. v One of the following browsers is required to view online help and to run First Steps (db2fs): Firefox 2.0 and later
20
Mozilla-based browsers 1.7 and later v An X Window System software capable of rendering a graphical user interface is required if: you want to use the DB2 Setup wizard to install a DB2 database product on Linux or UNIX operating systems, or you want to use any DB2 graphical tools on Linux for x86 and Linux on AMD 64/EM64T. v Micro Focus does not offer support for any of its COBOL compiler products on SLES 11.
Security-enhanced Linux considerations

On RHEL 5 systems, if Security-enhanced Linux (SELinux) is enabled and in enforcing mode, the installer might fail due to SELinux restrictions. To determine if SELinux is installed and in enforcing mode, you can do one of the following: v check the /etc/sysconfig/selinux file v run the sestatus command v check the /var/log/messages file for SELinux notices. To disable SELinux, you can do one of the following: v set it in permissive mode and run the setenforce 0 command as a superuser v modify /etc/sysconfig/selinux and reboot the machine. If your DB2 database product installs successfully on a RHEL 5 system, DB2 processes will run in the unconfined domain. To assign DB2 processes to their own domains, modify the policy. A sample SELinux policy is provided in the sqllib/samples directory.
Installation requirements for DB2 servers and IBM data server clients (Solaris)
Before you install a DB2 database product on Solaris, ensure that your system meets the operating system, hardware and software requirements.
Table 9. Solaris installation requirements Operating System Solaris 9 v 64- bit kernel v Patches 111711-12 and 111712-12 v If raw devices are used, patch 122300-11 v 64-bit Fujitsu PRIMEPOWER and Solaris 9 Kernel Update Patch 112233-01 or later to get the fix for patch 912041-01 Solaris 10 Update 5 v 64- bit kernel v If raw devices are used, patch 125100-07 Solaris 10 Update 5 v 64- bit kernel v Patch 127128-11
Hardware UltraSPARC or SPARC64 processors
Solaris x64 (Intel 64 or AMD64)
21
Kernel configuration considerations

The kernel configuration parameters are set in /etc/system. If the kernel parameter being modified is not listed as dynamic, a system reboot is required to make the changes to /etc/system take effect. These parameters must be set before you install an IBM data server client.
v (Clients only) If you plan to use Kerberos Authentication, you require Solaris 9 or higher with IBM Network Authentication Service (NAS) client v1.4 or later. The NAS client can be downloaded from Web site: www6.software.ibm.com/dl/ dm/dm-nas-p. v One of the following browsers is required to view online help and to run First Steps (db2fs): Firefox 2.0 and later Mozilla-based browsers 1.7 and later v An X Window System software capable of rendering a graphical user interface is required if you want to use the DB2 Setup wizard to install a DB2 database product v For details regarding known Solaris issues, see www.ibm.com/support/ docview.wss?&uid=swg21257606 Security patches can be obtained from the http://sunsolve.sun.com Web site. From the SunSolve Online Web site, click Patches in the left panel. The Java2 Standard Edition (J2SE) Solaris Operating System Patch Clusters and the SUNWlibC software are also required and can be obtained from the http://sunsolve.sun.com Web site. For DB2 database products on 64-bit Fujitsu PRIMEPOWER systems, you require the following: v Solaris 9 Kernel Update Patch 112233-01 or later to get the fix for patch 912041-01. The Fujitsu PRIMEPOWER patches for the Solaris Operating System can be downloaded from FTSI at: http://download.ftsi.fujitsu.com/. DB2 database products support the following Solaris concepts: v Solaris Logical Domains (LDoms) v Solaris Zones v ZFS filesystems
22
Chapter 3. Password rules

When choosing a password, be aware that your password length can be up to the maximum number of characters supported by your operating system. Some operating systems might have more password rules, such as minimum length and simplicity, and some operating systems can be configured to use different password encryption algorithms. See the appropriate operating system documentation for more information. Note: To enable long password support on the AIX operating system, Version 6.1, or later, install APAR IZ35001 on the DB2 client and server machines.
23
24
Chapter 4. Additional Windows requirements

DB2 services running on your system (Windows)
The following table lists the DB2 services that run on your system when a DB2 product is installed:
Table 10. DB2 Services Service Display Name Service Name Description
DB2 - (DB2 copy name) - <instance name>[<-nodenum>] Allows applications to create, <instance name> update, control, and manage [<-nodenum>] DB2 databases. where <-nodenum> is added for DB2 ESE instances. DB2 Governor (DB2 copy DB2GOVERNOR name) _db2copyname DB2 Information Center Server DB2ICSERVER_Vxx (where xx is the DB2 version you are running, for example, V95 is Version 9.5) DB2LICD _db2copyname Collects statistics for applications connected to DB2 databases. Provides documentation for DB2 products.
DB2 License Server (DB2 copy name)
Monitors DB2 license compliance.
DB2 Management Service DB2MGMTSVC _db2copyname Manages DB2 registry entries (DB2 copy name) for backward compatibility purposes for the DB2 copy. DB2 Query Patroller (DB2 copy name) DB2 Remote Command Server (DB2 copy name) DB2DAS - DB2DASXX DB2QP _db2copyname DB2 Query Patroller Supports remote DB2 command execution. Supports local and remote database administrative requests. Monitors the DB2 server and database for availability.
DB2REMOTECMD _db2copyname DB2DASXX (where XX is 00-99) kudcma_<instance name>
Monitoring Agent for DB2 - <instance name>
DB2TS - (DB2 copy <instance name>[<-nodenum>] Indexes and searches text name) - <instance name> documents in DB2 databases. [<-nodenum>] DB2EXT - (DB2 copy <instance name>[<-nodenum>] name) - <instance name> [<-nodenum>]
25
Required user accounts for installation of DB2 server products (Windows)

If you are installing a DB2 server product on Windows, you require the following user accounts: v An installation user account and v Optional - one or more setup user accounts. You can create these accounts during the installation. A DB2 Administration Server (DAS) user account A DB2 instance user account. You can also use the LocalSystem account for products other than DB2 Enterprise Server Edition. The installation user account is the account of the user performing the installation. The installation user account must be defined before running the DB2 Setup wizard. The setup user accounts can be defined before installation or you can have the DB2 Setup wizard create them for you. All user account names must adhere to your system naming rules and to DB2 User, user ID and group naming rules.
Extended security on Windows

DB2 products offer extended Windows security. If the extended security feature is selected, you must add the users who will administer or use the DB2 product to either the DB2ADMNS or DB2USERS group as appropriate. The DB2 installer creates these two new groups. You can either specify a new name or accept the default names during installation. To enable this security feature, select the Enable operating system security check box on the Enable operating system security for DB2 objects panel during the DB2 installation. Accept the default values for the DB2 Administrators Group field, and the DB2 Users Group field. The default group names are DB2ADMNS and DB2USERS. If there is a conflict with existing group names, you will be prompted to change the group names. If required, you can specify your own group names.
DB2 server user accounts

Installation user account A local or domain user account is required to perform the installation. Normally, the user account must belong to the Administrators group on the computer where you will perform the installation. Alternatively, a non-Administrator user account can be used. This alternative requires that a member of the Windows Administrators group first configure the Windows elevated privileges settings to allow a non-Administrator user account to perform an installation. On Windows 2008 and Windows Vista or higher, a non-administrator can perform an installation, but will be prompted for administrative credentials by the DB2 Setup wizard. The user right Access this computer from the network is required for the installation user account.
26
The installation user ID must belong to the Domain Administrators group on the domain if the installation requires a domain account to be created or verified. You may also use the built-in LocalSystem account as your Service Logon account for all products, except DB2 Enterprise Server Edition User rights granted by the DB2 installer The DB2 installation program does not grant the Debug Programs user right. The DB2 installer grants the following user rights: v Act as part of the operating system v Create token object v Lock pages in memory v Log on as a service v Increase quotas v Replace a process level token DB2 Administration Server (DAS) user account A local or domain user account is required for the DB2 Administration Server (DAS). If you are performing a response file installation, you can also specify the Local System account in the response file. For more details, refer to the sample response files in the db2\windows\samples directory. The LocalSystem account is available for all products, except DB2 Enterprise Server Edition and can be selected through the DB2 Setup wizard. The DAS is a special DB2 administration service used to support the GUI tools and assist with administration tasks on local and remote DB2 servers. The DAS has an assigned user account that is used to log the DAS service on to the computer when the DAS service is started. You can create the DAS user account before installing DB2 or you can have the DB2 Setup wizard create it for you. If you want to have the DB2 Setup wizard create a new domain user account, the user account you use to perform the installation must have authority to create domain user accounts. The user account must belong to the Administrators group on the computer where you will perform the installation. This account will be granted the following user rights: v Act as part of the operating system v Debug programs v Create token object v Lock pages in memory v Log on as a service v Increase quotas (adjust memory quotas for a process on Windows XP and Windows Server 2003 operating systems) v Replace a process level token If extended security is enabled, the DB2ADMNS group will have all these privileges. You can add users to that group and you do not need to add these privileges explicitly. However, the user still needs to be a member of the Local Administrators group. The Debug programs privilege is only needed when DB2 group lookup is explicitly specified to use the access token.
27
If the user account is created by the install program, the user account will be granted these privileges and if the user account already exists, this account will also be granted these privileges. If the install grants the privileges, some of them will only be effective on first log on by the account that was granted the privileges or upon reboot. It is recommended that the DAS user have SYSADM authority on each of the DB2 systems within your environment so that it can start or stop other instances if required. By default, any user that is part of the Administrators group has SYSADM authority. DB2 instance user account The user account must belong to the Administrators group on the computer where you will perform the installation. A local or domain user account is required for the DB2 instance. Every DB2 instance has one user that is assigned when the instance is created. DB2 logs on with this user name when the instance is started. An error will occur if you use a domain user account to perform a database operation (such as, creating a database) against a DB2 instance created with either a Local user account or the LocalSystem account. If you know you will be using a domain user account, you should create the instance using a domain user account. You may also use the built-in LocalSystem account to run the installation for all products, except for DB2 Enterprise Server Edition. You can create the DB2 instance user account before installing DB2 or you can have the DB2 Setup wizard create it for you. If you want to have the DB2 Setup wizard create a new domain user account, the user account you use to perform the installation must have authority to create domain user accounts. This account will be granted the following user rights: v Act as part of the operating system v Debug programs v Create token object v Increase quotas v Lock pages in memory v Log on as a service v Replace a process level token If extended security is enabled, then the DB2ADMNS group will have all these privileges. You can add users to that group and you do not need to add these privileges explicitly. However, the user still needs to be a member of the Local Administrators group. The Debug programs privilege is only needed when DB2 group lookup is explicitly specified to use the access token. If the user account is created by the install program, the user account will be granted these privileges and if the user account already exists, this account will also be granted these privileges. If the install grants the privileges, some of them will only be effective on first log on by the account that was granted the privileges or upon reboot.
28
Setting up Windows elevated privileges before installing a DB2 product (Windows)

The usual method to install a DB2 product on Windows is to use an Administrator user account. However, DB2 products can be installed using a non-administrator account. To do so, a Windows Administrator must configure the elevated privileges feature in Windows. This task explains how a Windows Administrator can set up a computer with elevated privileges to allow installation using a non-Administrator user account. The related task of granting DB2 administration authorities to non-Administrator users is also covered. Typically a Windows Administrator would perform this task to enable another person who does not have an Administrator account to install a DB2 product. The role of this person might be only to install DB2 products or to also administer DB2 products once installed. Before initiating this procedure, note the following restrictions on non-Administrator installation using elevated privileges: v Non-Administrator users can only install fix packs, add-on products, or upgrade DB2 products if prior installations or upgrades were also performed by the same non-Administrator user. v Non-Administrator users cannot uninstall a DB2 product. Those non-Administrator users on a Windows Vista (and later) operating system can uninstall a DB2 product. This procedure uses the Windows Group Policy Editor. 1. Click Start -> Run and type gpedit.msc. The Group Policy window opens. 2. Click on Computer Configuration > Administrative Templates > Windows Components > Windows Installer. 3. Enable the following Group Policy settings: v Always install with elevated privileges (mandatory) v Enable user control over installs (mandatory) v Disable Windows Installer. Then set it to Never. v Enable user to patch elevated products (optional) v Enable user to use media source while elevated (optional) v Enable user to browse for source while elevated (optional for new installations, mandatory for fix pack upgrades) 4. Enable elevated privileges for the user account that will be performing the installation. a. Click User Configuration > Administrative Templates > Windows Components > Windows Installer. b. Enable the Always install with elevated privileges (mandatory) Group Policy setting. 5. Perform setup related to the user account that will install the DB2 product. v Identify the user account that will install the DB2 product. If necessary, create that account. v Give that account write permission for the drive on which an installation is planned.
29
6. Optional: Complete additional steps applicable to installing fix packs: v Provide read access to the sqllib\cfg directory. v Ensure that allowlockdownpatch is enabled (as described in the Windows Installer SDK documentation) because fix pack installations are considered minor upgrades to the product. 7. Refresh the computers security policy in any one of the following ways: v Reboot the PC. v At the command line, enter gpupdate.exe. By following this procedure you will have set up the computer with elevated privileges and set up a user account that will be able to install DB2 server products, clients and fix packs. After DB2 installation is complete: v Any user in the system administrative (SYSADM) or system control (SYSCTRL) authority group defined in the database manager configuration for the instance can create and use DB2 databases within the DB2 instance. v Only a user with local Administrator authority can run DB2 instance utilities, such as db2icrt, db2idrop, db2iupdt, or db2iupgrade. v The authorization requirements for running the db2start or db2stop command is defined in the topics START DATABASE MANAGER command, and STOP DATABASE MANAGER command. Using regedit instead of the Windows Group Policy Editor An alternative to using the Windows Group Policy Editor is to use regedit. 1. In the registry branch HKEY_LOCAL_MACHINE\SOFTWARE\ Policies\Microsoft\Windows, add the key installer 2. Edit the key installer with the following values: v For AlwaysInstallElevated, enter REG_DWORD=1 v For AllowLockdownBrowse, enter REG_DWORD=1 v For AllowLockdownMedia, enter REG_DWORD=1 v For AllowLockdownPatch, enter REG_DWORD=1 v For DisableMSI, enter REG_DWORD=0 v For EnableUserControl, enter REG_DWORD=1 3. In the registry branch HKEY_CURRENT_USER\SOFTWARE\Policies\ Microsoft\Windows, add the key installer 4. Edit the key installer with the following values: v For AlwaysInstallElevated, enter REG_DWORD=1 Removing elevated privileges After you have given elevated privileges, you can reverse this action. To do so, remove the registry key Installer under HKEY_LOCAL_MACHINE\ SOFTWARE\Policies\Microsoft\Windows. Granting a non-administrator user DB2 administration authorities At this point, only members of the Windows Administrators group will have DB2 administration authorities. The Windows Administrator has the option to grant one or more DB2 authorities, such as SYSADM, SYSMAINT, or SYSCTRL to the non-Administrator user who installed the DB2 product.
30
Preparing the environment for a partitioned DB2 server (Windows)

This topic describes the steps required to prepare your Windows environment for a partitioned installation of the DB2 product. Each participating computer must have the same operating system. To prepare your Windows environment for installation: 1. Ensure that the primary computer and participating computers belong to the same Windows domain. Check the domain to which the computer belongs by using the System Properties dialog, accessible through the Control Panel. 2. Ensure that time and date settings on the primary computer and participating computers are consistent. To be considered consistent, the difference in GMT time between all computers must be no greater than one hour. System date and time can be modified using the Date/Time Properties dialog, accessible through the Control Panel. You can use the max_time_diff configuration parameter to change this restriction. The default is max_time_diff = 60, which allows a difference of less than 60 minutes. 3. Ensure that each computer object that participates in the partitioned database environment has the Trust computer for delegation privilege flagged. You can verify that the Trust computer for delegation checkbox on the General tab of each computers account Properties dialog box in the Active Directory Users and Computers console is checked. 4. Ensure that all participating computers can communicate with each other using TCP/IP: a. On one participating computer, enter the hostname command, which will return the hostname of the computer. b. On another participating computer, enter the following command:
ping hostname
where hostname represents the hostname of the primary computer. If the test is successful, you will receive output similar to the following:
Pinging ServerA.ibm.com [9.21.27.230] with 32 bytes of data: Reply from 9.21.27.230: bytes=32 time<10ms TTL=128 Reply from 9.21.27.230: bytes=32 time<10ms TTL=128 Reply from 9.21.27.230: bytes=32 time<10ms TTL=128
Repeat these steps until you are sure that all participating computers can communicate with each other using TCP/IP. Each computer must have a static IP address. If you are planning to use multiple network adapters, you can specify which adapter to use to communicate between database partition servers. Use thedb2nchg command to specify the netname field in the db2nodes.cfg file after the installation is complete. 5. During the installation you will be asked to provide a DB2 Administration Server user account. This is a local or domain user account that will be used by the DB2 Administration Server (DAS). The DAS is an administration service used to support the GUI tools and assist with administration tasks. You can define a user now or have the DB2 Setup wizard create one for you. If you want to create a new domain user using the DB2 Setup wizard, the account used to perform the installation must have authority to create domain users. 6. On the primary computer, where you will install the instance-owning partition, you must have a domain user account that belongs to the local Administrators
31
group. You will log on as this user when you install DB2. You must add the same user account to the local Administrators group on each participating computer. This user must have the Act as part of the operating system user right. 7. Ensure that all computers in the instance have the database directory on the same local drive letter. You can check this condition by running the GET DATABASE CONFIGURATION command and verifying the value of the DFTDBPATH DBM configuration parameter. 8. During the installation you will be asked to provide a domain user account to be associated with the DB2 instance. Every DB2 instance has one user assigned. DB2 logs on with this user name when the instance is started. You can define a user now, or you can have the DB2 Setup wizard create a new domain user for you. When adding a new node to a partitioned environment the DB2 copy name must be the same on all computers. If you want to create a new domain user using the DB2 Setup wizard, the account used to perform the installation must have authority to create domain users. The instance user domain account must belong to the local Administrators group on all the participating computers and will be granted the following user rights: v Act as part of the operating system v Create token object v Lock pages in memory v Log on as a service v Increase quotas v Replace a process level token If extended security was selected, the account must also be a member of the DB2ADMNS group. The DB2ADMNS group already has these privileges so the privileges are already explicitly added to the account.
Granting user rights (Windows)

This topic describes the steps required to grant user rights on Windows operating systems. Specific user rights are recommended for user accounts required to install and set up DB2. To grant advanced user rights on Windows you must be logged on as a local Administrator. 1. Click Start -> Run and type secpol.msc. On Windows 2008 and Windows Vista (or higher), click Start and type secpol.msc in the search bar. Click OK. 2. Select Local Security Policy. 3. In the left window pane, expand the Local Policies object, then select User Rights Assignment. 4. In the right window pane, select the user right that you want to assign. 5. From the menu, select Action > Security... 6. Click Add, then select a user or group to assign the right to, and click Add. 7. Click OK. If your computer belongs to a Windows domain, the domain user rights can override your local settings. In this case, your Network Administrator must make the changes to the user rights.
32
Fast communications manager (Windows)

The fast communications manager (FCM) provides communications support for DB2 server products belonging to the same instance. Each database partition server has one FCM sender, and one FCM receiver daemon to provide communications between database partition servers to handle agent requests and to deliver message buffers. The FCM daemon is started when you start the instance. If communications fail between database partition servers, or if they re-establish communications, the FCM thread updates information. You can query this information with the database system monitor. The FCM daemons also trigger the appropriate action. An example of an appropriate action is the rollback of an affected transaction. You can use the database system monitor to help you set the FCM configuration parameters. You can specify the number of FCM message buffers with the fcm_num_buffers database manager configuration parameter and the number of FCM channels with the fcm_num_channels database manager configuration parameter. The fcm_num_buffers and fcm_num_channels database manager configuration parameter are set to AUTOMATIC as the default value. FCM monitors resource usage when any of these parameters are set to automatic, and incrementally releases resources. It is recommended to leave these parameters set to AUTOMATIC.
Extending the Active Directory Schema for LDAP directory services (Windows)
If you plan to use the Lightweight Directory Access Protocol (LDAP) directory server feature with Windows Server 2003, you should extend the Active Directory schema to contain DB2 object classes and attribute definitions. You should perform this task before you install any DB2 products. Extending the directory schema ensures that: v The default DB2 instance, created during the installation, is cataloged as a DB2 node in Active Directory provided the installation user ID had sufficient privileges to write to Active Directory. v Any databases that the user creates after installation will automatically be cataloged into Active Directory. If you decide to install your DB2 product and create databases before you extend the directory schema, you must manually register the node and catalog the databases. Your Windows user account must have Schema Administration authority. To extend the directory schema: 1. Log onto the domain controller. 2. Run the db2schex.exe program from the installation DVD with a user account that has Schema Administration authority. You can run this program without logging off and logging on again, as follows:
runas /user:MyDomain\Administrator x:\db2\Windows\utilities\db2schex.exe
where x: represents the DVD drive letter.
33
When db2schex.exe completes, you can proceed with the installation of your DB2 product.
Verifying port range availability on participating computers (Windows)

This task describes the steps required to verify port range availability on participating computers. The port range is used by the Fast Communications Manager (FCM). FCM is a feature of DB2 that handles communications between database partition servers. When you install the instance-owning database partition server on the primary machine, DB2 reserves a port range according to the specified number of database partition servers participating in partitioned database environment. The default range is four ports. The DB2 Setup wizard must be able to reserve an identical port range when database partition servers are installed on participating computers; the port range needs to be free on each of the database partition servers. This task should be done after you install the instance-owning database partition server and before you install any participating database partition servers. To verify the port range availability on participating computers: 1. Open the services file. The default location of the services file is in the %SystemRoot%\system32\drivers\etc directory, where %SystemRoot% is your Windows root directory. 2. Locate the ports reserved for the DB2 Fast Communications Manager (FCM). The entries should appear similar to the following:
DB2_DB2 DB2_DB2_1 DB2_DB2_2 DB2_DB2_END 60000/tcp 60001/tcp 60002/tcp 60003/tcp
DB2 reserves the first four available ports after 60000. 3. On each participating computer, open the services file and verify that the ports reserved for DB2 FCM in the services file of the primary computer are not being used. 4. In the event that the required ports are in use on a participating computer, identify an available port range for all computers and update each service file, including the services file on the primary computer.
34
Chapter 5. Additional Linux and UNIX requirements

Multiple DB2 copies on the same computer (Linux and UNIX)
DB2 products can be installed to an installation path of your choice. DB2 products can also be installed multiple times on a single machine. Each DB2 Copy can be at the same or different code levels. Root installations of DB2 products can be installed to an installation path of your choice. Unless specified otherwise, the default installation paths are: v for AIX, HP-UX or Solaris operating systems /opt/IBM/db2/V9.7 v for Linux operating systems /opt/ibm/db2/V9.7 If you are using the DB2 Setup wizard and choose to install a new DB2 copy when the default installation path is already in use, the default path becomes: v for AIX, HP-UX or Solaris /opt/IBM/db2/V9.7_## v for Linux /opt/ibm/db2/V9.7_## where ## is a zero-prefixed sequential number in the range 01 to 99. The first occurrence of modifying the default path is _01. For example, a DB2 product is installed using the DB2 Setup wizard without specifying an installation path, and, the default installation path /opt/ibm/db2/V9.7 is already in use, the DB2 product will be installed in the new default path /opt/ibm/db2/V9.7_01. If you install a DB2 copy using an installation method other than the DB2 Setup wizard, you must specify the installation path. Automatic sequential incrementation of the default path only occurs when the DB2 Setup wizard is used to install a DB2 copy. Regardless of the installation method, another full product cannot be installed in the path of another DB2 copy (such as /opt/ibm/db2/V9.7). A DB2 copy installed to a subdirectory of an existing DB2 copy is not supported because all copies are rendered unusable. With the ability to install multiple copies of DB2 products on your system and the flexibility to install DB2 products and features in the path of your choice, the db2ls command helps you keep track of what is installed and where it is installed. Run the db2ls command to locate DB2 products installed on your system. The following restrictions apply when installing multiple DB2 copies on one system: Non-root installations do not support multiple DB2 copies There can be only one DB2 Administration Server (DAS) on the system. Instance names must be unique across DB2 copies. A DB2 copy is not aware of any instances created in another DB2 copy. However, the db2iupdt command can switch ownership of an instance from one DB2 copy to another. v Creating links with the db2ln command for one DB2 copy renders the other copies nonfunctional. Links must not be created when multiple DB2 copies are intended to coexist. v Linux 32-bit images cannot be installed on Linux x64 operating system platforms. v v v v
35
v The DB2 installation tools do not support multiple simultaneous invocations on the same machine by the same user.
Fast communications manager (Linux and UNIX)

The fast communications manager (FCM) provides communications support for DB2 server products that use the Database Partitioning Feature (DPF). For multiple partition instances, each database partition server has one FCM sender daemon and one FCM receiver daemon to provide communications between database partition servers to handle agent requests and to deliver message buffers. The FCM daemon is started when you start the multiple partition instance. If communications fail between database partition servers or if they re-establish communications, the FCM daemons update information. You can query this information with the database system monitor. The FCM daemons also trigger the appropriate action. An example of an appropriate action is the rollback of an affected transaction. You can use the database system monitor to help you set the FCM configuration parameters. You can specify the number of FCM message buffers with the fcm_num_buffers database manager configuration parameter. You can also specify the number of FCM channels with the fcm_num_channels database manager configuration parameter. The fcm_num_buffers and fcm_num_channels database manager configuration parameters are set to AUTOMATIC as the default value. The FCM monitors resource usage when any of these parameters are set to automatic, and incrementally releases resources. It is recommended to leave these parameters set to AUTOMATIC.
DB2 users and groups (Linux and UNIX)

The DB2 Setup wizard creates the users and groups automatically (if needed) during the installation of your DB2 product. Note: This topic does not apply to non-root installations. If you are using the DB2 Setup wizard, you can create the following users and groups during installation. To manually create the following users and groups, see Creating group and user IDs for a DB2 database installation (Linux and UNIX) on page 39. Three users and three groups are used to operate DB2 on Linux and UNIX platforms. Instance owner The DB2 instance is created in the instance owner home directory. This user ID controls all DB2 processes and owns all filesystems and devices used by the databases contained within the instance. The default user is db2inst1 and the default group is db2iadm1. When using the DB2 Setup wizard, the default action is to create a new user for your DB2 instance. The default name is db2inst1. If that user name already exists, the DB2 Setup wizard searches through user names (db2inst2, db2inst3, and so on). The search continues until a user name is identified that is not already an existing user on the system as the default instance owner ID. If you choose to proceed this user is created by the DB2 Setup wizard. However, you also have a choice to specify any existing user as the instance owner.
36
This method for user name creation also applies to the creation of fenced users and DB2 administration server users. Fenced user The fenced user is used to run user defined functions (UDFs) and stored procedures outside of the address space used by the DB2 database. The default user is db2fenc1 and the default group is db2fadm1. If you do not need this level of security, for example in a test environment, you can use your instance owner as your fenced user. DB2 administration server user The user ID for the DB2 administration server user is used to run the DB2 administration server (DAS) on your system. The default user is dasusr1 and the default group is dasadm1. This user ID is also used by the DB2 GUI tools to perform administration tasks against the local server database instances and databases. There is only one DAS per computer. One DAS services one or more database instances, including database instances that belong to different installations. The DAS can service database instances whose release level is lower than the release level of the DAS. However, for database instances whose release level is higher than the release level of the DAS, the DAS must be migrated to a higher level. The DAS release level must be as high (or higher) than the release level of any of the database instances it services.
User ID restrictions
User IDs have the following restrictions and requirements: v Must have a primary group other than guests, admins, users, and local v Can include lowercase letters (az), numbers (09), and the underscore character (_) v Cannot be longer than eight characters v Cannot begin with IBM, SYS, SQL, or a number v Cannot be a DB2 reserved word (USERS, ADMINS, GUESTS, PUBLIC, or LOCAL), or an SQL reserved word v Cannot use any User IDs with root privilege for the DB2 instance ID, DAS ID or fenced ID. v Cannot include accented characters v If existing user IDs are specified instead of creating new user IDs, make sure that the user IDs: Are not locked Do not have expired passwords
Centralized user-management considerations (Linux and UNIX)

In environments that include security software, there are some installation considerations. Note: The DB2 installation cannot update or create users and groups if they are controlled outside of the operating system. For example, LDAP can be used to control users and groups outside of the operating system. Note: Network Information Services (NIS) and Network Information Services Plus (NIS+) features are deprecated starting with DB2 Version 9.1 Fix Pack 2. Support
37
for these features might be removed in a future release. Lightweight Directory Access Protocol (LDAP) is the recommended solution for centralized user-management services. At instance creation, without a security component present, the instance owners group list is modified to include that of the database administrative server (DAS) users primary group, if the DAS is created. If the instance creation program is unable to modify these properties, it reports that it could not. The warning message provides the necessary information to manually make the changes. These considerations hold true for any environment in which an external security program does not allow the DB2 installation or instance creation programs to modify user characteristics.
Preparing to install DB2 for Linux on zSeries

To install a DB2 product on an IBM zSeries that is running Linux, you must make the installation image accessible to the Linux operating system. You can use FTP to send the installation image to the operating system, or use an NFS mount to make the product DVD available to the operating system. Prerequistes You have already obtained your DB2 product installation image. Using FTP to access the installation image From the IBM zSeries computer running Linux: 1. Enter the following command:
ftp yourserver.com
where yourserver.com represents the FTP server where the DB2 product installation image resides. 2. Enter your user ID and password. 3. Enter the following commands:
bin get product file
where product file represents the appropriate product package name. Using the DB2 product DVD over NFS to access the installation image To use the product DVD on a Linux operating system: 1. Mount the appropriate product DVD. 2. Export the directory where you mounted the DVD. For example, if you mounted the DVD under /db2dvd, then export the /db2dvd directory. 3. On the IBM zSeries computer running Linux, NFS mount this directory using the following command:
mount -t nfs -o ro nfsservername:/db2dvd /local_directory_name
where nfsservername represents the host name of the NFS server, db2dvd represents the name of the directory being exported on the NFS server, and local_directory_name represents the name of the local directory. 4. From the IBM zSeries computer running Linux, change to the directory where the DVD is mounted. You can do this by entering the cd /local_directory_name command, where local_directory_name represents the mount point of your product DVD.
38
Creating group and user IDs for a DB2 database installation (Linux and UNIX)
The DB2 Setup wizard will create these users and groups for you during the installation process. If you want, you can create them ahead of time. To perform this task, you must have root authority to create users and groups. Three users and groups are required. The user and group names used in the following instructions are documented in the following table. You can specify your own user and group names if they adhere to system naming rules and DB2 naming rules. The user IDs you create will be required to complete subsequent setup tasks.
Table 11. Default users and groups User Instance owner Fenced user DB2 administration server user Example user name db2inst1 db2fenc1 dasusr1 Example group name db2iadm1 db2fadm1 dasadm1
v The instance owner home directory is where the DB2 instance will be created. v The fenced user is used to run user defined functions (UDFs) and stored procedures outside of the address space used by the DB2 database. v The user ID for the DB2 administration server user is used to run the DB2 administration server on your system. To create the required groups and user IDs for DB2: 1. Log in as a user with root authority. 2. Enter the appropriate commands for your operating system. Note: These command line examples do not contain passwords. They are examples only. You can use the passwd username command from the command line to set the password. AIX operating systems To create groups on AIX, enter the following commands:
mkgroup id=999 db2iadm1 mkgroup id=998 db2fadm1 mkgroup id=997 dasadm1
Create users for each group:

mkuser id=1004 pgrp=db2iadm1 groups=db2iadm1 home=/home/db2inst1 db2inst1 mkuser id=1003 pgrp=db2fadm1 groups=db2fadm1 home=/home/db2fenc1 db2fenc1 mkuser id=1002 pgrp=dasadm1 groups=dasadm1 home=/home/dasusr1 dasusr1
Set initial password:

passwd db2inst1 passwd db2fenc1 passwd dasusr1
39
HP-UX operating systems To create groups on HP-UX, enter the following commands:
groupadd -g 999 db2iadm1 groupadd -g 998 db2fadm1 groupadd -g 997 dasadm1

useradd -g db2iadm1 -d /home/db2instl -m db2inst1 useradd -g db2fadm1 -d /home/db2fenc1 -m db2fenc1 useradd -g dbasgrp -d /home/dasusr1 -m dasusr1

Linux operating systems To create groups on Linux operating systems, enter the following commands:

useradd -u 1004 -g db2iadm1 -m -d /home/db2inst1 db2inst1 useradd -u 1003 -g db2fadm1 -m -d /home/db2fenc1 db2fenc1 useradd -u 1002 -g dasadm1 -m -d /home/dasusr1 dasusr1

Solaris operating systems To create groups on Solaris, enter the following commands:

useradd -g db2iadm1 -u 1004 -d /export/home/db2inst1 -m db2inst1 useradd -g db2fadm1 -u 1003 -d /export/home/db2fenc1 -m db2fenc1 useradd -g dasadm1 -u 1002 -d /export/home/dasusr1 -m dasusr1

OS user limit requirements (Linux and UNIX)

This topic outlines the recommended operating system user process resource limits (ulimits) on Linux and UNIX operating systems. Depending on your installation, the DB2 engine automatically raises the ulimits to varying degrees: v For root installations, the DB2 engine automatically raises ulimits where necessary based on the needs of the DB2 database system.
40
v For non-root installations, the DB2 engine can update only the data, nofiles, and fsize ulimits for the engine process up to the hard limits imposed by the system administrator. In either case, it might be more practical to set the resource limits permanently on your system. Especially for non-root installations, the data, nofiles, and fsize ulimit values should be set appropriately by an administrator after installing.
Recommended ulimit values for non-root installations

After a non-root installation is completed, the instance owner should verify the hard operating system ulimits for the data, nofiles, and fsize resources. The recommended values are outlined in the following table:
Table 12. Recommended ulimit values for non-root installations Hard ulimit resource data Description Maximum private memory allowed for a process Maximum number of open files allowed for a process Recommended Minimum value value The amount of memory available on the computer Larger than the sum of all MAXFILOP database configuration parameters for all databases in the instance Unlimited Unlimited Command to query the value ulimit Hd
nofiles
65536 or unlimited
ulimit Hn
fsize
Maximum file size allowed
Unlimited
ulimit Hf
If the minimum ulimit values are not met, the DB2 engine could encounter unexpected operating system resource shortage errors. These errors can lead to a DB2 outage. Contact a root user or a System Administrator if the ulimit values need to be updated for your non-root installation. Values for ulimits must be set manually, except on AIX operating systems, where you also have the option to set ulimits by running the db2rfe command.
DB2 products in a workload partition (AIX)

A DB2 installation process on a system WPAR is similar to any other installation, with the additional benefit of using DB2 products in a global read-only installation path. In AIX 6.1 there are two types of workload partitions (WPARs): system WPARs and application WPARs. DB2 installation is only supported on a system WPAR. System WPARs either share the /usr and /opt directories with the global environment, and have a local copy of the /usr and /opt directories. A DB2 product can be installed in a local file system on a system WPAR, or a DB2 product can be installed in a global environment with a DB2 copy shared with other system WPARs. When a DB2 copy is installed in a global environment under
41
either the /usr or /opt directory, which are shared with system WPARs, those system WPARs are able to use the shared DB2 copy to setup DB2 instances. Each system WPAR manages its own DB2 instances and DAS related to the DB2 copy, and can see only the DB2 instances and DAS created specifically for the system WPAR. DAS and instances created on one WPAR, or in a global environment, are not visible from any other system (system WPAR or global environment). When a DB2 copy is installed in a global environment, DB2 instances and DAS can be created and managed on each system WPAR sharing the globally installed DB2 copy. There are specific considerations when a DB2 copy is installed in a global environment: Installing the DB2 copy Installing a DB2 copy on a system WPAR is similar to any other DB2 product installation, with the following exceptions. The following cannot be installed on a system WPAR: v IBM Tivoli System Automation for Multiplatforms (SA MP) v IBM Data Studio Administration Console Uninstalling the DB2 copy Before uninstalling the DB2 copy in a global environment, the AIX system WPARs that shares the DB2 copy with DB2 instances or DAS, must be active. In addition, before uninstalling the DB2 copy, any system WPARs sharing the DB2 copy cannot have any related DB2 instances, or DAS associated with, or in use by, that DB2 copy. All instances and DAS must either be: v dropped (using the db2idrop or dasdrop command), or, v updated the instance or DAS to another DB2 copy (using the db2iupdt or dasupdt command). Note: The db2idrop and dasdrop command must be run as the root user. Applying a fix pack to the DB2 copy Applying fix packs on a system WPAR is similar to any other DB2 product update. However, before applying a fix pack to a DB2 copy in a global environment, the AIX system WPARs that share the DB2 copy must be active for the instances to be updated. In addition, before applying a fix pack, any system WPARs sharing the DB2 copy cannot have any related DB2 instances or DAS running. All instances and DAS related to the DB2 copy to be updated must either be: v stopped (using the db2stop command), or, v run the installFixPack command with the -f update parameter to bypass all the checking on DB2 library loading, instance and DAS properly stopped or not. (However, this is not recommended.) Considerations when using the db2ls command When installing the DB2 copy in a global environment, the directory containing the db2ls command (/usr/local/bin) is linked to a DB2 copy in the global environment. The db2ls command, is used to list the DB2 Version 9 (or higher) products installed on the system. On a system WPAR, if the /usr directory is shared with the global partition as read-only, the db2ls command running on the system WPAR might not work unless the
42
link target also exists on the system WPAR, and, the related DB2 copy is registered on the system WPAR. The db2ls command can be found both in the DB2 installation media and in a DB2 install copy on the system, and can be run from either location.
Kernel parameters (Linux and UNIX) Modifying kernel parameters (HP-UX)

For your DB2 product to perform properly on HP-UX, you might need to update your systems kernel configuration parameters. If you update your kernel configuration parameter values, you must restart your computer. You must have root authority to modify kernel parameters. To modify kernel parameters: 1. Enter the sam command to start the System Administration Manager (SAM) program. 2. Double-click the Kernel Configuration icon. 3. Double-click the Configurable Parameters icon. 4. Double-click the parameter that you want to change and type the new value in the Formula/Value field. 5. Click OK. 6. Repeat these steps for all of the kernel configuration parameters that you want to change. 7. When you are finished setting all of the kernel configuration parameters, select Action --> Process New Kernel from the action menu bar. The HP-UX operating system automatically restarts after you change the values for the kernel configuration parameters.
Recommended kernel configuration parameters (HP-UX)

For HP-UX systems running a DB2 64-bit database system, run the db2osconf command to suggest appropriate kernel configuration parameter values for your system. The db2osconf utility can only be run from $DB2DIR/bin, where $DB2DIR is the directory where you installed your DB2 product.
Modifying kernel parameters (Linux)

Before installing a DB2 database system, update your Linux kernel parameters. The default values for particular kernel parameters on Linux are not sufficient when running a DB2 database system. You must have root authority to modify kernel parameters. To update kernel parameters on Red Hat and SUSE Linux: 1. Run the ipcs -l command 2. Analyze the output to determine if there are any necessary changes required for your system. Comments have been added following the // to show what the parameter names are.
# ipcs -l ------ Shared Memory Limits -------Chapter 5. Additional Linux and UNIX requirements
43
max max max min
number of segments = 4096 // SHMMNI seg size (kbytes) = 32768 // SHMMAX total shared memory (kbytes) = 8388608 // SHMALL seg size (bytes) = 1 // // // // SEMMNI SEMMSL SEMMNS SEMOPM
------ Semaphore Limits -------max number of arrays = 1024 max semaphores per array = 250 max semaphores system wide = 256000 max ops per semop call = 32 semaphore max value = 32767 ------ Messages: Limits -------max queues system wide = 1024 max size of message (bytes) = 65536 default max size of queue (bytes) = 65536
// MSGMNI // MSGMAX // MSGMNB
v Beginning with the first section on Shared Memory Limits, SHMMAX and SHMALL are the parameters that need to be looked at. SHMMAX is the maximum size of a shared memory segment on a Linux system whereas SHMALL is the maximum allocation of shared memory pages on a system. It is recommended to set the SHMMAX value to be equal to the amount of physical memory on your system. However, the minimum required on x86 systems is 268435456 (256 MB) and for 64-bit systems, it is 1073741824 (1 GB). SHMALL is set to 8 GB by default (8388608 KB = 8 GB). If you have more physical memory than this, and it is to be used for DB2, then this parameter increases to approximately 90% of your computers physical memory For instance, if you have a computer system with 16 GB of memory to be used primarily for DB2, then SHMALL should be set to 3774873 (90% of 16 GB is 14.4 GB; 14.4 GB is then divided by 4 KB, which is the base page size). The ipcs output has converted SHMALL into kilobytes. The kernel requires this value as a number of pages. If you are upgrading to DB2 Version 9.7 and you are not using the default SHMALL setting, you must increase the SHMALL setting by an additional 4 GB. This increase in memory is required by the fast communication manager (FCM) for additional buffers or channels. v The next section covers the amount of semaphores available to the operating system. The kernel parameter sem consists of 4 tokens, SEMMSL, SEMMNS, SEMOPM and SEMMNI. SEMMNS is the result of SEMMSL multiplied by SEMMNI. The database manager requires that the number of arrays (SEMMNI) be increased as necessary. Typically, SEMMNI should be twice the maximum number of agents expected on the system multiplied by the number of logical partitions on the database server computer plus the number of local application connections on the database server computer. v The third section covers messages on the system. MSGMNI affects the number of agents that can be started, MSGMAX affects the size of the message that can be sent in a queue, and MSGMNB affects the size of the queue. MSGMAX should be change to 64 KB (that is, 65535 bytes), and MSGMNB should be increased to 65535. 3. To modify these kernel parameters, edit the /etc/sysctl.conf file. If this file does not exist, create it. The following lines are examples of what should be placed into the file:
kernel.sem=250 256000 32 1024 #Example shmmax for a 64-bit system kernel.shmmax=1073741824
44
#Example shmall for 90 percent of 16 GB memory kernel.shmall=3774873 kernel.msgmax=65535 kernel.msgmnb=65535
4. Run sysctl with -p parameter to load in sysctl settings from the default file /etc/sysctl.conf:
sysctl -p
5. To make the changes effective after every reboot: v (SUSE Linux) Make boot.sysctl active v (Red Hat) The rc.sysinit initialization script will read the /etc/sysctl.conf file automatically
Modifying kernel parameters (Solaris Operating System)

For the DB2 database system to operate properly, it is recommended that you update your systems kernel configuration parameters. You can use the db2osconf utility to suggest recommended kernel parameters. If you want to take advantage of project resource controls (/etc/project), consult your Solaris documentation. You must have root authority to modify kernel parameters. To use the db2osconf command, you must first install the DB2 database system. The db2osconf utility can only be run from $DB2DIR/bin, where $DB2DIR is the directory where you installed your DB2 product. You must restart your system after modifying kernel parameters. To set a kernel parameter, add a line at the end of the /etc/system file as follows:
set parameter_name = value
For example, to set the value of the msgsys:msginfo_msgmax parameter, add the following line to the end of the /etc/system file:
set msgsys:msginfo_msgmax = 65535
After updating the /etc/system file, restart the system.
Additional partitioned database environment pre-installation tasks (Linux and UNIX) Updating environment settings for a partitioned DB2 installation (AIX)
This task describes the environment settings that you need to update on each computer that will participate in your partitioned database system. To update AIX environment settings: 1. Log on to the computer as a user with root authority. 2. Set the AIX maxuproc (maximum number of processes per user) device attribute to 4096 by entering the following command:
chdev -l sys0 -a maxuproc=4096
Note: A bosboot/reboot may be required to switch to the 64-bit kernel if a different image is being run.
45
3. Set the TCP/IP network parameters on all the workstations that are participating in your partitioned database system to the following values. These values are the minimum values for these parameters. If any of the network-related parameters are already set to a higher value, do not change it.
thewall sb_max rfc1323 tcp_sendspace tcp_recvspace udp_sendspace udp_recvspace ipqmaxlen somaxconn = = = = = = = = = 65536 1310720 1 221184 221184 65536 65536 250 1024
To list the current settings of all network-related parameters, enter the following command:
no -a | more
To set a parameter, enter the follow command:

no -o parameter_name=value
where: v parameter_name represents the parameter you want to set. v value represents the value that you want to set for this parameter. For example, to set the tcp_sendspace parameter to 221184, enter the following command:
no -o tcp_sendspace=221184
4. If you are using a high speed interconnect, you must set the spoolsize and rpoolsize for css0 to the following values:
spoolsize rpoolsize 16777216 16777216
To list the current settings of these parameters, enter the following command:
lsattr -l css0 -E
To set these parameters, enter the following commands:

/usr/lpp/ssp/css/chgcss -l css0 -a spoolsize=16777216 /usr/lpp/ssp/css/chgcss -l css0 -a rpoolsize=16777216
If you are not using the /tftpboot/tuning.cst file to tune your system, you can use the DB2DIR/misc/rc.local.sample sample script file, where DB2DIR is path where the DB2 product has been installed to, to update the network-related parameters after installation. To update the network-related parameters using the sample script file after installation, perform the following steps: a. Copy this script file to the /etc directory and make it executable by root by entering the following commands:
cp /usr/opt/db2_09_01/misc/rc.local.sample /etc/rc.local chown root:sys /etc/rc.local chmod 744 /etc/rc.local
b. Review the /etc/rc.local file and update it if necessary. c. Add an entry to the /etc/inittab file so that the /etc/rc.local script is executed whenever the machine is rebooted. You can use the mkitab command to add an entry to the /etc/inittab file. To add this entry, enter the following command:
mkitab "rclocal:2:wait:/etc/rc.local > /dev/console 2>&1"
46
d. Ensure that /etc/rc.nfs entry is included in the /etc/inittab file by entering the following command:
lsitab rcnfs
e. Update the network parameters without rebooting your system by entering the following command:
/etc/rc.local
5. Ensure that you have enough paging space for a partitioned installation of DB2 ESE to run. If you do not have sufficient paging space, the operating system will kill the process that is using the most virtual memory (this is likely to be one of the DB2 processes). To check for available paging space, enter the following command:
lsps -a
This command will return output similar to the following:

Page Space Physical Volume Volume Group Size paging00 hdisk1 rootvg 60MB hd6 hdisk0 rootvg 60MB hd6 hdisk2 rootvg 64MB %Used 19 21 21 Active yes yes yes Auto yes yes yes Type lv lv lv
The paging space available should be equal to twice the amount of physical memory installed on your computer. 6. If you are creating a small to intermediate size partitioned database system, the number of network file system daemons (NFSDs) on the instance-owning computer should be close to:
# of biod on a computer # of computers in the instance
Ideally, you should run 10 biod processes on every computer. According to the above formula, on a four computer system with 10 biod processes, you use 40 NFSDs. If you are installing a larger system, you can have up to 120 NFSDs on the computer. For additional information about NFS, refer to your NFS documentation.
Setting up a working collective to distribute commands to ESE workstations (AIX)

In a partitioned database environment on AIX, you can set up a working collective to distribute commands to the set of workstations that participate in your partitioned database system. Commands can be distributed to the workstations by the dsh command. This can be useful when installing or administrating a partitioned database system on AIX, to enable you to quickly execute the same commands on all the computers in your environment with less opportunity for error. You must know the hostname of each computer that you want to include in the working collective. You must be logged on to the Control workstation as a user with root authority. Have a file that lists the hostnames for all of the workstations that will participate in your partitioned database system. To set up the working collective to distribute commands to this list of workstations: 1. Create a file called eeelist.txt that will list the hostnames for all of the workstations that will participate in the working collective.
47
For example, assume that you wanted to create a working collective with two workstations called workstation1 and workstation2. The contents of eeelist.txt would be:
workstation1 workstation2
2. Update the working collective environment variable. To update this list, enter the following command:
export WCOLL=path/eeelist.txt
where path is the location where eeelist.txt was created, and eeelist.txt is the name of the file that you created that lists the workstations in the working collective. 3. Verify that the names in the working collective are indeed the workstations that you want, by entering the following command:
dsh -q
You will receive output similar to the following:

Working collective file /eeelist.txt: workstation1 workstation2 Fanout: 64
Verifying port range availability on participating computers (Linux and UNIX)

This task describes the steps required to verify port range availability on participating computers. The port range is used by the Fast Communications Manager (FCM). FCM is a feature of DB2 that handles communications between database partition servers. Verifying the port range availability on participating computers should be done after you install the instance-owning database partition server and before you install any participating database partition servers. When you install the instance-owning database partition server on the primary computer, DB2 reserves a port range according to the specified number of logical database partition servers participating in partitioned database environment. The default range is four ports. For each server that participates in the partitioned database environment, you must manually configure the /etc/services file for the FCM ports. The range of the FCM ports depends on how many logical partitions you want to use on the participating computer. A minimum of two entries are required, DB2_<instance> and DB2_<instance>_END. Other requirements for the FCM ports specified on participating computers are: v The starting port number must match the starting port number of the primary computer v Subsequent ports must be sequentially numbered v Specified port numbers must be free To make changes to the services file, you require root authority. To verify the port range availability on participating computers: 1. Open the services file located in the /etc/services directory. 2. Locate the ports reserved for the DB2 Fast Communications Manager (FCM). The entries should appear similar to the following:
48
DB2_db2inst1 DB2_db2inst1_1 DB2_db2inst1_2 DB2_db2inst1_END
60000/tcp 60001/tcp 60002/tcp 60003/tcp
DB2 reserves the first four available ports after 60000. 3. On each participating computer, open the services file and verify that the ports reserved for DB2 FCM in the services file of the primary computer are not being used. 4. In the event that the required ports are in use on a participating computer, identify an available port range for all computers and update each service file, including the services file on the primary computer. After you install the instance-owning database partition server on the primary computer, you must install your DB2 product on the participating database partition servers. You can use the response file generated for the partitioning servers (default name is db2ese_addpart.rsp), you need to manually configure the /etc/services files for the FCM ports. The range of the FCM ports depend on how many logical partitions you want to use on the current machine. The minimum entries are for DB2_ and DB2__END two entries with consecutive free port numbers. The FCM port numbers used on each participating machines must have the same starting port number, and subsequent ports must be sequentially numbered.
Creating a DB2 home file system for a partitioned database environment

To install DB2 Enterprise Server Edition and create a partitioned database environment, you must have a file system that is available to all of the machines. This file system will be used as the instance home directory. It can also be used as a temporary location for the contents of the DB2 database product CD.
Creating a DB2 home file system for a partitioned database system (AIX)
This task is part of setting up your partitioned database system. This task describes how to: v create a DB2 home file system v NFS export the home file system v NFS mount the home file system from each participating computer It is recommended that you create a home file system that is as large as the content on the DB2 product DVD. You can use the following command to check the size, shown in KB:
du -sk <DVD mounting point>
A DB2 instance will require at least 200 MB of space. If you do not have enough free space, you can mount the DB2 product DVD from each participating computer as an alternative to copying the contents to disk. You must have: v root authority to create a file system v Created a volume group where your file system is to be physically located.
49
To create, NFS export, and NFS mount the DB2 home file system, perform the following steps: Creating the DB2 home file system Log on to the primary computer (ServerA) in your partitioned database system as a user with root authority and create a home file system for your partitioned database system called /db2home. 1. Enter the smit jfs command. 2. Click on the Add a Journaled File System icon. 3. Click on the Add a Standard Journaled File System icon. 4. Select an existing volume group from the Volume Group Name list where you want this file system to be physically located. 5. Set the SIZE of file system (SIZE of file system (in 512byte blocks) (Num.) field). This sizing is enumerated in 512-byte blocks, so if you only need to create a file system for the instance home directory, you can use 180 000, which is about 90 MB. If you need to copy the product DVD image over to run the installation, you can create it with a value of 2 000 000, which is about 1 GB. 6. Enter the mount point for this file system in the MOUNT POINT field. In this example, the mount point is /db2home. 7. Set the Mount AUTOMATICALLY at system restart field to yes. The remaining fields can be left to the default settings. 8. Click OK. Exporting the DB2 home file system 1. NFS export the /db2home file system so that it is available to all of the computers that will participate in your partitioned database system: a. Enter the smit nfs command. b. Click on the Network File System (NFS) icon. c. Click on the Add a Directory to Exports List icon. d. Enter the pathname and directory to export (for example, /db2home) in the PATHNAME of directory to export field. e. Enter the name of each workstation that will participate in your partitioned database system in the HOSTS allowed root access field. Use a comma (,) as the delimiter between each name. For example, ServerA, ServerB, ServerC. If you are using a high speed interconnect, it is recommended that you specify the high speed interconnect names for each workstation in this field as well. The remaining fields can be left to the default settings. f. Click OK. 2. Log out. Mounting the DB2 home file system from each participating computer Log on to each participating computer (ServerB, ServerC, ServerD) and NFS mount the file system that you exported by performing the following steps: 1. Enter the smit nfs command. 2. Click on the Network File System (NFS) icon. 3. Click on the Add a File System for Mounting icon. 4. Enter the pathname of the mount point in the PATHNAME of the mount point (Path) field.
50
The path name of the mount point is where you should create the DB2 home directory. For this example, use /db2home. 5. Enter the pathname of the remote directory in the PATHNAME of the remote directory field. For our example, you should enter the same value that you entered in the PATHNAME of the mount point (Path) field. 6. Enter the hostname of the machine where you exported the file system in the HOST where the remote directory resides field. This value is the hostname of the machine where the file system that you are mounting was created. To improve performance, you may want to NFS mount the file system that you created over a high speed interconnect. If you want to mount this file system using a high speed interconnect, you must enter its name in the HOST where remote directory resides field. You should be aware that if the high speed interconnect ever becomes unavailable for some reason, every workstation that participates in your partitioned database system will lose access to the DB2 home directory. 7. Set the MOUNT now, add entry to /etc/filesystems or both? field to both. 8. Set the /etc/filesystems entry will mount the directory on system RESTART field to yes. 9. Set the MODE for this NFS file system field to read-write. 10. Set the Mount file system soft or hard field to soft. A soft mount means that the computer will not try for an infinite period of time to remotely mount the directory. A hard mount means that your machine will infinitely try to mount the directory. This can cause problems in the event of a system crash. It is recommended that you set this field to soft. The remaining fields can be left to the default settings. 11. Ensure that this file system is mounted with the Allow execution of SUID and sgid programs in this file system? field set to Yes. This is the default setting. 12. Click OK. 13. Log out.
Creating a DB2 home file system for a partitioned database system (HP-UX)
This task is part of setting up your partitioned database system. This task describes how to: v create a DB2 home file system v NFS export the home file system v NFS mount the home file system from each participating computer It is recommended that you create a home file system that is as large as the content on the DB2 product DVD. You can use the following command to check the size, shown in KB:
51
A DB2 instance will require at least 50 MB of space. If you do not have enough free space, you can mount the DB2 product DVD from each participating computer as an alternative to copying the contents to disk. You must have root authority to create a file system. To create, NFS export, and NFS mount the DB2 home file system, perform the following steps: Creating the DB2 home file system Manually: 1. Select a disk partition or logical volume and use a utility like newfs to create this file system. For more information, enter the man newfs command. 2. Mount this file system locally and add an entry to the /etc/fstab file so that this file system is mounted each time the system is restarted. Using SAM: 1. Enter the sam command. 2. Click on the Disks and File Systems icon. 3. Click on the File Systems icon. 4. Select Action > Add Local File systems. 5. You can choose either to use or not to use a Logical Volume Manager. It is recommended to use a Logical Volume Manager. Exporting the DB2 home file system If you are installing DB2 ESE on a cluster of HP-UX systems, you can add an entry to the /etc/exports file to export this file system via NFS, or use SAM. To export the file system using SAM: 1. Enter the sam command. 2. Click on the Networking and Communications icon. 3. Click on the Networked File Systems icon. 4. Click on the Exported Local File Systems icon. 5. Click the Action menu and select Add Exported File System 6. Enter the pathname and directory to export (for example, /db2home) in the Local Directory Name field. 7. Click the User Access button and add read-write access for the other computers in the instance in the window that appears. 8. Click the Root User Access button and add access for the other computers in the instance in the window that appears. 9. Click OK. 10. Log out. Mounting the DB2 home file system from each participating computer After you have exported this file system, you must mount this file system on each of the participating computers. On 1. 2. 3. each participating computer: Enter the sam command. Click on the Networking and Communications icon. Click on the Networked File Systems icon.
52
4. Click on the Mounted Remote File Systems icon. 5. Click the Action menu and select Add Remote File System Using NFS 6. Enter the mount point of the file system to mount (for example, /db2home) in the Local Directory Name field. 7. Enter the name of the remote server (for example, ServerA) in the Remote Server Name field. 8. Enter the pathname and directory of the remote directory (for example, /db2home) in the Remote Directory Name field. 9. Set the Mount At System Boot option on. 10. Click the NFS Mount Options button and set soft mount type and the Allow SetUID Execution option on. A soft mount means that the computer will not try for an infinite period of time to remotely mount the directory. A hard mount means that your machine will infinitely try to mount the directory. This can cause problems in the event of a system crash. It is recommended that you set this field to soft. The remaining fields can be left to the default settings. 11. Click OK. 12. Log out.
Creating a file system for a partitioned DB2 server (Linux)

This task is part of setting up your partitioned database system. This task describes how to: v create a DB2 home file system v NFS export the home file system v NFS mount the home file system from each participating computer You must have a file system that is available to all machines that will participate in your partitioned database system. This file system will be used as the instance home directory. For configurations that use more than one machine for a single database instance, NFS (Network File System) is used to share this file system. Typically, one machine in a cluster is used to export the file system using NFS, and the remaining machines in the cluster mount the NFS file system from this machine. The machine that exports the file system has the file system mounted locally. For more command information, see your Linux distribution documentation. To create this file system: 1. On one machine, select a disk partition or create one using fdisk. 2. Using a utility like mkfs, create a file system on this partition. The file system should be large enough to contain the necessary DB2 program files as well as enough space for your database needs. 3. Locally mount the file system you have just created and add an entry to the /etc/fstab file so that this file system is mounted each time the system is rebooted. For example:
/dev/hda1 /db2home ext3 defaults 1 2
4. To automatically export an NFS file system on Linux at boot time, add an entry to the /etc/exports file. Be sure to include all of the host names participating in
53
the cluster as well as all of the names that a machine might be known as. Also, ensure that each machine in the cluster has root authority on the exported file system by using the root option. The /etc/exports file is an ASCII file which contains the following type of information:
/db2home machine1_name(rw) machine2_name(rw)
To export the NFS directory, run

/usr/sbin/exports -r
5. On each of the remaining machines in the cluster, add an entry to the /etc/fstab file to NFS mount the file system automatically at boot time. As in the following example, when you specify the mount point options, ensure that the file system is mounted at boot time, is read-write, is mounted hard, includes the bg (background) option, and that setuid programs can be run properly.
fusion-en:/db2home /db2home nfs rw,timeo=7, hard,intr,bg,suid,lock
where fusion-en represents the machine name. 6. NFS mount the exported file system on each of the remaining machines in the cluster by entering the following command:
mount /db2home
If the mount command fails, use the showmount command to check the status of the NFS server. For example:
showmount -e fusion-en
where fusion-en represents the machine name. This showmount command should list the file systems which are exported from the machine named fusion-en. If this command fails, the NFS server may not have been started. Run the following command as root on the NFS server to start the server manually:
/etc/rc.d/init.d/nfs restart
Assuming the present run level is 3, you can have this command run automatically at boot time by renaming K20nfs to S20nfs under the following directory: /etc/rc.d/rc3.d. 7. Ensure that the following steps were successful: a. On a single machine in the cluster, you have created a file system to be used as the instance and home directory. b. If you have a configuration that uses more than one machine for a single database instance, you have exported this file system using NFS. c. You have mounted the exported file system on each of the remaining machines in the cluster.
Creating a file system for a partitioned DB2 server (Solaris Operating System)
This task is part of setting up your partitioned database system. This task describes how to: v create a DB2 home file system v NFS export the home file system v NFS mount the home file system from each participating computer
54
It is recommended that you create a home file system that is as large as the content on the DB2 product DVD. You can use the following command to check the size, shown in KB:
A DB2 instance will require at least 50 MB of space. If you do not have enough free space, you can mount the DB2 product DVD from each participating computer as an alternative to copying the contents to disk. There are a number of ways to create a local file system on Solaris Operating Systems. If you want to use a product, such as Veritas, to create the file system, refer to the products documentation. You must have root authority to create a file system. To create, NFS export, and NFS mount the DB2 home file system, perform the following steps: Creating the DB2 home file system 1. On the primary computer (ServerA), select a disk partition or configure one using the format command. When using the format command, ensure that the disk partitions being used do not overlap. Overlapping partitions can cause data corruption or file system failures. Ensure you have correctly entered the command, as mistakes can cause serious problems. 2. Using a utility like newfs or mkfs, create a file system on this partition. The file system should be large enough to contain the necessary DB2 files as well as other non-DB2 files. A minimum of 300 MB is recommended. 3. Locally mount the file system you have just created and add an entry to the /etc/vfstab file so that this file system is mounted each time the system is rebooted. For example:
/dev/dsk/c1t0d2s2 /dev/rdsk/c1t0d2s2 /db2home ufs 2 yes -
Exporting the DB2 home file system 1. To automatically export an NFS file system on Solaris at boot time, add an entry to the /etc/dfs/dfstab file. Be sure to include all of the host names of the participating computers as well as all of the names that a given computer might be known as. Also, ensure that each computer has root authority on the exported file system by using the root option. In the following example, an entry for a four computer partitioned database system is added to the /etc/dfs/dfstab file. The participating computers, ServerB, ServerC, and ServerD, are given permission to mount the file system /db2home, which will be used as the DB2 home file system.
share -F nfs -o \ rw=ServerB.torolab.ibm.com,\ root=ServerB.torolab.ibm.com \ rw=ServerC.torolab.ibm.com, \ root=ServerC.torolab.ibm.com\ rw=ServerD.torolab.ibm.com,\ root=ServerD.torolab.ibm.com \ -d "homes" /db2home
55
If a computer is known by more than one hostname, all aliases must be included in the /etc/dfs/dfstab file. For example, if ServerB was also known by the name ServerB-tokenring, the entry in the /etc/dfs/dfstab for ServerB appears as follows:
rw=ServerB.torolab.ibm.com:ServerB-tokenring.torolab.ibm.com,\ root=ServerB.torolab.ibm.com:ServerB-tokenring.torolab.ibm.com \
2. On each of the participating computers, add an entry to the /etc/vfstab file to NFS mount the file system automatically at boot time. As in the following example, when you specify the mount point options, ensure that the file system is mounted at boot time, is read-write, is mounted hard, includes the bg (background) option, and that suid programs can be run properly:
ServerA:/db2home - /db2home nfs yes rw,hard,intr,bg,suid
Mounting the DB2 home file system from each participating computer 1. Create and NFS mount the exported file system on each of the participating computers in the partitioned database environment by entering the following commands:
mkdir /db2home mount /db2home
If the mount command fails, use the showmount command to check the status of the NFS server. For example:
showmount -e ServerA
This showmount command should list the file systems which are exported from the computer named ServerA. If this command fails, the NFS server may not have been started. To start the server manually, run the following commands as root on the NFS server:
/usr/lib/nfs/mountd /usr/lib/nfs/nfsd -a 16
These commands are run automatically at boot time if there are any entries in the /etc/dfs/dfstab file. After starting the NFS server, export the NFS file system again by running the following command:
sh /etc/dfs/dfstab
Ensure that you have completed the following steps: 1. On a single computer in the partitioned database environment, you have created a file system to be used as the instance and home directory. 2. You have exported this file system via NFS. 3. You have mounted the exported file system on each participating computer.
Verifying that NFS is running (Linux and UNIX)

Before setting up a database partitioned environment, you should verify that Network File System (NFS) is running on each computer that will participate in your partitioned database system. NFS must be running on each computer. To verify that NFS is running on each computer: AIX operating systems Type the following command on each computer:
lssrc -g nfs
56
The Status field for NFS processes should indicate active. After you have verified that NFS is running on each system, you should check for the specific NFS processes required by DB2 products. The required processes are:
rpc.lockd rpc.statd
HP-UX and Solaris operating systems Type the following command on each computer:
showmount -e hostname
Enter the showmount command without the hostname parameter to check the local system. If NFS is not active you will receive a message similar to the following:
showmount: ServerA: RPC: Program not registered
After you have verified that NFS is running on each system, you should check for the specific NFS processes required by DB2 products:
rpc.lockd rpc.statd
You can use the following commands to check for these processes:
ps -ef | grep rpc.lockd ps -ef | grep rpc.statd
Linux operating systems Type the following command on each computer:

showmount -e hostname
Enter the showmount command without the hostname parameter to check the local system. If NFS is not active you will receive a message similar to the following:
showmount: ServerA: RPC: Program not registered
After you have verified that NFS is running on each system, you should check for the specific NFS processes required by DB2 products. The required process is rpc.statd. You can use the ps -ef | grep rpc.statd commands to check for this process. If these processes are not running, consult your operating system documentation.
57
58
Chapter 6. Mounting product CDs or DVDs on Linux or UNIX

Mounting CDs or DVDs (AIX)
Depending on your system configuration, you might need to log on as root to mount discs. To mount the CD or DVD on AIX using the System Management Interface Tool (SMIT), perform the following steps: 1. Insert the disc in the drive. 2. Create a disc mount point by entering the mkdir -p /disc command, where disc represents the CD or DVD mount point directory. 3. Allocate a disc file system using SMIT by entering the smit storage command. 4. After SMIT starts, select File Systems > Add / Change / Show / Delete File Systems > CDROM File Systems > Add CDROM File System. 5. In the Add a File System window: v Enter a device name for your CD or DVD file system in the DEVICE Name field. Device names for CD or DVD file systems must be unique. If there is a duplicate device name, you may need to delete a previously-defined CD or DVD file system or use another name for your directory. In our example, we will use /dev/cd0 as the device name. v Enter the disc mount point directory in the MOUNT POINT window. In our example, the mount point directory is /disc. v In the Mount AUTOMATICALLY at system restart field, select yes to enable automatic mounting of the file system. v Click OK to close the window, then click Cancel three times to exit SMIT. 6. Next, mount the CD or DVD file system by entering the smit mountfs command. 7. In the Mount a File System window: v Enter the device name for this CD or DVD file system in the FILE SYSTEM name field. In our example, the device name is /dev/cd0. v Enter the disc mount point in the Directory over which to mount field. In our example, the mount point is /disc. v Enter cdrfs in the Type of Filesystem field. To view the other kinds of file systems you can mount, click List. v In the Mount as READ-ONLY system field, select yes. v Accept the remaining default values and click OK to close the window. Your CD or DVD file system is now mounted. To view the contents of the CD or DVD, place the disk in the drive and enter the cd /disc command where disc is the disc mount point directory.
Mounting CDs or DVDs (HP-UX)

This topic explains how to mount your DB2 product CD or DVD for HP-UX.
59
Depending on your system configuration, you might need to log on as root to mount discs. To mount your DB2 for HP-UX product CD or DVD: 1. Insert the CD or DVD in the drive. 2. If necessary, define a new directory as the mount point for the CD or DVD drive. Define /cdrom as the mount point using the mkdir /cdrom command. 3. If necessary, identify the drive device file using the ioscan -fnC disk command. This command lists all recognized CD or DVD drives and their associated device files. The file name will be something similar to /dev/dsk/c1t2d0. 4. Mount the CD or DVD drive to the mount-point directory:
mount -F cdfs -o rr /dev/dsk/c1t2d0 /cdrom
5. Obtain a file listing to verify the mount using the ls /cdrom command. 6. Log out. Your CD or DVD file system is now mounted. View the contents of the CD or DVD by placing it in the drive and enter the cd /cdrom command where cdrom is the mount point directory.
Mounting the CD or DVD (Linux)

Depending on your system configuration, you can log on as root to mount discs. To mount the CD or DVD on Linux operating systems: 1. Insert the CD or DVD in the drive and enter the following command:
mount -t iso9660 -o ro /dev/cdrom /cdrom
where /cdrom represents the mount point of the CD or DVD. 2. Log out. Your CD or DVD file system is now mounted. View the contents of the CD or DVD by placing the disc in the drive and enter the cd /cdrom command where cdrom is the mount point directory.
Mounting CDs or DVDs (Solaris Operating System)

If you are mounting the CD or DVD drive from a remote system using NFS, the CD or DVD file system on the remote computer must be exported with root access. Depending on your local system configuration, you might also need root access on the local computer. To mount the CD or DVD on Solaris Operating System: 1. Insert the CD or DVD into the drive. 2. If the Volume Manager (vold) is running on your system, the disc is automatically mounted as /cdrom/cd_label if the CD or DVD has a label or /cdrom/unnamed_cdrom if it is unlabeled. If the Volume Manager is not running on your system, complete the following steps to mount the CD or DVD: a. Determine the name of the device by entering the following command:
ls -al /dev/sr* |awk {print "/" $11}
60
This command returns the name of the CD or DVD device. In this example, the command returns the string /dev/dsk/c0t6d0s2. b. Enter the following commands to mount the CD or DVD:
mkdir -p /cdrom/unnamed_cdrom mount -F hsfs -o ro /dev/dsk/c0t6d0s2 /cdrom/unnamed_cdrom
where /dev/dsk/c0t6d0s2 represents the name of the device that was returned in the preceding step and /cdrom/unnamed_cdrom represents the CD or DVD mount directory. Note: If you are mounting the CD or DVD drive from a remote system using NFS, the CD or DVD file system on the remote machine must be exported with root access. You must also mount that file system with root access on the local machine. 3. Log out. Your CD or DVD file system is now mounted. View the contents of the CD or DVD by placing the disk in the drive and enter the cd /cdrom command where cdrom is the mount point directory.
Chapter 6. Mounting product CDs or DVDs on Linux or UNIX
61
62
Chapter 7. Installing on Windows

An overview of installing your DB2 server product (Windows)
This topic outlines the steps for installing your DB2 server product on Windows. To 1. 2. 3. install your DB2 server product: Review your DB2 product prerequisites. Review DB2 upgrade information if applicable. Prepare the installation media: Product DVD Insert the DB2 product DVD into your DVD-ROM drive. Installation image If you downloaded an installation image, extract the file. 4. Install your DB2 product using: v the DB2 Setup wizard. v a silent installation with a response file. You can use the DB2 Setup wizard to perform installation and configuration tasks, such as: v Selecting DB2 installation type (typical, compact, or custom). v Selecting DB2 product installation location. v Installing the languages that you can specify later as the default language for the product interface and messages. v Setting up DB2 Extended Security. v Setting up a DB2 instance (including instance user setup. By default, it is same as the DAS user). v Setting up the DB2 Administration Server (including DAS user setup). v Setting up the DB2 Text Search server. v Setting up Administration contact and health monitor notification. v Setting up and configuring your instance setup and configuration (including instance user setup). v Preparing the DB2 tools catalog. v Specifying the DB2 Information Center port. v Creating response files. v Installing additional products.
Installing DB2 servers (Windows)

This task describes how to start the DB2 Setup wizard on Windows. You will use the DB2 Setup wizard to define your installation and install your DB2 database product on your system. Before you begin Before you start the DB2 Setup wizard: v If you are planning on setting up a partitioned database environment, refer to Setting up a partitioned database environment.
63
v Ensure that your system meets installation, memory, and disk requirements. v If you are planning to use LDAP on Windows to register the DB2 server in Active Directory, you should extend the directory schema before you install. v If you are planning to use the IBM Tivoli Monitoring for Databases: DB2 Agent, before installing your DB2 product see topic Installing IBM Tivoli Monitoring for Databases: DB2 Agent with the DB2 installer for details, limitations and restrictions. v You must have a local Administrator user account with the recommended user rights to perform the installation. In DB2 database servers where LocalSystem can be used as the DAS and DB2 instance user and you are not using the database partitioning feature, a non-administrator user with elevated privileges can perform the installation. Note: If a non-Administrator user account is going to do the product installation, then the VS2005 runtime library must be installed before attempting to install a DB2 database product. The VS2005 runtime library is needed on the operating system before the DB2 database product can be installed. The VS2005 runtime library is available from the Microsoft runtime library download web site. There are two choices: choose vcredist_x86.exe for 32-bit systems or vcredist_x64.exe for 64-bit systems. v Although not mandatory, it is recommended that you close all programs so that the installation program can update any files on the computer without requiring a reboot. v Installing DB2 products from a virtual drive or an unmapped network drive (such as \\hostname\sharename in Windows Explorer) is not supported. Before attempting to install DB2 products, you must map the network drive to a Windows drive letter (for example, Z:). Restrictions v You cannot have more than one instance of the DB2 Setup wizard running in any user account. v The DB2 copy name and the instance name cannot start with a numeric value.The DB2 copy name is limited to 64 English characters consisting of the characters A-Z, a-z and 0-9. v The DB2 copy name and the instance name must be unique among all DB2 copies. v The use of XML features is restricted to a database that has only one database partition. v No other DB2 database product can be installed in the same path if one of the following is already installed: IBM Data Server Runtime Client IBM Data Server Driver Package DB2 Information Center v The DB2 Setup wizard fields do not accept non-English characters. v If you enable extended security on Windows Vista or Windows 2008, or higher, users must belong to the DB2ADMNS or DB2USERS group to run local DB2 commands and applications because of an extra security feature (User Access Control) that limits the privileges that local administrators have by default. If users do not belong to one of these groups, they will not have read access to local DB2 configuration or application data. Procedure
64
To start the DB2 Setup wizard: 1. Log on to the system with the local Administrator account that you have defined for the DB2 installation. 2. If you have the DB2 database product DVD, insert it into the drive. If enabled, the autorun feature automatically starts the DB2 Setup Launchpad. If the autorun does not work, use Windows Explorer to browse the DB2 database product DVD and double-click on the setup icon to start the DB2 Setup Launchpad. 3. If you downloaded the DB2 database product from passport advantage, run the executable file to extract the DB2 database product installation files. Use Windows Explorer to browse the DB2 installation files and double-click on the setup icon to start the DB2 Setup Launchpad. 4. From the DB2 Setup launchpad, you can view installation prerequisites and the release notes, or you can proceed directly to the installation. You may want to review the installation prerequisites and release notes for late-breaking information. 5. Click Install a Product and the Install a Product window will display the products available for installation. If you have no existing DB2 database products installed on your computer, launch the installation by clicking Install New. Proceed through the installation following the DB2 Setup wizards prompts. If you have at least one existing DB2 database product installed on your computer, you can: v Click Install New to create a new DB2 copy. v Click Work with Existing to update an existing DB2 copy, to add function to an existing DB2 copy, upgrade an existing DB2 Version 8, Version 9.1, or Version 9.5 copy, or to install an add-on product. 6. The DB2 Setup wizard will determine the system language, and launch the setup program for that language. Online help is available to guide you through the remaining steps. To invoke the online help, click Help or press F1. You can click Cancel at any time to end the installation. Results Your DB2 database product will be installed, by default, in the Program_Files\IBM\sqllib directory, where Program_Files represents the location of the Program Files directory. If you are installing on a system where this directory is already being used, the DB2 database product installation path will have _xx added to it, where xx are digits, starting at 01 and increasing depending on how many DB2 copies you have installed. You can also specify your own DB2 database product installation path. What to do next v Verify your installation. v Perform the necessary post-installation tasks. For information on errors encountered during installation, review the installation log file located in the My Documents\DB2LOG\ directory. The log file uses the following format: DB2-ProductAbrrev-DateTime.log, for example, DB2-ESE-Tue Apr 04 17_04_45 2008.log.
65
If this is a new DB2 product installation on Vista 64bit, and you will use a 32bit OLE DB provider, you must manually register the IBMDADB2 DLL. To register this DLL, run the following command:
c:\windows\SysWOW64\regsvr32 /s c:\Program_Files\IBM\SQLLIB\bin\ibmdadb2.dll
where Program_Files represents the location of the Program Files directory. If you want your DB2 database product to have access to DB2 documentation either on your local computer or on another computer on your network, then you must install the DB2 Information Center. The DB2 Information Center contains documentation for the DB2 database system and DB2 related products. By default, DB2 information will be accessed from the web if the DB2 Information Center is not locally installed. DB2 Express Edition and DB2 Workgroup Server Edition memory limits If you are installing DB2 Express Edition, the maximum allowed memory for the instance is 4 GB. If you are installing DB2 Workgroup Server Edition, the maximum allowed memory for the instance is 16 GB. The amount of memory allocated to the instance is determined by the INSTANCE_MEMORY database manager configuration parameter. Important notes when upgrading from Versions 9.1 or 9.5: v If the memory configuration for your Version 9.1 DB2 database product exceeds the allowed limit, the DB2 database product might not start after upgrading to the current version. v The self tuning memory manager will not increase your overall instance memory limit beyond the license limits.
Multiple DB2 copies on the same computer (Windows)

You can use multiple DB2 copies on the same computer. Each DB2 copy can be at the same or different code levels. The benefits of doing this include: v The ability to run applications that require different DB2 versions on the same machine at the same time. v The ability to run independent copies of DB2 products for different functions. v The ability to test on the same computer before moving the production database to the latter version of the DB2 product. v For independent software vendors, the ability to embed a DB2 server product into your product and hide the DB2 database from your users. A DB2 copy can contain one or more different DB2 products. This refers to the group of DB2 products that are installed at the same location. Differences when only one DB2 copy is installed v During installation, a unique Default DB2 copy name is generated. You can only change the name of the default DB2 copy as you go through the DB2 Setup wizard. You cannot change the DB2 copy name after the installation is completed. v Applications use the Default DB2 copy in an environment similar to the DB2 Version 8 environment. Differences when multiple DB2 copies are installed on the same computer
66
v DB2 Version 8 can coexist with DB2 Version 9.1 and DB2 Version 9.5, with restrictions described below. v The DB2 Version 8 copy must be the default copy even though you may have multiple copies of DB2 Version 9.1 or Version 9.5. This default copy cannot be changed. After DB2 Version 8 is uninstalled, you can use the Global Switcher to set the default copy to any the DB2 Version 9.1 or Version 9.5 copies. v Optional: You can configure each DB2 copy to use a different DB2 Information Center. Note: You can have only one copy of the DB2 Information Center installed on the same system at the same Release level. Specifically, you can have a Version 8, a Version 9.1, and a Version 9.5 (or higher) DB2 Information Center on the same system, but you cannot have one DB2 Information Center at Version 9 fix pack 1 and another at Version 9 fix pack 2 on the same machine. You can however configure the DB2 database server to access these DB2 Information Centers remotely. v Only the IBM Data Server Provider for .NET from the default IBM database client interface copy is registered in the Global Assembly Cache. If Version 8 is installed with Version 9, the IBM Data Server Provider for .NET 2.0 Provider from Version 9 is also registered in the Global Assembly Cache. Version 8 does not have a 2.0 .NET provider. v Each instance name must be unique. For a response file installation with NO_CONFIG=YES, the default instance will not be created. However, when you create the instance after the installation, it must be unique. The name of the default instance will be DB2. If an instance of the DB2 name already exists, a unique name for the instance is generated to ensure uniqueness. This is done by using the DB2 name and adding an underscore and generating the last 2 characters in numerical sequence. The subsequent instance names generated are DB2_01, DB2_02, and so on. For performance reasons, the DB2 Control Center should only be used from one DB2 copy at a single time on a machine. For Microsoft COM+ applications, it is recommended that you use and distribute the IBM Data Server Driver Package (installer) or IBM Data Server Driver for ODBC and CLI (zip) with your application instead of the IBM Data Server Runtime Client as only one Data Server Runtime Client can be used for COM+ applications at a time. The IBM Data Server Driver Package (installer) or IBM Data Server Driver for ODBC and CLI (zip) does not have this restriction. Microsoft COM+ applications accessing DB2 data sources are only supported with the default DB2 copy. Concurrent support of COM+ applications accessing different DB2 copies is not supported. If you have DB2 Universal Database (UDB) Version 8 installed, you can only use DB2 UDB Version 8 to run these applications. If you have DB2 Version 9 or higher installed, you can change the default DB2 copy using the Default DB2 Copy Selection Wizard, but you can not use them concurrently. Choosing a default when installing a new DB2 copy
67
System environment
DB2COPY1
-ESE -WSE -...
DB2COPY n... DB2COPY3 DB2COPY2

-ESE -CLIENT -...
Legend
Default DB2 copy
In Version 9.1, you can have a scenario where you have installed multiple DB2 copies. (In this example, DB2COPY1, DB2COPY2, and on to DB2COPYn.) One of the DB2 copies is selected by you as the default DB2 copy. In this case, DB2COPY1 is selected as the default DB2 copy. Beginning with Version 9.5, image a scenario where you install one DB2 copy (DB2COPY1). It is the default DB2 copy and the default IBM database client interface copy.
System environment
Install a DB2 product as a new DB2 copy (DB2COPY2)
DB2COPY1
-ESE -WSE -...
No
Make DB2COPY2 the default DB2 copy?
DB2COPY2
-ESE -CLIENT -...
Legend
Default DB2 copy Default IBM database client interface copy
Then you install a DB2 product in a new DB2 copy (DB2COPY2). During the installation of the new DB2 copy (DB2COPY2) you are asked if you want to make the new DB2 copy the default DB2 copy. If you respond No, then DB2COPY1 remains the default DB2 copy. (It is also the default IBM database client interface copy.)
68
However, consider the same scenario but you respond Yes when asked if you want to make the new DB2 copy the default DB2 copy.
System environment
Install a DB2 product as a new DB2 copy (DB2COPY2)
DB2COPY1
-ESE -WSE -...
DB2COPY2
Yes
-ESE -CLIENT -...
Legend
In this case, DB2COPY2 becomes the new default DB2 copy (and the default IBM database client interface copy). Version 8 coexistence DB2 Version 8 and DB2 Version 9 can coexist with the restriction that DB2 Version 8 is set as the Default DB2 copy. To no longer have DB2 Version 8 as the Default DB2 copy, you can upgrade that DB2 copy to DB2 Version 9 and then change the Default DB2 copy. On the server, there can be only one DAS version and it administers instances as follows: v If the DAS is on Version 9, then it can administer Version 8 and Version 9 instances. v If the DAS is on Version 8, then it can administer only Version 8 instances. You can upgrade your Version 8 DAS, or drop it and create a new Version 9 DAS to administer the Version 8 and Version 9 instances. This is required only if you want to use the Control Center to administer the instances. Version 8 and Version 9 coexistence and the DB2 .NET Data Provider In DB2 Version 9, the DB2 .NET Data Provider has System.Transaction support. However, this is only available for the default DB2 copy and is therefore not supported in a coexistence environment. If Version 8 is installed, the 1.1 .NET Data Provider registered in the Global Assembly Cache will be from Version 8. The 2.0 provider, that is registered, will be from Version 9. The 2.0 provider cannot be used in the same process that uses the 1.1 provider, OLE DB, or ODBC to connect to DB2. 3rd party applications that run as a service By default, 3rd party applications that dynamically bind DB2 DLLs, for example, that are linked with db2api.lib, will find the DB2 DLLs in the current PATH. This means that existing applications that are not enabled for multi-version support will use the Default DB2 copy. To work around
69
this, the application can use the db2SelectDB2Copy API before loading any DB2 libraries. For more information, see the Call Level Interface Guide and Reference, Volume 1. 32- and 64-bit versions on Win x64 DB2 does not support multiple DB2 32- and 64-bit versions installed on Windows. If you install the DB2 64-bit version, the 32-bit version will be removed from the system. This is because the DB2 32- and 64-bit registries reside in different locations. LDAP and CLI configuration With DB2 Version 8, if an application needs different LDAP settings, it needs to use a different LDAP user. Otherwise, the CLI configuration will affect all DB2 copies that the LDAP user might potentially use. Performance counters Performance counters can be registered for only one DB2 copy at a time and they can monitor only the instances in the DB2 copy in which they are registered. When you switch the Default DB2 copy, the DB2 Selection Wizard de-registers and reregisters the performance counters so that they are active for the Default DB2 copy. Windows Management Instrumentation (WMI) Only one version of the WMI provider can be registered at any given time. Client Connectivity You can use only one DB2 copy in the same process. Applications that dynamically link DB2 DLLs Applications that link to DB2 DLLs directly or that use LoadLibrary instead of LoadLibraryEx with the LOAD_WITH_ALTERED_SEARCH_PATH parameter will need to ensure that the initial dependent library is loaded properly. You can use your own coding technique to do this, or you can call the db2envar.bat file to setup the environment before running the application, or you can call the db2SelectDB2Copy API, which can be statically linked into the application. Visual Studio 2003 plugins If the default DB2 copy is a Version 9.5, a Version 9.1, or a Version 8 copy, there can be only one version of the plugins registered on the same computer at the same time. The version of the plugins that is active will be the version that is shipped with the default DB2 copy. Licensing Licenses need to be registered for each DB2 copy. They are not system-wide. This allows different licenses for different paths and provides the ability for both restricted versions of DB2 copies of the product and full versions of DB2 copies on the same machine. NT Services DB2 NT services will use the <servicename_installationname>. For example, DB2NETSECSERVER_MYCOPY1. The display name also contains the Copy Name appended to it in brackets, for example, DB2 Security Server (MYCOPY1). Instances also include the DB2<DB2 Copy Name><Instance Name><Node Number> in the display name, which is shown in the services control panel applet. The actual service name remains as is.
70
API to select the DB2 copy to use You can use the db2SelectDB2Copy API to select the DB2 copy that you want your application to use. This API does not require any DLLs. It is statically linked into your application. You can delay the loading of DB2 libraries and call this API first before calling any other DB2 APIs. Note that the function cannot be called more than once for any given process; that is, you cannot switch a process from one DB2 copy to another. The db2SelectDB2Copy API sets the environment required by your application to use the DB2 copy name or the location specified. If your environment is already set up for the copy of DB2 that you want to use, then you do not need to call this API. If, however, you need to use a different DB2 copy, you must call this API before loading any DB2 DLLs within your process. This call can be made only once per process. Database Partitioning with multiple physical nodes Each physical partition must use the same DB2 copy name on all computers. Using MSCS and Multiple DB2 Copies Each DB2 resource must be configured to run in a separate resource monitor.
71
72
Chapter 8. Installing on Linux and UNIX

An overview of installing your DB2 server product (Linux and UNIX)
This topic outlines the steps for installing your DB2 server product on AIX, HP-UX, Linux, and Solaris. To 1. 2. 3. install your DB2 server product: Review your DB2 product prerequisites. Review DB2 upgrade information if applicable. Modify kernel parameters on HP-UX, Linux, and Solaris. On all platforms, except for Linux on x86_32, you must install a 64-bit kernel before proceeding with the installation, otherwise the installation will fail. 4. Prepare the installation media: Product DVD If the DB2 product DVD does not automount, mount your DB2 product DVD. Installation image If you downloaded an installation image, untar the file. 5. Install your DB2 product using one of the available methods: v The DB2 Setup wizard v The db2_install command v A silent installation using a response file v Payload file deployment For DB2 servers, you can use the DB2 Setup wizard to perform installation and configuration tasks, such as: v Selecting DB2 installation type (typical, compact, or custom). v Selecting DB2 product installation location. v Install the languages that you can specify later as the default language for the product interface and messages. v Install or upgrade the IBM Tivoli System Automation for Multiplatforms (Linux and AIX). v Setting up a DB2 instance. v Setting up the DB2 Administration Server (including DAS user setup). v Setting up the DB2 Text Search server. v Setting up Administration contact and health monitor notification. v Setting up and configuring your instance setup and configuration (including instance user setup). v Setting up Informix data source support. v Preparing the DB2 tools catalog. v Specify the DB2 Information Center port. v Creating response files. 6. If you installed a DB2 server using a method other than the DB2 Setup wizard, post-installation configuration steps are required.
73
Installing as a root user Installing DB2 servers using the DB2 Setup wizard (Linux and UNIX)
This task describes how to start the DB2 Setup wizard on Linux and UNIX operating systems. The DB2 Setup wizard is used to define your installation preferences and to install your DB2 database product on your system. Before you begin Before you start the DB2 Setup wizard: v If you are planning on setting up a partitioned database environment, see how to do this by following the related link at the bottom of this topic. v Ensure that your system meets installation, memory, and disk requirements. v Ensure you have a supported browser installed (Firefox 2.0+, Mozilla 1.7+, or SeaMonkey 1.1.4). v You can install a DB2 server using either root or non-root authority. For more information on non-root installation, see the related links. v The DB2 database product image must be available. You can obtain a DB2 installation image either by purchasing a physical DB2 database product DVD, or by downloading an installation image from Passport Advantage. v If you are installing a non-English version of a DB2 database product, you must have the appropriate National Language Packages. v The DB2 Setup wizard is a graphical installer. You must have X windows software capable of rendering a graphical user interface for the DB2 Setup wizard to run on your machine. Ensure that the X windows server is running. Ensure that you have properly exported your display. For example, export DISPLAY=9.26.163.144:0. v If you are using security software in your environment, you must manually create required DB2 users before you start the DB2 Setup wizard. v If you are planning to use the IBM Tivoli Monitoring for Databases: DB2 Agent, before installing your DB2 product see topic Installing IBM Tivoli Monitoring for Databases: DB2 Agent with the DB2 installer for details, limitations and restrictions. Restrictions v You cannot have more than one instance of the DB2 Setup wizard running in any user account. v The use of XML features is restricted to a database that is defined with the code set UTF-8 and has only one database partition. v The DB2 Setup wizard fields do not accept non-English characters. Procedure To start the DB2 Setup wizard: 1. If you have a physical DB2 database product DVD, change to the directory where the DB2 database product DVD is mounted by entering the following command:
cd /dvdrom
where /dvdrom represents the mount point of the DB2 database product DVD.
74
2. If you downloaded the DB2 database product image, you must extract and untar the product file. a. Extract the product file:
gzip -d product.tar.gz
where product is the name of the product that you downloaded. b. Untar the product file: On Linux operating systems
tar -xvf product.tar
On AIX, HP-UX, and Solaris operating systems

gnutar -xvf product.tar
where product is the name of the product that you downloaded. c. Change directory:
cd ./product
where product is the name of the product that you downloaded. Note: If you downloaded a National Language Package, untar it into the same directory. This will create the subdirectories (for example ./nlpack) in the same directory, and allows the installer to automatically find the installation images without prompting. 3. Enter the ./db2setup command from the directory where the database product image resides to start the DB2 Setup wizard. 4. The IBM DB2 Setup Launchpad opens. From this window, you can view installation prerequisites and the release notes, or you can proceed directly to the installation. You can also review the installation prerequisites and release notes for late-breaking information. 5. Click Install a Product and the Install a Product window will display the products available for installation. Launch the installation by clicking Install New. Proceed through the installation following the DB2 Setup wizards prompts. Once you have initiated the installation, proceed through the DB2 Setup wizard installation panels and make your selections. Installation help is available to guide you through the remaining steps. To invoke the installation help, click Help or press F1. You can click Cancel at any time to end the installation. Results For non-root installations, DB2 database products are always installed in the $HOME/sqllib directory, where $HOME represents the non-root users home directory. For root installations, DB2 database products are installed, by default, in one of the following directories: AIX, HP-UX, and Solaris /opt/IBM/db2/V9.7 Linux /opt/ibm/db2/V9.7
75
If you are installing on a system where this directory is already being used, the DB2 database product installation path will have _xx added to it, where _xx are digits, starting at 01 and increasing depending on how many DB2 copies you have installed. You can also specify your own DB2 database product installation path. DB2 installation paths have the following rules: v Can include lowercase letters (az), uppercase letters (AZ), and the underscore character ( _ ) v Cannot exceed 128 characters v Cannot contain spaces v Cannot contain non-English characters The installation log files are: v The DB2 setup log file. This file captures all DB2 installation information including errors. For root installations, the DB2 setup log file name is db2setup.log. For non-root installations, the DB2 setup log file name is db2setup_username.log, where username is the non-root user ID under which the installation was performed. v The DB2 error log file. This file captures any error output that is returned by Java (for example, exceptions and trap information). For root installations, the DB2 error log file name is db2setup.err. For non-root installations, the DB2 error log file name is db2setup_username.err, where username is the non-root user ID under which the installation was performed. By default, these log files are located in the /tmp directory. You can specify the location of the log files. There is no longer a db2setup.his file. Instead, the DB2 installer saves a copy of the DB2 setup log file in the DB2_DIR/install/logs/ directory, and renames it db2install.history. If the name already exists, then the DB2 installer renames it db2install.history.xxxx, where xxxx is 0000-9999, depending on the number of installations you have on that machine. Each installation copy has a separate list of history files. If an installation copy is removed, the history files under this install path will be removed as well. This copying action is done near the end of the installation and if the program is stopped or aborted before completion, then the history file will not be created. What to do next v Verify your installation. v Perform the necessary post-installation tasks. National Language Packs can also be installed by running the ./db2setup command from the directory where the National Language Pack resides, after a DB2 database product has been installed. On Linux x86, if you want your DB2 database product to have access to DB2 documentation either on your local computer or on another computer on your
76
network, then you must install the DB2 Information Center. The DB2 Information Center contains documentation for the DB2 database system and DB2 related products. DB2 Express Edition and DB2 Workgroup Server Edition memory limits If you are installing DB2 Express Edition, the maximum allowed memory for the instance is 4 GB. If you are installing DB2 Workgroup Server Edition, the maximum allowed memory for the instance is 16 GB. The amount of memory allocated to the instance is determined by the INSTANCE_MEMORY database manager configuration parameter. Important notes when upgrading from Versions 9.1 or 9.5: v If the memory configuration for your Versions 9.1 or 9.5 DB2 database product exceeds the allowed limit, the DB2 database product might not start after upgrading to the current version. v The self tuning memory manager will not increase your overall instance memory limit beyond the license limits.
Installing as a non-root user Non-root installation overview (Linux and UNIX)

Before Version 9.5, you could install products, apply and roll back fix packs, configure instances, add features, or uninstall products only if you had root privileges. Now, if you are a non-root user, you can perform these tasks on Linux and UNIX platforms. The DB2 installer automatically creates and configures a non-root instance during a non-root installation. As a non-root user, you can customize the configuration of the non-root instance during the installation. You can also use and maintain the installed DB2 product without root privileges. The non-root installation of a DB2 product has one DB2 instance with most features enabled by default. A non-root installation can be attractive for many groups, such as the following ones: v Enterprises that have thousands of workstations and users who want to install a DB2 product without consuming a system administrators time v Application developers who are not typically system administrators but use DB2 products to develop applications v Independent Software Vendors (ISVs) who develop software that does not require root authority yet embeds a DB2 product Although non-root installations have most of the function of root installations, there are some differences and limitations. You can lift some of the limitations by having a root user run the db2rfe command.
Differences between root installations and non-root installations

In addition to a few limitations, the directory structure of a non-root installation is slightly different than the directory structure of a root installation.
77
During a root installation, subdirectories and files for the DB2 product are created in a directory of the root users choosing. Unlike root users, non-root users cannot choose where DB2 products are installed. Non-root installations are always placed in the $HOME/sqllib directory, where $HOME represents the non-root users home directory. The layout of the subdirectories within the sqllib directory of a non-root is similar to that of a root installation. For root installations, multiple instances can be created. Instance ownership is associated with the user ID under which the instance was created. Non-root installations can have only one DB2 instance. The non-root installation directory contains all of the DB2 product files and instance files with no soft links. The following table summarizes the differences between root installations and non-root installations.
Table 13. Differences between root installations and non-root installations Criteria User can select installation directory Number of DB2 instances allowed Files deployed during installation Root installations Yes Non-root installations No. DB2 products are installed under the users home directory. One Program files and instance files. The DB2 product is ready for use immediately after installation. No need to uninstall the old version before installing the new version. Install new version, and upgrade the instance, together.
Multiple Program files only. Instances must be created after installation. No
Upgrade version and instance
Limitations of non-root installations

In addition to the differences between root installations and non-root installations, there are several limitations on non-root installations. This topic discusses the limitations to help you decide if you want to use a non-root installation. Product limitations Some DB2 products are not supported in non-root installations: v DB2 Query Patroller v DB2 Net Search Extender v Locally installed DB2 Information Center Note: The locally installed DB2 Information Center is not supported in non-root installations because it requires root authority to start the daemon. However, a non-root-installation DB2 instance can be configured to use a locally installed DB2 Information Center if it is installed on the same computer. Features and tools limitations The following features and tools are not available in non-root installations:
78
v The DB2 Administration Server (DAS) and its associated commands: dascrt, dasdrop, daslist, dasmigr, and dasupdt v The Configuration Assistant v The Control Center v The ability for the db2governor to increase priority is not supported v In the Work Load Manager (WLM), attempts to set agent priority in a DB2 service class in a non-root DB2 instance are allowed. However, the agent priority will not be respected, and no SQLCODE error is returned. v Automatic starting of non-root DB2 instances at system reboot is not supported Health monitor limitations The following health monitor features are not supported in non-root installations: v Running script or task actions on alert occurrences v Sending alert notifications Partitioned database limitation Only single-partition databases are supported in non-root installations. You cannot add additional database partitions. Listing DB2 products The output produced by the db2ls command, when run as a non-root user, is different than the output produced when run as a root user. For details, refer to the db2ls command topic. DB2 copies Each non-root user can have only one copy of a DB2 product installed. DB2 instance limitation In non-root installations, one DB2 instance is created during installation. Additional instances cannot be created. DB2 instance actions can be performed only by the instance owner Root installations and non-root installations can coexist on the same computer in different installation paths. However, a non-root instance can be updated, or dropped (using the db2_deinstall command), only by the non-root user who owns the non-root instance. A DB2 instance created by a user with root privilege can be updated or dropped only by a user with root privilege. DB2 instance commands The following DB2 instance commands are unavailable in non-root installations: db2icrt When installing a DB2 product as a non-root user, a single instance is automatically created and configured. Further instances cannot be created in non-root installations. However, if the automatically created instance needs to be configured, you can use the non-root install configuration command, db2nrcfg. db2iupdt The db2iupdt command cannot be used for non-root instances. Instead, use the non-root install configuration command (db2nrupdt) to update the non-root DB2 instance. However, updating the non-root instance is normally not required because it gets updated automatically when updating your DB2 product.
79
db2idrop The instance that gets automatically created during non-root installations cannot be dropped. The DB2 product must be uninstalled to drop the DB2 instance. db2iupgrade Upgrading is not supported for non-root installations. To upgrade a non-root instance, use the db2nrupgrade command. Upgrading limitation Root instances cannot be upgraded to a non-root instance. Post-installation actions can be performed only by the DB2 instance owner Root installations and non-root installations can coexist on the same computer. However, only the original non-root user who installed the DB2 product can perform subsequent actions such as: v Applying fix packs v Adding features v Installing add-on products Adjusting ulimit values The ulimit command on UNIX and Linux sets or reports user resource limits, such as data and stack limits. For root instances, the database server dynamically updates required ulimit settings without changing the permanent settings. However, for non-root instances, the ulimit settings can only be checked during installation. A warning message is displayed if the settings are inadequate. Root authority is required to change the ulimit settings.
Limitations that can be overcome by running db2rfe

There are further limitations on non-root installations which can be overcome by running the db2rfe command. The following features and abilities are initially unavailable in non-root installations: v v v v Operating system-based authentication High Availability (HA) feature The ability to reserve service names in the /etc/services file The ability to increase user data limits (ulimits). This ability applies only to AIX. On other platforms, user data limits must be increased manually.
Run the Enable root features for non-root install command (db2rfe) to enable these features and abilities. Running the db2rfe command is optional, and must be run by a user with root authority.
Authentication type in non-root installations

Operating system-based authentication is the default authentication type for DB2 products. Since non-root installations do not support operating system-based authentication, if you choose not to run the db2rfe command after installing your DB2 product as a non-root user, then you must manually set the authentication type. You can do so by updating the following parameters in the database manager configuration (dbm cfg) file: v clnt_pw_plugin (Client userid-password plug-in configuration parameter) v group_plugin (Group plug-in configuration parameter)
80
v srvcon_pw_plugin (Userid-password plug-in for incoming connections at the server configuration parameter)
Installing a DB2 product as a non-root user

Most DB2 database products can be installed as a non-root user. Before you begin Before you install any DB2 database product as a non-root user, be aware of the differences between root installations and non-root installations, and the limitations of non-root installations. For more information on non-root installation, see Non-root installation overview (Linux and UNIX). Prerequisites for installing a DB2 database product as a non-root user are: v You must be able to mount the installation DVD, or have it mounted for you. v You must have a valid user ID that can be used as the owner of a DB2 instance. User IDs have the following restrictions and requirements: Must have a primary group other than guests, admins, users, and local Can include lowercase letters (az), numbers (09), and the underscore character ( _ ) Cannot be longer than eight characters Cannot begin with IBM, SYS, SQL, or a number Cannot be a DB2 reserved word (USERS, ADMINS, GUESTS, PUBLIC, or LOCAL), or an SQL reserved word Cannot use any User IDs with root privilege for the DB2 instance ID, DAS ID or fenced ID. Cannot include accented characters If existing user IDs are specified instead of creating new user IDs, make sure that the user IDs: - Are not locked - Do not have expired passwords v The hardware and software prerequisites that exist for the product you are installing apply to the non-root user just as they do for root users. v On AIX Version 5.3, Asynchronous I/O (AIO) must be enabled. It is strongly recommended the system has I/O Completion Ports (IOCP) enabled. v Your home directory must be a valid DB2 path. DB2 installation paths have the following rules: Can include lowercase letters (az), uppercase letters (AZ), and the underscore character ( _ ) Cannot exceed 128 characters Cannot contain spaces Cannot contain non-English characters About this task Installing DB2 database products as a non-root user is transparent to the non-root user. In other words, there is nothing special a non-root user needs to do to install a DB2 database product, other than being logged being logged in as a non-root user.
81
Procedure To perform a non-root installation: 1. Log in as a non-root user 2. Install your DB2 database product using any of the methods available to you. Options include: v The DB2 Setup wizard (GUI install) v The db2_install command v The db2setup command with a response file (silent install) Note: Since non-root users cannot choose the directory where DB2 database products are installed, any FILE keyword in your response file is ignored. 3. After the DB2 database product is installed, you must open a new login session to use the non-root DB2 instance. Alternatively, you can use the same login session if you set up the DB2 instance environment with $HOME/sqllib/ db2profile (for Bourne shell and Korn shell users) or $HOME/sqllib/db2chsrc (for C shell users), where $HOME is the non-root users home directory. What to do next After the DB2 database product is installed, verify your operating system user process resource limits (ulimits). If the minimum ulimit values are not met, the DB2 engine can encounter unexpected operating resource shortage errors. These errors can lead to a DB2 database system outage.
Enabling root-based features in non-root installations with db2rfe

There are several features and abilities in non-root installations that are initially unavailable but can be enabled by running a the db2rfe command This task requires root authority. To enable the features and abilities that are initially unavailable in non-root installations: 1. Locate the sample configuration files. Two sample configuration files are provided: v $HOME/sqllib/instance/db2rfe.cfg is pre-configured with default values for the non-root DB2 instance v $HOME/sqllib/cfg/db2rfe.cfg.sample is not configured where $HOME is the non-root users home directory. 2. Copy one of the sample configuration files to a different location so the original file remains unaltered. 3. Update the copied configuration file as needed. This configuration file is input to the db2rfe command. An example of a configuration file is:
INSTANCENAME=db2inst2 SET_ULIMIT=NO ENABLE_HA=NO ENABLE_OS_AUTHENTICATION=NO RESERVE_REMOTE_CONNECTION=NO **SVCENAME=db2c_db2inst2
82
**SVCEPORT=48000 RESERVE_TEXT_SEARCH_CONNECTION=NO **SVCENAME_TEXT_SEARCH=db2j_db2inst2 **SVCEPORT_TEXT_SEARCH=55000
Note: v The value for the INSTANCENAME parameter is filled in automatically by DB2 installer v The SET_ULIMIT parameter is available only on AIX. On other operating systems, a user with root authority needs to set ulimit values manually. v The default value for the other keywords is NO v Child parameters (such as SVCENAME) are commented out by default. Comments are denoted with ** v If you set a parameter to YES, and if it has any child parameters, it is recommended that you uncomment the child parameters and provide appropriate values. Any port values that are provided are examples. Ensure the port values you assign are free. An example is provided below to show an edited configuration file that will enable the following features and abilities: v High availability v Operating system-based authentication v DB2 Text Search, with a service name of db2j_db2inst2 and a port value of 55000 To enable these features and abilities, edit the configuration file as follows:
INSTANCENAME=db2inst2 SET_ULIMIT=NO ENABLE_HA=YES ENABLE_OS_AUTHENTICATION=YES RESERVE_REMOTE_CONNECTION=NO **SVCENAME=db2c_db2inst2 **SVCEPORT=48000 RESERVE_TEXT_SEARCH_CONNECTION=YES SVCENAME_TEXT_SEARCH=db2j_db2inst2 SVCEPORT_TEXT_SEARCH=55000
4. Log in as a user with root authority 5. Navigate to the $HOME/sqllib/instance directory, where $HOME represents the non-root users home directory. 6. Run the db2rfe command using the following syntax:
db2rfe -f config_file
where config_file is the configuration file created in Step 3 on page 82. To keep root-based features enabled on non-root installations, rerun the db2rfe command after applying fix packs or upgrading to a new version.
83
84
Chapter 9. Setting up a partitioned database environment

Setting up a partitioned database environment
This topic describes how to set up a partitioned database environment. You will use the DB2 Setup wizard to install your instance-owning database server and to create the response files that will in turn be used to create your participating database servers. Note: A partitioned database environment is not supported in non-root installations. A database partition is part of a database that consists of its own data, indexes, configuration files, and transaction logs. A partitioned database is a database with two or more partitions. Prerequisites v Ensure that you have the InfoSphere Warehouse Activation CD license key that will need to be copied over to all participating computers. v The same number of consecutive ports must be free on each computer that is to participate in the partitioned database environment. For example, if the partitioned database environment will be comprised of four computers, then each of the four computers must have the same four consecutive ports free. During instance creation, a number of ports equal to the number of logical partitions on the current server will be reserved in the /etc/services on Linux and UNIX and in the %SystemRoot%\system32\drivers\etc\services on Windows. These ports will be used by the Fast Communication Manager. The reserved ports will be in the following format:
DB2_InstanceName DB2_InstanceName_1 DB2_InstanceName_2 DB2_InstanceName_END
The only mandatory entries are the beginning (DB2_InstanceName) and ending (DB2_InstanceName_END) ports. The other entries are reserved in the services file so that other applications do not use these ports v To support multiple participating DB2 database servers, the computer on which you want to install DB2 must belong to an accessible domain. However, you can add local partitions to this computer even though the computer doesnt belong to a domain. v On Linux and UNIX systems, a remote shell utility is required for partitioned database systems. DB2 supports the following remote shell utilities: rsh ssh By default, DB2 uses rsh when executing commands on remote DB2 nodes, for example, when starting a remote DB2 database partition. To use the DB2 default, the rsh-server package must be installed. For more information about security issues when installing DB2 products, see the Related Links.
85
If you choose to use the rsh remote shell utility, inetd (or xinetd) must be installed and running as well. If you choose to use the ssh remote shell utility, you need to set the DB2RSHCMD registry variable immediately after the DB2 installation is complete. If this registry variable is not set, rsh is used. v On Linux and UNIX operating systems, ensure the hosts file under the etc directory does not contain an entry for 127.0.0.2 if that IP address maps to the fully qualified hostname of the machine. To set up a partitioned database environment: 1. Install your instance-owning database server using the DB2 Setup wizard. For detailed instructions, see the appropriate Installing DB2 servers topic for your platform. v On the Select installation, response files creation, or both window, ensure that you select the Save my installation settings in a response files option. After the installation has completed, two files will be copied to the directory specified in the DB2 Setup wizard: PROD_ESE.rsp and PROD_ESE_addpart.rsp. The PROD_ESE.rsp file is the response file for instance-owning database servers. The PROD_ESE_addpart.rsp file is the response file for participating database servers. v On the Set up partitioning options for the DB2 instance window, ensure that you select Multiple partition instance, and enter the maximum number of logical partitions. 2. Make the DB2 install image available to all participating computers in the partitioned database environment. 3. Distribute the participating database servers response file (PROD_ESE_addpart.rsp). 4. Install a DB2 database server on each of the participating computers using the db2setup command on Linux and UNIX, or the setup command on Windows: Linux and UNIX Go to the directory where the DB2 product code is available and run:
./db2setup -r /responsefile_directory/response_file_name
Windows
setup -u x:\responsefile_directory\response_file_name
For example, here is the command using the PROD_ESE_addpart.rsp as the response file: Linux and UNIX Go to the directory where the DB2 product code is available and run:
./db2setup -r /db2home/PROD_ESE_addpart.rsp
where /db2home is the directory where you have copied the response file. Windows
setup -u c:\resp_files\PROD_ESE_addpart.rsp
where c:\resp_files\ is the directory where you have copied the response file. 5. (Linux and UNIX only) Configure the db2nodes.cfg file. The DB2 installation only reserves the maximum number of logical partitions you want to use for
86
the current computer, but does not configure the db2nodes.cfg file. If you do not configure the db2nodes.cfg file, the instance is still a single partitioned instance. 6. Update the services file on the participating servers to define the corresponding FCM port for the DB2 instance. The services file is in the following location: v /etc/services on Linux and UNIX v %SystemRoot%\system32\drivers\etc\services on Windows 7. For partitioned database environments on Windows 2000 or later, start the DB2 Remote Command Service security feature to protect your data and resources. To be fully secure, start either the computer (if the service is running under the context of the LocalSystem account) or a user for delegation (if the service is being run under the logon context of a user). To start the DB2 Remote Command Service security feature: a. Open the Active Directory Users and Computers window on the domain controller, click Start and select Programs Administrative tools Active Directory Users and Computers b. In the right window panel, right-click the computer or user to start, select Properties c. Click the General tab and select the Trust computer for delegation check box. For user setting, click the Account tab and select the Account is trusted for delegation check box in the Account option group. Ensure that the Account is sensitive and cannot be delegated box has not been checked. d. Click OK to start the computer or user for delegation. Repeat these steps for each computer or user that needs to be started. You must restart your computer for the security change to take effect.
Installing database partition servers on participating computers using a response file (Windows)
In this task you will use the response file you created using the DB2 Setup wizard to install database partition servers on participating computers. Prerequisites v You have installed a DB2 copy on the primary computer using the DB2 Setup wizard. v You have created a response file for installing on participating computers and copied it onto the participating computer. v You must have administrative authority on participating computers. To install additional database partition servers using a response file: 1. Log to the computer that will participate in the partitioned database environment with the local Administrator account that you have defined for the DB2 installation. 2. Change to the directory containing the DB2 product DVD. For example:
cd c:\db2dvd
where db2dvd represents the name of the directory containing the DB2 product DVD. 3. From a command prompt, enter the setup command as follows:
setup -u responsefile_directory\response_file_name
Chapter 9. Setting up a partitioned database environment
87
In the following example, the response file, Addpart.file can be found in the c:\responsefile directory. The command for this example, would be:
setup -u c:\reponsefile\Addpart.file
4. Check the messages in the log file when the installation finishes. You can find the log file in the My Documents\DB2LOG\ directory. You should see output similar to the following at the end of the log file:
=== Logging stopped: 5/9/2007 10:41:32 === MSI (c) (C0:A8) [10:41:32:984]: Product: DB2 Enterprise Server Edition - DB2COPY1 -- Installation operation completed successfully.
5. When you install the instance-owning database partition server on the primary computer, the DB2 product reserves a port range according to the specified number of logical database partition servers participating in partitioned database environment. The default range is four ports. For each server that participates in the partitioned database environment, you must manually configure the /etc/services file for the FCM ports. The range of the FCM ports depends on how many logical partitions you want to use on the participating computer. A minimum of two entries are required, DB2_<instance> and DB2_<instance>_END. Other requirements for the FCM ports specified on participating computers are: v The starting port number must match the starting port number of the primary computer. v Subsequent ports must be sequentially numbered. v Specified port numbers must be free. You must log onto each participating computer and repeat these steps. If you want your DB2 product to have access to DB2 documentation either on your local computer or on another computer on your network, then you must install the DB2 Information Center. The DB2 Information Center contains documentation for the DB2 database system and DB2 related products.
Verifying access to the registry on the instance-owning computer (Windows)

This step is only required if you are setting up a partitioned database environment. After installing DB2 on a participating computer, verify that you have access to the registry on the instance-owning computer. This verification step must be run from all participating computers. You must have DB2 installed. To verify access to the registry on the instance-owning computer: 1. From a command prompt, type the regedit command. The Registry Editor window opens. 2. Click the Registry menu item. 3. Select Connect Network Registry. 4. Type the name of the instance-owning computer in the Computer name field. If the information is returned, then you have successfully verified that you have access to the registry on the instance-owning computer.
88

Response file install basics
Unlike the DB2 Setup wizard, a DB2 response file installation lets you install DB2 products without any user interaction. A response file is an English-only text file that contains setup and configuration information. A response file specifies configuration and setup parameters and the products and components to install. This method is useful not only for large-scale deployments of DB2 products, but also for embedding the DB2 installation process transparently inside your customized installation and configuration procedure. You can create a response file by any of the following methods: v Modifying one of the sample response files that are provided. Sample response files are located in the DB2 product DVD under the directory:
db2/platform/samples
where platform refers to the appropriate hardware platform. v Using the DB2 Setup wizard to save the setup and configuration data according to the input you provided. If you choose the option to create a response file in the DB2 Setup wizard, the response files (one for the server, and one for the partition, if you are setting up a multi-partitioned environment) will be saved by default at this location. By default, response files are save to: My Documents on Windows operating systems, and /tmp on Linux and UNIX operating systems. v Using the response file generator to create a response file from an existing installed and configured DB2 product. A response file installation can also be referred to as a silent installation or an unattended installation.
Response file uninstall basics

You can use a response file to uninstall one or more DB2 products, features, or languages. On Linux and UNIX operating systems, you can also use a response file to uninstall the DB2 Information Center. A response file uninstall can also be referred to as a silent uninstall or an unattended uninstall. A sample uninstall response file, db2un.rsp, is provided. When the DB2 product was installed, as part of the installation the sample uninstall response file is copied to DB2DIR/install, where DB2DIR specifies the path where the DB2 product was installed. You can customize the response file. To activate a keyword in the response file, remove the asterisk (*) to the left of the keyword. Before uninstalling using a response file, the following considerations, and restrictions, must be considered. When removing a DB2 product, you must first drop the DB2 instance. For example, if only DB2 ESE is installed, before removing the ESE product you must first drop the instance.
89
If multiple DB2 products exist within the same DB2 copy, a response file uninstallation of one DB2 product does not affect the components shared by other DB2 products in that copy. For example, DB2COPY1 contains the DB2 products ESE, WSE and PE. Several components are shared among the three products. In this case, uninstalling ESE removes the components that are not shared. In the following figure, the shaded region represents the components to be removed from DB2COPY1:
DB2COPY1
DB2 Personal Edition
DB2 Enterprise Server Edition
DB2 Workgroup Server Edition
Figure 1. Shared components among different DB2 products within the same DB2 copy
However, before removing a DB2 product, consider the instance type. For example, ESE, WSE and PE are installed in the same DB2 copy. You want to remove the ESE product. Before removing the ESE product, you can either: v move the instance to another DB2 copy of the same version that supports the ESE instance type using the db2iupdt command, or, v remove the existing ESE instance using the db2idrop command. If a DB2 feature is installed by multiple products in the same DB2 copy, a response file uninstallation of the feature removes the feature from all of the products in the DB2 copy. The following restrictions apply: v A DB2 product cannot be removed if that product is required by an add-on product. For example, if both ESE and QP are installed, ESE cannot be uninstalled. v A DB2 feature cannot be removed if that feature is required by another feature. v The language English cannot be removed. v On Windows operating systems: When you are removing a DB2 product, the uninstall response file cannot also contain the keywords to remove a feature or a language. The keyword REMOVE_PROD cannot be combined with keywords REMOVE_COMP or REMOVE_LANG. If you have a clustered environment, before uninstalling your DB2 product you must run the db2mscs command, with the -u option, from the same server that originally ran the db2mscs command to create the failover infrastructure. For details, see the db2mscs command.
90
After a response file uninstall, check the log file. This file captures all DB2 uninstallation information, including errors. v On Linux and UNIX operating systems, the log file is located in /tmp/db2_deinstall-<nnnnn>.log where <nnnnn> are generated numbers. The log file name displays on the screen after running the db2_deinstall command. You can also verify the product, feature, or language was removed using the db2ls command. v On Windows operating systems, the log file is located in My Documents\DB2LOG\db2un-<TimeStamp>.log. You can verify the product, feature, or language was removed by opening the Add/Remove Programs dialog in the control panel.
Response file considerations

You should understand the following considerations before proceeding with a response file installation: v Although response files created in Version 8 and response files created in Version 9 have similar formats, there are version limitations as to where response files can be used. For example, any response file generated in DB2 Version 9 can only be used to install a DB2 Version 9 product (for example Version 9.5 or higher); the response file cannot be used to install DB2 Version 8. The opposite is also true, where response files generated in DB2 Version 8 cannot be used to install DB2 Version 9. This is primarily caused by mandatory keywords that are new in Version 9. v On Linux or UNIX platforms, a response file created for a root installation might not be usable for a non-root installation. Some response file keywords are valid for root installation only. For details, see the response file keywords. v If you are using the DB2 Setup wizard: You can save your settings in a response file during the installation in the Select the installation action panel of the DB2 Setup wizard. You are creating a response file based on just the installation you are performing. This method is recommended if you have either a fairly simple configuration or if you want to create a response file that you plan to later customize. A response file is only generated if you allow the installation process to complete, and it completes successfully. If you cancel the installation, or if the installation fails, the response file is not created. Response files created with this method cannot be used in the db2isetup command -r parameter without modification. A response file created using the setup wizard, and used in the db2isetup command must be modified to meet the following conditions: - must contain the keyword FILE - must not contain the keywords: PROD, LIC_AGREEMENT, or INSTALL_TYPE. v You can use a response file to install an identical configuration across every workstation on your network or to install multiple configurations of a DB2 product. You can then distribute this file to every workstation where you want this product to be installed. v If you use the response file generator, you are creating the response file based on an existing installation. This method is recommended when you have a more complex configuration, one that you manually configured. If you are using the response file generated by the response file generator, you might need to input user names and passwords.
91
Creating a response file using the DB2 Setup wizard

You can create a response file using the DB2 Setup wizard based on the installation you are performing. This response file will be generated based on your DB2 Setup wizard selections. You can then use the response file to perform an unattended installation using the same settings. To create a response file using the DB2 Setup wizard: 1. From the DB2 Setup launchpad, select Install New for the product you want to install, or, select Work with Existing to select the DB2 copy you want to work with. 2. Select the product or DB2 copy you want to install and click Next to start the DB2 Setup wizard. 3. Click Next on the Welcome page and accept the license agreement terms. 4. In the Select the installation type window, select from Typical, Compact or Custom installation. 5. In the Select the installation, response file creation, or both window, select either the Save my installation setting in a response file option or the Install product on this computer and save my settings in a response file option. Then, in the Response file name field type the path where you want the DB2 Setup wizard to place the generated response file. By default, the response file name is Prod_<abbrev>.rsp, and is saved in directory1. Note: a. If you select the Save my installation setting in a response file option, no software is installed on the computer, only the response file is created with the name specified in the Response file name field. b. If you select a partitioned database installation, two response files will be generated, one for the instance-owning computer and one for the participating computers. The participating computer response file name is generated based on the name of the instance-owning computer. By default, the partition response file name is Prod_<abbrev>_addpart.rsp, and is saved in directory2. 6. Proceed through the rest of the installation panels selecting the options you want. 7. In the Start copying files and create response file window, review the settings you selected. 8. To install the product, click Finish. 9. When the installation has completed, the DB2 Setup wizard will have placed the generated response file in the path you specified. When the DB2 Setup wizard is used to create the response file, a special keyword ENCRYPTED is added to the response file. For example:
DAS_PASSWORD = 07774020164457377565346654170244883126985535505156353 ENCRYPTED = DAS_PASSWORD
The keyword ENCRYPTED indicates the actual value of the password is not the sequence of numbers shown.
92
Response file installation of DB2 overview (Linux and UNIX)

This task describes how to perform response file installations on Linux or UNIX. You can use the response file to install additional components or products after an initial installation. A response file installation might also be referred to as a silent installation or an unattended installation. Restrictions Be aware of the following limitations when using the response files method to install DB2 on Linux or UNIX platforms: v If you set any instance or global profile registry keywords to BLANK (the word BLANK), that keyword is, in effect, deleted from the list of currently set keywords. v Ensure that you have sufficient disk space before installing. Otherwise, if the installation fails, manual cleanup is required. v If you are performing multiple installations or are installing DB2 from multiple DVDs, it is recommended that you install from a network file system rather than a DVD drive. Installing from a network file system significantly decreases the amount of time it will take to perform the installation. v If you are planning on installing multiple clients, set up a mounted file system on a code server to improve performance. Prerequisites Before you begin the installation, ensure that: v Your system meets all of the memory, hardware, and software requirements to install your DB2 product. v All DB2 processes are stopped. If you are installing a DB2 product on top of an existing DB2 installation on the computer, you must stop all DB2 applications, the DB2 database manager, and DB2 processes for all DB2 instances and DB2 DAS related to the existing DB2 installation. To perform a response file installation: 1. Mount your DB2 product DVD or access the file system where the installation image is stored. 2. Create a response file using the sample response file Response files have a file type of .rsp. For example, ese.rsp. 3. Install DB2 using a response file
Creating a response file using the sample response file (Linux and UNIX)
After creating a response file, you can make changes to the response file to activate or deactivate keywords. One of the following scenarios apply: v You want to create a response file based on a sample response file (located in db2/platform/samples where platform refers to the appropriate hardware platform.) v You created a response file using the DB2 Setup wizard (based on your installation) and want to make changes to it.
93
If you are installing directly from the DVD, you must store the renamed response file on another file system. You can specify the name of the instance owner in the response file. If this user does not already exist, DB2 will create this user on your system. To edit a response file: 1. If you are using the sample response file, copy the sample response file to a local file system and edit it using the Response file keywords topic as a guide. 2. Customize the sample response file. To activate an item in the response file, remove the asterisk (*) to the left of the keyword. Then, replace the current setting to the right of the value with the new setting. The possible settings are listed to the right of the equal sign. Some product response files have mandatory keywords that you must provide values for. The mandatory keywords are documented in the comments of each response file. Keywords that are unique to installation are only specified in a response file during a response file installation. 3. Save the file on an exported file system available to everyone on the network.
Installing a DB2 product using a response file (Linux and UNIX)

Before you begin the installation, ensure that: v For root installations, log on with the user ID that has root privileges. For non-root installations, log on with the user ID that is to own the DB2 installation. v Your system meets all of the memory, hardware, and software requirements to install your DB2 product. v You can install a DB2 product using a response file with either root or non-root authority. For more information about non-root installation, see the related links. v All DB2 processes associated with the copy of DB2 you are working with are stopped. To perform a response file installation: 1. Enter the db2setup command as follows:
dvd/db2setup -r responsefile_directory/response_file
where: v dvd represents the location of the DB2 installable image; v responsefile_directory represents the directory where the customized response file is located; and v response_file represents the name of the response file. 2. Check the messages in the log file when the installation finishes. The installation logs are located, by default, in the /tmp directory: v db2setup.log (db2setup_username.log for non-root installations, where username is the non-root user ID under which the installation was performed) v db2setup.err (db2setup_username.err for non-root installations, where username is the non-root user ID under which the installation was performed)
94
You can specify the location of the log file. An installation history log db2install.history is located in DB2DIR/install/logs where DB2DIR specifies the path where the DB2 product was installed. The default installation directory is: v For AIX, HP-UX or Solaris /opt/IBM/db2/V9.7 v For Linux/opt/ibm/db2/V9.7 If more than one DB2 product is installed in the same location, you will see db2install.history.xxxx, where xxxx are digits, starting at 0001 and increasing depending on how many DB2 copies you have installed. If you want your DB2 product to have access to DB2 documentation either on your local computer or on another computer on your network, then you must install the DB2 Information Center. The DB2 Information Center contains documentation for the DB2 database and related products.
Installing database partition servers on participating computers using a response file (Linux and UNIX)
In this task you will use the response file you created using the DB2 Setup wizard to install database partition servers on participating computers. Prerequisites v You have installed DB2 on the primary computer using the DB2 Setup wizard and have created a response file for installing on participating computers. v You must have root authority on participating computers. To install additional database partition servers using a response file: 1. As root, log on to a computer that will participate in the partitioned database environment. 2. Change to the directory where you copied the contents of the DB2 product DVD. For example:
cd /db2home/db2dvd
3. Enter the db2setup command as follows:

./db2setup -r /responsefile_directory/response_file_name
In our example, the response file, AddPartitionResponse.file, was saved to the /db2home directory. The command for our example, is:
./db2setup -r /db2home/AddPartitionResponse.file
4. Check the messages in the log file when the installation finishes. You must log onto each participating computer and perform a response file installation. If you want your DB2 product to have access to DB2 documentation either on your local computer or on another computer on your network, then you must install the DB2 Information Center. The DB2 Information Center contains documentation for the DB2 database system and DB2 related products.
Response file error codes (Linux and UNIX)

The following tables describe error return codes (primary and secondary) that can be encountered during a response file installation.
95
Table 14. Primary response file installation error codes Error code value 0 1 67 Description The action completed successfully. The action returns a warning. A fatal error occurred during the installation.
Table 15. Secondary response file installation error codes Error code value 3 5 10 13 16 17 18 19 20 21 22 87 66 74 76 82 86 97 102 103 143 Description The path was not found. Access was denied. An environment error occurred. The data is invalid. The DAS creation failed. The instance creation failed. The database creation failed. The fix pack image is at a lower level than the installed product. The fix pack image is at the same level as the installed product. There is nothing to update. There are no DB2 products installed at the selected location. There is nothing to update. To update an already installed DB2 product, use the installFixPack command instead of the db2setup command. One of the parameters was invalid. The installation was cancelled by the user. The configuration data is corrupt. Contact your support personnel. The installation source for this product is not available. Verify that the source exists and that you can access it. Another installation is already in progress. Complete that installation first before proceeding with this installation. There was an error opening the installation log file. Verify that the specified log file location exists and that it is writable. This installation package is not supported on this platform. Another version of this product is already installed. Installation of this version cannot continue. Invalid command line argument. The system does not have enough free space to continue with the installation.
Uninstalling a DB2 product, feature, or language using a response file (Linux and UNIX)
To silently uninstall DB2 products, features, or languages in a DB2 copy, use the db2_deinstall command with the -r option. You can also use a response file to uninstall the DB2 Information Center.
96
If you have DB2 products installed in various installation paths, you must run this command separately from each installation path. Sample response file, db2un.rsp, is in DB2DIR/install, where DB2DIR specifies the path where the DB2 product was installed. To perform an uninstallation: 1. Customize the db2un.rsp response file. To activate an item in the response file, remove the asterisk (*) to the left of the keyword. Then, replace the current setting to the right of the value with the new setting. The possible settings are listed to the right of the equal sign. 2. Run the db2_deinstall command. For example, db2_deinstall -r db2un.rsp. 3. Check the messages in the log file when the uninstallation finishes. The log file is located in: v For root installations: /tmp/db2_deinstall.log.<process id> v For non-root installations: /tmp/db2_deinstall_<user id>.log
Response file installation of DB2 overview (Windows)

On Windows, you can perform a response file installation of a DB2 product on a single machine or on multiple machines. A response file installation might also be referred to as a silent installation or an unattended installation. Before you begin the installation, ensure that: v Your system meets all of the memory, hardware, and software requirements to install your DB2 product. v You have all of the required user accounts to perform the installation. v Ensure all DB2 processes are stopped. v To perform a response file installation of a DB2 product on a single machine: 1. Create and customize a response file by one of the following methods: Modifying a sample response file. Sample response files are located in (db2\Windows\samples). Using the DB2 Setup wizard to generate a response file. Using the response file generator. 2. Run the setup -u command specifying your customized response file. For example, a response file created during an installation:
setup -u my.rsp
v To 1. 2. 3.
perform a response file installation of a DB2 product on multiple machines: Set up shared access to a directory Create a response file using the sample response file Install a DB2 product using a response file
Making the DB2 installation files available for a response file installation (Windows)
Making the DB2 installation file available for an installation is part of the process to perform a response file installation of a DB2 product on multiple machines. To make the DB2 installation files available for a response file installation, you must copy the required files from the product DVD to another drive. To copy the required files from the product DVD to another drive:
97
1. Insert the appropriate DB2 product DVD into your DVD drive. 2. Create a directory (for example, c:\db2prods). 3. Copy the DB2 installation files.
Setting up shared access to a directory (Windows)

Setting up shared access to a directory is part of the process to perform a response file installation of a DB2 product on multiple machines. This allows you to grant your network workstations access to a directory on the installation server. To 1. 2. 3. 4. set up shared access to a directory on the installation server: Copy the DB2 installation files to a directory. For example, c:\db2prods. Open Windows Explorer. Select the directory on the installation server that you want to share. Select File>Properties from the menu bar. The Properties window for the directory opens. 5. Select the Sharing tab. 6. For Windows 2003, select the Shared this folder button. 7. For Windows 2008 or Windows Vista (or higher), click the Advanced Sharing button. Enable the Shared this folder check box. 8. In the Share Name field, type a share name. For example, db2win. 9. To specify Read access for everyone: a. Click the Permissions push button. The Permissions for <share name> window opens. b. Ensure that the Everyone option is selected in the Group or user names box. c. In the Permissions for Everyone box, ensure that read permission is enabled. Click the check box in the Allow column for Read. d. Click OK. You are returned to the Properties window of the directory for which you want to set up shared access. e. Click OK.
Editing a response file (Windows)

After creating a response file, you can make changes to the response file to activate or deactivate keywords. One of the following scenarios apply: v You want to create a response file based on a sample response file (located in db2\Windows\samples). v You created a response file using the DB2 Setup wizard (based on your installation) and want to make changes to it. v You have already set up and configured your DB2 product and you want to distribute this exact configuration across your network using the response file generated by the response file generator. If you are using the response file generated by the response file generator, you can input user names and passwords. Install DB2 products only on a drive which is local to the target workstation. Installing on a non-local drive can cause performance and availability problems.
98
To edit a response file: 1. If you are using the sample response file, make a copy of it and open it in a text editor. If you are using the response file created by the DB2 Setup wizard, open it in a text editor. 2. Customize the response file. To activate an item in the response file, remove the asterisk (*) to the left of the keyword. Then, replace the current setting to the right of the value with the new setting. The possible settings are listed to the right of the equal sign. Some product response files have mandatory keywords that you must provide values for. The mandatory keywords are documented in the comments of each response file. 3. Save the file on the shared network drive so that it is available to the installation server. If you have made any changes, save the file under a new file name to preserve the original sample response file. If you are installing directly from the product DVD, store the renamed response file on another drive.
Installing a DB2 product using a response file (Windows)

Before you begin the installation, ensure that: v Your system meets all of the memory, hardware, and software requirements to install your DB2 product. To perform an installation from the workstation where the DB2 product will be installed: 1. Connect to the shared directory of the network drive or DVD drive containing the DB2 installation files by entering the following command from the command prompt:
net use x: \\computer_name\directory_sharename /USER:domain\username
where: v x: represents the shared directory on the local drive. v computer_name represents the computer name of the remote server where the DB2 installation files are located. v directory_sharename represents the share name of the directory on the network drive or DVD drive where the DB2 installation files are located. v domain represents the domain where the account is defined. v username represents a user that has access to this system. For example, to use the remote db2prods directory, which was shared as DB2_Installation_Images and is located on the remote server Server, as the local x: drive, enter the following command:
net use x: \\Server\DB2_Installation_Images
Depending on how security is set up across your network, you might have to specify the /USER parameter. 2. Enter the setup command as follows:
setup -u response_file
where response_file represents the full path and file name of the response file to use.
99
If you are using a response file that was created using the response file generator, ensure that all the instance profiles are located in the same drive and directory as the response file that you specify. 3. Check the messages in the log file when the installation finishes. For information about errors encountered during installation, review the installation log file located in the My Documents\DB2LOG\ directory. The log file uses the following format: DB2-ProductAbrrev-DateTime.log, for example, DB2-ESE-Tue Apr 04 17_04_45 2007.log. If you want your DB2 product to have access to DB2 documentation either on your local computer or on another computer on your network, you must install the DB2 Information Center.
Installing DB2 products using Microsoft Systems Management Server (SMS)

With Microsoft Systems Management Server (SMS), you can install DB2 products across a network, and set up the installation from a central location. An SMS installation will minimize the amount of work users perform. This installation method is ideal if you want to roll out an installation based on the same setup on a large number of clients. You must have at least SMS Version 2.0 installed and configured on your network for both your SMS server and SMS workstation. Refer to Microsofts Systems Management Server Administrators Guide for your platform for more details on how to: v Set up SMS (including setting up primary and secondary sites). v Add clients to the SMS system. v Set up inventory collection for clients. When you are using SMS, you have control over which response file you will use. You can have several different installation options, resulting in several different response files. When you configure the SMS install package, you can specify which response file to use. To install DB2 products using SMS: 1. Import the DB2 install file into SMS 2. Create the SMS package on the SMS server 3. Distribute the DB2 installation package across your network
Importing the DB2 install file into SMS

Importing the DB2 install file into SMS is part of the larger task of installing DB2 products using SMS. To set up a package through SMS, use the sample SMS package definition file and your customized response file and instance profile. The sample SMS file name is db2<product_abbreviation>.pdf. For example db2ese.pdf. To import the DB2 installation files into SMS: 1. Insert the DB2 product DVD into the drive. 2. Start the Microsoft SMS Administrator. The Microsoft SMS Administrator Logon window opens. 3. Enter your logon ID and password, and click OK. The Open SMS window opens.
100
4. Select the Packages window type and click OK. The Packages window opens 5. Select File>New from the menu bar. The Package Properties window opens. 6. Click the Import push button. The File Browser opens. Find the SMS package definition file located in x:\db2\Windows\samples, where x: represents the DVD drive. Typically, the pdf file needs to be customized before being used. You can copy the sample file from x:\db2\Windows\samples to local a local drive, modified the file, and import the updated file. 7. Click OK.
Creating the SMS package on the SMS server

Creating the SMS package on the SMS server is part of the larger task of Installing DB2 products using SMS. An SMS package is a bundle of information that you send from the SMS server to an SMS client. The package consists of a set of commands that can be run on the client workstation. These commands are for system maintenance, changing client configuration parameters, or installing software. To create an SMS package: 1. From the Package Properties window, click the Workstations push button. The Setup Package For Workstations window opens, with the imported response file and instance profile ready to use. 2. In the Source Directory field, enter the name of the parent directory where you put the copied DB2 files. For example, x:\db2prods, where x: represents your DVD drive. 3. Select the name of the product to install from the Workstation Command Lines window. 4. If you changed and renamed the sample response file, click the Properties push button. The Command Line Properties window opens. Change the value of the Command Line parameter to match the new response file name and path. If you are using a response file that was created using the response file generator, ensure that all the instance profiles are located in the same drive and directory as the response file that you specify. 5. Click OK. 6. Click the Close push button. 7. Click OK to close the opened windows. The Packages window shows the name of the new SMS package.
Distributing the DB2 installation package across your network

Distributing the DB2 installation package across your network is part of the larger task of Installing DB2 products using SMS. Now that you have created the package, you have three options: v You can distribute your SMS package and then log on locally on the client workstation to run the package. This option requires that the user account used to perform the installation belongs to the local Administrators group where the account is defined. v You can distribute your SMS package and then log on remotely on the client workstation to run the package. This option requires that the user account used to perform the installation belongs to the Domain Admins group. v You can set up your SMS package with an auto-install feature.
101
Options 1 and 2 are available to you, but for a large number of installations option 3 is recommended, which will be the focus for this step. Once sent to the client workstation, the SMS package will tell the client workstation what code to execute, and the location, on the SMS server, of that code. v To send the code to a client workstation: 1. Open the Sites window. 2. Open the Packages window. 3. In the Packages window, select the appropriate package and drag it onto the target client in the Sites window. The Job Details window opens. This window lists the package that will be sent to the client machine (Machine Path) and the command that will be executed at the workstation. 4. Select the Run Workstation Command check box and select the installation package that you want to use. 5. In the Run Phase box of the Job Details window, select the Mandatory After check box. A default mandatory date is set one week from the current date. Adjust the date as required. 6. Deselect the Not Mandatory over Slow Link check box. This feature is critical if you are installing across a large number of workstations. It is recommended that you stagger the installation to avoid overloading your server. For example, if you are considering an overnight install, then spread out the install time for a manageable amount of client workstation. For more information about completing the Job Details window, refer to Microsofts Systems Management Server Administrators Guide for your platform. 7. When the job specifications are complete, click OK. You are returned to the Job Properties window. 8. Add a comment that explains what the job will do. For example, Install IBM Data Server Client. 9. Click the Schedule push button and the Job Schedule window opens. This window will arrange a priority for this job. By default, the job is low priority and all other jobs will be executed first. It is recommended that you select medium or high priority. You can also select a time to start the job. 10. Click OK to close the Job Schedule window. 11. Click OK. The job is created and the package is sent to the SMS client workstation. v To run the installation on the SMS client, perform the following steps: 1. On the target SMS client workstation, log on to the workstation with a user account that belongs to the local Administrators group where the account is defined. This level of authority is required because a system program install is being performed instead of a user program install. 2. Start the Package Command Manager. The Package Command Manager window opens. 3. When the SMS client workstation receives the packages from the SMS server, it is listed in the Package Name section of the window. Select the package and click the Execute push button. The installation runs automatically. 4. Following installation, you must reboot the SMS client workstation before using DB2. Important: If you specified REBOOT = YES in your response file, the SMS client will reboot automatically.
102
5. Click Start and select Programs>SMS Client>Package Command Manager. The Package Command Manager window opens. 6. Click the Executed Commands folder and verify the execution of the package. Similarly, you can verify completion on the SMS server by checking the status of the job and ensuring that it has been changed to complete from pending or active. On the SMS client, open the Package Command Manager again. When the package, which you created and sent to the client, appears under the Executed Commands folder, the installation has completed.
Distributing DB2 installation packages using Microsoft Systems Management Server (SMS)
This topic describes how to use the Microsoft Systems Management Server (SMS) to distribute the DB2 installation package. To distribute the DB2 installation package using SMS, ensure that: v your SMS environment has already been set up. v your DB2 install media is copied to a location where the contents of the install media can be edited. Note: For information on how to set up your SMS environment, consult the documentation for that product. To distribute the DB2 installation package using SMS, perform the following: 1. Prepare the sample response file located on your DB2 install media for the type of DB2 installation that you want to perform. The sample response file is db2*.rsp and is located in the db2\windows\samples directory on your DB2 install media. 2. On an SMS Distribution Point computer in your SMS environment, open the SMS Administrator Console. Click the Site Database drop down menu and right click Packages. 3. Select New > Package From Definition. The Create Package from Definition wizard opens. 4. Click Next. The Package Definition window opens. Browse for the desired package file from the db2\windows\samples directory located on your DB2 install media. The name of this file is in the form db2*.pdf. Click Open. 5. Select the appropriate package definition from the list displayed. Click Next. The Source Files window opens. 6. Select the Create a compressed version of the source radio button, and click Next. The Source Directory window opens. 7. Select the location type and directory of the DB2 install media, and click Next. 8. Click Finish to complete the creation of the SMS package. 9. From inside the SMS Administrator Console, open the Site Database drop down menu and select Packages > All Tasks > Distribute Software. The Distribute Software wizard opens. 10. Click Next. The Package window opens. 11. Select the Distribute an existing package radio button, and select the appropriate package from the list of packages shown. Click Next. The Distribute Points window opens. Select one or more distribution points for the package that you are planning to distribute. 12. Click Next. The Advertise a Program window opens.
103
13. Select the radio button indicating that you want to advertise the program to a collection, and select the program that you want to run from the list shown. Click Next. The Advertisement Target window opens. 14. Select either an existing collection of computers or a choose to create a new collection of computers where you want to advertise and install the selected program. Click Next. The Advertisement Name window opens. 15. Type in a name for the new advertisement and any comments that you want to add. Click Next. The Advertise to Subcollections window opens. 16. Specify where you want the relevant DB2 program to be run relative to the hierarchical setup of the SMS computers in your SMS environment. Click Next. The Advertisement Schedule window opens. 17. Select a date and time after which you want the DB2 program to be run on the collection of computers specified. You might also want to select a expiration time for the advertisement of the program. Click Next. The Assign Program window opens. 18. If you want the DB2 program to be a mandatory requirement on the computers in the specified collection, specify a date and time after which the program will automatically run. Click Next. 19. Click Finish to complete the Distribute Software wizard.
Configuring remote access to a server database

Once you have installed your DB2 database product, you can configure your product to access remote databases individually on each client workstation using the Configuration Assistant or the command line processor. About this task DB2 uses the CATALOG command to catalog remote database access information: v The CATALOG NODE command specifies the protocol information about how to connect to the host or to the server. v The CATALOG DATABASE command catalogs the remote database name and assigns it a local alias. v The CATALOG DCS command specifies that the remote database is a host or OS/400 database. (This command is only required for DB2 Connect Personal or Enterprise Editions). v The CATALOG ODBC DATA SOURCE command registers the DB2 database with the ODBC driver manager as a data source. If you plan to roll out multiple copies of IBM data server clients with identical configurations, then you can create a batch file that will run your customized script. For example, consider the following sample batch file, myscript.bat, used to run the script file:
@echo off cls db2cmd catmvs.bat
The DB2CMD command initializes the DB2 database environment and the catmvs.bat file calls the batch job of the same name. Here is a sample catalog script file, catmvs.bat, that could be used to add databases to a DB2 Connect Personal Edition workstation:
104
db2 catalog tcpip node tcptst1 remote mvshost server 446 db2 catalog database mvsdb at node tcptst1 authentication server db2 catalog dcs database mvsdb as mvs_locator db2 catalog system odbc data source mvsdb db2 terminate exit
You can either send these files to your client workstations manually or use SMS and have the script run automatically after the installation and reboot have completed. Procedure To create another SMS package with the catalog script, perform the following steps: 1. Start the SMS Administrator. The Open SMS window opens. 2. Select the Packages window type and click OK. The Packages window opens. 3. Select File New from the menu bar. The Package Properties window opens. 4. Enter a name for your new package. For example, batchpack. 5. Enter a comment about the package. For example, Package for batch file. 6. Click the Workstations push button. The Setup Package for Workstations window opens. 7. Enter the source directory. Ensure that the source directory is a location that both the server and the client have access to, and that contains the batch file that is to be run from the client workstation. 8. Under the Workstation Command Lines section, click New. The Command Line Properties window opens. 9. Enter a command name. 10. Enter the command line. 11. Click the check box for the platforms that should be supported, under the Supported Platforms section. 12. Click OK. 13. Click Close. 14. Click OK. What to do next Distribute this package in the same way as an installation package.
Configuring db2cli.ini
The db2cli.ini file is an ASCII file which initializes the DB2 CLI configuration. This file is included to help you get started and can be found in different directories depending on whether the ODBC Driver Manager is used, the type of data source names (DSN) used, the client or driver being installed, and whether the DB2CLIINIPATH registry variable is set: When the ODBC Driver Manager is used to configure a user DSN on Windows platforms, the db2cli.ini file is created in Documents and Settings\User Name where User Name represents the name of the user directory. In other cases, including when system DSN are used, the db2cli.ini file is installed in the following directories:
105
v For runtime clients: On the Windows XP and Windows 2003 operating systems: Documents and Settings\All Users\Application Data\IBM\DB2\Copy Name On the Windows 2008 and Windows Vista (and later) operating systems: ProgramData\IBM\DB2\Copy Name where Copy Name represents the DB2 copy name. v For other data server clients and drivers: On Windows operating systems: Program Files\IBM\IBM DATA SERVER DRIVER (this represents the driver installation path) On UNIX and Linux operating systems: driver_installation_path/clidriver/cfg where driver_installation_path represents the installation path of the clients or drivers You can use the DB2CLIINIPATH registry variable to specify a different location for the file. If you use any specific CLI optimization values or CLI parameters, you can use your customized db2cli.ini file and override the existing copy on the other IBM data server client workstations, or you can edit directly the existing db2cli.ini file on the client.
The response file generator

You can use the response file generator to re-create an exact setup on other machines. The response file generator utility creates a response file from an existing installed and configured DB2 product. You can use the generated response file to install an identical product setup on other machines. For example, you can install and configure an IBM Data Server Client to connect to various databases across your network. Once this IBM Data Server Client is installed and configured to access all the databases that your users have access to, you can run the response file generator to create a response file and a configuration profile for each DB2 instance. The response file generator creates a response file using the db2rspgn command. A response file is created for the installation and instance profiles for each instance that you specify. The response file name is db2<product_abbreviation>.rsp, for example db2ese.rsp. The instance profile file name is <instance_name>.ins, for example db2inst1.ins. You can use the response file generator to create multiple response files, one for each installed product. For example, if ESE and CLIENT are installed in the same location, the db2rspgn command generates response files db2ese.rsp and db2client.rsp. Although several DB2 copies might already be installed on your system, the response file generator only generates the response file for the current copy (that is, for the DB2 copy where you ran the db2rspgn command.)
Response file error codes (Windows)

The following tables describe error return codes (primary and secondary) that can be encountered during a response file installation or uninstallation.
106
Table 16. Primary response file installation error codes Error code value 0 1 1603 3010 Description The action completed successfully. The action returns a warning. A fatal error occurred. The installation or uninstallation is successful, however a reboot is required to complete the process. This does not include installations where the ForceReboot action is run. This error code is not available on Windows Installer version 1.0.
Table 17. Secondary response file installation error codes Error code value 3 5 10 13 87 1602 1610 1612 1618 1622 1632 1633 1638 1639 Description The path was not found. Access was denied. An environment error occurred. The data is invalid. One of the parameters was invalid. The installation was cancelled by the user. The configuration data is corrupt. Contact your support personnel. The installation source for this product is not available. Verify that the source exists and that you can access it. Another installation is already in progress. Complete that installation first before proceeding with this installation. There was an error opening the installation log file. Verify that the specified log file location exists and that it is writable. The Temp folder is either full or inaccessible. Verify that the Temp folder exists and that you can write to it. This installation package is not supported on this platform. Another version of this product is already installed. Installation of this version cannot continue. Invalid command line argument.
For more information regarding response file return codes, refer to the Microsoft Web site.
Response file installation using a batch file (Windows)

You can use a batch file to start a response file installation. To start a response file installation using a batch file: 1. Edit or create your response file. 2. Create your batch file using a text editor. For example, create a batch file called ese.bat with the following content to install DB2 Enterprise Server Edition:
c:\db2ese\setup /U c:\PROD_ESE.rsp echo %ERRORLEVEL%
where /U specifies the location of the response file and echo %ERRORLEVEL% specifies that you want the batch process to display the installation return code.
107
3. Run the batch file, using the ese.bat command issued from a command prompt.
Available sample response files

You can use the sample response files to install or uninstall DB2 products, features, and languages. The DB2 DVD includes ready-to-use sample response files with default entries. The sample response files are located in:
db2/platform/samples
where platform refers to the appropriate hardware platform. On Windows, the sample response files for IBM Data Server Runtime Client and IBM Data Server Driver Package are located in:
\samples
After an install, the uninstall sample response file is also saved in the DB2DIR/install directory, where DB2DIR is the full path name where you install the DB2 product. Note: On Windows, an uninstall sample response file does not exist for IBM Data Server Runtime Client or IBM Data Server Driver Package, because the db2unins command is not supported for this client or driver.
Response file keywords

Response files use keywords. You can use a response file to perform tasks such as the following: v an installation of DB2 products, features, or language, v an installation of additional DB2 features or language, or v an uninstallation of DB2 products, features, or language. Sample response files are provided for both an installation and uninstallation. The following response file keywords are explained in conjunction with a sample response file. The edited response file must then be copied to your shared network drive or network file system where it will be used by your installation server. The following response file keywords can be used to install a DB2 product, feature, or language. On Linux or UNIX platforms, some keywords are valid for root installation only. PROD Specifies the product that you want to install. Only one DB2 product can be installed at a time. Therefore, only one product can be specified with this keyword. Note: 1. You should not comment out the PROD keyword as you might have some missing components even with a successful response file installation. 2. This keyword cannot be used with the db2isetup command -r response_file parameter. FILE Specifies the destination directory for a DB2 product.
108
Windows On Windows operating systems, this keyword is limited to 110 characters. Linux or UNIX On Linux or UNIX operating systems, this keyword is mandatory for root installations. DB2 installation paths have the following rules: v Can include lowercase letters (az), uppercase letters (AZ), and the underscore character ( _ ) v Cannot exceed 128 characters v Cannot contain spaces v Cannot contain non-English characters This keyword is required for any response file used with the db2isetup command -r response_file parameter. INSTALL_OPTION Windows platforms only and specific to DB2 Enterprise Server Edition. This keyword specifies the installation. The default is SINGLE_PARTITION. The options are: v INSTANCE_OWNING v NEW_NODE v SINGLE_PARTITION LIC_AGREEMENT Indicates you have read and agree to the license agreement file in the db2/license directory on the DB2 product DVD. The default is DECLINE. The options are: v DECLINE v ACCEPT Note: 1. You must change this keyword to ACCEPT to signify your acceptance of the DB2 license agreement for the installation to proceed. 2. This keyword cannot be used with the db2isetup command -r response_file parameter. INTERACTIVE Linux or UNIX platforms only. Determines if installation provides prompting for location of the national language package (either on DVDs or fileset location) and progress reports. The options are: v NONE v YES v MACHINE Note: 1. When NONE is specified, there is no interaction.
109
2. When YES is specified, progress information and prompt information displays to the console. During installation, if a language is missing, you are prompted for the location of the national language package. 3. Specify MACHINE to receive progress or prompt information in a format easily parsed by another program. A sample program is also provided, see Embedding the DB2 installation image (Linux and UNIX). CONFIG_ONLY This keyword is deprecated and will be discontinued in a future release. Linux or UNIX platforms only. Specifies that this response file is for performing configuration tasks only. For example, creating a new instance using the db2isetup command. The options are: v YES v NO INSTALL_TYPE Specifies the type of install. The options are: v COMPACT v TYPICAL v CUSTOM A compact or typical install type will ignore any custom keywords (COMP). Note: This keyword cannot be used with the db2isetup command -r response_file parameter. DB2_COPY_NAME Windows platforms only. Represents the name used to refer to a set of DB2 products installed in the same location. This name is limited to 64 characters. DEFAULT_COPY Windows platforms only. Specifies if the copy being installed or modified should be set as the default DB2 copy used by DB2 applications. The default is NO unless this is the only DB2 copy installed. The options are: v YES v NO COPY_NAME Windows platforms only. Represents the name used to refer to the IBM Data Server Driver Package installed. Valid only when the PROD keyword is set to IBM_DATA_SERVER_DRIVER. This name is limited to 64 characters. DEFAULT_CLIENT_INTERFACE_COPY Windows platforms only. Specifies if the copy of DB2 products, or the IBM Data Server Driver Package, installed should be set as the default IBM database client interface copy. If this keyword is set to YES, the IBM data server client interface (ODBC/CLI driver and .NET data provider) in the copy is the default driver to be used by the applications. If you are installing the IBM Data Server Driver, the default is NO unless the
110
computer does not have a DB2 product, or the IBM Data Server Driver Package, installed. If you are installing other products, the default is the value of the DEFAULT_COPY keyword. The options are: v YES v NO POPULATE_XML_FROM_CATALOG Specifies whether the db2dsdriver.cfg configuration file is populated with catalog information. The default is FALSE. The options are: v TRUE v FALSE INSTALL_TSAMP AIX and Linux platforms only. Specifies support of IBM Tivoli System Automation for Multiplatforms. The default value is YES. The options are: v YES v NO INSTALL_ITMA Specifies that the IBM Tivoli Monitoring for Databases: DB2 Agent is installed from the DB2 installation media. The default value is YES. The options are: v YES v NO If you choose NO, to install IBM Tivoli Monitoring for Databases you need to set this keyword to YES and rerun the silent installation. MIGRATE_PRIOR_VERSIONS This keyword is deprecated and you should use the UPGRADE_PRIOR_VERSIONS keyword instead. Windows platforms only. Specifies if an existing version of the DB2 product is to be migrated. The default is FALSE. The options are: v TRUE v FALSE UPGRADE_PRIOR_VERSIONS Specifies if an existing version of the DB2 product is to be upgraded. The default is FALSE. The options are: v TRUE v FALSE This keyword is supported on Linux, UNIX, and Windows platforms. However, on Linux and UNIX operating systems, this keyword is valid only for non-root installation. On Windows platforms, in addition to setting UPGRADE_PRIOR_VERSIONS to the value TRUE, you must also set the DB2_COPY_NAME keyword to the value of an existing copy name.
111
UPGRADE_DBCK_IGNORE_TYPE1 Linux and UNIX platforms only, and specific to non-root installation. Forces the db2setup command to ignore type-1 index checking. The default is NO. The options are: v YES v NO PACKAGE_LOCATION Linux or UNIX platforms only. This keyword is used only when nlpack is removed from the image and NL languages are selected to install. This keyword specifies the location of the nlpack. The path can be the location of the product DVD, or, the location where the contents of the DVD has been saved. Built in search paths allow automatic searching of the same parent directory. For example, if the contents of a DB2 product DVD are copied into subdirectories:
/db2images/ese/dvd /db2images/nlpack/dvd
The subdirectories are automatically searched without specifying each subdirectory:

PACKAGE_LOCATION=/db2images/ese/disk1
This includes searching subdirectories for the national language DVD. If the contents of a DB2 product DVD are copied into different parent directories, this keyword can be repeated as many times as required. For example:
PACKAGE_LOCATION=/db2images1/dvd PACKAGE_LOCATION=/db2images2/nlpack/dvd
COMP Specifies the components that you want to install. The setup program automatically installs components that are required for a product. In a custom install, you must select components individually. This can be done by uncommenting the COMP keywords for the components that you want installed (this differs depending on the product). Note: This keyword is ignored unless your INSTALL_TYPE is CUSTOM. LANG This refers to language selection keywords. You must uncomment any additional languages that you would like to install. The English language is mandatory and is always selected. CLIENT_IMPORT_PROFILE Specifies a file name with a full path to a profile exported by the db2cfexp command. The profile contains instance related parameters. REBOOT Windows platforms only. Specifies whether to restart the system when the installation or uninstallation has completed. The default is NO. The options are: v YES v NO
112
KILL_PROCESSES Windows platforms only. If you have an existing version of DB2 and it is running and this keyword is set to YES, it will terminate your running DB2 processes without prompt. The options are: v YES v NO NEW_CONTACT Specifies if the email address contact on the notification and contact list is new or existing. The email address does not need to be provided if there is an existing email address. On Linux or UNIX platforms, this keyword is valid only for root installation. The options are: v YES v NO This keyword is optional. If the keyword is not specified, by default the contact is considered as a new contact. DB2_OLEDB_GUID Windows platforms only. Use this keyword to enter the GUID used by DB2 applications using OLE DB. If you do not specify this keyword, it is generated. CREATE_DAS Windows platforms only. Specifies whether to create the DAS or not. The options are: v YES v NO CHECK_UNCPATH Windows platforms only. Specifies to check that the Universal Naming Convention (UNC) path is in the PATH environment variable. The default value is YES. The options are: v YES v NO DB2 Administration Server settings To enable any of the following DAS settings, remove the * (uncomment). This setting is applicable for Windows, Linux and UNIX environments but on Linux or UNIX platforms, this keyword is valid for root installation only. v On Linux or UNIX platforms:
*DAS_USERNAME = dasuser *DAS_PASSWORD = dasp *DAS_GID = 100 *DAS_UID = 100 *DAS_GROUP_NAME = dasgroup *DAS_SMTP_SERVER = jsmith.torolab.ibm.com
v On Windows platforms:
113
*DAS_USERNAME = dasuser *DAS_DOMAIN = domain *DAS_PASSWORD = dasp *DAS_SMTP_SERVER = jsmith.torolab.ibm.com
You can also specify LOCALSYSTEM as a valid userid that does not require a password. The LOCALSYSTEM userid is available for all products, except DB2 Enterprise Server Edition. The following options specify where the DAS contact list will be kept. On Linux or UNIX platforms, these options are valid for root installation only. If the contact list is remote, then you must specify a username and password that has authority to add a contact to the system.
*DAS_CONTACT_LIST = LOCAL or *DAS_CONTACT_LIST_HOSTNAME = *DAS_CONTACT_LIST_USERNAME = *DAS_CONTACT_LIST_PASSWORD = REMOTE (DEFAULT = LOCAL) hostname username password
Special instance specifications This takes the instance section not instance name. The instance section must exist in the response file. v Windows platforms: DEFAULT_INSTANCE - This is the default instance. v Linux or UNIX platforms: none Instance specifications For root installations, you can use the response file to create as many instances as you want. To create a new instance you must specify an instance section using the INSTANCE keyword. Once this has been done, any keywords that contain the value specified in INSTANCE as a prefix belong to that instance. On Windows platforms, you can also specify LOCALSYSTEM as a valid userid that does not require a password. The LOCALSYSTEM userid is available for all products, except DB2 Enterprise Server Edition. The following are examples of instance specifications for Windows, Linux and UNIX platforms: v On Linux or UNIX platforms:
*INSTANCE=DB2_INSTANCE *DB2_INSTANCE.NAME = db2inst1 *DB2_INSTANCE.TYPE = ESE *DB2_INSTANCE.PASSWORD = PASSWORD (valid for root installation only) *DB2_INSTANCE.UID = 100 (valid for root installation only) *DB2_INSTANCE.GID = 100 (valid for root installation only) *DB2_INSTANCE.GROUP_NAME = db2grp1 (valid for root installation only)) *DB2_INSTANCE.HOME_DIRECTORY = /home/db2inst1 (valid for root installation only) *DB2_INSTANCE.SVCENAME = db2cdb2inst1 *DB2_INSTANCE.PORT_NUMBER = 50000 *DB2_INSTANCE.FCM_PORT_NUMBER = 60000 (valid for root installation only) *DB2_INSTANCE.MAX_LOGICAL_NODES = 4 (valid for root installation only) *DB2_INSTANCE.AUTOSTART = YES *DB2_INSTANCE.START_DURING_INSTALL = YES *DB2_INSTANCE.FENCED_USERNAME = USERNAME
114
(valid for root installation only) *DB2_INSTANCE.FENCED_PASSWORD = PASSWORD *DB2_INSTANCE.FENCED_UID = 100 *DB2_INSTANCE.FENCED_GID = 100 *DB2_INSTANCE.FENCED_GROUP_NAME = db2grp1 *DB2_INSTANCE.FENCED_HOME_DIRECTORY =/home/db2inst1 *DB2_INSTANCE.CONFIGURE_TEXT_SEARCH = NO *DB2_INSTANCE.TEXT_SEARCH_HTTP_SERVICE_NAME = db2j_DB2_INSTANCE (valid for root installation only) *DB2_INSTANCE.TEXT_SEARCH_HTTP_PORT_NUMBER = 55000
v On Windows platform:
*INSTANCE = DB2_INSTANCE *DB2_INSTANCE.NAME = db2inst1 *DB2_INSTANCE.DEFAULT_INSTANCE = db2inst1 *DB2_INSTANCE.TYPE = ESE *DB2_INSTANCE.PASSWORD = PASSWORD *DB2_INSTANCE.AUTOSTART = YES *DB2_INSTANCE.START_DURING_INSTALL = YES *DB2_INSTANCE.SVCENAME = db2cdb2inst1 *DB2_INSTANCE.PORT_NUMBER = 50000 *DB2_INSTANCE.FCM_PORT_NUMBER = 60000 *DB2_INSTANCE.MAX_LOGICAL_NODES = 4 *DB2_INSTANCE.CONFIGURE_TEXT_SEARCH = NO *DB2_INSTANCE.TEXT_SEARCH_HTTP_SERVICE_NAME = db2j_DB2_INSTANCE *DB2_INSTANCE.TEXT_SEARCH_HTTP_PORT_NUMBER = 55000
Note: The keyword START_DURING_INSTALL determines if the instance is started after installation. The keyword AUTOSTART determines if the instance is auto started after system reboot. If START_DURING_INSTALL is not specified, AUTOSTART also determines if the instance is started after installation. Database Section These keywords can be used to have the installation create or catalog a database on the machine that is being installed.
DATABASE = DATABASE_SECTION DATABASE_SECTION.INSTANCE = db2inst1 DATABASE_SECTION.DATABASE_NAME = MYDB DATABASE_SECTION.LOCATION = LOCAL DATABASE_SECTION.ALIAS = MYDB DATABASE_SECTION.USERNAME = username DATABASE_SECTION.PASSWORD = password * these keywords are only used for REMOTE databases that are being cataloged DATABASE_SECTION.SYSTEM_NAME = hostname DATABASE_SECTION.SVCENAME = db2c_db2inst1
TOOLS_CATALOG_DATABASE On Linux or UNIX platforms, this keyword is valid for root installation only. This keyword specifies the database to use to store the tools catalog. The value for this keyword should be one of the database section keywords that were specified in the response file.
*TOOLS_CATALOG_DATABASE = DATABASE_SECTION
TOOLS_CATALOG_SCHEMA To set the tools catalog schema, remove the * (uncomment) from the following:
*TOOLS_CATALOG_SCHEMA = toolscat_schema
On Linux or UNIX platforms, this keyword is valid for root installation only.
115
Contact Section These keywords define a contact section that will be created by the installation process if it does not already exist. The Health notifications for the instance that is specified will be sent to this contact.
CONTACT = contact_section contact_section.NEW_CONTACT = YES contact_section.CONTACT_NAME = contact name contact_section.INSTANCE = DB2_INSTANCE contact_section.EMAIL = Email address contact_section.PAGER = NO
On Linux or UNIX platforms, this keyword is valid for root installation only. DB2 Information Center settings Section The default location for accessing the DB2 documentation is the IBM Web site. Only edit this section if you want to access DB2 documentation from a different location, such as your local computer or an intranet server. The following options specify the host name and port number where the Information Center server is installed, and the service name and port number that the Information Center server service uses.
*DB2_DOCHOST = hostname *DB2_DOCPORT = 1024-65535 *DB2_ECLIPSEIC_SVCENAME = db2icv95 *DB2_ECLIPSEIC_PORT = 51000
DB2_ECLIPSEIC_SVCENAME and DB2_ECLIPSEIC_PORT are only valid for the installation of the DB2 Information Center. Extended security section Windows platforms only. These keywords define a security section.
*DB2_EXTSECURITY *DB2_ADMINGROUP_NAME *DB2_USERSGROUP_NAME *DB2_ADMINGROUP_DOMAIN *DB2_USERSGROUP_DOMAIN = YES = DB2ADMNS = DB2USER = BLANK = BLANK
No configuration option Windows platforms only. This keyword gives you the option to install a DB2 product with only the mandatory configuration. The DB2 instance must be created manually. The default is NO.
*NO_CONFIG = NO
The options are: v YES v NO Query Patroller These keywords can be used to install Query Patroller.
QUERY_PATROLLER_DATABASE = databas1 databas1.QP_CONTROL_TABLESPACE = db2qpControlTableS databas1.QP_CONTROL_DBPARTITIONGROUP = db2qpControlDBPGrp databas1.QP_CONTROL_DBPARTITIONNUM = 0,1,2,...,999 databas1.QP_CONTROL_PATH = any valid path databas1.QP_CONTROL_DMS = NO databas1.QP_CONTROL_DMS_CONTAINER = FILE databas1.QP_CONTROL_DMS_NUMPAGES = any non-negative integer databas1.QP_RESULT_TABLESPACE = db2qpResultTableS databas1.QP_RESULT_DBPARTITIONGROUP = db2qpResultDBPGrp databas1.QP_RESULT_DBPARTITIONNUM = 0,1,2,...,999
116
databas1.QP_RESULT_PATH = any valid path databas1.QP_RESULT_DMS = NO databas1.QP_RESULT_DMS_CONTAINER = FILE databas1.QP_RESULT_DMS_NUMPAGES = any non-negative integer databas1.QP_REPLACE = YES
On Windows platforms only, the following additional keywords for Query Patroller Server User Information are required:
*QP_USERNAME *QP_DOMAIN *QP_PASSWORD
db2rfe configuration file

Keywords for the db2rfe configuration file Use the following keywords to select features and settings to create the db2rfe configuration file: INSTANCENAME Specifies the user name who owns the non-root installation copy. Note: Do not comment out the INSTANCENAME keyword. This is required keyword. SET_ULIMIT AIX only. For other platforms, refer to the system documentation to set this manually. On AIX, when this keyword is set to YES, the db2rfe command sets the hard and soft data parameter to unlimited, hard and soft file size to unlimited, and, sets the hard and soft nofile parameter to 65536. The options are: v YES v NO The default is NO. ENABLE_DB2_ACS AIX, Linux on AMD64/EM64T, and Linux on POWER only. Enables the DB2 Advanced Copy Services (ACS). The default value is NO. The options are: v NO v YES ENABLE_HA Specifies support of High Availability using IBM Tivoli System Automation for Multiplatforms. The default value is NO. The options are: v NO v YES ENABLE_OS_AUTHENTICATION Specifies support of operating system authentication for database connection. The default value is NO. The options are: v NO
117
v YES RESERVE_REMOTE_CONNECTION Reserves service for a remote connection. The default value is NO. The options are: v NO v YES Note: 1. If the database manager configuration parameter SVCENAME has a value, and keywords SVCENAME or SVCEPORT are also provided in the configuration file, all three values must match. 2. If the database manager configuration parameter SVCENAME has a value, and either keyword SVCENAME or SVCEPORT is not provided, either port_number or service_name of SVCNAME is used with a generated service_name or port_number respectively. 3. If the database manager configuration parameter SVCENAME is not set, and neither keyword SVCENAME and SVCEPORT are provided, a default service name and port number is generated and reserved. SVCENAME Used with keyword RESERVE_REMOTE_CONNECTION. Specifies the service name of a remote connection. This keyword is limited to 14 characters. SVCEPORT Used with keyword RESERVE_REMOTE_CONNECTION. Specifies a port number of a remote connection within the range 1024 65535.
RESERVE_TEXT_SEARCH_CONNECTION Reserves the service entry for the port used by DB2 Text Search. The default value is NO. The options are: v NO v YES SVCENAME_TEXT_SEARCH Used with keyword RESERVE_REMOTE_CONNECTION. Specifies the service name of the service entry for the port used by DB2 Text Search. This keyword is limited to 14 characters. SVCEPORT_TEXT_SEARCH Used with keyword RESERVE_REMOTE_CONNECTION. Specifies a port number of the service entry for the port used by DB2 Text Search. See the related links for the configuration parameters summary, and, DB2 registry and environment variables.
118
Uninstallation keywords
The following response file keywords can be used to uninstall a product, feature, or language: Uninstallation keywords REMOVE_PROD Specifies the DB2 product you want to uninstall. You can uninstall DB2 products individually or you can uninstall all DB2 products. To uninstall all products in the current installation copy, specify REMOVE_PROD=ALL. On Windows operating systems, this keyword cannot be combined with REMOVE_COMP, REMOVE_LANG, or REMOVE_ITMA. REMOVE_COMP Specifies the DB2 components you want to uninstall. On Windows operating systems, this keyword cannot be combined with REMOVE_PROD. REMOVE_LANG Specifies the languages you want to uninstall. English cannot be uninstalled. To uninstall all languages, except English, from the current installation copy, specify REMOVE_LANG=ALL. On Windows operating systems, this keyword cannot be combined with REMOVE_PROD. REMOVE_ITMA Specifies the IBM Tivoli Monitoring for Databases: DB2 Agent is to be uninstalled. The default is NO. The options are: v YES v NO On Windows operating systems, this keyword cannot be combined with REMOVE_PROD. REMOVE_TSAMP AIX and Linux platforms only. Specifies the IBM Tivoli System Automation for Multiplatforms to be uninstalled. The default is NO. The options are: v YES v NO This keyword is only considered when a DB2 copy is removed. To remove a DB2 copy, specify each product or uncomment REMOVE_PROD=ALL. REMOVE_DAS Windows platforms only. Determines if the DAS is to be deleted. The default is YES. The options are: v YES v NO The keyword REMOVE_DAS will only be examined in the following situation:
119
v there is more than one DB2 copy on the system, v the DAS is configured and active under the DB2 copy that is being removed, or v you choose to remove all server products in the DB2 copy In this case, after the uninstallation, other DB2 copies that require the use of a DAS will not function properly. To correct the problem, use the dasupdt command to move the DAS to another DB2 copy. When the keyword REMOVE_DAS is set to YES, and the conditions specified above are met, the uninstallation will always remove the DAS when removing the current DB2 copy. When the keyword REMOVE_DAS is set to NO, and the conditions specified above are met, the uninstallation will fail. REBOOT Windows platforms only. Specifies whether to restart the system when the installation or uninstallation has completed. The default is NO. The options are: v YES v NO
Embedding the DB2 installation image (Linux and UNIX)

On Linux and UNIX platforms, you can embed a DB2 installation image into the installation image of your own application. When installing a DB2 product using a response file with the interactive keyword specified, installation-related information such as progress or prompts is provided in a format easily parsed by your application. To bundle a DB2 installation image in your own application: 1. Copy the DB2 sample program, located in db2/samples/, to a working directory. Sample programs are provided in both C and Java. The C and Java subdirectories contain a sample program and a readme file. 2. Build the sample program using the makefile provided or a compatible compiler. 3. Modify the response file to specify the keyword INTERACTIVE=MACHINE. 4. Using the sample program, start the DB2 installation from your working directory. v In a C-based installation application, enter:
./InstallTester image -r response_file
v In a Java based installation application, enter:

java InstallTester image -r response_file
where v image represents the location of the DB2 installable image where either the db2setup command or the db2_install command is located v response_file specifies the full path and file name of the response file to use.
120
Exporting and importing a profile

Configuration information can be exported and imported to another DB2 workstation instance. If you did not use a configuration profile when you installed your DB2 product using the response file that was created by the response file generator, you can create a configuration file and import it to another workstation. 1. To create a configuration profile, enter the db2cfexp command specifying the fully qualified name of the target export file. The resulting profile contains only configuration information associated with the current DB2 database instance. 2. To import the configuration profile, you can: v Use the db2cfimp command v Use a response file by uncommenting the keyword DB2.CLIENT_IMPORT_PROFILE and specify the filename as the export file Note: You can also use the Configuration Assistant (CA) to export and import a configuration profile.
Stopping DB2 processes during an interactive installation (Windows)

If you are modifying or installing a new product on top of an existing DB2 copy, it is recommended to stop the DB2 processes of the DB2 copy before proceeding. You must exercise extreme caution when you stop active DB2 processes because the termination of a DB2 process can cause the loss of data. To lessen the risk of data loss, it is recommended that you issue the db2stop command for each instance. The following describes how to stop DB2 processes. 1. For an interactive installation, to stop any running DB2 processes, specify the /F option for the setup command. The /F option stops the running processes, and the message and prompt are not displayed. 2. In addition, DB2 services can be viewed in the Services Window to ensure that they have been stopped.
Stopping DB2 processes during a response file installation (Windows)

If any DB2 processes are running when the DB2 setup command is issued, the installation cannot occur. You must stop the DB2 processes so that the installation can proceed. You must exercise extreme caution when you stop active DB2 processes because the termination of a DB2 process can cause the loss of data. The following describes how to stop these processes. To lessen the risk of data loss, it is recommended that you issue the db2stop command for each instance and that you close any applications accessing DB2 data. For a response file installation, you can use either of the following methods to stop any active DB2 processes. If you specify either of these options, the active DB2 processes are stopped before the installation proceeds. v Specify the /F option for the setup command.
121
v Set the KILL_PROCESSES keyword to YES (the default is NO).
122
Chapter 11. Changing DB2 product editions

Moving between DB2 database products (Linux and UNIX)
You can move from one DB2 database product edition to another (or from one DB2 copy to another) and preserve all information from the original DB2 database product installation. For example, you can move from DB2 Workgroup Server Edition to DB2 Enterprise Server Edition. Before you begin Your system must comply with the system prerequisites for the DB2 database product edition that you are installing. About this task Be careful when you issue the db2_deinstall command. If you issue the command without specifying appropriate command options, you might remove all DB2 database product components. These instructions apply only when switching among the same version of a DB2 database product. Procedure To move between DB2 database products: 1. Complete the DB2 database product installation for the new edition. You do not need to create a new instance. Existing instances can be re-configured by issuing db2iupdt or db2nrupdt commands when the installation is complete. 2. Add the license file for the new database product by issuing the db2licm command.
db2licm -a LicenseFile
The license file is found in the db2/license directory on the product activation CD. 3. Obtain a list of the names of all instances on your system using the db2ilist command:
DB2DIR/db2ilist
where DB2DIR represents the location where the original DB2 database product is installed. By default, it is /opt/ibm/db2/V9.7 on Linux and /opt/IBM/db2/V9.7 on UNIX operating systems. 4. Stop any of the instances that are running. 5. To re-configure the instances, issue the following commands: v db2iupdt for each root instance v db2nrupdt for the non-root instance. For example:
DB2DIR/bin/db2iupdt InstanceName
123
where DB2DIR represents the location where the new DB2 database product is installed and InstanceName represents the name of the instance. 6. Remove the original DB2 database products license by issuing the db2licm command. a. Issue the command db2licm -l to find the original DB2 database products product-identifier value. b. Issue the following command to remove the license:
db2licm -r product-identifier
c. Issue the command db2licm -l and check the expiry date value. If the original DB2 database product does not have an expiry date of Expired, repeat the db2licm -r command until you have successfully removed all of the original DB2 database products licenses. 7. Remove the original DB2 database products signature: a. Find the product signature by issuing the db2ls command:
db2ls -q -a -b DB2DIR
where DB2DIR represents the location where the new DB2 database product is installed. You will see product signatures for both the old and new DB2 database products. For example, EXPRESS_PRODUCT_SIGNATURE or WSE_PRODUCT_SIGNATURE. b. Remove the old product signature by issuing the db2_deinstall command:
DB2DIR/install/db2_deinstall -F product_signature
where DB2DIR represents the location where the new DB2 database product is installed. You will no longer see the old product signature in the output from the db2ls command. 8. (Optional) Uninstall the original DB2 database product. Results When these steps are completed, your instances are configured to run in the new DB2 database product installation.
Moving between DB2 database products (Windows)

You can move from one DB2 database product to another (or from one DB2 copy to another) and preserve all information from the original DB2 database product installation. For example, you can upgrade from DB2 Workgroup Server Edition to DB2 Enterprise Server Edition. Before you begin Your system must comply with the system prerequisites for the new DB2 database product that you are installing. If there were any fix packs installed on the original DB2 database product, you should obtain the image for that fix pack level and install that directly, as opposed to installing the DB2 database product and then applying the fix pack. The reason for this is that each DB2 fix pack image is a full refresh image. About this task
124
These instructions apply only when the old and new DB2 database products share the same version level (for example, Version 9.7 ). Procedure To move between DB2 database products: 1. Log on as a user with administrator access. 2. Stop all DB2 processes and services. 3. Insert the DB2 database product DVD for the new edition you are installing into the drive. The IBM DB2 database product launchpad will open. 4. The DB2 database product setup wizard will determine the system language, and will start the setup program for that language. To start the DB2 database product setup wizard manually: a. Click Start and select the Run option. b. In the Open field, type the following command:
x:\setup /i language
where x represents your DVD drive and language is the territory identifier for your language, for example, EN for English. If the /i flag is not specified, the installation program will run in the default language of the operating system. Click OK. 5. Choose Work with existing to start the installation and proceed by following the setup programs prompts. Online help is available to guide you through these steps. To invoke the online help, click Help or press F1. You can click Cancel at any time to end the installation. 6. Add the license file for the new DB2 database product by issuing the db2licm command.
db2licm -a LicenseFile
The license file is found in the db2\license directory on the product activation CD. 7. Remove the original DB2 database products license by issuing the db2licm command. a. Issue the command db2licm -l to find the original DB2 database products product-identifier value. b. Issue the following command to remove the license:
db2licm -r product-identifier
c. Issue the command db2licm -l and check the expiry date value. If the original DB2 database product does not have an expiry date of Expired, repeat the db2licm -r command until all of the original DB2 database products licenses are removed. 8. Remove the original DB2 database product using the Add or Remove Control Programs Control Panel window. 9. When the original DB2 database product is completely uninstalled, reactivate the administration server and the services using the db2start command or the Services window of the Control Panel. Results
Chapter 11. Changing DB2 product editions
125
When these steps are completed, your instances are configured to run in the new DB2 database product installation.
126
Part 2. Installation methods that require manual configuration (Linux and UNIX)
It is recommended that you install DB2 products and features using the DB2 Setup wizard or by using a response file. The DB2 Setup wizard provides an easy-to-use graphical interface with installation help, user and group creation, protocol configuration, and instance creation. A response file installation provides the same advantages as the DB2 Setup wizard, but without the graphical interface. In addition, by using a response file you can take advantage of advanced configuration capabilities such as setting individual database manager configuration parameters or setting profile registry variables. If you do not prefer these installation methods, you can install DB2 products, features, and components on supported Linux and UNIX operating systems using methods which require manual configuration: v The db2_install command for DB2 products, or doce_install command for the DB2 Information Center v Payload file deployment With each of these two methods, manual configuration is required after the product files are deployed. Prerequisites Refer to the installation documentation for the particular DB2 product you want to install. For example, if you want to install DB2 Enterprise Server Edition, then refer to the Quick Beginnings for DB2 Servers documentation to review installation prerequisites and other important setup information. Restrictions You cannot install DB2 products or feature on Windows operating systems using the db2_install command or the payload file method. On Windows operating systems, DB2 products and features can be only installed using the DB2 Setup wizard or a response file. On supported Linux or UNIX operating systems, you cannot install a DB2 product or feature using the operating systems native installation utility (that is, rpm, SMIT, swinstall or pkgadd). Any existing scripts containing a native installation utility that you use to interface and query with DB2 installations must change. Select an installation method: v Chapter 12, Installing a DB2 product using the db2_install or doce_install command (Linux and UNIX), on page 129 v Chapter 13, Installing DB2 products with payload files (Linux and UNIX), on page 133
127
128
Chapter 12. Installing a DB2 product using the db2_install or doce_install command (Linux and UNIX)
Before you install DB2 products and features or the DB2 Information Center: v You should refer to the installation documentation for the particular DB2 product you want to install. For example, if you want to install DB2 Enterprise Server Edition, then refer to the Quick Beginnings for DB2 Servers documentation to review installation prerequisites and other important setup information. v You can install a DB2 product and the DB2 Information Center using either root or non-root authority. v The DB2 product image must be available. You can obtain a DB2 installation image either by purchasing a physical DB2 product DVD, or by downloading an installation image from Passport Advantage. The db2_install command installs DB2 products and features on supported Linux and UNIX operating systems. The doce_install command installs the DB2 Information Center on supported Linux operating systems. You cannot manually install a DB2 product or feature using an operating systems native installation utility such as rpm, SMIT, swinstall or pkgadd. Any existing scripts containing a native installation utility that you use to interface and query with DB2 installations will need to change. The db2_install command is not supported on the National Language Package DVD. Only one copy of the DB2 Information Center for the current release can be installed on your system. The Information Center cannot be installed in the same location where a DB2 product is installed. If you install the DB2 Information Center on a system with a firewall, and you plan to allow other systems to access the DB2 Information Center, you must open the port in your firewall setting. To install a DB2 product or feature using the db2_install command, or to install the DB2 Information Center using the doce_install command: 1. If you have a physical DB2 product DVD, insert and mount the appropriate DVD or access the file system where the installation image was stored. 2. If you downloaded the DB2 product image, you must decompress and untar the product file. a. Decompress the product file:
For example,
gzip -d ese.tar.gz
b. Untar the product file: On Linux operating systems

For example,
129
tar -xvf ese.tar

For example,
gnutar -xvf ese.tar
c. Change directory into the product directory:

cd product
For example,
cd ese
3. Enter the ./db2_install or ./doce_install command:

./db2_install -b DB2DIR -p productShortName -c NLPackLocation -L language... -n
where: v DB2DIR specifies the path where the DB2 product will be installed. If the path is not specified, you are prompted to either select the default path or to provide the path. The default installation path is: for AIX, HP-UX or Solaris operating systems: /opt/IBM/db2/V9.7 for Linux operating systems: /opt/ibm/db2/V9.7 for the DB2 Information Center: /opt/ibm/db2ic/V9.7. The Workstation version of the DB2 Information Center does not have a default installation path, you must specify the installation location. However, by default, the Workstation version of the DB2 Information Center is installed at port 51097. If you provide your own path, you must specify the full path name. DB2 installation paths have the following rules: Can include lowercase letters (az), uppercase letters (AZ), and the underscore character ( _ ) Cannot exceed 128 characters Cannot contain spaces Cannot contain non-English characters Note: For DB2 products and components to work together, they must be installed to a single path. This is not to be confused with the ability to install DB2 products to multiple paths. But, for products and components to work together, they must be installed to the same path, and, must be at the same release level. v productShortName specifies the DB2 product to be installed. This parameter is case insensitive and is mandatory when the -n parameter is specified. The product short name (productShortName) can be found in the file ComponentList.htm (under the product full name) located in the /db2/plat directory on your media where plat is the platform name that you are installing on. You can only install one product at a time. v NLPackLocation specifies the National Language Pack (NLPACK) location. v language specifies national language support. You can install a non-English version of a DB2 product. However, you must run this command from the product DVD, not the National Language pack DVD. By default, English is always installed, therefore, English does not need to be specified. When more than one language is required this parameter is
130
mandatory. To indicate multiple languages, specify this parameter multiple times. For example, to install both French and German specify -L FR -L DE. v n parameter indicates noninteractive installation mode. When this parameter is specified, both -b and -p must also be specified. You only need to specify -c and -L if applicable. When installing the DB2 Information Center, if you specify a port number other than the default, you might receive the error The service name specified is in use. You can correct this error by either choosing to use the default port number or by specifying a different service name. After installation, you must manually configure your DB2 server. Tasks include user and instance creation and configuration.
Chapter 12. Installing with the db2_install and doce_install command
131
132
Chapter 13. Installing DB2 products with payload files (Linux and UNIX)
This task describes how to install DB2 database products, components, and features from DB2 payload files. This is not a recommended method for installation. It is recommended that you use the DB2 Setup wizard or the response file method. Before you begin Before you deploy DB2 payload files: v Review the installation prerequisites and ensure the requirements are met. v Ensure that DB2 dependencies are met. While reviewing the installation prerequisites, make note of any DB2 database products that must be installed with each other. Then be sure to deploy the tar.gz file for a product, as well as any of the tar.gz files for required products. v Get the payload files, which are contained on the DB2 database product DVD or can be downloaded from IBM Passport Advantage: http://www.ibm.com/ software/howtobuy/passportadvantage/. Restrictions You cannot manually install a DB2 database product, component, or feature using an operating systems native installation utility such as rpm, SMIT, swinstall or pkgadd. Procedure To install DB2 database products, components, and features from DB2 payload files: 1. For root installations, log on as a root user. For non-root installations, log on with the user ID that is to own the DB2 installation. 2. Insert and mount the appropriate DVD or access the file system where the installation image is stored. 3. Locate the DB2 component you want to install. Each DB2 database product DVD provides a file that lists the components available for installation. The component list is in a file called ComponentList.htm and is located in the /db2/platform directory on your DVD, where platform is the platform that you are installing on. 4. Uncompress the payload file. Note: For DB2 database products and components to work together, they must be installed to a single path. This is not to be confused with the ability to install DB2 database products to multiple paths. But, for products and components to work together, they must be installed to the same path, and must be at the same release level. If a component has prerequisites, look in the DB2DIR/.metadata/COMPONENT/prereqs file inside each payload to see what the prerequisites are. If any required components are missing, that functionality will not work. To uncompress the payload file, run the appropriate command: v For AIX, HP-UX or Solaris:
133
cd DB2DIR gunzip -c /dvd/db2/platform/FILES/filename.tar.gz | tar -xvf -
v For Linux:
cd DB2DIR tar xzvf /dvd/db2/platform/FILES/filename.tar.gz
where v DB2DIR is the full path name where you are installing: For non-root installations, DB2DIR must be $HOME/sqllib. This directory must be empty For root installations, the default path is: - /opt/IBM/db2/V9.7 for AIX, HP-UX or Solaris - /opt/ibm/db2/V9.7 for Linux If you choose not to use the default path, you can specify a different installation path. DB2 installation paths have the following rules: - Can include lowercase letters (az), uppercase letters (AZ), and the underscore character ( _ ) - Cannot exceed 128 characters - Cannot contain spaces - Cannot contain non-English characters v dvd represents the mount point of the DB2 DVD. v filename is the name of the DB2 component you are installing. 5. To ensure the embedded library search path on each DB2 executable and library file uses the installation path, run the following command:
DB2DIR/install/db2chgpath
where DB2DIR is the full path name where you are installing. Important notes: v After you run the db2chgpath command, program files cannot be moved. v If you install additional features to the same path at a subsequent time, you must run the db2stop command, and rerun the db2chgpath command. 6. For root installations, you can create a DB2 instance at this time using the db2icrt command. If there is no need to create an instance, you should at least run the db2ilist command. Either the db2icrt command or the db2ilist command must be run at this time, because a side-effect of running either command is that the installation is registered with the global registry. 7. For non-root installations, run $HOME/sqllib/db2nrcfg to configure the non-root instance. 8. Set up the db2ls utility. The db2ls utility allows you to query information about installed DB2 copies. To set up the db2ls utility: a. Determine which DB2 copy is the most updated copy by running the following command:
db2greg dump
Output such as the following will display:

S,DB2,9.5.0.0,/opt/ibm/copy1,-,,0,,,1159464765,0 S,DB2,9.5.0.1,/opt/ibm/copy2,,,1,0,,1159466596,0
134
In the sample output, 9.5.0.1 in the second line indicates that copy2 is at a higher level than copy1, which is at 9.5.0.0. b. Check /usr/local/bin to see if a link to db2ls exists. If it exists, check which DB2 copy it points to. c. If either of the following conditions are true, create a link to /opt/ibm/latest_copy/install/db2ls in the /usr/local/bin directory (where latest_copy is the DB2 copy with the highest level): v /usr/local/bin/db2ls does not exist v /usr/local/bin/db2ls exists, but points to an installed DB2 copy which is not the most updated copy on the system 9. Set up the DB2 fault monitor in /etc/inittab by running the db2fmcu command, which is available in a server installation. For example:
DB2DIR/bin/db2fmcu u p /etc/inittab
where DB2DIR is the full path name where you are installing. 10. For non-root installations, after the DB2 database product is installed, you need to open a new login session to use the non-root DB2 instance. Alternatively, you can use the same login session if you set up the DB2 instance environment with $HOME/sqllib/db2profile (for Bourne shell and Korn shell users) or $HOME/sqllib/db2chsrc (for C shell users), where $HOME is the non-root users home directory. What to do next After payload deployment, there are further manual configuration tasks which must be performed.
Chapter 13. Installing with payload files
135
136
Chapter 14. Manually configuring DB2 servers after installation

This task provides steps for manually setting up a DB2 server after installing the server using the db2_install command or payload file deployment method on supported Linux and UNIX operating systems. This task does not apply to DB2 products that were installed using the DB2 Setup wizard or a response file. Installation using the db2_install command or the payload file deployment method only installs DB2 components. Configuration and setup tasks such as the ones listed below must be performed manually. Use the following steps to manually set up a DB2 server. Note that steps 1 to 4 do not apply to non-root installations. 1. Create group and user IDs for a DB2 installation 2. Create a DB2 Administration Server (DAS) 3. 4. 5. 6. Create an instance using db2icrt Create links for DB2 files (Optional) Configure TCP/IP communications for a DB2 instance Register the license key using the License Center
If you plan to use DB2 tools such as the Task Center or the DB2 Administration Server scheduler functionality, it is recommended that you set up the DB2 tools catalog. The DB2 tools catalog contains metadata required for DB2 tools and the scheduler to function.
Creating group and user IDs for a DB2 database installation (Linux and UNIX)
The DB2 Setup wizard will create these users and groups for you during the installation process. If you want, you can create them ahead of time. To perform this task, you must have root authority to create users and groups. Three users and groups are required. The user and group names used in the following instructions are documented in the following table. You can specify your own user and group names if they adhere to system naming rules and DB2 naming rules. The user IDs you create will be required to complete subsequent setup tasks.
Table 18. Default users and groups User Instance owner Fenced user DB2 administration server user
Example user name db2inst1 db2fenc1 dasusr1
Example group name db2iadm1 db2fadm1 dasadm1
137
v The instance owner home directory is where the DB2 instance will be created. v The fenced user is used to run user defined functions (UDFs) and stored procedures outside of the address space used by the DB2 database. v The user ID for the DB2 administration server user is used to run the DB2 administration server on your system. To create the required groups and user IDs for DB2: 1. Log in as a user with root authority. 2. Enter the appropriate commands for your operating system. Note: These command line examples do not contain passwords. They are examples only. You can use the passwd username command from the command line to set the password. AIX operating systems To create groups on AIX, enter the following commands:

mkuser id=1004 pgrp=db2iadm1 groups=db2iadm1 home=/home/db2inst1 db2inst1 mkuser id=1003 pgrp=db2fadm1 groups=db2fadm1 home=/home/db2fenc1 db2fenc1 mkuser id=1002 pgrp=dasadm1 groups=dasadm1 home=/home/dasusr1 dasusr1

HP-UX operating systems To create groups on HP-UX, enter the following commands:

useradd -g db2iadm1 -d /home/db2instl -m db2inst1 useradd -g db2fadm1 -d /home/db2fenc1 -m db2fenc1 useradd -g dbasgrp -d /home/dasusr1 -m dasusr1

Linux operating systems To create groups on Linux operating systems, enter the following commands:
138
useradd -u 1004 -g db2iadm1 -m -d /home/db2inst1 db2inst1 useradd -u 1003 -g db2fadm1 -m -d /home/db2fenc1 db2fenc1 useradd -u 1002 -g dasadm1 -m -d /home/dasusr1 dasusr1

Solaris operating systems To create groups on Solaris, enter the following commands:

useradd -g db2iadm1 -u 1004 -d /export/home/db2inst1 -m db2inst1 useradd -g db2fadm1 -u 1003 -d /export/home/db2fenc1 -m db2fenc1 useradd -g dasadm1 -u 1002 -d /export/home/dasusr1 -m dasusr1

Creating group and user IDs in a partitioned database environment Creating required users for a DB2 server installation in a partitioned database environment (AIX)
Three users and groups are required to operate a DB2 database. The user and group names used in the following instructions are documented in the following table. You can specify your own user and group names if they adhere to your system naming rules and DB2 naming rules. If you are planning to use the DB2 Setup wizard to install your DB2 product, the DB2 Setup wizard will create these users for you.
Table 19. Required users and groups Required user Instance owner Fenced user DB2 administration server user User name db2inst1 db2fenc1 dasusr1 Group name db2iadm1 db2fadm1 dasadm1
If the DB2 administration server user is an existing user, this user must exist on all the participating computers before the installation. If you use the DB2 Setup wizard to create a new user for the DB2 administration server on the instance-owning computer, then the new user is also created (if necessary) during the response file installations on the participating computers. If the user already exists on the participating computers, the user must have the same primary group. Prerequisites v You must have root authority to create users and groups.
139
v If you manage users and groups with security software, additional steps might be required when defining DB2 users and groups. Restriction The user names you create must conform to both your operating systems naming rules, and those of DB2. To create all three of these users, perform the following steps: 1. Log on to the primary computer. 2. Create a group for the instance owner (for example, db2iadm1), the group that will run UDFs or stored procedures (for example, db2fadm1), and the group that will own the DB2 administration server (for example, dasadm1) by entering the following commands:
3. Create a user that belongs to each group that you created in the previous step using the following commands. The home directory for each user will be the DB2 home directory that you previously created and shared (db2home).
mkuser id=1004 pgrp=db2iadm1 groups=db2iadm1 home=/db2home/db2inst1 core=-1 data=491519 stack=32767 rss=-1 fsize=-1 db2inst1 mkuser id=1003 pgrp=db2fadm1 groups=db2fadm1 home=/db2home/db2fenc1 db2fenc1 mkuser id=1002 pgrp=dasadm1 groups=dasadm1 home=/home/dasusr1 dasusr1
4. Set an initial password for each user that you created by entering the following commands:
5. Log out. 6. Log on to the primary computer as each user that you created (db2inst1, db2fenc1, and dasusr1). You might be prompted to change each users password because this is the first time that these users have logged onto the system. 7. Log out. 8. Create the exact same user and group accounts on each computer that will participate in your partitioned database environment.
Creating required users for a DB2 server installation in a partitioned database environment (HP-UX)
Table 20. Required users and groups Required user Instance owner Fenced user User name db2inst1 db2fenc1 Group name db2iadm1 db2fadm1
140
Table 20. Required users and groups (continued) Required user DB2 administration server user User name dasusr1 Group name dasadm1
If the DB2 administration server user is an existing user, this user must exist on all the participating computers before the installation. If you use the DB2 Setup wizard to create a new user for the DB2 administration server on the instance-owning computer, then the new user is also created (if necessary) during the response file installations on the participating computers. If the user already exists on the participating computers, the user must have the same primary group. Prerequisites v You must have root authority to create users and groups. v If you manage users and groups with security software, additional steps might be required when defining DB2 users and groups. Restriction The user names you create must conform to both your operating systems naming rules, and those of DB2. To create all three of these users, perform the following steps: 1. Log on to the primary computer. 2. Create a group for the instance owner (for example, db2iadm1), the group that will run UDFs or stored procedures (for example, db2fadm1), and the group that will own the DB2 administration server (for example, dasadm1) by entering the following commands:
3. Create a user that belongs to each group that you created in the previous step using the following commands. The home directory for each user will be the DB2 home directory that you previously created and shared (db2home).
useradd -u 1004 db2iadm1 -d /db2home/db2inst1 -m db2inst1 useradd -u 1003 db2fadm1 -d /db2home/db2fenc1 -m db2fenc1 useradd -u 1002 dbasgrp -d /home/dasusr1 -m dasusr1
141
Creating required users for a DB2 server installation in a partitioned database environment (Linux)
Ensure that the specific numbers you are using do not currently exist on any of the machines. 3. Create a user that belongs to each group that you created in the previous step using the following commands. The home directory for each user will be the DB2 home directory that you previously created and shared (db2home).
useradd -u 1004 -g db2iadm1 -m -d /db2home/db2inst1 db2inst1 useradd -u 1003 -g db2fadm1 -m -d /db2home/db2fenc1 db2fenc1 useradd -u 1002 -g dasadm1 -m -d /home/dasusr1 dasusr1
142
Creating required users for a DB2 server installation in a partitioned database environment (Solaris Operating System)
143
groupadd id=999 db2iadm1 groupadd id=998 db2fadm1 groupadd id=997 dasadm1
3. Create a user for each group using the following commands. The home directory for each user will be the DB2 home directory that you previously created and shared (/db2home).
useradd -u 1004 -g db2iadm1 -d /db2home/db2instl -m db2inst1 useradd -u 1003 -g db2fadm1 -d /db2home/db2fenc1 -m db2fenc1 useradd -u 1002 -g dasadm1 -d /export/home/dasusr1 -m dasusr1
Creating the DB2 Administration Server (Linux and UNIX)

The DB2 Administration Server (DAS) provides support services for DB2 tools such as the Control Center and Configuration Assistant. Before you begin To create a DAS, you must have: v Root authority. v Created a DAS user. Important: The DB2 Administration Server (DAS) has been deprecated in Version 9.7 and might be removed in a future release. For more information, see the Control Center tools and DB2 administration server (DAS) have been deprecated topic in the Whats New for DB2 Version 9.7 book. Restrictions User IDs have the following restrictions and requirements: v Must have a primary group other than guests, admins, users, and local v Can include lowercase letters (az), numbers (09), and the underscore character (_) v Cannot be longer than eight characters v Cannot begin with IBM, SYS, SQL, or a number v Cannot be a DB2 reserved word (USERS, ADMINS, GUESTS, PUBLIC, or LOCAL), or an SQL reserved word v Cannot use any User IDs with root privilege for the DB2 instance ID, DAS ID or fenced ID. v Cannot include accented characters v If existing user IDs are specified instead of creating new user IDs, make sure that the user IDs:
144
Are not locked Do not have expired passwords Procedure To create the DAS: 1. Log in as user with root authority. 2. Issue the following command to create the DAS:
DB2DIR/instance/dascrt -u DASuser
where v DB2DIR specifies the path where the DB2 database product was installed. The default installation directory is: for AIX, HP-UX or Solaris operating systems: /opt/IBM/db2/V9.7 for Linux operating systems: /opt/ibm/db2/V9.7 v u specifies the DAS user you created when creating users and groups.
Creating an instance using db2icrt

A DB2 instance is an environment in which you store data and run applications. Use the db2icrt command to create an instance. Before you begin On Linux or UNIX operating systems, you must have root authority. Procedure To create an instance using db2icrt: 1. Log in with proper authority. 2. Run the db2icrt command. For example, on Linux or UNIX operating systems:
DB2DIR/instance/db2icrt -a AuthType -u FencedID InstName
where: DB2DIR is the DB2 installation directory. v On AIX, HP-UX, or Solaris operating systems, the default DB2 installation directory is /opt/IBM/db2/V9.7. v On Linux operating systems, the default installation directory is /opt/ibm/db2/V9.7. -a AuthType (Linux or UNIX) Represents the authentication type for the instance. AuthType can be one of SERVER, CLIENT, or SERVER_ENCRYPT. SERVER is the default. This parameter is optional. -u FencedID Represents the name of the user under which fenced user defined functions (UDFs) and fenced stored procedures will run. This flag is not required if you are creating an instance on a client. Specify the name of the fenced user you created. InstName Represents the name of instance. The name of the instance must be the
145
same as the name of the instance owning user. Specify the name of the instance owning user you created. The instance will be created in the instance owning users home directory.
Example
For example, if you are using server authentication, your fenced user is db2fenc1, and your instance owning user is db2inst1, use the following command to create an instance on an AIX system:
/opt/IBM/db2/V9.7/instance/db2icrt -a server -u db2fenc1 db2inst1
What to do next (Optional) After you create an instance you can configure notification for health monitoring. This task can be performed using the Health Center or CLP.
Creating links for DB2 files

You can create links for the DB2 files to the /usr/lib directory, and for the include files to the /usr/include directory for a particular DB2 version and release level. To perform this task, you must be logged on as a user with root authority. This task is not required for normal DB2 operation. Consider creating links for the DB2 files only if both of the following conditions are met: v You have only one copy of DB2 on the current computer. v You are developing or running applications and want to avoid having to specify the full path to the product libraries and include files. The following restrictions apply: v Creating links for one DB2 copy will render the other DB2 copies nonfunctional. Links can be established for only one DB2 copy on a given system. v If there are existing links to the /usr/lib and /usr/include directories from a previous DB2 version, they will automatically be removed. v Links must not be created on systems where multiple DB2 copies are intended to coexist. To create links for DB2 files: 1. Log on as a user with root authority 2. Run the db2ln command. For example:
DB2DIR/cfg/db2ln
where: DB2DIR is the DB2 installation directory. v On AIX, HP-UX, or Solaris operating systems, the default DB2 installation directory is /opt/IBM/db2/V9.7 v On Linux operating systems, the default installation directory is /opt/ibm/db2/V9.7
146
If there are existing links to the /usr/lib and /usr/include directories from a previous DB2 version, they will automatically be removed by entering the db2ln command to create links for this DB2 version. If you want to reestablish the links to the libraries of the previous version, then you must run the db2rmln command from your current DB2 version before you run the db2ln command from the previous DB2 version.
Configuring TCP/IP communications for a DB2 instance

This task describes how to configure TCP/IP communications on your DB2 server using the DB2 Command Line Processor (CLP). Communication protocols on the DB2 server must be configured in order for your DB2 server to accept inbound requests from remote DB2 clients. Before you configure TCP/IP communications for a DB2 instance: v Ensure that TCP/IP is functional on the DB2 server. TCP/IP must also be functional on the DB2 client to establish a connection. v Identify either a Connection Service name and Connection Port, or just a Connection Port. Connection Service Name and Connection Port The service name is used to update the Service name (svcename) parameter in the database manager configuration file at the server. When a Connection Service name is specified, the services file must be updated with the same Service name, a port number, and the protocol. The Service name is arbitrary but must be unique within the services file. A sample value for the service name could be server1. If you are using DB2 Enterprise Server Edition in a partitioned format, ensure that the port number does not conflict with the port numbers used by the Fast Communications Manager (FCM). The Connection port must be unique within the services file. A sample value for the port number and protocol could be 3700/tcp. Connection Port The Service name (svcename) parameter in the database manager configuration file at the server can be updated with a port number. If this is the case, it is not necessary to update the services file. If you are using DB2 Enterprise Server Edition in a partitioned format, ensure that the port number does not conflict with the port numbers used by the Fast Communications Manager (FCM) or any other applications on the system. A sample value for the port number could be 3700. Most protocols are automatically detected and configured when you set up DB2 using the DB2 Setup wizard. Perform the current task if: v You deselected the TCP/IP communication protocol when you set up DB2 using the DB2 Setup wizard. v You added the TCP/IP communication protocol to your network after you set up DB2 using the DB2 Setup wizard. v The TCP/IP communication protocol was not detected by the DB2 Setup wizard. v You installed a DB2 product using the db2_install command or the payload file method. To configure TCP/IP communications for a DB2 instance: 1. Update the services file on the server.
147
2. Update the database manager configuration file on the server. 3. Set communication protocols for a DB2 instance
148
Part 3. After you install a DB2 Server product
149
150
Chapter 15. Verifying your installation

Verifying the installation of DB2 servers using First Steps (Linux and Windows)
You can verify that the DB2 server installation has completed successfully by accessing data from the SAMPLE database. You must have the Control Center and the First Steps component installed to perform this task. First Steps is listed as a getting started component in the feature selection window in the DB2 Setup wizard. It is installed as part of a Typical installation or can be selected when performing a Custom installation. The Control Center component is only available on Linux (x86 and AMD64/EM64T only) and Windows (x86 and AMD64/EM64T only). 1. On Linux, log on to the system as the instance owner. 2. Start First Steps: v On Windows operating systems, click Start and, select Programs -> IBM DB2 -> [DB2 Copy Name] -> Set-up Tools > First Steps v On Linux and Windows operating systems, you can start First Steps by typing the db2fs command. 3. You have the options to choose the type of database objects to create and the database location. You can choose the drive on which to create the SAMPLE database on Windows, and the directory in which to create the SAMPLE database on Linux. 4. This command can take a few minutes to process. When the SAMPLE database has been created, you will receive a completion message. Click OK. 5. Start the Control Center. On Windows, click Start and, select Programs -> IBM DB2 -> [DB2 Copy Name] -> General Administration Tools > Control Center. On Linux systems, type the db2cc command. 6. In the left pane of the Control Center screen, expand the object tree to view the SAMPLE database and SAMPLE database objects. Select the Tables object to view the SAMPLE database tables in the right pane of the Control Center screen. Right-click the table name staff and select Query. In the command editor window, click the run button to run the query and see the result set. After you have verified the installation, you can remove the SAMPLE database to free up disk space. However, keep the SAMPLE database if you plan to make use of the sample applications. Enter the db2 drop database sample command to drop the SAMPLE database. You can also use First Steps to check for product updates to ensure that you are aware of the available product updates and enhancements for DB2 products.
151
Verifying the installation using the command line processor (CLP)

You can verify the installation by creating the SAMPLE database and running SQL commands to retrieve sample data. Prerequisites v The SAMPLE database component, found in the features selection, must be installed on your system and is included in a typical installation. v You require a user with SYSADM authority. To 1. 2. 3. verify the installation: Log on to the system as a user with SYSADM authority. Start the database manager by entering the db2start command. Enter the db2sampl command to create the SAMPLE database.
This command can take a few minutes to process. There is no completion message; when the command prompt returns, the process is complete. The SAMPLE database is automatically cataloged with the database alias SAMPLE when it is created. 4. Connect to the SAMPLE database, retrieve a list of all the employees that work in department 20, and reset the database connection. Enter the following commands from the command line processor (CLP):
connect to sample "select * from staff where dept = 20" connect reset
The output should be similar to the following:

ID ---10 20 80 190 NAME DEPT JOB YEARS --------- ------ ----- -----Sanders 20 Mgr 7 Pernal 20 Sales 8 James 20 Clerk Sneider 20 Clerk 8 SALARY COMM -------- --------98357.50 78171.25 612.45 43504.60 128.20 34252.75 126.50
4 record(s) selected.
After you have verified the installation, you can remove the SAMPLE database to free up disk space. Enter the db2 drop database sample command to drop the SAMPLE database.
Verifying a partitioned database environment installation (Windows)

To verify that your DB2 server installation was successful, you will create a sample database and run SQL commands to retrieve sample data and to verify that the data has been distributed to all participating database partition servers. You have completed all of the installation steps. To create the SAMPLE database: 1. Log on to the primary computer (ServerA) as user with SYSADM authority. 2. Enter the db2sampl command to create the SAMPLE database. This command can take a few minutes to process. When the command prompt returns, the process is complete. The SAMPLE database is automatically cataloged with the database alias SAMPLE when it is created.
152
3. Start the database manager by entering the db2start command. 4. Enter the following DB2 commands from a DB2 command window to connect to the SAMPLE database, retrieve a list of all the employees that work in department 20:
db2 connect to sample db2 "select * from staff where dept = 20"
5. To verify that data has been distributed across database partition servers, enter the following commands from a DB2 command window:
db2 "select distinct dbpartitionnum(empno) from employee"
The output will list the database partitions used by the employee table. The specific output will depend on the number of database partitions in the database and the number of database partitions in the database partition group that is used by the table space where the employee table was created. After you have verified the installation, you can remove the SAMPLE database to free up disk space. However, it is useful to keep the sample database, if you plan to make use of the sample applications. Enter the db2 drop database sample command to drop the SAMPLE database.
Verifying a partitioned database server installation (Linux and UNIX)

Use the db2val tool to verify the core functions of a DB2 copy by validating installation files, instances, database creation, connections to that database, and the state of DPF environments. For details, see Validating your DB2 copy. The state of a DPF environment is only verified if there are at least 2 nodes. In addition, to verify that your DB2 server installation was successful, you will create a sample database and run SQL commands to retrieve sample data and to verify that the data has been distributed to all participating database partition servers. Before following these steps, make sure you have completed all of the installation steps. To create the SAMPLE database: 1. Log on to the primary computer (ServerA) as the instance-owning user. For this example, db2inst1 is the instance-owning user. 2. Enter the db2sampl command to create the SAMPLE database. By default, the sample database will be created in the instance-owners home directory. In our example /db2home/db2inst1/ is the instance owners home directory. The instance owners home directory is the default database path. This command can take a few minutes to process. There is no completion message; when the command prompt returns, the process is complete. The SAMPLE database is automatically cataloged with the database alias SAMPLE when it is created. 3. Start the database manager by entering the db2start command. 4. Enter the following DB2 commands from a DB2 command window to connect to the SAMPLE database, retrieve a list of all the employees that work in department 20:
db2 connect to sample db2 "select * from staff where dept = 20"
5. To verify that data has been distributed across database partition servers, enter the following commands from a DB2 command window:
153
db2 "select distinct dbpartitionnum(empno) from employee"
The output will list the database partitions used by the employee table. The specific output will depend on: v The number of database partitions in the database v The number of database partitions in the database partition group that is used by the table space where the employee table was created After you have verified the installation, you can remove the SAMPLE database to free up disk space. Enter the db2 drop database sample command to drop the SAMPLE database.
Directory structure for your installed DB2 database product (Windows)

When you install DB2 database products, you can specify a DB2 database product installation path or else use the default path. After installation, DB2 objects are created in these directories. Follow these steps to verify the DB2 product you have installed on Windows. 1. From a command prompt, type the regedit command. The Registry Editor window opens. 2. Expand HKEY_LOCAL_MACHINE > Software > IBM > DB2 The DB2 product you have installed will be displayed. The following table shows the location of DB2 objects after a default installation.
Table 23. DB2 objects and their locations DB2 Object DAS information Location v For Windows XP and Windows 2003 operating systems: C:\Documents and Settings\All Users\Application Data\IBM\DB2\DB2COPY1 v For Windows Vista and later operating systems: C:\ProgramData\IBM\DB2\ DB2COPY1 Database configuration file SQLDBCON Database directory Contains files needed for: v buffer pool information v history information v log control files v storage path information v table space information Database manager configuration file db2systm v For Windows XP and Windows 2003 operating systems: C:\Documents and Settings\All Users\Application Data\IBM\DB2\DB2COPY1\DB2 v For Windows Vista and later operating systems: C:\ProgramData\IBM\DB2\ DB2COPY1\DB2 DB2 commands C:\Program Files\IBM\SQLLIB\BIN C:\DB2\NODE0000\SQL00001 C:\DB2\NODE0000\SQL00001
154
Table 23. DB2 objects and their locations (continued) DB2 Object DB2 error messages file db2diag log files Location v For Windows XP and Windows 2003 operating systems: C:\Documents and Settings\All Users\Application Data\IBM\DB2\DB2COPY1\DB2 v For Windows Vista and later operating systems: C:\ProgramData\IBM\DB2\ DB2COPY1\DB2 DB2 installation path Directory for event monitor data Directory for transaction log files Installation log file C:\Program Files\IBM\SQLLIB C:\DB2\NODE0000\SQL00001\DB2EVENT C:\DB2\NODE0000\SQL00001\SQLOGDIR v For Windows XP and Windows 2003 operating systems: C:\Documents and Settings\Administrator\My Documents\DB2LOG v For Windows Vista and later operating systems: C:\Users\USER_NAME\ Documents\DB2LOG Instance v For Windows XP and Windows 2003 operating systems: C:\Documents and Settings\All Users\Application Data\IBM\DB2\DB2COPY1\DB2 v For Windows Vista and later operating systems: C:\ProgramData\IBM\DB2\ DB2COPY1\DB2 Instance information v For Windows XP and Windows 2003 operating systems: C:\Documents and Settings\All Users\Application Data\IBM\DB2\DB2COPY1\DB2 v For Windows Vista and later operating systems: C:\ProgramData\IBM\DB2\ DB2COPY1\DB2 Node directory v For Windows XP and Windows 2003 operating systems: C:\Documents and Settings\All Users\Application Data\IBM\DB2\DB2COPY1\DB2\ SQLNODIR v For Windows Vista and later operating systems: C:\ProgramData\IBM\DB2\ DB2COPY1\DB2\SQLNODIR Local database directory for the instance called DB2 Partitioned database environment file db2nodes.cfg C:\DB2\NODE0000\SQLDBDIR v For Windows XP and Windows 2003 operating systems: C:\Documents and Settings\All Users\Application Data\IBM\DB2\DB2COPY1\DB2 v For Windows Vista and later operating systems: C:\ProgramData\IBM\DB2\ DB2COPY1\DB2
155
Table 23. DB2 objects and their locations (continued) DB2 Object System database directory Location v For Windows XP and Windows 2003 operating systems: C:\Documents and Settings\All Users\Application Data\IBM\DB2\DB2COPY1\DB2\ SQLDBDIR v For Windows Vista and later operating systems: C:\ProgramData\IBM\DB2\ DB2COPY1\DB2\SQLDBDIR
The following figures illustrate an example of the DB2 directory structure after installation on Windows XP or Windows 2003 operating systems using the default options. In these figures, there are two instances, DB2 and MYINST. The directories DB2 and MYINST under the local disk C: will only appear if a database has been created under the appropriate instance.
156
Directory structure - instance information
1. 2. 3. 4. 5.
Contains the Contains the Contains the Contains the Contains the MYINST.
databases created under the information for the DAS. instance information for the instance information for the databases created under the
C: drive for the instance named DB2. instance named DB2. instance named MYINST. C: drive for the instance named
157
Directory structure - directory information
1. 2. 3. 4. 5.
System database directory Node directory The db2diag log files DB2 error messages. The db2nodes.cfg file is used in a partitioned database environment. Database manager configuration file
158
Directory structure - local directory information
1. Local database directory for the instance DB2 2. Local database directory for the instance MYINST 3. Database configuration file
Directory structure - installation log file location
Directory structure for your installed DB2 database product (Linux)

During a root installation, you can specify where the subdirectories and files for the DB2 database product will be created. For non-root installations, you cannot choose where DB2 products are installed; you must use the default locations.
159
Note: For non-root installations, all DB2 files (program files and instance files) are located in or beneath the $HOME/sqllib directory, where $HOME represents the non-root users home directory. After installation, the DB2 objects are created in various directories. The following table shows the location of DB2 objects after a default root installation.
Table 24. Location of DB2 objects after a default root installation DB2 Object DAS home directory DAS information Database configuration file SQLDBCON Database directory Contains files needed for: v buffer pool information v history information v log control files v storage path information v table space information Database manager configuration file db2systm DB2 commands DB2 error messages file (db2diag log file) DB2 installation path Directory for event monitor data Directory for transaction log files Installation log file db2install.history Instance home directory Instance information Local database directory for the instance Partitioned database environment file db2nodes.cfg System database directory home/db2inst1/sqllib /opt/IBM/db2/V9.7/bin home/db2inst1/sqllib/db2dump default is /opt/IBM/db2/V9.7 home/db2inst1/db2inst1/NODE0000/ SQL00001/db2event home/db2inst1/db2inst1/NODE0000/ SQL00001/SQLOGDIR /opt/IBM/db2/V9.7/install/logs home/db2inst1 home/db2inst1/sqllib home/db2inst1/db2inst1/NODE0000/ sqldbdir home/db2inst1/sqllib home/db2inst1/sqllib/sqldbdir Location home/dasusr1 home/dasusr1/das home/db2inst1/db2inst1/NODE0000/ SQL00001 home/db2inst1/db2inst1/NODE0000/ SQL00001
The following figures illustrate an example of the DB2 directory structure after a root installation. In these examples, there are two instances, db2inst1 and db2inst2.
160
Directory structure - default local database directory information for the DB2 instance db2inst1
1. Local database directories. 2. Database configuration file
161
Directory structure - directory information for the DB2 instance db2inst1
1. 2. 3. 4.
The db2diag log files in this directory logs DB2 error messages. System database directory The db2nodes.cfg file is used in a partitioned database environment. Database manager configuration file
The dasusr1 directory contains the DB2 administration server (DAS) configuration files and the symbolic links to DB2 core files.
162
Directory structure - install log file location
This figure illustrates the location of your install log file. If there were multiple installations under the same installation path, the db2install.history file will be indexed as db2install.history.n where n represents a four digit number, for example, 0000, or 0001. The DB2 installation directory /opt/IBM/db2/V9.7 contains the installed DB2 files.
163
164

Validating your DB2 copy
The db2val command ensures that your DB2 copy is functioning properly. The db2val tool verifies the core function of a DB2 copy by validating installation files, instances, database creation, connections to that database, and the state of DPF environments. This validation can be helpful if you have manually deployed a DB2 copy on Linux and UNIX operating systems using tar.gz files. The db2val command can quickly ensure that all the configuration has been correctly done and ensure that the DB2 copy is what you expect it to be. You can specify instances and databases or you can run db2val against all of the instances. The db2val command can be found in the DB2 install path\bin and sqllib/bin directories. For example, to validate all the instances for the DB2 copy, run the following command:
db2val -a
For complete db2val command details and further example, refer to the db2val DB2 copy validation tool command topic.
Listing DB2 database products installed on your system (Linux and UNIX)
On supported Linux and UNIX operating systems, the db2ls command lists the DB2 database products and features installed on your system, including the DB2 Version 9.7 HTML documentation. Before you begin At least one DB2 Version 9 (or later) database product must already be installed by a root user for a symbolic link to the db2ls command to be available in the /usr/local/bin directory. About this task With the ability to install multiple copies of DB2 database products on your system and the flexibility to install DB2 database products and features in the path of your choice, you need a tool to help you keep track of what is installed and where it is installed. On supported Linux and UNIX operating systems, the db2ls command lists the DB2 products and features installed on your system, including the DB2 HTML documentation. The db2ls command can be found both in the installation media and in a DB2 install copy on the system. The db2ls command can be run from either location. The db2ls command can be run from the installation media for all products except IBM Data Server Driver Package. The db2ls command can be used to list: v Where DB2 database products are installed on your system and list the DB2 database product level
165
v All or specific DB2 database products and features in a particular installation path Restrictions The output that the db2ls command lists is different depending on the ID used: v When the db2ls command is run with root authority, only root DB2 installations are queried. v When the db2ls command is run with a non-root ID, root DB2 installations and the non-root installation owned by matching non-root ID are queried. DB2 installations owned by other non-root IDs are not queried. The db2ls command is the only method to query a DB2 database product. You cannot query DB2 database products using Linux or UNIX operating system native utilities, such as pkginfo, rpm, SMIT, or swlist. Any existing scripts containing a native installation utility that you use to query and interface with DB2 installations must change. You cannot use the db2ls command on Windows operating systems. Procedure v To list the path where DB2 database products are installed on your system and list the DB2 database product level, enter:
db2ls
The command lists the following information for each DB2 database product installed on your system: Installation path Level Fix pack Special Install Number. This column is used by IBM DB2 Support. Installation date. This column shows when the DB2 database product was last modified. Installer UID. This column shows the UID with which the DB2 database product was installed. v To list information about DB2 database products or features in a particular installation path the q parameter must be specified:
db2ls -q -p -b baseInstallDirectory
where: q specifies that you are querying a product or feature. This parameter is mandatory. If a DB2 Version 8 product is queried, a blank value is returned. p specifies that the listing displays products rather than listing the features. b specifies the installation directory of the product or feature. This parameter is mandatory if you are not running the command from the installation directory. Results Depending on the parameters provided, the command lists the following information: v Installation path. This is specified only once, not for each feature. v The following information is displayed:
166
Response file ID for the installed feature, or if the p option is specified, the response file ID for the installed product. For example, ENTERPRISE_SERVER_EDITION. Feature name, or if the p option is specified, product name. Product version, release, modification level, fix pack level (VRMF). For example, 9.5.0.0 Fix pack, if applicable. For example, if Fix Pack 1 is installed, the value displayed is 1. This includes interim fix packs, such as Fix Pack 1a. v If any of the products VRMF information do not match, a warning message displays at the end of the output listing. The message suggests the fix pack to apply.
First Steps interface

First Steps is a DB2 setup tool which introduces which directs you to the information required to accomplish your tasks after you install DB2 database products. From First Steps you can: v Create the sample database or your own database. v Check for product updates. Product updates Ensure that you are aware of the available product updates and enhancements for DB2 database products. With the update service you can view a list of available DB2 database product updates, and learn details about DB2 database product updates. Running First Steps You can manually start First Steps using the db2fs command:
$ db2fs
On Linux and UNIX operating systems The db2fs command is located in the INSTHOME/sqllib/bin directory, where INSTHOME is the instance home directory. You need SYSADM authority to run this command. Alternatively, on Linux operating systems you can start First Steps from Main Menu by selecting IBM DB2 First Steps. On Windows operating system The db2fs command is located in the DB2DIR\bin directory, where DB2DIR is set to the location you specified during the DB2 installation. Alternatively, you can start First Steps from the Start menu by selecting Programs IBM DB2 [DB2 Copy Name] Set Up Tools First Steps or from the DB2 database product folder on the desktop. To make full use of the resources provided by First Steps, you must have an internet connection and access to the online DB2 Information Center.
167
Deleting a Firefox browser profile

After you have run the DB2 Setup wizard or DB2 First Steps, you might want to delete the browser profile to prevent JavaScript from running automatically when visiting other Web pages with this profile. About this task If you use this profile to view other Web pages that have JavaScript, the JavaScript will run automatically without warnings. If you use Firefox as your Web browser, a browser profile is created when you run DB2 First Steps. If you agree, a browser profile named DB2_FIRSTSTEPS is created. Procedure To delete a Firefox browser profile: 1. If any Firefox browsers are open, close them. 2. Open the Firefox Profile Manager. v On Windows a. Open the Windows Start menu and select Run... b. Type firefox.exe -profilemanager and click OK. The Firefox - Choose User Profile dialog opens. v On Linux and UNIX a. Open a command prompt. b. Switch to the Firefox directory. c. Start Firefox with the -profilemanager switch. For example:
./firefox -profilemanager
3. Select the DB2_FIRSTSTEPS profile. 4. Click Delete Profile... 5. Click Exit to close the Firefox - Choose User Profile dialog. What to do next For further information about Firefox profiles, visit www.mozilla.org/support/ firefox/profile
Adding your user ID to the DB2ADMNS and DB2USERS user groups (Windows)
After successfully completing a DB2 installation, you now have to add users to the DB2ADMNS or the DB2USERS groups for users that need to run local DB2 applications and tools on the machine. The DB2 installer creates two new groups. You can either use a new name or accept the default names. The default group names are DB2ADMNS and DB2USERS. Prerequisites v You must have installed a DB2 product. v You must have selected the Enable operating system security check box on the Enable operating system security for DB2 object panel during the installation of your DB2 product.
168
To add users to the appropriate group: 1. Click Start and select Run. 2. Type lusrmgr.msc and click OK. 3. Select Local Users and Groups. 4. Select Users. 5. Select the user you want to add. 6. Click Properties. 7. 8. 9. 10. Click the Member Of tab. Click Add. Select the appropriate group. Click OK.
If you did the install and chose not to enable the new security feature you can still do so post-install by running the db2extsec.exe command. Adding a user to a group takes effect the first time the user logs on after the user has been added. For example, if you add you user ID to the DB2ADMNS group, you need to log out and then log in again for this change to take effect.
Updating your 32-bit DB2 instances to 64-bit instances (Windows)

If you have more than one 32-bit DB2 Version 9.7 copy on your system, you can convert them to 64-bit instances. Restrictions v DB2 32-bit and 64-bit instances cannot coexist on the same system. v You cannot install a 64-bit DB2 Version 9.7 copy on a system with multiple 32-bit DB2 Version 9.7 copies. v You cannot upgrade directly from a 32-bit pre-Version 9.7 DB2 copy to a 64-bit DB2 Version 9.7 copy. You can upgrade from a 32-bit pre-Version 9.7 DB2 copy to a 32-bit Version 9.7 DB2 copy then update from DB2 Version 9.7 32-bit to DB2 Version 9.7 64-bit. Refer to the Upgrading DB2 32-bit servers to 64-bit systems topic. Procedure 1. Move all your 32-bit instances over to one DB2 copy using the db2iupdt command. 2. Uninstall the 32-bit DB2 copies, except for the one where you have moved all your 32-bit instances over to. 3. Install DB2 Version 9.7 64-bit which will upgrade your 32-bit DB2 Version 9.7 instances to 64-bit DB2 Version 9.7 instances.
Setting up notification and contact lists

For your DB2 product to contact you or others regarding the status of your databases, set up notification and contact lists. If you did not do this during the DB2 installation, you can manually set up these lists. To set up notification and contact lists: 1. Log on as the instance owner or a user with SYSADM authority. 2. If the SMTP server was not specified during the installation process, you can configure it manually using the following command:
169
db2 update admin cfg using smtp_server host1
where host1 represents the TCP/IP host name for the SMTP server used for e-mail notification. You can also update this information using the Create Database with Automatic Maintenance wizard, or the Troubleshoot Alert Notification wizard in the Health Center. 3. If you want the contact information to be located on a remote DB2 administration server (DAS), you can specify the contact_host parameter using the following command:
db2 update admin cfg using contact_host host2
where host2 represents the TCP/IP host name where the DAS is running. If the contact_host parameter is not specified, the DAS assumes the contact information is local. 4. Turn on the scheduler using the following command:
db2 update admin cfg using sched_enable on
5. For these changes to take effect, restart the DAS use the following commands:
db2admin stop db2admin start
6. From either the Task Center or the Health Center, click the Contacts icon in the Task bar. Select System name, then click Add Contact. Type in contact information and then click OK.
Changing the default DB2 and default IBM database client interface copy after installation (Windows)
The db2swtch command can be run from any DB2 copy, IBM data server driver copy, Version 9 or greater. Also, the options -db2 and -client can only be used in Version 9.5 or later. Prerequisite: Multiple DB2 copies (Version 9 or later) or multiple IBM database client interface copies (Version 9.5 or later) are installed on the same computer.
DB2COPY1
-ESE -WSE -...
DB2COPY1 is the default name of the DB2 copy that is the first installation of a DB2 product on your machine. This same name is part of the instance directory where the database manager code and user data is stored. If there are further DB2 copies installed on your machine, they will receive default names DB2COPY2, DB2COPY3, and so on.
IBMDBCL1
DSDRIVER
170
IBMDBCL1 is the default name of the IBM Data Server Driver Package (DSDRIVER) that is the first installation of a driver on you machine. If there are further DSDRIVER products installed on your machine, they will receive default names: IBMDBCL2, IBMDBCL3, and so on. Changing the default DB2 copy after installation (Windows) To change the default DB2 copy using the Default DB2 and Database Client Interface Selection wizard: 1. Open the Default DB2 and Database Client Interface Selection wizard: From a command window, run the db2swtch command without any additional parameters. Or, from the Start Menu, select Programs > IBM DB2 > (DB2 copy name) >Set-up Tools ->Default DB2 and Database Client Interface Selection wizard. The Default DB2 and Database Client Interface Selection wizard opens. 2. On the Configuration page, select the copy type you want to work with (Default DB2 Copy). 3. On the default DB2 copy page, select the copy that you want to make the default so that it is highlighted and click Next to make it the default DB2 copy. 4. On the summary page, the wizard indicates the result of the operation. 5. Run the dasupdt command to move the DB2 Administration Server (DAS) to the new default copy. This procedure switches the current default DB2 copy to the new default DB2 copy and makes the necessary changes to the registry. To access and use the new default DB2 copy, after you have moved the DAS to the new default DB2 copy, open a new command window. You can still access the original default DB2 copy by using the shortcuts in the Start menu for the original default DB2 copy. To change the default DB2 copy using the command line, you can use db2swtch command: v The db2swtch -d <new default copy name> command is used to change both the default DB2 copy and the default IBM database client interface copy to the new default copy name. v The db2swtch -db2 -d <new default copy name> command is used to change the default DB2 copy to the new default copy name. This procedure removes registration of the current default DB2 copy and registers the specified DB2 copy as the default DB2 copy. It also makes the necessary changes to the registry, to the environment variables, to the ODBC and CLI drivers and the .NET data provider (when the change also makes the DB2 copy the default IBM database client interface copy), to the WMI registration, and to various other objects, and moves the DAS to the specified default DB2 copy. To access and use the new default DB2 copy, open a new command window. Differences between Version 9.1 and Version 9.5 when changing the default DB2 copy In Version 9.1, after you install the first DB2 copy, it becomes the default DB2 copy.
171
DB2 Version 9.1

Default DB2 copy
DB2COPY1
-ESE -WSE -...
Any database actions requiring the use of the DB2 server code will access the code and the data that is from the default DB2 copy. In Version 9.1, over time you can install other Version 9.1 or later DB2 copies.
DB2 Version 9.1

Default DB2 copy
DB2COPY1
-ESE -WSE -...
DB2COPY2
-ESE -CLIENT -...
DB2COPY3
-WSE -QP -...
172
However, only one DB2 copy is the default DB2 copy. If not explicitly referenced, requested database actions will use the code and data that is from the default DB2 copy. If you want to use the code and data from the other DB2 copies (such as DB2COPY2 or DB2COPY3 in this example) and not from the default DB2 copy (DB2COPY1), then you must explicitly reference the code and data from the other DB2 copies. In Version 9.5, after you install the first DB2 copy, it becomes the default DB2 copy and the default IBM database client interface copy.
DB2 Version 9.5

DB2COPY1
-ESE -WSE -...
Legend
In Version 9.5, over time you can install other Version 9.5 or later DB2 copies.
173
DB2 Version 9.5

DB2COPY1
-ESE -WSE -...
DB2COPY2
-ESE -CLIENT -...
DB2COPY3
-WSE -QP -...
Legend
However, only one DB2 copy is the default DB2 copy or IBM Data Server driver copy. In this case, following the installation of two additional DB2 copies, both defaults remain associated with the original DB2 copy (DB2COPY1). In Version 9.5, when you have installed more than one DB2 copy, you can choose to have one DB2 copy as the default DB2 copy and a different DB2 copy as the default IBM database client interface copy.
174
DB2 Version 9.5

Default DB2 copy
DB2COPY1
-ESE -WSE -...
Default IBM database client interface copy

DB2COPY2
-ESE -CLIENT -...
DB2COPY3
-WSE -QP -...
Legend
If not requiring the code associated with the default IBM database client interface copy (DB2COPY2), then applications or users requiring client interface code must explicitly reference the code that is from one of the other two DB2 copies (DB2COPY1 and DB2COPY3). If not explicitly referenced, the client interface code that is from the default IBM database client interface copy is used.
175
Changing the default IBM database client interface copy after installation (Windows) To change the default IBM database client interface copy using the Default DB2 and Database Client Interface Selection wizard: 1. Open the Default DB2 and Database Client Interface Selection wizard: From the Start Menu, select Programs > IBM DB2 > (DB2 copy name) >Set-up Tools ->Default DB2 and Database Client Interface Selection wizard. Or go to the installdir\bin and run thedb2swtch command. The Default DB2 and Database Client Interface Selection wizard open. 2. On the Configuration page, select the copy type you want to work with (Default IBM Database Client Interface Copy ). 3. On the default IBM database client interface copy page, select the DB2 copy or the IBM data server driver copy that you want to make the default so that it is highlighted and click Next to make it the default IBM database client interface copy. (Recall that the code for the IBM database client interface copy was included with the DB2 copy.) 4. On the summary page, the wizard indicates the result of the operation. This procedure switches the current default IBM database client interface copy to the new IBM data server driver copy making it the new default IBM database client interface copy. The procedure also makes the necessary changes to the registry. After the switching, the default ODBC and CLI drivers and the .NET data provider will point to the new copy. All the other ODBC drivers with copy name appended can also be accessed. To change the default IBM database client interface copy using the command line, you can use db2swtch command: v The db2swtch -d <new default copy name> command is used to change both the default DB2 copy and the default IBM database client interface copy to the new default copy name. v The db2swtch -client -d <new default copy name> command is used to change the default IBM database client interface copy to the new default copy name. This procedure unregisters the current default IBM database client interface copy and registers the specified copy as the default IBM database client interface copy. Changing the default IBM database client interface copy In an environment with no other DB2 products installed, you install the IBM Data Server Driver Package (DSDRIVER).
176
DB2 Version 9.5

IBMDBCL1 DSDRIVER
Legend
Default IBM database client interface copy DSDRIVER = IBM Data Server Driver for ODBC, CLI, and .NET
By default, the name given to the DSDRIVER is IBMDBCL1. With no other DB2 server products (such as Enterprise Server Edition, or Workstation Server Edition) or other DSDRIVERs, this DSDRIVER is the default IBM database client interface copy. Any database actions requiring the use of application requestor code will access the code and data that is from the default IBM database client interface copy by default. Over time, you can install DSDRIVERs in other IBM data server driver copies. However, only one IBM data server driver copy (or DB2 copy that is not shown in this example) is the default IBM database client interface copy.
177
DB2 Version 9.5

IBMDBCL1 DSDRIVER
IBMDBCL2 DSDRIVER
IBMDBCL3 DSDRIVER
Legend
DSDRIVER = IBM Data Server Driver for ODBC, CLI, and .NET
If not explicitly referenced, application requests will use the code and data that is from the default IBM database client interface copy. If you want to use the code from the other DSDRIVERs (such as IBMDBCL2 or IBMDBCL3 in the example) and not from the default IBM database client interface copy (IBMDBCL1), then you must explicitly reference the code and data from the other DSDRIVERs. Over time, you can have several DSDRIVERs installed. Only one IBM database client interface copy is the default. At some point you might decide to switch from one copy and make another copy the default IBM database client interface copy.
178
DB2 Version 9.5

IBMDBCL1 DSDRIVER Make IBMDBCL3 the default IBM database client interface copy?
IBMDBCL2 DSDRIVER

IBMDBCL3 DSDRIVER
Yes
Legend
Use the switch default DB2 copy and database client interface copy command (db2swtch) to choose and set the new default IBM database client interface copy. Using db2swtch with no arguments starts the Default DB2 and IBM Database Client Interface Selection wizard. When both IBM database client interface copies and DB2 copies are on your machine Over time you can have several DSDRIVERs and several DB2 copies installed on your machine. In the scenario presented here, IBMDBCL1 is the default IBM database client interface copy and DB2COPY1 is the default DB2 copy.
179
DB2 Version 9.5

IBMDBCL1 DSDRIVER
Default DB2 copy

DB2COPY1
-ESE -WSE -...
IBMDBCL2 DSDRIVER
DB2COPY2
-ESE -CLIENT -...
Legend
Default DB2 copy Default IBM database client interface copy Option for switching default IBM database client interface copy Option for switching default DB2 copy
If you want to change either or both defaults, use the db2swtch command with no arguments (Windows only) to start the Default DB2 and IBM Database Client Interface Selection wizard. The wizard will show all possible candidates when choosing a new default. You can also use the db2swtch command with -client or -db2 option to do the switching. When choosing a new default DB2 copy, in this scenario there is only one other choice: DBCOPY2. When choosing a new default IBM database client interface copy, in this scenario there are three choices: IBMDBCL2, DB2COPY1, and DB2COPY2. (Recall that DB2 copies have the needed database client interface code to be declare the default IBM database client interface copy.)
IBM data server client connectivity using multiple copies

When using multiple DB2 copies of DB2 database products or multiple data server driver copies, various options are available for applications to access the DB2 databases. Existing applications will continue to function properly. Restrictions Only one copy can be used within the same process for each of the following modes of connecting to databases.
180
While this topic mainly deals with issues on Windows operating systems, on Linux and UNIX operating systems, you also cannot access instances associated with multiple DB2 copies within the same process. Procedure Review the considerations associated with each of the following methods to connect to DB2 databases: v OLE DB To use a DB2 copy other than the default, in the connection string, specify the IBMDADB driver name for this DB2 copy, which will be of the format: IBMDADB2.$DB2_COPY_NAME. Some applications might not have the ability to change the connection strings without recompiling, therefore these applications will only work with the default DB2 copy. If an application uses the default program id, ibmdadb2, or the default clsid, it will always use the default DB2 copy. Specifically, you will need to change the value of "provider=IBMDADB2" in the connection string. For example, if the DB2 copy that you want to use is called MY_COPY, you would specify "provider=IBMDADB2.MY_COPY" in the connection string. In case you must explicitly specify a GUID during installation, a response file keyword, OLEDB_GUID, is used to do this and allows you to enter your own GUID. Otherwise, the generated ID is used, as listed in the DB2 installation log. Note: If you continue to use the IBMDADB2 provider name, then you will only be able to access data sources from the default DB2 copy. v IBM Data Server Driver for ODBC and CLI The IBM Data Server Driver for ODBC and CLI contains the copy name as part of the driver name. The default driver, IBM DB2 ODBC DRIVER, is set to the default IBM database client interface copy. The name of the driver for each installation is IBM DB2 ODBC DRIVER - Copy Name. Note: You can use only one copy in the same ODBC application at the same time Even when you set up a Data source with the default ODBC driver, it will be configured to access the DB2 copy that was the default at the time the Data source was cataloged. If you move or upgrade instances from one copy to another, you will re-configure the associated Data sources. IBM Data Server Provider for .NET The IBM Data Server Provider for .NET is not accessed by the DB2 database product identified by the copy name. Instead, depending on the version of the provider that the application requires, it finds that version and uses it using the standard methods. JDBC or SQLJ JDBC uses the current version of the driver in the classpath. The Type 2 JDBC driver uses the native DLL. By default, the classpath is configured to point to the default DB2 copy. Running db2envar.bat from the DB2 copy you want to use will update your PATH and CLASSPATH settings for this copy. MMC Snap-in The MMC Snap-in starts the DB2 Control Center for the Default DB2 copy. WMI
v v
181
WMI does not support multiple DB2 copies. You can register only one copy of WMI at a time. To register WMI, follow this process: Unregister the WMI Schema extensions. Unregister the COM object. Register the new COM object. Use MOFCOMP to extend the WMI schema. WMI is not registered during DB2 installation. You must complete the two registration steps. WMI is a selectable feature in DB2 database products, in DB2 Personal Edition and above. You must select this feature during a custom installation. It is not included in a typical installation. v CLI applications CLI applications that dynamically load the IBM data server client libraries should use the LoadLibraryEx API with the LOAD_WITH_ALTERED_SEARCH_PATH option, instead of the LoadLibrary option. If you do not use the LoadLibraryEx API with the LOAD_WITH_ALTERED_SEARCH_PATH option, specify db2app.dll in the Path by running db2envar.bat from the bin directory of the DB2 copy that you want to use. For applications that link using db2apie.lib, to use a different DB2 copy, you can use the /delayload option in your link command to delay load db2app.dll and call the db2SelectDB2Copy API before any DB2 calls. v DB2 System Tray To reduce the number of system tray executables running on the system, by default any items in the system tray that are running in the previous default DB2 copy when the default copy is changed are disabled.
Working with existing DB2 copies

You can install and run multiple DB2 copies on the same computer. Each DB2 copy can either be at the same DB2 database product level or at a different DB2 database product level. Restrictions v On Linux and UNIX, non-root installations allow only one DB2 copy for each valid non-root user. v On Windows, no other DB2 database product can be installed in the same path if either of the following products is already installed: IBM Data Server Runtime Client IBM Data Server Driver Package DB2 Information Center Procedure 1. When you start the DB2 Launchpad, it will display the available products that you can install. You can install a new DB2 copy or work with an existing DB2 copy. Note: Add-on products are always installed using the Work with Existing option. 2. Click Work with Existing. The Work with Existing window opens and displays the existing DB2 copies on your system and the possible operations that can be performed. Possible operations include:
182
Install Add new function Update (Windows only). Use this option to apply fix packs. Upgrade (Windows only). Use this option to upgrade your DB2 database product to a new release. v Not available v v v v
Checking for DB2 updates

Check for product updates to ensure that you are aware of the available product updates and enhancements for DB2 products. About this task During DB2 product installation, the update service is enabled by default. The update service allows you to stay informed of product updates such as: v Messages about releases and updates of the DB2 products. v Availability of technical materials such as tutorials, Web cast, and white papers. v IBM Marketing activities pertinent to your area of interest. You can access product updates in any of the following ways: v Using the command line v Using First Steps v On Linux operating systems, using the Main Menu. v On Windows operating systems, if the DB2 product was installed without elevated privileges, the update service is disabled. Restrictions v This update service requires an Internet connection. v On Windows operating systems, using the shortcuts in the Start menu. Procedure Access DB2 product updates and enhancements using one of the following ways: v Using the command line, enter:
db2updserv
v Using First Steps: You can start First Steps by typing the db2fs command. On Windows operating systems, click Start and, select Programs -> IBM DB2 -> [DB2 Copy Name] -> Set-up Tools -> First Steps Click the Start Check for Product Updates button. v On Windows operating systems, using the shortcuts in the Start menu, click Start and, select Programs -> IBM DB2 -> [DB2 Copy Name] -> Information -> Check for DB2 Updates. v On Linux operating systems, click Main Menu and, select IBM DB2 -> Check for DB2 Updates Results
183
With this update service you can view a list of available DB2 product updates, and learn details about DB2 product updates.
Main menu entries for DB2 tools (Linux)

After installation, you can add several DB2 tools to the Main menu. On Linux operating systems, the following DB2 tools can be added to the Main menu: v v v v v v v Check for DB2 Updates Command Line Processor (CLP) Command Line Processor Plus (CLPPlus) Configuration Assistant Control Center First Steps Query Patroller.
These DB2 tools can be added to the main menu automatically or manually. Main menu entries are created automatically when any of the following DB2 commands are run: v db2icrt v db2iupdt v db2nrcfg v db2nrupdt. The db2icrt and db2iupdt commands must be run by root. The db2nrcfg and db2nrupdt are for non-root install and are run by the instance owner. To see the menu entries you might need to restart the desktop. The main menu entries are automatically removed when either of the following commands are run: v db2_deinstall (only removes the menu entries for the DB2 non-root instance when the non-root installation is removed) v db2idrop. In addition, you can manually create or remove main menu entries by running the following commands: v db2addicons to add menu entries v db2rmicons to remove menu entries. Before running the db2addicons command, the DB2 instance environment must be set for the current user. The instance environment can be setup with: Instance_HOME/sqllib/db2profile (for Bourne shell and Korn shell users), or Instance_HOME/sqllib/db2chsrc (for C shell users), where Instance_HOME is the instance owners home directory.
184
Applying fix packs

It is recommended that you keep your DB2 database environment running at the latest fix pack level to ensure problem-free operation. To install a fix pack successfully, perform all of the necessary preinstallation and post-installation tasks. About this task A DB2 fix pack contains updates and fixes for problems (Authorized Program Analysis Reports, or APARs) found during testing at IBM, as well as fixes for problems reported by customers. The APARLIST.TXT file describes the fixes contained in each fix pack and it is available for download at ftp:// ftp.software.ibm.com/ps/products/db2/fixes/english-us/aparlist/. Fix packs are cumulative. This means that the latest fix pack for any given version of DB2 contains all of the updates from previous fix packs for the same version of DB2. The fix pack images available are: v A single server image. The single server image contains the new and updated code required for all DB2 database server products and the IBM Data Server Client. If more than one DB2 database server product is installed in a single location, the DB2 database server fix pack applies maintenance code updates to all the installed DB2 database server products. The Data Server Client fix pack is contained within the one DB2 database server fix pack (namely the fix pack that can service any one of the following database server products: DB2 Enterprise Server Edition, DB2 Workgroup Server Edition, DB2 Express Edition, DB2 Personal Edition, DB2 Connect Enterprise Edition, DB2 Connect Application Server Edition, DB2 Connect Unlimited Edition for zSeries, and DB2 Connect Unlimited Edition for i5/OS). You can use the DB2 database server fix pack to upgrade a Data Server Client. A single server image can also be used to install any of the DB2 database server products, at a particular fix pack level, with a DB2 try and buy license by default. v A fix pack for each of the other DB2 database products. Use this fix pack only if you only have non-server database products or add-on products installed. For example, IBM Data Server Runtime Client or DB2 Query Patroller. Do not use this type of fix pack if the installed DB2 database products are only DB2 database server products or a Data Server Client. Instead, use the single server image fix pack. For Windows platforms, if you have more than one DB2 database product (which includes at least one product that is not a Data Server Client or a DB2 database server) installed in a single DB2 copy, you must download and uncompress all of the corresponding product-specific fix packs before starting the fix pack installation process. v A universal fix pack. The universal fix pack services installations where more than one DB2 database product has been installed. The universal fix pack is not needed if the installed DB2 database products are only DB2 database server products or a Data Server Client. In this case, the single server image fix pack should be used.
185
On Linux or UNIX operating systems, if national languages have been installed, you also require a separate national language fix pack. The national language fix pack can not be installed alone. A universal or product-specific fix pack must be applied at the same time and they must both be at the same fix pack level. For example, if you are applying a universal fix pack to non-English DB2 database products on Linux or UNIX, you must apply both the universal fix pack and the national language fix pack to update the DB2 database products. Restrictions v A DB2 Version 9.7 fix pack can only be applied to DB2 Version 9.7 general availability (GA) or DB2 Version 9.7 fix pack copies. v All DB2 instances, DAS, and applications related to the DB2 copy being updated must be stopped before installing a fix pack. v In a partitioned database environment, prior to installing the fix pack, you must stop the database manager on all database partition servers. You must install the fix pack on the instance-owning database partition server and all other database partition servers. All computers participating in the instance must be updated to the same fix pack level. v On Linux or UNIX operating systems: If you have DB2 database products on a Network File System (NFS), you must ensure the following are stopped completely before installing the fix pack: all instances, the DB2 administration server (DAS), interprocess communications (IPC), and applications on other machines using the same NFS mounted installation. If the system commands fuser or lsof are not available, the installFixPack command cannot detect loaded DB2 files. You must ensure no DB2 files are loaded and provide an override option to install the fix pack. On UNIX, the fuser command is required to check for loaded files. On Linux, either the fuser command or lsof command is required. For details on the override option, see the installFixPack command. v On client applications, after a fix pack has been applied, to perform autobind of applications, the user must have bind authority. v Installation of a DB2 fix pack will not service IBM Data Studio Administration Console or IBM Data Studio. Procedure To 1. 2. 3. 4. 5. install a fix pack: Check fix pack prerequisites. Perform the necessary tasks prior to installing a fix pack. Choose a fix pack installation method and install the fix pack. Perform the necessary tasks after installing the fix pack. Apply the appropriate DB2 database product license. If a previously licensed copy of a DB2 server product does not already exist on the machine, a single server fix pack image can be used to install any of the DB2 database server products. In this case, the DB2 database product installed is treated as a try and buy license, and will stop working after a 90 day trial period unless you upgrade the try and buy license.
What to do next
186
Check the log file for any post-installation steps, or error messages and recommended actions. For non-root installations on Linux or UNIX, root-based features (such as High Availability and operating system-based authentication) can be enabled using the db2rfe command. If root-based features were enabled after installing your DB2 database product, you must rerun the db2rfe command each time a fix pack is applied in order to re-enable those features. For details, see the non-root related links below. If you have multiple DB2 copies on the same system, those copies can be at different version and fix pack levels. If you want to apply a fix pack to one or more DB2 copies, you must install the fix pack on those DB2 copies one by one.
Applying fix packs to a non-root installation

The task of applying fix packs to a non-root installation is essentially the same as applying fix packs to a root installation, with a few exceptions. Before applying fix packs to a non-root installation, you must log on with the user ID that was used to install the non-root installation. If you enabled root features in your non-root installation using the db2rfe command, you should locate the configuration file that was used when running the db2rfe command. That configuration file will be needed to re-enable the root features after you apply the fix pack. To apply a fix pack to a non-root installation: 1. Apply your fix pack according to the Applying fix packs topic. Note: The installFixPack commands b option is invalid for non-root installations. 2. Optional: Run the db2rfe command. If you had root-based features enabled in your non-root installation, and if you want to re-enable those features, the db2rfe command must be rerun. Running this command requires root authority. Note: If you edited $HOME/sqllib/instance/db2rfe.cfg when you first enabled root features, that configuration file will not have been overwritten when applying the fix pack, so you can reuse that file when running the db2rfe command. However, you should also check $HOME/sqllib/cfg/ db2rfe.cfg.sample. If the fix pack introduced any new root features available to non-root installations, $HOME/sqllib/cfg/db2rfe.cfg.sample shows the new features.
Reducing the size of your DB2 fix pack installation image

You can use the db2iprune command to reduce the size of the DB2 fix pack installation image. The db2iprune is a command line utility that removes the files associated with those features and languages based on an input file. The input file (.prn file) allows you to specify which features and languages you want to remove from the fix pack image. The result is a new, smaller DB2 fix pack image. Reducing the size of a fix pack image is also referred to as pruning the fix pack image.
187
Before installing a fix pack that has been pruned, you must ensure that the pruned fix pack image contains all the components that are in the DB2 copy. If you prune a component from the fix pack image that is part of the DB2 copy, the fix pack installation will fail. For example, if you installed a DB2 copy with the First Steps component, you must ensure that you have not pruned the First Steps component from that fix pack image. However, the reverse is permitted. If you did not install a specific component from your DB2 copy, you can successfully install a DB2 fix pack image that includes that specific component. In this case, that component is ignored when the fix pack image is installed. For example, if you installed a DB2 copy without the First Steps component, you can install a DB2 fix pack image that includes the First Steps component. You can verify what was installed in the DB2 copy so you will know what to prune from the fix pack installation image. On Linux and UNIX platforms Run the db2ls command to get a list of installed products and components. On Windows platforms Run the regedit command and look under the HKEY_LOCAL_MACHINE\ SOFTWARE\IBM\DB2\InstalledCopies\DB2 copy name\COMPONENTS to verify what has been installed. To reduce the size of your DB2 fix pack installation image 1. Use db2iprune to prune some DB2 components from the product installation image. 2. Install the pruned DB2 product installation image. 3. Use db2iprune to prune the same set of DB2 components, or a subset of DB2 components, from the fix pack image. (The same response file can be used.) 4. Install the pruned DB2 fix pack image.
Partitioned database environment Format of the DB2 node configuration file

The db2nodes.cfg file is used to define the database partition servers that participate in a DB2 instance. The db2nodes.cfg file is also used to specify the IP address or host name of a high-speed interconnect, if you want to use a high-speed interconnect for database partition server communication. The format of the db2nodes.cfg file on Linux and UNIX operating systems is as follows:
dbpartitionnum hostname logicalport netname resourcesetname
dbpartitionnum, hostname, logicalport, netname, and resourcesetname are defined in the following section. The format of the db2nodes.cfg file on Windows operating systems is as follows:
dbpartitionnum hostname computername logicalport netname resourcesetname
188
On Windows operating systems, these entries to the db2nodes.cfg are added by the db2ncrt or START DBM ADD DBPARTITIONNUM commands. The entries can also be modified by the db2nchg command. You should not add these lines directly or edit this file. dbpartitionnum A unique number, between 0 and 999, that identifies a database partition server in a partitioned database system. To scale your partitioned database system, you add an entry for each database partition server to the db2nodes.cfg file. The dbpartitionnum value that you select for additional database partition servers must be in ascending order, however, gaps can exist in this sequence. You can choose to put a gap between the dbpartitionnum values if you plan to add logical partition servers and wish to keep the nodes logically grouped in this file. This entry is required. hostname The TCP/IP host name of the database partition server for use by the FCM. This entry is required. Canonical hostname is recommended. If host names are supplied in the db2nodes.cfg file, instead of IP addresses, the database manager will dynamically try to resolve the host names. Resolution can be either local or through lookup at registered Domain Name Servers (DNS), as determined by the OS settings on the machine. Starting with DB2 Version 9.1, both TCP/IPv4 and TCP/IPv6 protocols are supported. The method to resolve host names has changed. While the method used in pre-Version 9.1 releases resolves the string as defined in the db2nodes.cfg file, the method in Version 9.1 or later tries to resolve the Fully Qualified Domain Names (FQDN) when short names are defined in the db2nodes.cfg file. Specifying short configured for fully qualified host names, this may lead to unnecessary delays in processes that resolve host names. To avoid any delays in DB2 commands that require host name resolution, use any of the following work arounds: 1. If short names are specified in the db2nodes.cfg files and the operating system host name file, specify the short name and the fully qualified domain name for host name in the operating system host files. 2. To use only IPv4 addresses when you know that the DB2 server listens on an IPv4 port, issue the following command:
db2 catalog tcpip4 node db2tcp2 remote 192.0.32.67 server db2inst1 with "Look up IPv4 address from 192.0.32.67"
3. To use only IPv6 addresses when you know that the DB2 server listens on an IPv6 port, issue the following command:
db2 catalog tcpip6 node db2tcp3 1080:0:0:0:8:800:200C:417A server 50000 with "Look up IPv6 address from 1080:0:0:0:8:800:200C:417A"
logicalport Specifies the logical port number for the database partition server. This field is used to specify a particular database partition server on a workstation that is running logical database partition servers. DB2 reserves a port range (for example, 60000 - 60003) in the /etc/services file for inter-partition communications at the time of installation. This
189
logicalport field in db2nodes.cfg specifies which port in that range you want to assign to a particular logical partition server. If there is no entry for this field, the default is 0. However, if you add an entry for the netname field, you must enter a number for the logicalport field. If you are using logical database partitions, the logicalport value you specify must start at 0 and continue in ascending order (for example, 0,1,2). Furthermore, if you specify a logicalport entry for one database partition server, you must specify a logicalport for each database partition server listed in your db2nodes.cfg file. This field is optional only if you are not using logical database partitions or a high speed interconnect. netname Specifies the host name or the IP address of the high speed interconnect for FCM communication. If an entry is specified for this field, all communication between database partition servers (except for communications as a result of the db2start, db2stop, and db2_all commands) is handled through the high speed interconnect. This parameter is required only if you are using a high speed interconnect for database partition communications. resourcesetname The resourcesetname defines the operating system resource that the node should be started in. The resourcesetname is for process affinity support, used for Multiple Logical Nodes (MLNs). This support is provided with a string type field formerly known as quadname. This parameter is only supported on AIX, HP-UX, and Solaris Operating System. On AIX, this concept is known as resource sets and on Solaris Operating System it is called projects. Refer to your operating systems documentation for more information on resource management. On HP-UX, the resourcesetname parameter is the name of a PRM group. Refer to HP-UX Process Resource Manager. User Guide. (B8733-90007) documentation from HP for more information. On Windows operating systems, process affinity for a logical node can be defined through the DB2PROCESSORS registry variable. On Linux operating systems, the resourcesetname column defines a number that corresponds to a Non-Uniform Memory Access (NUMA) node on the system. The system utility numactl must be available as well as a 2.6 Kernel with NUMA policy support. The netname parameter must be specified if the resourcesetname parameter is used.
Example configurations
Use the following example configurations to determine the appropriate configuration for your environment.
190
One computer, four database partitions servers If you are not using a clustered environment and want to have four database partition servers on one physical workstation called ServerA, update the db2nodes.cfg file as follows:
0 1 2 3 ServerA ServerA ServerA ServerA 0 1 2 3
Two computers, one database partition server per computer If you want your partitioned database system to contain two physical workstations, called ServerA and ServerB, update the db2nodes.cfg file as follows:
0 1 ServerA ServerB 0 0
Two computers, three database partition server on one computer If you want your partitioned database system to contain two physical workstations, called ServerA and ServerB, and ServerA is running 3 database partition servers, update the db2nodes.cfg file as follows:
4 6 8 9 ServerA ServerA ServerA ServerB 0 1 2 0
Two computers, three database partition servers with high speed switches If you want your partitioned database system to contain two computers, called ServerA and ServerB (with ServerB running two database partition servers), and use a high speed interconnect called switch1 and switch2, update the db2nodes.cfg file as follows:
0 1 2 ServerA ServerB ServerB 0 0 1 switch1 switch2 switch2
Examples using resourcesetname

These restrictions apply to the following examples: v This example shows the usage of resourcesetname when there is no high speed interconnect in the configuration. v The netname is the fourth column and a hostname also can be specified on that column where there is no switch name and you want to use resourcesetname. The fifth parameter is resourcesetname if it is defined. The resource group specification can only show as the fifth column in the db2nodes.cfg file. This means that for you to specify a resource group, you must also enter a fourth column. The fourth column is intended for a high speed switch. v If you do not have a high speed switch or you do not want to use it, you must then enter the hostname (same as the second column). In other words, the DB2 database management system does not support column gaps (or interchanging them) in the db2nodes.cfg files. This restriction already applies to the first three columns, and now it applies to all five columns.
AIX example
Here is an example of how to set up the resource set for AIX operating systems. In this example, there is one physical node with 32 processors and 8 logical database partitions (MLNs). This example shows how to provide process affinity to each MLN.
191
1. Define resource sets in /etc/rset:

DB2/MLN1: owner group perm resources DB2/MLN2: owner group perm resources DB2/MLN3: owner group perm resources DB2/MLN4: owner group perm resources DB2/MLN5: owner group perm resources DB2/MLN6: owner group perm resources DB2/MLN7: owner group perm resources DB2/MLN8: owner group perm resources = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = db2inst1 system rwr-rsys/cpu.00000,sys/cpu.00001,sys/cpu.00002,sys/cpu.00003 db2inst1 system rwr-rsys/cpu.00004,sys/cpu.00005,sys/cpu.00006,sys/cpu.00007 db2inst1 system rwr-rsys/cpu.00008,sys/cpu.00009,sys/cpu.00010,sys/cpu.00011 db2inst1 system rwr-rsys/cpu.00012,sys/cpu.00013,sys/cpu.00014,sys/cpu.00015 db2inst1 system rwr-rsys/cpu.00016,sys/cpu.00017,sys/cpu.00018,sys/cpu.00019 db2inst1 system rwr-rsys/cpu.00020,sys/cpu.00021,sys/cpu.00022,sys/cpu.00023 db2inst1 system rwr-rsys/cpu.00024,sys/cpu.00025,sys/cpu.00026,sys/cpu.00027 db2inst1 system rwr-rsys/cpu.00028,sys/cpu.00029,sys/cpu.00030,sys/cpu.00031
2. Enable memory affinity by typing the following command:

vmo -p -o memory_affinity=1
3. Give instance permissions to use resource sets:

chuser capabilities= CAP_BYPASS_RAC_VMM,CAP_PROPAGATE,CAP_NUMA_ATTACH 1 2 3 4 5 6 7 8 regatta regatta regatta regatta regatta regatta regatta regatta 0 1 2 3 4 5 6 7 regatta regatta regatta regatta regatta regatta regatta regatta DB2/MLN1 DB2/MLN2 DB2/MLN3 DB2/MLN4 DB2/MLN5 DB2/MLN6 DB2/MLN7 DB2/MLN8 db2inst1
4. Add the resource set name as the fifth column in db2nodes.cfg:
192
HP-UX example
This example shows how to use PRM groups for CPU shares on a machine with 4 CPUs and 4 MLNs and 24% of CPU share per MLN, leaving 4% for other applications. The DB2 instance name is db2inst1. 1. Edit GROUP section of /etc/prmconf:
OTHERS:1:4:: db2prm1:50:24:: db2prm2:51:24:: db2prm3:52:24:: db2prm4:53:24::
2. Add instance owner entry to /etc/prmconf:

db2inst1::::OTHERS,db2prm1,db2prm2,db2prm3,db2prm4
3. Initialize groups and enable CPU manager by entering the following command:
prmconfig -i prmconfig -e CPU
4. Add PRM group names as a fifth column to db2nodes.cfg:

1 2 3 4 voyager voyager voyager voyager 0 1 2 3 voyager voyager voyager voyager db2prm1 db2prm2 db2prm3 db2prm4
PRM configuration (steps 1-3) may be done using interactive GUI tool xprm.
Linux example
On Linux operating systems, the resourcesetname column defines a number that corresponds to a Non-Uniform Memory Access (NUMA) node on the system. The numactl system utility must be available in addition to a 2.6 kernel with NUMA policy support. Refer to the man page for numact1 for more information about NUMA support on Linux operating systems. This example shows how to set up a four node NUMA computer with each logical node associated with a NUMA node. 1. Ensure that NUMA capabilities exist on your system. 2. Issue the following command:
$ numactl --hardware
Output similar to the following displays:

available: 4 node 0 size: node 0 free: node 1 size: node 1 free: node 2 size: node 2 free: node 3 size: node 3 free: nodes (0-3) 1901 MB 1457 MB 1910 MB 1841 MB 1910 MB 1851 MB 1905 MB 1796 MB
3. In this example, there are four NUMA nodes on the system. Edit the db2nodes.cfg file as follows to associate each MLN with a NUMA node on the system:
0 1 2 3 hostname hostname hostname hostname 0 1 2 3 hostname hostname hostname hostname 0 1 2 3
193
Solaris example
Here is an example of how to set up the project for Solaris Version 9. In this example, there is 1 physical node with 8 processors: one CPU will be used for the default project, three (3) CPUs will used by the Application Server, and four (4) CPUs for DB2. The instance name is db2inst1. 1. Create a resource pool configuration file using an editor. For this example, the file will be called pool.db2. Heres the content:
create system hostname create pset pset_default (uint pset.min = 1) create pset db0_pset (uint pset.min = 1; uint pset.max = 1) create pset db1_pset (uint pset.min = 1; uint pset.max = 1) create pset db2_pset (uint pset.min = 1; uint pset.max = 1) create pset db3_pset (uint pset.min = 1; uint pset.max = 1) create pset appsrv_pset (uint pset.min = 3; uint pset.max = 3) create pool pool_default (string pool.scheduler="TS"; boolean pool.default = true) create pool db0_pool (string pool.scheduler="TS") create pool db1_pool (string pool.scheduler="TS") create pool db2_pool (string pool.scheduler="TS") create pool db3_pool (string pool.scheduler="TS") create pool appsrv_pool (string pool.scheduler="TS") associate pool pool_default (pset pset_default) associate pool db0_pool (pset db0_pset) associate pool db1_pool (pset db1_pset) associate pool db2_pool (pset db2_pset) associate pool db3_pool (pset db3_pset) associate pool appsrv_pool (pset appsrv_pset)
2. Edit the /etc/project file to add the DB2 projects and appsrv project as follows:
system:0:::: user.root:1:::: noproject:2:::: default:3:::: group.staff:10:::: appsrv:4000:App Serv project:root::project.pool=appsrv_pool db2proj0:5000:DB2 Node 0 project:db2inst1,root::project.pool=db0_pool db2proj1:5001:DB2 Node 1 project:db2inst1,root::project.pool=db1_pool db2proj2:5002:DB2 Node 2 project:db2inst1,root::project.pool=db2_pool db2proj3:5003:DB2 Node 3 project:db2inst1,root::project.pool=db3_pool
3. Create the resource pool: # poolcfg -f pool.db2. 4. Activate the resource pool: # pooladm -c 5. Add the project name as the fifth column in db2nodes.cfg file:
0 1 2 3 hostname hostname hostname hostname 0 1 2 3 hostname hostname hostname hostname db2proj0 db2proj1 db2proj2 db2proj3
Updating the node configuration file (Linux and UNIX)

This task provides steps for updating the db2nodes.cfg file to include entries for participating computers. The node configuration file (db2nodes.cfg), located in the instance owners home directory, contains configuration information that tells DB2 which servers participate in an instance of the partitioned database environment. A db2nodes.cfg file exists for each instance in a partitioned database environment.
194
The db2nodes.cfg file must contain one entry for each server participating in the instance. When you create an instance, the db2nodes.cfg file is automatically created and an entry for the instance-owning server is added. For example, when you created the DB2 instance using the DB2 Setup wizard, on the instance-owning server ServerA, the db2nodes.cfg file is updated as follows:
0 ServerA 0
Prerequistes v The DB2 application must be installed on all participating computers. v A DB2 instance must exist on the primary computer. v You must be a user with SYSADM authority. v Review the configuration examples and file format information provided in the Format of the DB2 node configuration file topic if either of the following conditions apply: You plan to use a high speed switch for communication between database partition servers Your partitioned configuration will have multiple logical partitions Restriction The hostnames used in the steps of the Procedure section must be fully qualified hostnames. To update the db2nodes.cfg file: 1. Log on as the instance owner (in our example, db2inst1 is the instance owner). 2. Ensure that the DB2 instance is stopped by entering:
INSTHOME/sqllib/adm/db2stop
where INSTHOME is the home directory of the instance owner (the db2nodes.cfg file is locked when the instance is running and can only be edited when the instance is stopped). For example, if your instance home directory is /db2home/db2inst1, enter the following command:
/db2home/db2inst1/sqllib/adm/db2stop
3. Add an entry to the .rhosts file for each DB2 instance. Update the file by adding the following:
<hostname> <db2instance>
where <hostname> is the TCP/IP host name of the database server and <db2instance> is the name of the instance you use to access the database server. 4. Add an entry to the db2nodes.cfg file of each participating server. When you first view the db2nodes.cfg file, it should contain an entry similar to the following:
0 ServerA 0
This entry includes the database partition server number (node number), the TCP/IP host name of the server where the database partition server resides, and a logical port number for the database partition server. For example, if you are installing a partitioned configuration with four computers and a database partition server on each computer, the updated db2nodes.cfg should appear similar to the following:
195
0 1 2 3
ServerA ServerB ServerC ServerD
0 0 0 0
5. When you have finished updating the db2nodes.cfg file, enter the INSTHOME/sqllib/adm/db2start command, where INSTHOME is the home directory of the instance owner. For example, if your instance home directory is /db2home/db2inst1, enter the following command:
/db2home/db2inst1/sqllib/adm/db2start
6. Log out.
Enabling communications between database partition servers (Linux and UNIX)

This task describes how to enable communication between the database partition servers that participate in your partitioned database system. Communication between database partition servers is handled by the Fast Communications Manager (FCM). To enable FCM, a port or port range must be reserved in the /etc/services file on each computer in your partitioned database system. You must have a user ID with root authority. You must perform this task on all computers that participate in the instance. The number of ports to reserve for FCM is equal to the maximum number of database partitions hosted, or potentially hosted, by any computer in the instance. In the following example, the db2nodes.cfg file contains these entries:
0 1 2 3 4 5 6 7 8 server1 server1 server2 server2 server2 server3 server3 server3 server3 0 1 0 1 2 0 1 2 3
Assume that the FCM ports are numbered starting at 60000. In this situation: v server1 uses two ports (60000, 60001) for its two database partitions v server2 uses three ports (60000, 60001, 60002) for its three database partitions v server3 uses four ports (60000, 60001, 60002, 60003) for its four database partitions All computers must reserve 60000, 60001, 60002, and 60003, since this is the largest port range required by any computer in the instance. If you use a high availability solution such as High Availability Cluster Multi-Processing (HACMP) or Tivoli System Automation to fail over database partitions from one computer to another, you must account for potential port requirements. For example, if a computer normally hosts four database partitions, but another computers two database partitions could potentially fail over to it, six ports must be planned for that computer. When you create an instance, a port range is reserved on the primary computer. The primary computer is also known as the instance-owning computer. However,
196
if the port range originally added to the /etc/services file is not sufficient for your needs, you will need to extend the range of reserved ports by manually adding additional entries. To enable communications between servers in a partitioned database environment using /etc/services: 1. Log on to the primary computer (instance owning computer) as a user with root authority. 2. Create an instance. 3. View the default port range that has been reserved in the /etc/services file. In addition to the base configuration, the FCM ports should appear similar to the following:
db2c_db2inst1 50000/tcp #Add FCM port information DB2_db2inst1 60000/tcp DB2_db2inst1_1 60001/tcp DB2_db2inst1_2 60002/tcp DB2_db2inst1_END 60003/tcp
By default, the first port (50000) is reserved for connection requests, and the first available four ports above 60000 are reserved for FCM communication. One port is for the instance-owning database partition server and three ports are for logical database partition servers that you might choose to add to the computer after installation is complete. The port range must include a start and an END entry. Intermediate entries are optional. Explicitly including intermediate values can be useful for preventing other applications from using these ports, but these entries are not verified by the database manager. DB2 port entries use the following format:
DB2_instance_name_suffix port_number/tcp # comment
where: v instance_name is the name of the partitioned instance. v suffix is not used for the first FCM port. Intermediate entries are those between the lowest and highest port. If you include the intermediate entries between the first and ending FCM port, the suffix consists of an integer that you increment by one for each additional port. For example, the second port is numbered 1, and third is numbered 2, and so on to ensure uniqueness. The word END must be used as the suffix for the last entry. v port_number is the port number that you reserve for database partition server communications. v comment is an optional comment describing an entry. 4. Ensure that there are sufficient ports reserved for FCM communication. If the range of reserved ports is insufficient, add new entries to the file. 5. Log on as a root user to each computer participating in the instance and add identical entries to the /etc/services file.
Enabling the execution of remote commands (Linux and UNIX)

You must update your .rhosts file to execute remote commands using rsh. In a partitioned database system, each database partition server must have the authority to perform remote commands on all the other database partition servers participating in an instance. This authority can be granted by updating the.rhosts
197
file in the home directory for the instance. Because the home directory for the instance is on the shared DB2 home file system, only one .rhosts file is required. Prerequisites v You must have root authority. v You must know the host name of each participating computer. v You must know the instance owners user name. This topic describes how to enable execution of remote commands using rsh. You can also use ssh enable execution of remote commands. To use ssh without being prompted for passwords or pass phrases, refer to: v Setting up a partitioned database environment on page 85 v http://www-128.ibm.com/developerworks/db2/library/techarticle/dm0506finnie/index.html To update your .rhosts file to execute remote commands using rsh: 1. Log onto the primary computer as a user with root authority. 2. Create a .rhosts file in the instance home directory. For example, if your instance home directory is /db2home/db2inst1, you can use a text editor to create the .rhosts file by entering the following command:
vi /db2home/db2inst1/.rhosts
3. Add entries to the .rhosts file for each computer including the primary computer. The .rhosts file has the following format:
hostname instance_owner_user_name
Some systems might require a long host name to be specified, for example: ServerA.yourdomain.com. Before you add host name entries to the .rhosts file, make sure the host names in the /etc/hosts and the /etc/resolv.conf files can be resolved. The INSTHOME/.rhosts file should contain entries similar to the following:
ServerA.yourdomain.com ServerB.yourdomain.com ServerC.yourdomain.com ServerD.yourdomain.com db2inst1 db2inst1 db2inst1 db2inst1
Rather than specifying each host name individually, you can specify the following entry in the .rhosts file, but this action may pose a security risk and should only be done in a test environment.
+ db2inst1
If you have specified a high speed switch (netname) in the db2nodes.cfg file, you should also add netname entries for each computer to the .rhosts file. The netname values are specified in the fourth column of the db2nodes.cfg file. A .rhosts file with high speed switch (netname) entries may look similar to the following:
ServerA.yourdomain.com ServerB.yourdomain.com ServerC.yourdomain.com ServerD.yourdomain.com Switch1.yourdomain.com Switch2.yourdomain.com Switch3.yourdomain.com Switch4.yourdomain.com db2inst1 db2inst1 db2inst1 db2inst1 db2inst1 db2inst1 db2inst1 db2inst1
198
An alternative to using a .rhosts file is to use /etc/hosts.equiv file. The /etc/hosts.equiv file would contain the exact same entries as the .rhosts file, but must be created on each computer. For more information about the .rhosts file or the /etc/hosts.equiv file, see your operating system documentation.
Enabling Control Center administration (Linux)

Before you can use the Control Center to administer your partitioned database system, you must start the DB2 Administration server (DAS) on all computers. To enable Control Center administration for a partitioned database system: 1. In turn, log on to each computer (ServerA, ServerB, ServerC, ServerD) as the DAS user. In our example, dasusr1 is the DAS user. 2. To start the DB2 Administration Server, run the db2admin start command.
199
200
Part 4. Installing the DB2 Information Center
201
202
Chapter 17. DB2 Information Center installation options

The DB2 Information Center can be accessed from: v the IBM Web site v a server on your organizations network v a copy installed on your computer By default, DB2 products access the DB2 Information Center at the IBM Web site: http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/. However, if you want to access the DB2 Information Center on an intranet server or on your own computer, you must install the DB2 Information Center. The following types of DB2 Information Centers are available: v The regular DB2 Information Center This is the same DB2 Information Center that is distributed with DB2 database products. It comes with an installer and other programs that let you install the Information Center on your computer. The install program requires that you have administrative authority on your computer to complete the installation. v A Workstation version of the DB2 Information Center These packages allow you to run the DB2 Information Center on your computer if you do not have administrator or root authority. The Workstation version of the DB2 Information Center run in stand-alone mode; it cannot be accessed by other clients on your network. There are no services or daemons associated with this type of DB2 Information Center, therefore you must start and stop it manually. It also differs from the regular DB2 Information Center because it determines the locale from the computers system locale, not from the browser. You can install either of the DB2 Information Centers using the DB2 Information Center DVD found in your product Media Pack. Alternatively, you can download the DB2 Information Center installation image from https://www.ibm.com/ services/forms/preLogin.do?lang=en_US&source=swg-dm-db297info. The following table provides recommendations on possible options for accessing DB2 product documentation in the DB2 Information Center based on your work environment.
Internet access Yes Intranet access Yes Recommendation Access the DB2 Information Center at the IBM Web site, or access the DB2 Information Center installed on an intranet server. Access the DB2 Information Center at the IBM Web site. Access the DB2 Information Center installed on an intranet server. Access the DB2 Information Center on a local computer, or access the stand-alone Workstation version of the DB2 Information Center..
Yes No No
No Yes No
203
Accessing the DB2 Information Center at the IBM Web site

The DB2 Information Center can be found on the Internet at http:// publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp. If you configure your local DB2 installation to use this version of the DB2 Information Center, you will always be accessing the most up-to-date information about the DB2 product. On Windows platforms, use the db2set command to configure the registry variables on your computer to access the DB2 Information Center from either the IBM Web site or from your computer. You can also change these variables through the DB2 GUI tools, if you have installed the DB2 GUI tools on your system.
Accessing the DB2 Information Center on your computer

After installing your DB2 product, you need to install the DB2 Information Center if you want to access DB2 documentation on this computer. Use the DB2 Information Center DVD in the media pack or the files that you downloaded from https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?lang=en_US &source=swg-dm-db297info to install the DB2 Information Center.
Accessing the DB2 Information Center on an intranet server

You may also choose to install a copy of the DB2 Information Center on an intranet server so that everyone on the intranet can have access to DB2 documentation without having to install the documentation on every machine. Using a response file for product installation, you can configure every IBM data server client to access the documentation on the intranet server. The response file should contain the configuration information necessary to access the DB2 Information Center using the host name and the port number of the DB2 Information Center on the intranet server. This configuration can also be done using the db2setup command and choosing a custom installation from any of the DB2 server or IBM data server client products. You can also change the settings for already-installed IBM Data Server Client to use the DB2 Information Center hosted on your Intranet. To change the DB2 Information Center registry variables on each computer, use either of the following methods: v The db2set command v The Tools Settings notebook from any DB2 GUI tool DB2_DOCHOST is the registry variable used for the host name, and DB2_DOCPORT is the registry variable used for the port number. These values must match those set on the intranet server where the DB2 Information Center is installed.
204
Chapter 18. Installation tasks

Installing the DB2 Information Center using the DB2 Setup wizard (Windows)
Using the DB2 Setup wizard, you can define your installation preferences and install the DB2 Information Center on a computer that uses the Windows operating system. DB2 database product documentation can be accessed in three ways: v at the IBM Web site v on an intranet server v on a version installed on your computer By default, DB2 database products access DB2 documentation at the IBM Web site. If you want to access the DB2 documentation on an intranet server or on your own computer, you must install the DB2 documentation from the DB2 Information Center DVD, or from an image downloaded from Passport Advantage, or DB2 database product documentation Web site. Prerequisites This section lists the hardware, operating system, software, and communication requirements for installing the DB2 Information Center on Windows. Operating system requirements You require one of the following operating systems: v Windows Vista v Windows XP v Windows Server 2003 v Windows Server 2008 The DB2 Information Center will run on Windows and Linux on AMD/EMT 64, but it does not exploit the 64-bit architecture. Software requirements You require one of the following browsers: v Firefox 1.0 and higher v Internet Explorer (IE) 6.0 and higher v Mozilla-based browsers 1.7 and higher v Safari 3.0 v Konqueror (UI base mode only). Base mode restricts the users basic functionality such as displaying topics, locating topics in the table of contents, and searching for topics. Communication requirements You require TCP/IP protocol. Restrictions v To install a Network version of the DB2 Information Center, you require an account with administrative privileges to install. To install a Workstation version of the DB2 Information Center, you do not need administrative privileges.
205
v You cannot install the DB2 Information Center in a location where a DB2 database product is installed. Similarly, the DB2 Information Center cannot coexist in the same installation path of a previous version of the DB2 Information Center on the same system. v You can only install one copy of each version of the DB2 Information Center on your system. For example, you can install a copy of the DB2 Information Center Version 9.1 and DB2 Information Center Version 9.5 (or higher) on the same system, but you cannot install two copies of the DB2 Information Center Version 9.5 (or higher). v If you install the DB2 Information Center on a system with a firewall, and you plan for other systems to access the DB2 Information Center, you must open the port in your firewall setting. To install the DB2 Information Center using the DB2 Setup wizard: 1. Log on to the system with the account that you have defined for the DB2 Information Center installation. 2. If you have the DB2 Information Center product DVD, insert your DB2 database product DVD into the drive. If enabled, the auto-run feature automatically starts the DB2 Setup launchpad. If the auto-run does not work, use Windows Explorer to browse the DB2 database product DVD. 3. If you downloaded the image from an online source (such as Passport Advantage, or, ibm.com), uncompress the DB2 Information Center installation image. 4. Double-click the setup icon. 5. From the DB2 Setup Launchpad, you can view installation prerequisites and the release notes, or you can proceed directly to the installation. You should review the installation prerequisites and release notes for late-breaking information. 6. Click Install a Product and the Install a Product window displays. 7. On the Install a Product window, if you do not have an existing DB2 Information Center installed on your computer, launch the installation by clicking Install New. 8. On the Welcome to the DB2 Setup wizard window, click Next. The DB2 Setup wizard will guide you through the program setup process. The DB2 Setup wizard will determine the system language, and launch the setup program for that language. Online help is available to guide you through the remaining steps. To invoke the online help, click Help or press F1. You can click Cancel at any time to end the installation. Your DB2 Information Center will be installed, by default, in the Program_Files\IBM\DB2 Information Center\Version 9.7 directory, where Program_Files represents the location of the Program Files directory. For information on errors encountered during installation, review the installation log file located, by default, in the My Documents\DB2LOG\ directory. You can specify the location of the log files. The log file uses the following format: DB2-DOCE-DateTime.log, for example, DB2-DOCE-Wed Apr 11 08_38_35 2007.log
206
Installing the DB2 Information Center using the DB2 Setup wizard (Linux)
DB2 product documentation can be accessed in three ways: v at the IBM Web site v on an intranet server v on a version installed on your computer By default, DB2 products access DB2 documentation at the IBM Web site. If you want to access the DB2 documentation on an intranet server or on your own computer, you must install the documentation from the DB2 Information Center DVD, Passport Advantage, or DB2 database product documentation Web site. Using the DB2 Setup wizard, you can define your installation preferences and install the DB2 Information Center on a computer that uses a Linux operating system. Prerequisite Review the prerequisite information in the Installation requirements for DB2 servers and IBM data server clients (Linux) topic. Restrictions v To install a Network version of the DB2 Information Center, you must be logged on as a user with root authority. To install a Workstation version of the DB2 Information Center, you do not require root authority. v You cannot install the DB2 Information Center in a location where a DB2 product is installed. Similarly, the DB2 Information Center cannot coexist in the same installation path of a previous version of the DB2 Information Center on the same system. v You can only install one copy of the DB2 Information Center of the same version on your system. For example, you can install a copy of the DB2 Information Center Version 9.1 and DB2 Information Center Version 9.5 (or higher) on the same system, but you cannot install two copies of the DB2 Information Center Version 9.5 (or higher) on the same system. v If you install the DB2 Information Center on a system with a firewall, and you plan for other systems to access the DB2 Information Center, you must open the port in your firewall setting. To install the DB2 Information Center using the DB2 Setup wizard: 1. Log on to the system. 2. If you have the DB2 Information Center product DVD: a. Insert and mount the DVD on your system. b. Change to the directory where the DVD is mounted by entering the following command:
cd /dvd
where /dvd represents the mount point of the DVD. 3. If you downloaded the image from an online source (such as Passport Advantage, or, ibm.com), untar the image: a. Decompress the product file:
For example,
207
gzip -d ese.tar.gz
b. Untar the product file:

For example,
tar -xvf ese.tar

cd product
For example,
cd ese
4. Enter the ./db2setup command to start the DB2 Setup wizard. 5. The DB2 Setup Launchpad opens. From the launchpad, you can view installation prerequisites and the release notes, or you can proceed directly to the installation. You should review the installation prerequisites and release notes for late-breaking information. 6. Click Install a Product and the Install a Product window displays. 7. On the Install a Product page, if you do not have an existing DB2 Information Center installed on your computer, launch the installation by clicking Install New. If you already have an existing DB2 Information Center installed on your computer, click Work with Existing to work with the existing DB2 Information Center. 8. On the Welcome to the DB2 Setup wizard page, click Next. The DB2 Setup wizard will guide you through the program setup process. 9. To proceed with the installation, you must accept the license agreement. On the Software License Agreement page, select Accept and click Next. 10. On the Select installation, response file creation, or both page, select Install DB2 Information Center on this computer. If you want to use a response file to install the DB2 Information Center on this or other computers at a later time, select Install DB2 Information Center on this computer and save my settings in a response file. You can specify where the response file will be saved. Click Next. 11. On the Select the languages to install page, select the languages the DB2 Information Center will install. By default, the DB2 Information Center is installed in the /opt/ibm/db2ic/V9.7 directory. However, you can specify your own installation path. Click Next. 12. Configure the DB2 Information Center for incoming communication on the Specify the DB2 Information Center port page. Click Next to continue the installation. If you specify a port number other than the default and you receive the error The service name specified is in use, you can correct this error by either choosing to use the default port number or by specifying a different service name. 13. Review the installation choices you have made in the Start copying files page. To change any settings, click Back. Click Finish to complete the installation of the DB2 Information Center files onto your computer. The installation logs, db2setup.log and db2setup.err will be located, by default, in the /tmp directory. You can specify the location of the log files.
208
The db2setup.log file captures all DB2 installation information including errors. The db2setup.err file captures any error output that is returned by Java (for example, exceptions and trap information). There is no longer a db2setup.his file. Instead, the DB2 installer saves a copy of the db2setup.log file in the DB2_DIR/install/logs/ directory, and renames it to db2install.history. If db2install.history already exists, the copy of the db2setup.log will be renamed db2install.history.xxxx where xxxx are digits starting at 0000 and increasing by 1 for the next log file. Note: You may need to run the eject command or unmount the CD drive before you can physically remove the installation media.
Installing a DB2 product using the db2_install or doce_install command (Linux and UNIX)
Before you install DB2 products and features or the DB2 Information Center: v You should refer to the installation documentation for the particular DB2 product you want to install. For example, if you want to install DB2 Enterprise Server Edition, then refer to the Quick Beginnings for DB2 Servers documentation to review installation prerequisites and other important setup information. v You can install a DB2 product and the DB2 Information Center using either root or non-root authority. v The DB2 product image must be available. You can obtain a DB2 installation image either by purchasing a physical DB2 product DVD, or by downloading an installation image from Passport Advantage. The db2_install command installs DB2 products and features on supported Linux and UNIX operating systems. The doce_install command installs the DB2 Information Center on supported Linux operating systems. You cannot manually install a DB2 product or feature using an operating systems native installation utility such as rpm, SMIT, swinstall or pkgadd. Any existing scripts containing a native installation utility that you use to interface and query with DB2 installations will need to change. The db2_install command is not supported on the National Language Package DVD. Only one copy of the DB2 Information Center for the current release can be installed on your system. The Information Center cannot be installed in the same location where a DB2 product is installed. If you install the DB2 Information Center on a system with a firewall, and you plan to allow other systems to access the DB2 Information Center, you must open the port in your firewall setting. To install a DB2 product or feature using the db2_install command, or to install the DB2 Information Center using the doce_install command: 1. If you have a physical DB2 product DVD, insert and mount the appropriate DVD or access the file system where the installation image was stored. 2. If you downloaded the DB2 product image, you must decompress and untar the product file.
209
a. Decompress the product file:

For example,
gzip -d ese.tar.gz
b. Untar the product file: On Linux operating systems

For example,
tar -xvf ese.tar

For example,
gnutar -xvf ese.tar

cd product
For example,
cd ese
3. Enter the ./db2_install or ./doce_install command:

./db2_install -b DB2DIR -p productShortName -c NLPackLocation -L language... -n
where: v DB2DIR specifies the path where the DB2 product will be installed. If the path is not specified, you are prompted to either select the default path or to provide the path. The default installation path is: for AIX, HP-UX or Solaris operating systems: /opt/IBM/db2/V9.7 for Linux operating systems: /opt/ibm/db2/V9.7 for the DB2 Information Center: /opt/ibm/db2ic/V9.7. The Workstation version of the DB2 Information Center does not have a default installation path, you must specify the installation location. However, by default, the Workstation version of the DB2 Information Center is installed at port 51097. If you provide your own path, you must specify the full path name. DB2 installation paths have the following rules: Can include lowercase letters (az), uppercase letters (AZ), and the underscore character ( _ ) Cannot exceed 128 characters Cannot contain spaces Cannot contain non-English characters Note: For DB2 products and components to work together, they must be installed to a single path. This is not to be confused with the ability to install DB2 products to multiple paths. But, for products and components to work together, they must be installed to the same path, and, must be at the same release level. v productShortName specifies the DB2 product to be installed.
210
This parameter is case insensitive and is mandatory when the -n parameter is specified. The product short name (productShortName) can be found in the file ComponentList.htm (under the product full name) located in the /db2/plat directory on your media where plat is the platform name that you are installing on. You can only install one product at a time. v NLPackLocation specifies the National Language Pack (NLPACK) location. v language specifies national language support. You can install a non-English version of a DB2 product. However, you must run this command from the product DVD, not the National Language pack DVD. By default, English is always installed, therefore, English does not need to be specified. When more than one language is required this parameter is mandatory. To indicate multiple languages, specify this parameter multiple times. For example, to install both French and German specify -L FR -L DE. v n parameter indicates noninteractive installation mode. When this parameter is specified, both -b and -p must also be specified. You only need to specify -c and -L if applicable. When installing the DB2 Information Center, if you specify a port number other than the default, you might receive the error The service name specified is in use. You can correct this error by either choosing to use the default port number or by specifying a different service name. After installation, you must manually configure your DB2 server. Tasks include user and instance creation and configuration.
211
212

Starting or stopping the Information Center (Linux and Windows)
The DB2 Information Center is started and stopped using either the Windows services dialog, or a Linux daemon. On Linux operating systems, the DB2 Information Center daemon is part of the DB2 Information Center installation. This daemon is a background process that runs the Information Center. The daemon is initialized by the script db2icd which can be found in INST_PATH/doc/bin where INST_PATH is the installation path for your DB2 product. The only time you should need to start or stop the daemon manually is when you want to change the configuration variables for the daemon. Normally, the daemon is started at system startup, according to the run levels created during the installation of the DB2 Information Center. The Workstation version of the DB2 Information Center does not have a daemon. On Windows operating systems, to stop or start the Information Center use the services control panel applet: Control Panel Administrative Tools Services. Right-click the service labelled DB2 Information Center. Select either Stop or Start. On Linux operating systems, to stop and start the Information Center daemon: 1. Log in as a user with root authority. 2. Halt the daemon if it is already running. At a command line, enter:
INIT_DIR/db2icd stop
where INIT_DIR is the installation directory of the db2icd file listed previously. 3. Change any of the variables for the daemon by editing the db2ic.conf file. Currently, you can modify the TCP port number for the documentation service, and the location of the temporary workspace used by the daemon while it is running. 4. Start the daemon. At a command line, enter:
INIT_DIR/db2icd start
where INIT_DIR is the installation directory of the db2icd file listed previously. When the daemon restarts, it uses the new environment variables. There is also an option to shut down and restart the daemon immediately. At a command line, enter:
INIT_DIR/db2icd restart
where INIT_DIR is the installation directory of the db2icd file listed previously. You can check the status of the daemon at any time. At a command line, enter:
INIT_DIR/db2icd status
where INIT_DIR is the installation directory of the db2icd file listed previously. The daemon returns the current status, and displays the process ID of the daemon if it is active.
213
214
Part 5. Configuring
215
216
Chapter 20. Configuring DB2 server communications using the Control Center
Configuring communication protocols for a local DB2 instance
This task describes how to configure communication protocols for a local DB2 instance using the Control Center. Communication protocols on the DB2 server must be configured in order for your DB2 server to accept inbound requests from remote DB2 clients. Most protocols are automatically detected and configured when you set up DB2 using the DB2 Setup wizard. Perform this task if: v You deselected a detected communication protocol when you set up a DB2 product using the DB2 Setup wizard. v You added a communication protocol to your network since you set up a DB2 product using the DB2 Setup wizard. v You are using a communication protocol that could not be detected by the DB2 Setup wizard. v You installed a DB2 product manually. Communication protocols can also be configured using the Command Line Processor (CLP). The following restrictions apply: v You cannot use the Control Center to configure communication protocols for a partitioned DB2 server. v Modifying an instances communication protocol settings might require you to update the database connection catalogs on the client (reconfigure client-to-server communications). To configure communication protocols for local instances, perform the following steps: 1. Launch the Control Center. 2. Click the [+] beside a systems name to get the instances folder. 3. Select either the Databases or Gateway Connections folder and click the [+] beside the Instances folder to get a list of instances on a particular system. 4. Select the instance that you want to configure and click the right mouse button. 5. Select the Setup communications option from the pop-up menu. The Setup communications window opens. 6. Use the Setup communications window to configure communication protocols for the instance that you selected. Invoke the online help by clicking Help or by pressing F1. 7. You must stop and restart the instance for these changes to take effect. a. To stop the database manager instance, select the instance, click with the right mouse button and select the Stop option from the pop-up menu. b. To start the database manager instance, select the instance, click with the right mouse button and select the Start option from the pop-up menu.
217
Configuring communication protocols for a remote DB2 instance

This task describes how to configure communication protocols for a remote instance on your DB2 server using the Control Center. Communication protocols on the DB2 server must be configured for your DB2 server to accept inbound requests from remote clients. Most protocols are automatically detected and configured when you set up DB2 using the DB2 Setup wizard. Perform this task if: v You deselected a detected communication protocol when you set up DB2 using the DB2 Setup wizard. v You added a communication protocol to your network since you set up DB2 using the DB2 Setup wizard. v You are using a communication protocol that could not be detected by the DB2 Setup wizard. v You installed a DB2 product using the db2_install command or the payload file method. The following restrictions apply: v You cannot use the Control Center to configure communication protocols for a partitioned DB2 server. v Modifying an instances communication protocol settings might require you to update the database connection catalogs on the client (reconfigure client-to-server communications). To configure DB2 communication protocols for remote instances, perform the following steps: 1. Launch the Control Center. 2. If the system containing the remote instance you want is listed, click on the [+] sign beside the system name to get the Instances folder. Click on the [+] beside the Instances folder to get a list of the systems instances, then go to step 13 on page 219. If the system containing the remote instance you want is listed, but the instance you want does not display under that system, go to step 8 on page 219. 3. If the system containing the remote instance that you want to configure is not listed, select the Systems folder, click on the right mouse button and select the Add option. The Add System window opens. 4. To add a system to the Control Center, you can do one of the following: v If the system name is empty, click on Discover to display a list of TCP/IP systems on the network. Select a system and press OK. The system information is populated on the Add System window. v If the system name is filled, click on Discover to invoke a known discovery. If successful, the system information is populated on the Add System window. Note: Discovery will only work on remote TCP/IP systems. 5. Click Apply to add the system to the Control Center window. 6. Click Close. 7. Click on the [+] sign beside the system name you just added to get the Instances folder.
218
8. Select the Instances folder for the new system and click on the right mouse button. 9. Select the Add option. The Add Instance window opens. 10. Click Discover to obtain a list of available instances to display a list of remote instances on the system. 11. Select the instance that you want to add and click OK. The Add Instance window will be populated with the remote instance info. 12. Click Close. 13. Select the instance you want to configure and click on the right mouse button. 14. Select the Setup communications option from the pop-up menu. The Setup Communications window opens. 15. Use the Setup Communications window to configure communication protocols for the instance. Click on the Help push button for more information. 16. You must stop and restart the instance for these changes to take effect: a. To stop an instance, select the instance, click on the right mouse button, and select the Stop option. b. To start an instance, select the instance, click on the right mouse button, and select the Start option.
DB2 server communications configuration using the Control Center

Important: The Control Center and its associated components have been deprecated in Version 9.7 and might be removed in a future release. For more information, see the Control Center tools and DB2 administration server (DAS) have been deprecated topic in the Whats New for DB2 Version 9.7 book. The Control Center is a graphical tool used to administer DB2 databases. The Control Centers setup communications function allows you to display the protocols and configuration parameters that a server instance is configured to use. It also allows you to modify the parameter values of a configured protocol, as well as add or delete protocols. When you add support for a new protocol to the server system, the setup communications function detects and generates server instance parameter values for the new protocol. You can accept or modify these values before use. When you remove support for an existing protocol from the server system, the setup communications function detects the protocol that has been removed and disables its use by the server instance. You can add a protocol that has not been detected, however, you must supply all of the parameter values required before you proceed. The setup communications function can be used to maintain communications for both local and remote server instances, provided that the DB2 Administration Server (DAS) is running on the server system. Modifying instance communication settings that have been previously configured might require you to update the database connection catalogs on the client. You can do this by: v Using the Configuration Assistant on the client. Select the database connection that you want to change. Under the Selected menu, select Change database. This will start a Wizard that will help you with the changes.
Chapter 20. Configuring DB2 server communications using the Control Center
219
v Using the command line processor on the client to uncatalog and re-catalog the node, depending on the values changed on the server.
220
Chapter 21. Setting communication protocols for a DB2 instance

To perform this task you require sysadm authority. Setting communication protocols for a DB2 instance is part of the main task of configuring TCP/IP or SSL communications for a DB2 instance. The DB2COMM registry variable allows you to set communication protocols for the current DB2 instance. If the DB2COMM registry variable is undefined or set to null, no protocol connection managers are started when the database manager is started. The DB2COMM registry variable can be set with one of the following keywords: tcpip ssl starts TCP/IP support starts SSL support
To set the communication protocol for the instance: Enter the db2set DB2COMM command from the DB2 command window:
db2set DB2COMM=tcpip
For example, to set the database manager to start connection managers for the TCP/IP communication protocols, enter the following command:
db2set DB2COMM=tcpip db2stop db2start
221
222
Chapter 22. Configuring DB2 server communications (TCP/IP)

Configuring TCP/IP communications for a DB2 instance
This task describes how to configure TCP/IP communications on your DB2 server using the DB2 Command Line Processor (CLP). Communication protocols on the DB2 server must be configured in order for your DB2 server to accept inbound requests from remote DB2 clients. Before you configure TCP/IP communications for a DB2 instance: v Ensure that TCP/IP is functional on the DB2 server. TCP/IP must also be functional on the DB2 client to establish a connection. v Identify either a Connection Service name and Connection Port, or just a Connection Port. Connection Service Name and Connection Port The service name is used to update the Service name (svcename) parameter in the database manager configuration file at the server. When a Connection Service name is specified, the services file must be updated with the same Service name, a port number, and the protocol. The Service name is arbitrary but must be unique within the services file. A sample value for the service name could be server1. If you are using DB2 Enterprise Server Edition in a partitioned format, ensure that the port number does not conflict with the port numbers used by the Fast Communications Manager (FCM). The Connection port must be unique within the services file. A sample value for the port number and protocol could be 3700/tcp. Connection Port The Service name (svcename) parameter in the database manager configuration file at the server can be updated with a port number. If this is the case, it is not necessary to update the services file. If you are using DB2 Enterprise Server Edition in a partitioned format, ensure that the port number does not conflict with the port numbers used by the Fast Communications Manager (FCM) or any other applications on the system. A sample value for the port number could be 3700. Most protocols are automatically detected and configured when you set up DB2 using the DB2 Setup wizard. Perform the current task if: v You deselected the TCP/IP communication protocol when you set up DB2 using the DB2 Setup wizard. v You added the TCP/IP communication protocol to your network after you set up DB2 using the DB2 Setup wizard. v The TCP/IP communication protocol was not detected by the DB2 Setup wizard. v You installed a DB2 product using the db2_install command or the payload file method. To configure TCP/IP communications for a DB2 instance: 1. Update the services file on the server. 2. Update the database manager configuration file on the server. 3. Set communication protocols for a DB2 instance
223
Updating the database manager configuration file on the server for TCP/IP communications
This task is part of the main task of Configuring TCP/IP communications for a DB2 instance. You must update the database manager configuration file with the service name (svcename) parameter. To update the database manager configuration file: 1. Log on to the system as a user with System Administrative (SYSADM) authority. 2. If you are using a UNIX server, set up the instance environment:
. INSTHOME/sqllib/db2profile (for Bash, Bourne or Korn shell) source INSTHOME/sqllib/db2cshrc (for C shell)
3. Start the DB2 command line processor (CLP). 4. Update the database manager configuration file with the Service name (svcename) parameter by entering the following commands:
update database manager configuration using svcename [service_name | port_number] db2stop db2start
where: v service_name is the service name reserved in the services file v port_number is the corresponding port number for the service_name, or a free port number if the service_name is not reserved If a service name is being specified, the svcename used must match the Connection Service name specified in the services file. After the database manager is stopped and started again, view the database manager configuration file to ensure that these changes have taken effect. View the database manager configuration file by entering the following command:
get database manager configuration
Updating the services file on the server for TCP/IP communications

This task is part of the main task of Configuring TCP/IP communications for a DB2 instance. The TCP/IP services file specifies the ports that server applications can listen on for client requests. If you specified a service name in the svcename field of the DBM configuration file, the services file must be updated with the service name to port number/protocol mapping. If you specified a port number in the svcename field of the DBM configuration file, the services file does not need to be updated. Update the services file and specify the ports that you want the server to listen on for incoming client requests. The default location of the services file depends on the operating system: Linux and UNIX operating systems /etc/services Windows operating systems %SystemRoot%\system32\drivers\etc\services
224
Using a text editor, add the Connection entry to the services file. For example:
db2c_db2inst1 3700/tcp # DB2 connection service port
where: db2c_db2inst1 represents the connection service name 3700 tcp represents the connection port number represents the communication protocol that you are using
Chapter 22. Configuring DB2 server communications (TCP/IP)
225
226
Chapter 23. DB2 license files

There are two types of license files associated with DB2 database products: base license keys and full license keys. These license keys are stored in plaintext files, which are generally referred to as license files or license entitlement certificates. A base license does not confer any usage rights. It is included in the DB2 database product installation media and is applied automatically during the installation process. For example, db2ese.lic is a base license file for DB2 Enterprise Server Edition . License keys are required for all DB2 database products (including DB2 Connect) and for each optional database feature. The license key is found in the /db2/license directory of the Activation CD, which is supplied as a part of the product installation media. For example, db2ese_u.lic is a license key and can be found on the DB2 Enterprise Server Edition for Linux, UNIX, and Windows Authorized User Option Activation CD. By default, license keys are not applied during the DB2 database product installation. However, the following products do not have an Activation CD, therefore their license is automatically applied during the installation process: DB2 Express-C and DB2 Connect Personal Edition. In addition, DB2 Personal Edition is also a special case. Although DB2 Personal Edition has an Activation CD, its license is also automatically applied during installation. For a list of license files, refer to Table 25 on page 228. In general, licenses for DB2 database products can be purchased either per processor (priced by processor value unit (PVU)) or by authorized user. DB2 Express Edition can be purchased per server. IBM Database Enterprise Developer Edition is licensed per developer. The DB2 Storage Optimization feature is an exception. Since it can only be purchased by PVU (and only if the underlying database system is also licensed by PVU). If you purchased a DB2 database product as well as separately priced features, you will need to apply more than one license key. Each DB2 database product and DB2 feature has its own license key. All of the features must be acquired under the same charge metric as the underlying DB2 database product. For example, if you purchase DB2 Enterprise Server Edition with a per processor license, you would need to purchase the DB2 Performance Optimization Feature by processor as well. If you downloaded a DB2 database product or feature from one of the following Web sites and you do not have an Activation CD, you can obtain license keys as follows: v Passport Advantage: You can obtain an Activation CD image from the Passport Advantage Web site: http://www.ibm.com/software/lotus/passportadvantage/. When using Passport Advantage, you must download the Activation CD image for each product and feature separately. v PartnerWorld: Contact PartnerWorld for the appropriate license key. Refer to the PartnerWorld Web site: http://www.ibm.com/partnerworld/pwhome.nsf/ weblook/index_pub.html v The DB2 support or fix central Web sites: If you have not purchased a license key, contact an IBM Sales representative.
227
Once you have obtained the appropriate license keys, you should apply them before you use the DB2 database product. This is also referred to as registering the license key or adding a license. As a mechanism for you to keep track of, and differentiate, the DB2 database products and features you have installed on your system, it is recommended that you register the license key for your DB2 database products. You can find the DB2 database product license terms at: http://www.ibm.com/software/sla. The management of licenses for DB2 database products or features is done through either: v the db2licm license management tool command, or, v the License Center within the Control Center.
Table 25. DB2 license files License file name db2aac.lic db2conpe.lic db2consv.lic db2consv_as.lic db2consv_ee.lic db2consv_is.lic db2consv_zs.lic db2dede.lic db2dpf.lic db2ese.lic db2ese_c.lic db2ese_u.lic db2exp.lic db2exp_c.lic db2exp_s.lic db2exp_sftl.lic db2exp_u.lic db2exp_uftl.lic db2expc_uw.lic db2geo.lic db2hrese.lic db2haexp.lic db2pe.lic db2poese.lic DB2 database product or feature DB2 Advanced Access Control feature DB2 Connect Personal Edition DB2 Connect Server (Unlicensed base) DB2 Connect Application Server Edition DB2 Connect Enterprise Edition DB2 Connect Unlimited Edition for System i DB2 Connect Unlimited Edition for System z IBM Database Enterprise Developer Edition DB2 Database Partitioning feature DB2 Enterprise Server Edition (Unlicensed base) DB2 Enterprise Server Edition (CPU option) DB2 Enterprise Server Edition (Authorized User option) DB2 Express Edition (Unlicensed base) DB2 Express Edition (CPU option) DB2 Express Edition (Server option) DB2 Express Edition (Server option Fixed Term License) DB2 Express Edition (Authorized User option) DB2 Express Edition (Authorized User Option Fixed Term License) DB2 Express-C (Unwarranted) DB2 Geodetic Data Management Feature Homogeneous Replication Feature for DB2 Enterprise Server Edition DB2 High Availability feature for DB2 Express Edition DB2 Personal Edition DB2 Performance Optimization Feature for DB2 Enterprise Server Edition
228
Table 25. DB2 license files (continued) License file name db2so.lic db2wse.lic db2wse_c.lic db2wse_u.lic bwdb2.lic ewdb2.lic iwebe.lic iwde.lic iwdpb_c.lic iwdpb_u.lic iwdp_c.lic iwdp_u.lic iwee.lic sam31.lic DB2 database product or feature DB2 Storage Optimization feature DB2 Workgroup Server Edition (Unlicensed base) DB2 Workgroup Server Edition (CPU option) DB2 Workgroup Server Edition (Authorized User option) Base Warehouse Feature for DB2 Enterprise Warehouse Feature for DB2 InfoSphere Warehouse Enterprise Base Edition InfoSphere Warehouse Developer Edition InfoSphere Warehouse Departmental Base Edition CPU Option InfoSphere Warehouse Departmental Base Edition Authorized User Option InfoSphere Warehouse Departmental Edition CPU Option InfoSphere Warehouse Departmental Edition Authorized User Option InfoSphere Warehouse Enterprise Edition IBM Tivoli System Automation for Multiplatforms (SA MP)
If you have license files that end in _t.lic, they are trial licenses.
Applying DB2 licenses

To license your product, register the appropriate license key with your DB2 database product. If you want the license key added automatically during product installation, copy the license key to the /db2/license directory of the installation image before launching the DB2 Setup wizard. To use DB2 features or to be in compliance with your current product entitlement, you might be required to register additional license keys. For example, ensure you add the db2ese_c.lic or db2ese_u.lic licence files to the /db2/license directory of the installation image before installing DB2 Enterprise Server Edition. If you do not add any license files to the /db2/license directory, you will see a License not registered message in the output from the db2licm -l command or in the License Center. You can apply the licenses manually after the installation by running the db2licm -a command. If you register a valid license key, the db2licm -l command will successfully list all the products with available license information.
Chapter 23. DB2 licenses
229
Updating a Trial license

If you installed a DB2 product with a trial license and now want to update to a full license, you must update the product license key. You cannot use this method to update from one DB2 product to another. If a previously licensed copy of a DB2 server product does not already exist, a single server fix pack image can be used to install any of the DB2 database server products. In this case, the license installed is a trial license. To update your DB2 license: 1. Get the license key. The license key is available from either: v the activation key that you downloaded from Passport Advantage, or v the Activation CD that you received in the physical media pack from IBM. 2. Register the license key using the License Center or the db2licm command. Note: The trial license for DB2 Enterprise Server Edition on 32-bit Linux cannot be updated to a production license.
Registering a DB2 product or feature license key using the db2licm command
Use the db2licm command to apply the license entitlement certificate (also referred to as registering a license key). To complete this task, you must have the appropriate license file (*.lic). Refer to Chapter 23, DB2 license files, on page 227. On Windows operating systems, you must belong to the local Administrators or Power Users group to use the db2licm command with the -a command parameter. v On Windows operating systems, register a DB2 license key by entering the following command:
db2instance_path\bin\db2licm -a filename
where db2instance_path is where the DB2 instance was created and filename is the full path name and file name for the license file that corresponds to the product or feature you have purchased. v On Linux or UNIX operating systems, register a DB2 license key by entering the following command:
INSTHOME/sqllib/adm/db2licm -a filename
where INSTHOME represents the home directory of the instance owner and filename is the full path name and file name for the license file that corresponds to the product or feature you have purchased. The db2licm command can also be found in the path where the DB2 database product is installed. For example, /opt/IBM/db2/V9.7/adm on AIX, HP-UX or Solaris operating systems or /opt/ibm/db2/V9.7/adm on Linux operating systems, if you use the default installation directory.
230
Registering a DB2 product or feature license key using the License Center
From the License Center, use the Add License window to add new licenses on Linux or Windows operating systems. This action is also referred to as applying license entitlement certificates or adding a license. Important: The License Center has been deprecated in Version 9.7 and might be removed in a future release. For more information, see the Control Center tools and DB2 administration server (DAS) have been deprecated topic in the Whats New for DB2 Version 9.7 book. To complete this task, you must have the appropriate license file (*.lic). Refer to Chapter 23, DB2 license files, on page 227. On Linux operating systems, the instance owner must have read and execute privileges on the directory where the license files are located. To register a DB2 license key: 1. Click in the Control Center to open the License Center. Select the system for which you want to add a new license. 2. Select an instance. 3. The Installed Products field will display the name of the products that you have installed. Select a product. 4. Select Add from the License menu. The Add License dialog opens. 5. Select the license key (*.lic) that you want to add. 6. Click OK to add the license key. The license information is refreshed immediately in the License Center.
Setting the DB2 license policy using the db2licm command

For DB2 Connect Enterprise Edition the license policy controls and monitors the number of users that can connect simultaneously to a DB2 Connect server. For InfoSphere Replication Server or InfoSphere Federation Server, the license policy controls and monitors the number of connectors to a non-DB2 data source. 1. Before you set your license policy using the db2licm command, you need the product identifier. To list the product identifier information, enter the following command:
db2licm -l
The product identifier is listed in the Product Identifier field. 2. To set your license policy, perform one of the following depending on the type of licenses that you purchased. For example: v If you purchased a InfoSphere Replication Server or InfoSphere Federation Server Concurrent Connector policy, enter the following command:
db2licm -c isrs concurrent
or
db2licm -c isfs concurrent
231
v If you purchased a DB2 Connect Server Concurrent User policy, enter the following command:
db2licm -p db2consv concurrent
Setting the DB2 license policy using the License Center

For DB2 Connect Enterprise Edition the license policy controls and monitors the number of users that can connect simultaneously to a DB2 Connect server. For InfoSphere Replication Server or InfoSphere Federation Server, the license policy controls and monitors the number of connectors to a non-DB2 data source. Important: The License Center has been deprecated in Version 9.7 and might be removed in a future release. For more information, see the Control Center tools and DB2 administration server (DAS) have been deprecated topic in the Whats New for DB2 Version 9.7 book. To set your license policy using the License Center, perform the following depending on the type of licenses that you purchased: 1. In the License Center, select Change from the License menu. 2. In the Change License window, select the type of license that you have purchased. For example: v If you purchased a InfoSphere Replication Server or InfoSphere Federation Server Concurrent Connector policy, select Connector and enter the number of connector licenses that you purchased. v If you purchased a DB2 Connect Server Concurrent User license, select Concurrent users or Concurrent connect users and enter the number of user licenses that you have purchased.
Checking DB2 license compliance

Each DB2 database product and feature has a license key associated with it. The license key should be registered before using the DB2 database product or feature. To verify license compliance, run the db2licm command and generate a compliance report. Note: If you installed a DB2 database product trial image, the image includes access to all features available in the edition you are using. 1. Verify that you have registered the license keys for your DB2 database products. a. Open the License Center or issue the command db2licm -l. b. Examine the License Type information. v If you see License Type: Developer, it means that your DB2 database product was obtained as part of Database Enterprise Developer Edition for Linux, UNIX, and Windows. In this case, the IBM Database Enterprise Developer Edition license terms take precedence over the typical DB2 product license terms. v If you see License Type: Restricted use, it means that your DB2 database product was obtained as part of another IBM product. In this case, the license terms of the bundling product take precedence over the typical DB2 product license terms. v If you see License Type: License not registered, it means that only a base license key has been registered. You should register the appropriate full license key for the DB2 database product.
232
2. Verify that you have registered the license keys for your DB2 features. a. Generate a compliance report using the db2licm command or the License Center or query the ENV_FEATURE_INFO administrative view. v To generate compliance report using the db2licm command, issue the command:
db2licm -g filename
where filename is the path and file name where output is to be stored. v . To generate the compliance report from the License Center, select License Generate Compliance Report. v To see the compliance information in the ENV_FEATURE_INFO administrative view, connect to a database and issue the following query:
SELECT * FROM SYSIBMADM.ENV_FEATURE_INFO
b. Analyze the compliance report. If you have not registered the license key for a used DB2 feature, the compliance report will list the feature as a In Violation. 3. Resolve the compliance issues by registering the appropriate license keys or by removing the sources of the violation.
233
234
Part 6. Installing Tivoli System Automation for Multiplatforms
235
236
Chapter 24. Installing and upgrading the SA MP with the DB2 installer
IBM Tivoli System Automation for Multiplatforms (SA MP) is integrated with IBM Data Server on AIX and Linux as part of the DB2 High Availability (HA) Feature. You can install, upgrade, or uninstall SA MP using either the DB2 installer or the installSAM and uninstallSAM scripts that are included in the IBM Data Server install media. On Windows operating systems, the SA MP is bundled as part of the DB2 High Availability Feature, but it is not integrated with the DB2 installer. Before you begin v To install and use SA MP, your system configuration and intended use of SA MP must meet the terms of the license that comes with SA MP that is integrated with IBM Data Server. For information about the license details of SA MP that is integrated with IBM Data Server, see: License terms for using IBM Tivoli System Automation for Multiplatforms (SA MP) integrated with IBM Data Server on page 248 v To install or upgrade SA MP your system architecture must be supported by the SA MP that is integrated with IBM Data Server. For more information about SA MP supported software and hardware, see: Supported software and hardware for IBM Tivoli System Automation for Multiplatforms (SA MP) on page 248 v You must have root authority to install SA MP. If you perform a non-root install of IBM Data Server, you can install SA MP from the IBM Data Server install media separately. When you install SA MP separately, you still must have root authority. v SA MP does not support AIX system workload partitions (WPARs), Solaris 9 platform, Solaris x64 AMD64, or non-global zones on Solaris. For a list of supported platforms & system configurations, see http:// publib.boulder.ibm.com/tividd/td/ IBMTivoliSystemAutomationforMultiplatforms2.2.html. v If you plan to use DB2 High Availability with IBM Tivoli System Automation for Multiplatforms (SA MP) Version 3.1 on SUSE Linux Enterprise Server (SLES) 11, you must download and install SA MP Version 3.1 Fix Pack 4. To download the required fix pack, see: http://www.ibm.com/software/tivoli/support/sys-automulti
IBM Tivoli System Automation for Multiplatforms (SA MP)

IBM Tivoli System Automation for Multiplatforms (SA MP) provides high availability and disaster recovery capabilities for AIX, Linux, Solaris SPARC, and Windows. SA MP is integrated with DB2 Enterprise Server Edition, DB2 Workgroup Server Edition, DB2 Connect Enterprise Server Edition and DB2 Connect Application Server Edition on AIX, Linux, and Solaris SPARC operating systems. It is also integrated with DB2 Express-C Fixed Term License (FTL) and the DB2 High Availability Feature for Express Edition on Linux operating systems. On Windows operating systems, the SA MP is bundled with all of these DB2 database products and features, but it is not integrated with the DB2 installer.
237
You can use this copy of SA MP to manage the high availability of your DB2 database system; you cannot use it to manage other things in your cluster without buying an upgrade for the SA MP license. SA MP is the default cluster manager in an IBM Data Server clustered environment on AIX and Linux. For more information about SA MP, see: http://publib.boulder.ibm.com/tividd/ td/IBMTivoliSystemAutomationforMultiplatforms2.2.html. The list of supported operating systems is also available on the following Web site: http:// www.ibm.com/software/tivoli/products/sys-auto-linux/platforms.html.
Installing IBM Tivoli System Automation for Multiplatforms (SA MP)

You can install IBM Tivoli System Automation for Multiplatforms (SA MP) using either the DB2 installer or the installSAM install script that is included in the IBM Data Server install media. Before you begin Whether you are using the DB2 installer, installSAM, or uninstallSAM, you must meet the basic prerequisites for installing, upgrading, or uninstalling SA MP. See: Chapter 24, Installing and upgrading the SA MP with the DB2 installer, on page 237. If you already have SA MP installed, you can upgrade the installed version of SA MP using the DB2 installer or the installSAM install script. For more information about upgrading SA MP, see: Upgrading IBM Tivoli System Automation for Multiplatforms (SA MP) on page 240. Procedure There are two methods for installing or upgrading SA MP: v Using the DB2 installer v Using the installSAM install script that is included in the IBM Data Server install media What to do next Look in the SA MP install log for diagnostic information about any warnings or errors that the DB2 installer or the installSAM install script returned. For more information about the SA MP install log, see: IBM Tivoli System Automation for Multiplatforms (SA MP) install and uninstall logs on page 247.
Installing IBM Tivoli System Automation for Multiplatforms (SA MP) using the DB2 installer
You can install IBM Tivoli System Automation for Multiplatforms (SA MP) using the DB2 installer. Before you begin Whether you use the DB2 installer or the installSAM install script to install SA MP, you must meet the basic prerequisites for installing SA MP. See: Installing IBM Tivoli System Automation for Multiplatforms (SA MP).
238
About this task There are three methods for using the DB2 installer: v DB2 Setup wizard (install, upgrade, or uninstall) v Silent install using a response file with db2setup (install or upgrade) or db2unins (for uninstall) v db2_install command (for install), installFixPack command (for upgrade), or db2_deinstall command (for uninstall) Before installing SA MP on a given machine, the DB2 installer queries your system for the following information: v Is SA MP on your IBM Data Server install media? v Is SA MP already installed? The DB2 installer calls the installSAM install script to perform some parts of the SA MP install operation. Instead of using the DB2 installer to install SA MP, you can call installSAM directly. For more information about using the installSAM install script to install SA MP, see: Installing IBM Tivoli System Automation for Multiplatforms (SA MP) using the installSAM install script on page 240. You can use the -l option with db2setup, db2_install, or installFixPack to specify where the installSAM utility should place the SA MP install log. For more information about the SA MP install log, see: IBM Tivoli System Automation for Multiplatforms (SA MP) install and uninstall logs on page 247. Procedure v To install SA MP using DB2 Setup wizard, run DB2 Setup wizard and follow the instructions in the wizard. The information about your system that the DB2 installer collects determines which panels appear in the graphical interface of the DB2 Setup wizard during install. For example, if you already have SA MP installed, then the DB2 Setup wizard will not display a panel to install SA MP. v To install SA MP using a response file, set the response file keyword INSTALL_TSAMP to YES. In a response file installation operation, the default behavior of the DB2 installer is to install SA MP. If INSTALL_TSAMP is YES, or if INSTALL_TSAMP is commented out or missing from the response file, the DB2 installer will attempt to install SA MP. To prevent the DB2 installer from installing SA MP in a response file installation, set INSTALL_TSAMP to NO. v To install SA MP using db2_install, you can run db2_install without any parameters specific to SA MP. The default behavior of db2_install is to install SA MP. To prevent db2_install from installing SA MP, use the -f NOTSAMP option with db2_install. What to do next Whether you use the DB2 installer or the installSAM install script to install SA MP, follow the same post-installation steps. For more information about general post-install steps, see: Installing IBM Tivoli System Automation for Multiplatforms (SA MP) on page 238
Chapter 24. Installing the integrated cluster manager
239
Installing IBM Tivoli System Automation for Multiplatforms (SA MP) using the installSAM install script
You can install IBM Tivoli System Automation for Multiplatforms (SA MP) using the installSAM install script that is included in the IBM Data Server install media. Before you begin Whether you use the DB2 installer or the installSAM install script to install SA MP, you must meet the basic prerequisites for installing SA MP. See: Installing IBM Tivoli System Automation for Multiplatforms (SA MP) on page 238. Run the installSAM install script The installSAM install script is located on the IBM Data Server media at the following location:
db2/<platform>/tsamp
where <platform> refers to the appropriate hardware platform. For information about using installSAM see: http://publib.boulder.ibm.com/ tividd/td/IBMTivoliSystemAutomationforMultiplatforms2.2.html. What to do next Whether you use the DB2 installer or the installSAM install script to install SA MP, follow the same post-installation steps. For more information about general post-install steps, see: Installing IBM Tivoli System Automation for Multiplatforms (SA MP) on page 238 If you use the DB2 High Availability (HA) Feature with IBM Tivoli System Automation for Multiplatforms (SA MP) as your cluster manager, the database manager uses scripts to support DB2 High Availability Disaster Recovery (HADR) functions. These HADR scripts are installed or updated automatically when you use the DB2 installer to install or update SA MP. When you install or update SA MP using the installSam utility, then you must manually install or update these HADR scripts. For more information about installing or upgrading the HADR scripts manually, see: Installing, updating, and uninstalling DB2 High Availability Disaster Recovery (HADR) scripts for the IBM Tivoli System Automation for Multiplatforms (SA MP) on page 245.
Upgrading IBM Tivoli System Automation for Multiplatforms (SA MP)

You can upgrade IBM Tivoli System Automation for Multiplatforms (SA MP) using either the DB2 installer or the installSAM install script that is included in the IBM Data Server install media. Before you begin Whether you are using the DB2 installer, installSAM, or uninstallSAM, you must meet the basic prerequisites for installing, upgrading, or uninstalling SA MP. See: Chapter 24, Installing and upgrading the SA MP with the DB2 installer, on page 237. If you already have SA MP installed, you can upgrade the installed version of SA MP using the DB2 installer or the installSAM install script. For more information about upgrading SA MP, see: Upgrading IBM Tivoli System Automation for Multiplatforms (SA MP).
240
Restrictions v The version of SA MP that is on the IBM Data Server install media is Version 3.1. v You cannot upgrade SA MP using either the DB2 installer or the installSAM install script included in the IBM Data Server install media if you have one or more IBM Reliable Scalable Cluster Technology (RSCT) peer domains defined on your system. Procedure There are two methods for installing or upgrading SA MP: v Using the DB2 installer v Using the installSAM install script that is included in the IBM Data Server install media What to do next Look in the SA MP install log for diagnostic information about any warnings or errors that the DB2 installer or the installSAM install script returned. For more information about the SA MP install log, see: IBM Tivoli System Automation for Multiplatforms (SA MP) install and uninstall logs on page 247.
Upgrading IBM Tivoli System Automation for Multiplatforms (SA MP) using the DB2 installer
You can upgrade IBM Tivoli System Automation for Multiplatforms (SA MP) using the DB2 installer. Before you begin Whether you use the DB2 installer or the installSAM install script that is included in the IBM Data Server install media to upgrade SA MP, you must meet the basic prerequisites for upgrading SA MP. See: Upgrading IBM Tivoli System Automation for Multiplatforms (SA MP) on page 240. About this task There are three methods for using the DB2 installer: v DB2 Setup wizard (install, upgrade, or uninstall) v Silent install using a response file with db2setup (install or upgrade) or db2unins (for uninstall) v db2_install command (for install), installFixPack command (for upgrade), or db2_deinstall command (for uninstall) Before upgrading SA MP on a given machine, the DB2 installer queries your system for the following information: v If SA MP is already installed, is the version of SA MP that is already installed older than the version of SA MP that is on the IBM Data Server install media? The DB2 installer calls the installSAM install script to perform some parts of the SA MP upgrade operation. You can call installSAM directly. For more information about using the installSAM install script to upgrade SA MP, see: Upgrading IBM Tivoli System Automation for Multiplatforms (SA MP) using the installSAM install script on page 242.
241
You can use the -l option with db2setup, db2_install, or installFixPack to specify where the installSAM utility should place the SA MP install log. For more information about the SA MP install log, see: IBM Tivoli System Automation for Multiplatforms (SA MP) install and uninstall logs on page 247. Procedure v To upgrade SA MP using DB2 Setup wizard, run DB2 Setup wizard and follow the instructions in the wizard. The information about your system that the DB2 installer collects determines which panels appear in the graphical interface of the DB2 Setup wizard during the upgrade. For example, if the version of SA MP that you already have installed is at the same version as, or at a later version than the version of SA MP that is on the IBM Data Server install media, then the DB2 Setup wizard will not display a panel to upgrade SA MP. v To upgrade SA MP using a response file, set the response file keyword INSTALL_TSAMP to YES. In a response file installation operation, the default behavior of the DB2 installer is to upgrade SA MP if the version of SA MP that is already installed is older than the version that is on the IBM Data Server install media. If INSTALL_TSAMP is YES, or if INSTALL_TSAMP is comment out or missing from the response file, the DB2 installer will attempt to upgrade SA MP. To prevent the DB2 installer from upgrading SA MP in a response file installation, set INSTALL_TSAMP to NO. v To upgrade SA MP using db2_install, you can run db2_install without any parameters specific to SA MP. The default behavior of db2_install is to upgrade SA MP if the version of SA MP that is already installed is older than the version that is on the IBM Data Server install media. To prevent db2_install from upgrading SA MP, use the -f NOTSAMP option with db2_install. What to do next Whether you use the DB2 installer or the installSAM install script to upgrade SA MP, follow the same post-upgrade steps. For more information about general post-upgrade steps, see: Installing IBM Tivoli System Automation for Multiplatforms (SA MP) on page 238
Upgrading IBM Tivoli System Automation for Multiplatforms (SA MP) using the installSAM install script
You can upgrade IBM Tivoli System Automation for Multiplatforms (SA MP) using the installSAM install script that is included in the IBM Data Server install media. Before you begin Whether you use the DB2 installer or the installSAM install script that is included in the IBM Data Server install media to upgrade SA MP, you must meet the basic prerequisites for upgrading SA MP. See: Upgrading IBM Tivoli System Automation for Multiplatforms (SA MP) on page 240. Run the installSAM install script The installSAM install script is located on the IBM Data Server media at the following location:
242
where <platform> refers to the appropriate hardware platform. For information about using installSAM see: http://publib.boulder.ibm.com/ tividd/td/IBMTivoliSystemAutomationforMultiplatforms2.2.html. What to do next Whether you use the DB2 installer or the installSAM install script to install SA MP, follow the same post-installation steps. For more information about general post-install steps, see: Installing IBM Tivoli System Automation for Multiplatforms (SA MP) on page 238 If you use the DB2 High Availability (HA) Feature with IBM Tivoli System Automation for Multiplatforms (SA MP) as your cluster manager, the database manager uses scripts to support DB2 High Availability Disaster Recovery (HADR) functions. These HADR scripts are installed or updated automatically when you use the DB2 installer to install or update SA MP. When you install or update SA MP using the installSam utility, then you must manually install or update these HADR scripts. For more information about installing or upgrading the HADR scripts manually, see: Installing, updating, and uninstalling DB2 High Availability Disaster Recovery (HADR) scripts for the IBM Tivoli System Automation for Multiplatforms (SA MP) on page 245.
Uninstalling IBM Tivoli System Automation for Multiplatforms (SA MP)

You can uninstall IBM Tivoli System Automation for Multiplatforms (SA MP) using either the DB2 installer or the uninstallSAM uninstall script that is included in the IBM Data Server install media. Before you begin Whether you are using the DB2 installer, installSAM, or uninstallSAM, you must meet the basic prerequisites for installing, upgrading, or uninstalling SA MP. See: Chapter 24, Installing and upgrading the SA MP with the DB2 installer, on page 237. If you already have SA MP installed, you can upgrade the installed version of SA MP using the DB2 installer or the installSAM install script. For more information about upgrading SA MP, see: Upgrading IBM Tivoli System Automation for Multiplatforms (SA MP) on page 240. Procedure There are two methods for uninstalling SA MP: v Using the DB2 installer v Using the uninstallSAM uninstall script that is included in the IBM Data Server install media What to do next Look in the SA MP uninstall log for diagnostic information about any warnings or errors that the DB2 installer or the uninstallSAM uninstall script returned. For more information about the SA MP uninstall log, see: IBM Tivoli System Automation for Multiplatforms (SA MP) install and uninstall logs on page 247.
243
Uninstalling IBM Tivoli System Automation for Multiplatforms (SA MP) using the DB2 installer
You can uninstall IBM Tivoli System Automation for Multiplatforms (SA MP) using the DB2 installer. Before you begin Whether you use the DB2 installer or the uninstallSAM uninstall script that is included in the IBM Data Server install media to uninstall SA MP, you must meet the basic prerequisites for uninstalling SA MP. See: Uninstalling IBM Tivoli System Automation for Multiplatforms (SA MP) on page 243. About this task There are three methods for using the DB2 installer: v DB2 Setup wizard (install, upgrade, or uninstall) v Silent install using a response file with db2setup (install or upgrade) or db2unins (for uninstall) v db2_install command (for install), installFixPack command (for upgrade), or db2_deinstall command (for uninstall) The DB2 installer calls the uninstallSAM install script to perform parts of the SA MP uninstall. You can call uninstallSAM directly. For more information about using the uninstallSAM script to uninstall SA MP, see: Uninstalling IBM Tivoli System Automation for Multiplatforms (SA MP) using the uninstallSAM uninstall script. You can use the -l option with db2setup, db2_install, or installFixPack to specify where the installSAM utility should place the SA MP install log. For more information about the SA MP install log, see: IBM Tivoli System Automation for Multiplatforms (SA MP) install and uninstall logs on page 247. Procedure To uninstall SA MP using db2_deinstall, you can run db2_deinstall with the -a -F TSAMP option. By default, the DB2 installer will not uninstall SA MP when you run db2_deinstall. What to do next Whether you use the DB2 installer or the uninstallSAM uninstall script that is included with the IBM Data Server install media to uninstall SA MP, follow the same post-uninstall steps. For more information about general post-uninstall steps, see: Uninstalling IBM Tivoli System Automation for Multiplatforms (SA MP) on page 243
Uninstalling IBM Tivoli System Automation for Multiplatforms (SA MP) using the uninstallSAM uninstall script
You can uninstall IBM Tivoli System Automation for Multiplatforms (SA MP) using the uninstallSAM uninstall script that is included in the IBM Data Server install media. Before you begin
244
Whether you use the DB2 installer or the uninstallSAM uninstall script that is included in the IBM Data Server install media to uninstall SA MP, you must meet the basic prerequisites for uninstalling SA MP. See: Uninstalling IBM Tivoli System Automation for Multiplatforms (SA MP) on page 243. Run the uninstallSAM uninstall script The uninstallSAM uninstall script is located on the IBM Data Server media at the following location:
where <platform> refers to the appropriate hardware platform. For information about using uninstallSAM see: http://publib.boulder.ibm.com/ tividd/td/IBMTivoliSystemAutomationforMultiplatforms2.2.html. What to do next Whether you use the DB2 installer or the installSAM install script to install SA MP, follow the same post-installation steps. For more information about general post-install steps, see: Installing IBM Tivoli System Automation for Multiplatforms (SA MP) on page 238 If you use the DB2 High Availability (HA) Feature with IBM Tivoli System Automation for Multiplatforms (SA MP) as your cluster manager, the database manager uses scripts to support DB2 High Availability Disaster Recovery (HADR) functions. These HADR scripts are uninstalled automatically when you run db2_deinstall to uninstall SA MP. When you uninstall SA MP using the uninstallSam utility, then you must manually uninstall these HADR scripts. For more information about uninstalling the HADR scripts manually, see: Installing, updating, and uninstalling DB2 High Availability Disaster Recovery (HADR) scripts for the IBM Tivoli System Automation for Multiplatforms (SA MP).
Installing, updating, and uninstalling DB2 High Availability Disaster Recovery (HADR) scripts for the IBM Tivoli System Automation for Multiplatforms (SA MP)
If you use the DB2 High Availability (HA) Feature with IBM Tivoli System Automation for Multiplatforms (SA MP) as your cluster manager, the database manager uses scripts to support DB2 High Availability Disaster Recovery (HADR) functions. You can install, upgrade, and uninstall these SA MP HADR scripts using the DB2 installer, or the installSAM or uninstallSAM scripts that are included in the IBM Data Server install media. Before you begin v To install, upgrade, or uninstall SA MP HADR scripts using the DB2 installer or the installSAM or uninstallSAM scripts that are included in the IBM Data Server install media, you must purchase the DB2 High Availability Feature. v You must have root authority to install, upgrade, or uninstall SA MP HADR scripts. If you perform a non-root install of IBM Data Server, you can install the SA MP HADR scripts from the IBM Data Server install media separately. When you install the SA MP HADR scripts separately, you still must have root authority. Procedure
245
There are two methods for installing, upgrading, and uninstalling SA MP HADR scripts: v Using the DB2 installer v Manually installing from the IBM Data Server install media Results When you install the SA MP HADR scripts, the scripts are installed in the following location:
/usr/sbin/rsct/sapolicies/db2
If you uninstall the SA MP HADR scripts, you can no longer use HADR functions within a cluster managed by SA MP.
Installing, updating, and uninstalling DB2 High Availability Disaster Recovery (HADR) scripts for the IBM Tivoli System Automation for Multiplatforms (SA MP) using DB2 installer
You can install, upgrade, or uninstall IBM Tivoli System Automation for Multiplatforms (SA MP) DB2 High Availability Disaster Recovery (HADR) scripts using the DB2 installer. Before you begin Whether you use the DB2 installer or manually install, upgrade, or uninstall SA MP HADR scripts, you must meet the basic prerequisites for installing, upgrading, and uninstalling SA MP HADR scripts. See: Installing, updating, and uninstalling DB2 High Availability Disaster Recovery (HADR) scripts for the IBM Tivoli System Automation for Multiplatforms (SA MP) on page 245. About this task There are three methods for using the DB2 installer: v DB2 Setup wizard (install, upgrade, or uninstall) v Silent install using a response file with db2setup (install or upgrade) or db2unins (for uninstall) v db2_install command (for install), installFixPack command (for upgrade), or db2_deinstall command (for uninstall) Procedure 1. To install SA MP HADR scripts, run the DB2 installer. By default, the DB2 installer installs SA MP HADR scripts if SA MP is installed or being installed, and the scripts are not already installed. 2. To upgrade the SA MP HADR scripts, run the DB2 installer. By default, the DB2 installer will upgrade SA MP HADR scripts if SA MP is installed or being installed, and the scripts that are already installed are at a lower version than the version of the scripts that are on the IBM Data Server install media. 3. To uninstall SA MP HADR scripts, run the DB2 installer. Results
246
Whether you use the DB2 installer or manually install, upgrade, or uninstall SA MP HADR scripts, the general results are the same, see: Installing, updating, and uninstalling DB2 High Availability Disaster Recovery (HADR) scripts for the IBM Tivoli System Automation for Multiplatforms (SA MP) on page 245.
Installing, updating, and uninstalling DB2 High Availability Disaster Recovery (HADR) scripts for the IBM Tivoli System Automation for Multiplatforms (SA MP) manually
You can manually install, upgrade, or uninstall IBM Tivoli System Automation for Multiplatforms (SA MP) DB2 High Availability Disaster Recovery (HADR) scripts from the IBM Data Server install media. Before you begin Whether you use the DB2 installer or manually install, upgrade, or uninstall SA MP HADR scripts, you must meet the basic prerequisites for installing, upgrading, and uninstalling SA MP HADR scripts. See: Installing, updating, and uninstalling DB2 High Availability Disaster Recovery (HADR) scripts for the IBM Tivoli System Automation for Multiplatforms (SA MP) on page 245. About this task The SA MP HADR scripts are installed automatically by the DB2 installer when SA MP is installed or being installed. If you install or upgrade SA MP manually, then you must install or upgrade the SA MP HADR scripts manually. The DB2 installer does not uninstall the SA MP HADR scripts, so to remove these scripts, you must uninstall them manually. Procedure To install, update, or uninstall SA MP HADR scripts manually, use the db2cptsa utility. Results Whether you use the DB2 installer or manually install, upgrade, or uninstall SA MP HADR scripts, the general results are the same, see: Installing, updating, and uninstalling DB2 High Availability Disaster Recovery (HADR) scripts for the IBM Tivoli System Automation for Multiplatforms (SA MP) on page 245.
IBM Tivoli System Automation for Multiplatforms (SA MP) install and uninstall logs
Diagnostic information, warnings, and error messages related to installing, upgrading, and uninstalling IBM Tivoli System Automation for Multiplatforms (SA MP) are located in install and uninstall logs specific to SA MP. You can install, upgrade, or uninstall SA MP using the DB2 installer, or the installSAM or uninstallSAM scripts that are included on the IBM Data Server install media. In fact, the DB2 installer uses the installSAM utility and the uninstallSAM utility to perform part of the install, upgrade, and uninstall operations.
247
The installSAM utility generates a sequence of log files that are named sequentially:
/tmp/installSAM.<log-number>.log
where log-number identifies the log file in the sequence. You can use the -l option with db2setup, db2_install, or installFixPack to specify where the installSAM utility should place the SA MP install log. The uninstallSAM utility generates a sequence of log files that are named sequentially:
/tmp/uninstallSAM.<log-number>.log
log-number identifies the log file in the sequence. You can use the -l option with db2unins or db2_deinstall to specify where the uninstallSAM utility should place the SA MP uninstall log.
License terms for using IBM Tivoli System Automation for Multiplatforms (SA MP) integrated with IBM Data Server
There are conditions under which you can use IBM Tivoli System Automation for Multiplatforms (SA MP) that is integrated with IBM Data Server. You can use SA MP that is integrated with IBM Data Server with DB2 High Availability Disaster Recovery (HADR) functionality if you have purchased a license for one of: v DB2 Enterprise Server Edition v v DB2 Connect Enterprise Edition DB2 Workgroup Server Edition
Also you can use SA MP that is integrated with IBM Data Server with HADR functionality if you have purchased a license for the DB2 High Availability Feature and one of: v DB2 Express Edition You can use a try and buy version of SA MP that is integrated with IBM Data Server with HADR functionality if you have a try and buy license for one of: v DB2 Enterprise Server Edition v DB2 Connect Enterprise Edition v DB2 Workgroup Server Edition v DB2 Express Edition
Supported software and hardware for IBM Tivoli System Automation for Multiplatforms (SA MP)
IBM Tivoli System Automation for Multiplatforms (SA MP) is integrated with IBM Data Server and supported on AIX, Linux and Solaris SPARC. It is also bundled with IBM Data Server on Windows. SA MP is integrated or bundled with the following DB2 database products and features:
248
v v v v v
DB2 DB2 DB2 DB2 DB2
Enterprise Server Edition Connect Enterprise Edition Workgroup Server Edition Express-C Fixed Term License (FTL) High Availability feature for Express Edition
In particular, the integrated or bundled copy of SA MP is supported on the following operating systems and hardware: v AIX Version 5.3 and 6.1 on the following hardware: eServer pSeries IBM System p IBM System p5 v Linux distributions: Red Hat Enterprise Linux (RHEL) 5 Update 2 SUSE Linux Enterprise Server (SLES) 10 Service Pack 2 On the following hardware: x86 (Intel Pentium, Intel Xeon, and AMD) 32-bit Intel and AMD processors x64 (64-bit AMD64 and Intel EM64T processors) POWER (IBM eServer OpenPower, System i or pSeries systems that support Linux) eServer System z or System z9 Microsoft Windows Sever 2003 R2 Standard Edition (32-bit) Microsoft Windows Sever 2003 R2 Enterprise Edition (32-bit) Microsoft Windows Sever 2008 Standard Edition (32-bit) Microsoft Windows Sever 2008 Enterprise Edition (32-bit) Microsoft Windows Sever 2008 Datacenter Edition (32-bit) Solaris 10 on SPARC (64bit)
v v v v v v
If you plan on using DB2s High Availability feature, ensure that your system meets the prerequisites for the SA MP. For more details, see the Installation and Configuration Guide at http://publib.boulder.ibm.com/tividd/td/ IBMTivoliSystemAutomationforMultiplatforms2.2.html If you are not using the integrated or bundled copy of IBM Tivoli System Automation for Multiplatforms (SA MP), refer to the following Web site for the full list of supported operating systems: http://www.ibm.com/software/tivoli/ products/sys-auto-linux/platforms.html.
249
250
Part 7. IBM Tivoli Monitoring for Databases: DB2 Agent
251
252
Chapter 25. IBM Tivoli Monitoring for Databases: DB2 Agent

The IBM Tivoli Monitoring for Databases: DB2 Agent monitors the availability and performance information of DB2 servers. The IBM Tivoli Monitoring for Databases: DB2 Agent provides useful historical data that you can use to track trends and to troubleshoot system problems. Installation of the Monitoring Agent for DB2 is supported on Windows operating systems, and, root installations on Linux and UNIX operating systems. The Monitoring Agent for DB2 that is installed with the DB2 product is intended for users of Optim Database Administrator. Use of the Monitoring Agent for DB2 is specifically restricted to supplying monitoring information to the Optim Database Administrator Health and Availability monitoring feature only. For more information about the IBM Tivoli Monitoring for Databases: DB2 Agent, see http://publib.boulder.ibm.com/infocenter/tivihelp/v15r1/index.jsp?topic=/ com.ibm.itmfd.doc/main_db2.htm
Installing IBM Tivoli Monitoring for Databases: DB2 Agent with the DB2 installer
The IBM Tivoli Monitoring for Databases: DB2 Agent that is installed with the DB2 product is intended for users of Optim Database Administrator. Use of the Monitoring Agent for DB2 is specifically restricted to supplying monitoring information to the Optim Database Administrator Health and Availability monitoring feature only. Installation of the Monitoring Agent for DB2 is supported on Windows operating systems, and, root installations on Linux and UNIX operating systems. Before you begin When installing a DB2 product with either the DB2 setup wizard or a response file, the Monitoring Agent for DB2 is installed by default. If you install your DB2 product using a response file, you can choose to not install the Monitoring Agent for DB2 by changing the value of the INSTALL_ITMA keyword. For more details, see Response file keywords. On Windows operating systems: v Installation of the Monitoring Agent for DB2 is supported on all platforms supported by DB2 products, except Windows Vista and Windows 2008. This support includes installing a Monitoring Agent for DB2 with a non-administrator account with elevated privileges. v If the DB2 copy being installed is the default copy, all DB2 instances are configured to use this copy of the Monitoring Agent for DB2. If this DB2 copy is not the default copy, the Monitoring Agent for DB2 instance created during the installation is configured to use the default DB2 copy. v During DB2 product installation, if a previous IBM Tivoli Monitoring for Databases product already exists on the system, and, the existing Monitoring Agent for DB2 was not installed as part of a previous DB2 product installation, the DB2 installer does not configure DB2 instances for using the Monitoring Agent for DB2. In this case, neither the pre-existing Monitoring Agent for DB2,
253
nor the Monitoring Agent for DB2 installed as part of the DB2 product installation are used. In addition, the Monitoring Agent for DB2 instance created during this DB2 product installation is not configured to use the default DB2 copy. v If you have multiple DB2 copies on the same computer, some DB2 copies might have a Monitoring Agent for DB2 installed and some DB2 copies might not. Only one DB2 copy can be the default. When you switch DB2 default copy, you need to consider the following: if the current DB2 default copy had a Monitoring Agent for DB2 installed, and you switch to a DB2 copy that does not have a Monitoring Agent for DB2 installed, all Monitoring Agent for DB2 instances are unconfigured. if the current DB2 default copy does not have a Monitoring Agent for DB2 installed, and you switch to a DB2 copy with a Monitoring Agent for DB2, you must create and configure the Monitoring Agent for DB2 instances for all DB2 instances on the system. On Linux and UNIX operating systems: v Installation of the Monitoring Agent for DB2 is valid for root installations only on all Linux and UNIX platforms that support the following DB2 products: DB2 Enterprise Server Edition, DB2 Workgroup Server Edition, DB2 Personal Edition, DB2 Express Edition, DB2 Connect Enterprise Edition. v The Monitoring Agent for DB2 exists at the predefined location on the image media. v Multiple copies of the Monitoring Agent for DB2 are allowed on the same system, however, each Monitoring Agent for DB2 must be configured to a different DB2 copy. If a copy of the Monitoring Agent for DB2 is already installed with the current DB2 copy, the DB2 installer will not install the Monitoring Agent for DB2. Procedure v To install the Monitoring Agent for DB2 using DB2 Setup wizard, run DB2 Setup wizard and follow the instructions in the wizard. The Monitoring Agent for DB2 is installed by default. v To install the Monitoring Agent for DB2 using a response file, ensure the response file keyword INSTALL_ITMA is set to YES. In a response file installation operation, the default behavior of the DB2 installer is to install the Monitoring Agent for DB2 . If INSTALL_ITMA is YES, or if INSTALL_ITMA is commented out or missing from the response file, the DB2 installer will install the Monitoring Agent for DB2. To prevent the DB2 installer from installing ITMA in a response file installation, set INSTALL_ITMA to NO. Check the messages in the log file when the installation finishes. v On Windows operating systems, by default the installation log file is located in the My Documents\DB2LOG\ directory. The log file uses the following format: DB2-ProductAbrrev-DateTime.log, for example, DB2-ESE-Tue Apr 04 17_04_45 2009.log. v On Linux and UNIX operating systems, by default the installation logs are located in the /tmp directory: db2setup.log db2setup.err v The itm_install.log is located in the DB2 installation path. For example, DB2DIR/itma/logs/itm_install.log, where DB2DIR represents the location where the DB2 copy is installed.
254
Uninstalling IBM Tivoli Monitoring for Databases: DB2 Agent with the DB2 installer
IBM Tivoli Monitoring for Databases: DB2 Agent is uninstalled automatically as part of the DB2 product uninstallation process. About this task On Windows operating systems, the Monitoring Agent for DB2 is uninstalled when uninstalling the last DB2 server product in a DB2 copy. On Linux and UNIX operating systems, the Monitoring Agent for DB2 is uninstalled when the entire DB2 copy is removed. Procedure You cannot uninstall just the Monitoring Agent for DB2. The Monitoring Agent for DB2 is uninstalled as part of the DB2 product uninstallation. For details and instructions, see the Uninstalling your DB2 product topic.
Chapter 25. IBM Tivoli Monitoring for Databases: DB2 Agent
255
256
Part 8. Uninstalling
257
258
Chapter 26. Uninstalling your DB2 product (Windows)

Uninstalling your DB2 product (Windows)
This task provides steps for completely removing your DB2 product from your Windows operating system. Only perform this task if you no longer require your existing DB2 instances and databases. If you are uninstalling the default DB2 copy, and you have other DB2 copies on your system, use the db2swtch command to choose a new default copy before you proceed with the uninstallation. Also, if your DB2 Administration Server (DAS) is running under the copy being removed, move your DAS to a copy that is not being removed. Otherwise, re-create the DAS using the db2admin create command after the uninstall, and you reconfigure the DAS for some function to work. To remove your DB2 product from Windows: 1. (Optional) Drop all databases using the Control Center or drop database command. Be sure that you no longer need these databases. If you drop your databases, all of your data will be gone. 2. Stop all DB2 processes and services. This can be done through the Windows Services panel or by issuing the db2stop command. If DB2 services and processes are not stopped before attempting to remove your DB2 product, you will receive a warning containing a list of processes and services that are holding DB2 DLLs in memory. If you will use Add/Remove Programs to remove your DB2 product, this step is optional. 3. You have two options for removing your DB2 product: Add/Remove Programs Accessible through the Windows Control Panel, use the Add/Remove Programs window to remove your DB2 product. Refer to your operating systems help for more information about removing software products from your Windows operating system. db2unins command You can run the db2unins command from the DB2DIR\bin directory to remove your DB2 products, features, or languages. Using this command, you can uninstall multiple DB2 products at the same time using the /p parameter. You can use a response file to uninstall DB2 products, features, or languages using /u parameter. For more information, see the db2unins command topic. Unfortunately, your DB2 product cannot always be removed by using the Control Panel - Add/Remove Programs facility or using the db2unins /p command or the db2unins /u command. The following uninstallation option must ONLY be attempted if the previous method fails. To forcefully remove all DB2 copies from your Windows system, run the db2unins /f command. This command will perform a brute force uninstallation of ALL DB2 copies on the system. Everything except user data, such as DB2 databases, will be forcefully deleted. Before running this command with the /f parameter, see the db2unins command for details.
259
Uninstalling a DB2 product, feature, or language using a response file (Windows)

Before you begin the uninstallation, ensure that you have all the required user accounts to perform the uninstallation. To silently uninstall DB2 products, features, or languages in a DB2 copy, use the db2unins command with the -u option. If you have DB2 products installed in various installation paths, you must run this command separately from each installation path. Sample response file, db2un.rsp, is in DB2DIR\install, where DB2DIR specifies the path where the DB2 product was installed. If you have a clustered environment, before uninstalling your DB2 product you must run the db2mscs command, with the -u option, from the same server that originally ran the db2mscs command to create the failover infrastructure. For details, see the db2mscs command. To perform an uninstallation: 1. Customize the db2un.rsp response file. To activate an item in the response file, remove the asterisk (*) to the left of the keyword. Then, replace the current setting to the right of the value with the new setting. The possible settings are listed to the right of the equal sign. 2. Run the db2unins command. For example, db2unins -u c:\db2un.rsp. The db2unins command is found under the SQLLIB\BIN directory. 3. Check the messages in the log file when the uninstallation finishes. The default log file location is My Documents\DB2LOG\db2un_<timestamp>.log.
260
Chapter 27. Uninstalling your DB2 product (Linux and UNIX)

This task provides steps for removing a DB2 product from your Linux or UNIX operating system. This task is not required to install a new version of a DB2 product. Each version of a DB2 product on Linux or UNIX has a different installation path and can therefore coexist on the same computer. Note: This task applies to DB2 products that were installed with root authority. A separate topic explains how to uninstall DB2 products that were installed as a non-root user. To remove your DB2 product: 1. Optional: Drop all databases. You can drop databases using the Control Center or the drop database command. Database files remain intact on your file systems when you drop an instance without dropping databases first. 2. Stop the DB2 Administration Server. Refer to the Installing DB2 Servers manual. 3. Remove the DB2 Administration Server, or run the dasupdt command to update the DB2 Administration Server to another installation path. To remove the DB2 Administration Server, refer to the Installing DB2 Servers manual. 4. Stop all DB2 instances. Refer to the Installing DB2 Servers manual. 5. Remove the DB2 instances, or run the db2iupdt command to update the instances another installation path. To remove the DB2 instances, refer to the Installing DB2 Servers manual. 6. Remove the DB2 products. Refer to the Installing DB2 Servers manual.
Stopping the DB2 administration server (Linux and UNIX)

You must stop the DB2 administration server (DAS) before you remove your DB2 product. When uninstalling a DB2 product, you must drop the DAS if you are removing your last DB2 copy. If you have other DB2 copies, it is recommended that you run the dasupdt command to associate the DAS with another DB2 copy. If you decide to drop the DAS, you must stop the DAS first. Note: This task does not apply to non-root installations of DB2 products. To stop the DB2 administration server: 1. Log in as the DB2 administration server owner. 2. Stop the DB2 administration server by entering the db2admin stop command.
Removing the DB2 administration server (Linux and UNIX)

If you are removing your last DB2 copy, you must remove the DB2 administration server (DAS) before you remove your DB2 product. If you removing a DB2 copy, but have other DB2 copies, run the dasupdt command from the DB2 copy that you want to have the DB2 DAS associated with.
261
Note: This task applies only to DB2 products that were installed with root authority. To remove the DAS: 1. Log in as a user with root authority. 2. Stop the DAS:
db2admin stop
3. Remove the DAS by entering the following command:

DB2DIR/instance/dasdrop
where DB2DIR is the location you specified during the DB2 installation. The default installation path for UNIX is /opt/IBM/db2/V9.7. The default installation path for Linux is /opt/ibm/db2/V9.7.
Stopping root instances (Linux and UNIX)

You must stop all DB2 instances associated with the DB2 copy you are uninstalling. Instances associated with other DB2 copies might not be affected by uninstalling the current copy. Note: This task applies to DB2 products that were installed with root authority. To stop a DB2 instance: 1. Log in as a user with root authority. 2. Obtain a list of the names of all DB2 instances associated with your current DB2 copy by entering the following command:
DB2DIR/bin/db2ilist
where DB2DIR is the location you specified during the DB2 Version 9 installation. The default installation path for UNIX is /opt/IBM/db2/V9.7. The default installation path for Linux is /opt/ibm/db2/V9.7. 3. Run the script if it is not included in .profile.
. INSTHOME/sqllib/db2profile source INSTHOME/sqllib/db2cshrc (bash, Bourne, or Korn shells) (C shell)
where INSTHOME is the home directory of the instance. 4. It is recommended that you save the following files: v The database manager configuration file, $HOME/sqllib/db2systm v The node configuration file, $HOME/sqllib/db2nodes.cfg v User defined functions or fenced stored procedure applications in $HOME/sqllib/function 5. Stop the DB2 database manager by entering the db2stop force command. 6. Confirm that the instance is stopped by entering the db2 terminate command. 7. Repeat these steps for each instance.
Removing DB2 instances (Linux and UNIX)

This task explains how to remove some or all of the root instances on your system. Note: This task does not apply to non-root installations. To remove a non-root instance, you must uninstall your DB2 product.
262
If you are removing your last DB2 Version 9 copy, you can remove the DB2 instances before you remove your DB2 product. If you removing a DB2 Version 9 copy, but have other DB2 Version 9 copies, you can run the db2iupdt command from the DB2 copy that you would like to have the DB2 instances associated with. Once an instance is removed, you can use the DB2 databases owned by the instance if you catalog them under another instance of the same release. Even though you remove the instance, the databases are still intact and can be reused unless the database files are expressly deleted. Remove DB2 instances only if you are not planning to use your DB2 products, or if you do not want to upgrade existing instances to a later version of the DB2 product. Upgrading requires that both the new and old DB2 versions are still installed. You cannot upgrade an instance if the DB2 copy it is associated with has been removed. To remove an instance: 1. Log in as a user with root authority. 2. Optional: If you are certain you no longer need the data in the associated databases, you can remove the database files from the systems or drop the databases before dropping the instance. 3. Remove the instance by entering the following command:
DB2DIR/instance/db2idrop InstName
where DB2DIR is the location you specified during the DB2 installation. The default installation path for UNIX is /opt/IBM/db2/V9.7. The default installation path for Linux is /opt/ibm/db2/V9.7. The db2idrop command removes the instance entry from the list of instances and removes the INSTHOME/sqllib directory, where INSTHOME is the home directory of the instance and where InstName is the login name of the instance. If you are storing any files in /sqllib directory, these files will be removed by this action. If you still need these files, you must make a copy of them before dropping the instance. 4. Optional: As a user with root authority, remove the instance owners user ID and group (if used only for that instance). Do not remove these if you are planning to re-create the instance. Note: This step is optional since the instance owner and the instance owner group might be used for other purposes.
Removing DB2 products using the db2_deinstall or doce_deinstall command (Linux and UNIX)
This task provides steps for removing DB2 products or DB2 components using the db2_deinstall command. The db2_deinstall command removes all DB2 products from your system. The doce_deinstall command removes the DB2 Information Center that is in the same install path as the doce_deinstall tool. This command is only available on the Linux operating systems. Before you remove DB2 products from your system, ensure that you have performed all steps outlined in Chapter 27, Uninstalling your DB2 product (Linux and UNIX), on page 261 Note:
Chapter 27. DB2 products installed as root (Linux and UNIX)
263
v This task applies to DB2 products that were installed with root authority. v You cannot remove DB2 products using a native operating system utility, such as rpm or SMIT. v The doce_deinstall command is available only on Linux x32 and x64. To remove ALL DB2 products from a specific path: 1. Log in as the root user. 2. Access the path where the DB2 products are located. 3. Run one of the following commands: v To remove a feature from an installed DB2 product in the current location, run the db2_deinstall -F command from the DB2DIR/install directory. v To remove all installed DB2 products in the current location, run the db2_deinstall -a command from the DB2DIR/install directory. v To remove a DB2 product using a response file, run the db2_deinstall -r <response_file> command from the DB2DIR/install directory. You can use a sample response file to uninstall the product. For example, doce_deinstall -r db2un.rsp v To remove the DB2 Information Center in the current location, run the doce_deinstall -a from the DB2DIR/install directory. v To remove the DB2 Information Center using a response file, run the doce_deinstall -r <response_file> from the DB2DIR/install directory. You can use the sample response file to uninstall the Information Center. For example, doce_deinstall -r doceun.rsp where DB2DIR is the location that you specified when you installed your DB2 product.
264
Chapter 28. Uninstalling non-root DB2 products (Linux and UNIX)

This task provides steps for removing non-root DB2 products from your Linux or UNIX operating system. Note: This task applies to DB2 products that were installed without root authority. To uninstall DB2 products that were installed with root authority, see Chapter 27, Uninstalling your DB2 product (Linux and UNIX), on page 261 Non-root installations of DB2 products are uninstalled in the same manner as root installations. However, there are important differences which are detailed in the substeps. To remove your DB2 product: 1. Stop your non-root instance 2. Remove your DB2 product
Stopping non-root instances (Linux and UNIX)

You must stop your non-root instance before uninstalling your DB2 product. Note: This task applies to DB2 products that were installed with non-root authority. To stop a DB2 instance: 1. Log in as the non-root instance owner. 2. Run the start up script if it is not included in .profile.
. $HOME/sqllib/db2profile source $HOME/sqllib/db2cshrc (bash, Bourne, or Korn shells) (C shell)
where $HOME is your home directory. 3. You might want to save any of the following files: v The database manager configuration file, db2systm v The configuration file used to enable root features before running db2rfe. v User defined functions or fenced stored procedure applications in $HOME/sqllib/function. 4. Stop the DB2 database manager by entering the db2stop force command. 5. Confirm that the instance is stopped by entering the db2 terminate command.
Removing non-root DB2 products using db2_deinstall (Linux and UNIX)

This task provides steps for removing non-root DB2 products or components using the db2_deinstall command. You must stop the non-root instance before running the db2_deinstall command. Note:
265
v This task applies to DB2 products that were installed without root authority. A separate task exists for uninstalling DB2 products that were installed with root authority. v As with root users, non-root users can use the db2_deinstall command to uninstall DB2 products. The db2_deinstall command for non-root installations has the same options as root installations, and has an extra option: f sqllib. v It is important to note that running db2_deinstall as a non-root user uninstalls the DB2 product and drops the non-root instance. This is different than root installations, where running db2_deinstall only uninstalls the DB2 program files. v You cannot remove DB2 products using a native operating system utility, such as rpm or SMIT. To uninstall a DB2 product that was installed by a non-root user: 1. Log in with the user ID that was used to install the DB2 product. 2. Navigate to the $HOME/sqllib/install directory, where $HOME is your home directory. 3. Run the db2_deinstall command. Note: v If you run the db2_deinstall command with the a option, the DB2 program files are removed, but any configuration files are left behind in a backup directory called sqllib_bk. v If you run the db2_deinstall command with the a f sqllib option, the entire sqllib subdirectory in your home directory will be removed. If you have any files in sqllib you want to keep, be sure to copy them elsewhere before running db2_deinstall a f sqllib. v As with root installations, running the db2_deinstall command with the F option against a non-root installation allows the non-root user to remove specific DB2 features.
266
Chapter 29. Uninstalling DB2 copies and IBM database client interface copies
On Linux and UNIX operating systems Use the db2_deinstall command from the DB2 copy that you are using. The db2_deinstall command uninstalls installed DB2 products or features that are in the same install path as the db2_deinstall tool. The db2_deinstall command is also available on the DB2 product DVD. The product version you are uninstalling must match the product version on the DB2 DVD. If you do not provide the -b parameter when you run the db2_deinstall command from the DB2 DVD, you will be prompted for the installation path. Use the db2ls command to see the list of installed DB2 products and features. If one or more instances are currently associated with a DB2 copy, that DB2 copy cannot be uninstalled. On Windows operating systems To uninstall DB2 copies on Windows operating systems, use one of the following methods: v Use the Windows Add/Remove Control Panel Applet. v Run the db2unins command from the installed DB2 copy directory Note: v You can uninstall DB2 even when there are instances associated with DB2 copies. If you do this, the instance information will be removed with the DB2 uninstall. Therefore, take extra care when managing, recovering, and uninstalling instances. v If multiple Version 9 copies are installed, you cannot remove the default DB2 copy. If you want to remove the default DB2 copy, switch the default DB2 copy to one of the other DB2 copies before uninstalling. For more information about switching the default DB2 copy, see the db2swtch command.
267
Uninstalling DB2 copies when both those copies and IBM Data Server Driver copies are on your machine
DB2 Version 9.5
IBMDBCL1 DSDRIVER
Default DB2 copy

DB2COPY1
-ESE -WSE -...
DB2COPY2
-ESE -CLIENT -...
Legend
Default DB2 copy Default IBM database client interface copy DSDRIVER = IBM Data Server Driver for ODBC, CLI, and .NET
In the scenario presented here, IBMDBCL1 is the default IBM database client interface copy, DB2COPY1 is the default DB2 copy, and there is another DB2 copy (DB2COPY2).
268
DB2 Version 9.5

IBMDBCL1 DSDRIVER
Default DB2 copy

DB2COPY1
-ESE -WSE -... Unsuccessful
Uninstall the last product in DB2COPY1
DB2COPY2
-ESE -CLIENT -...
Legend
You decide to uninstall all of the DB2 products that are part of DB2COPY1. When you attempt to uninstall the last DB2 product within DB2COPY1, because it is the default DB2 copy, the uninstall request will be unsuccessful. Before uninstalling the last of the remaining DB2 products within the default DB2 copy, and if there is another DB2 copy on your system, you must switch the default from one DB2 copy to the other.
269
DB2 Version 9.5

IBMDBCL1 DSDRIVER
Default DB2 copy

DB2COPY1
-ESE -WSE -...
Yes
Default DB2 copy

DB2COPY2
-ESE -CLIENT -...
Legend
To change the default, use the db2swtch command with no arguments (Windows only) to start the Default DB2 and IBM Database Client Interface Selection wizard. The wizard will show all possible candidates when choosing a new default. In this case, you can choose DB2COPY2 as the new default DB2 copy. After you have made DB2COPY2 the default DB2 copy, you can request the uninstall of the last product in DB2COPY1.
270
DB2 Version 9.5

IBMDBCL1 DSDRIVER
DB2COPY1
-ESE -WSE -... Successful
Uninstall the last product in DB2COPY1
Default DB2 copy

DB2COPY2
-ESE -CLIENT -...
Legend
Since DB2COPY1 is no longer the default DB2 copy, the uninstall request is successful. Uninstalling IBM Data Server Driver copies when only those copies are on your machine Over time you can have several DSDRIVERs installed. Only one IBM database client interface copy is the default. At some point you might decide to uninstall the DSDRIVER that is the default IBM database client interface copy.
271
DB2 Version 9.5

IBMDBCL1 DSDRIVER

IBMDBCL2 DSDRIVER
Switching the default IBM database client interface copy

IBMDBCL3 DSDRIVER Uninstall DSDRIVER in IBMDBCL1 Successful
Legend
When you uninstall the default IBM database client interface copy, the database manager will choose between any of the remaining DSDRIVERs and pick one of them to be the new default IBM database client interface copy. Unless you switch the default before requesting the uninstall, you will not control which DSDRIVER will become the new default. (If there is only one other DSDRIVER besides the original default, then you will know which DSDRIVER the database manager will choose. If there are several DSDRIVERs installed besides the original default, then you will not know which DSDRIVER the database manager will choose.) Uninstalling IBM Data Server Driver copies when both those copies and DB2 copies are on your machine
272
DB2 Version 9.5

IBMDBCL1 DSDRIVER
Default DB2 copy

DB2COPY1
-ESE -WSE -...
Legend
In the scenario presented here, DB2COPY1 is the default DB2 copy and IBMDBCL1 is the default IBM database client interface copy. You decide to uninstall the DSDRIVER in IBMDBCL1.
DB2 Version 9.5
DB2COPY1
-ESE -WSE -...

IBMDBCL1 DSDRIVER Uninstall DSDRIVER in IBMDBCL1 Successful
Legend
As part of the uninstall request, the default IBM database client interface copy is switched by the database manager automatically so that DB2COPY1 becomes both the default DB2 copy and the default IBM database client interface copy. (This is also be true if there is more than one DB2 copy on the machine.)
273
274
Chapter 30. Uninstalling fix packs

For Linux and UNIX operating systems, you can go back to an earlier fix pack level by reinstalling an earlier fix pack. On Windows operating systems, after a fix pack is applied, you cannot go back to a previous fix pack unless you uninstall the current fix pack, then install the previous fix pack. 1. On Linux or UNIX operating systems, to uninstall a fix pack, use the installFixPack command with the force option (-f) to bypass the level check. The command must be run from the lower level fix pack image. For example:
./installFixPack -f level -b DB2DIR
where v DB2DIR is the location of the DB2 product that you want to force to a lower level fix pack image. For example:
./installFixPack -f level -b /opt/ibm/db2/V9.7
2. On Windows operating system, to uninstall a fix pack, use the Add/Remove Programs window, accessible through the Windows Control Panel. Refer to your operating systems help for more information about removing software products from your Windows operating system.
275
276
Part 9. Appendixes
277
278
Appendix A. DB2 database product and packaging information

DB2 database products are available in several different editions. There are also optional DB2 features. Some DB2 database products and features are only available on specific operating systems. For information about DB2 database product and packaging information, see http://www-1.ibm.com/support/docview.wss?rs=73&uid=swg21219983.
279
280
Appendix B. Overview of the DB2 technical information

DB2 technical information is available through the following tools and methods: v DB2 Information Center Topics (Task, concept and reference topics) Help for DB2 tools Sample programs Tutorials v DB2 books PDF files (downloadable) PDF files (from the DB2 PDF DVD) printed books v Command line help Command help Message help Note: The DB2 Information Center topics are updated more frequently than either the PDF or the hardcopy books. To get the most current information, install the documentation updates as they become available, or refer to the DB2 Information Center at ibm.com. You can access additional DB2 technical information such as technotes, white papers, and IBM Redbooks publications online at ibm.com. Access the DB2 Information Management software library site at http://www.ibm.com/software/ data/sw-library/.
Documentation feedback
We value your feedback on the DB2 documentation. If you have suggestions for how to improve the DB2 documentation, send an e-mail to [email protected]. The DB2 documentation team reads all of your feedback, but cannot respond to you directly. Provide specific examples wherever possible so that we can better understand your concerns. If you are providing feedback on a specific topic or help file, include the topic title and URL. Do not use this e-mail address to contact DB2 Customer Support. If you have a DB2 technical issue that the documentation does not resolve, contact your local IBM service center for assistance.
DB2 technical library in hardcopy or PDF format

The following tables describe the DB2 library available from the IBM Publications Center at www.ibm.com/shop/publications/order. English and translated DB2 Version 9.7 manuals in PDF format can be downloaded from www.ibm.com/ support/docview.wss?rs=71&uid=swg2700947. Although the tables identify books available in print, the books might not be available in your country or region.
281
The form number increases each time a manual is updated. Ensure that you are reading the most recent version of the manuals, as listed below. Note: The DB2 Information Center is updated more frequently than either the PDF or the hard-copy books.
Table 26. DB2 technical information Name Administrative API Reference Administrative Routines and Views Call Level Interface Guide and Reference, Volume 1 Call Level Interface Guide and Reference, Volume 2 Command Reference Form Number SC27-2435-00 SC27-2436-00 SC27-2437-00 Available in print Yes No Yes Last updated August, 2009 August, 2009 August, 2009
SC27-2438-00
Yes
August, 2009
SC27-2439-00
Yes Yes Yes
August, 2009 August, 2009 August, 2009
Data Movement Utilities SC27-2440-00 Guide and Reference Data Recovery and High Availability Guide and Reference SC27-2441-00
Database Administration SC27-2442-00 Concepts and Configuration Reference Database Monitoring Guide and Reference Database Security Guide DB2 Text Search Guide Developing ADO.NET and OLE DB Applications Developing Embedded SQL Applications Developing Java Applications Developing Perl, PHP, Python, and Ruby on Rails Applications Developing User-defined Routines (SQL and External) Getting Started with Database Application Development SC27-2458-00 SC27-2443-00 SC27-2459-00 SC27-2444-00
Yes
August, 2009
Yes Yes Yes Yes
August, 2009 August, 2009 August, 2009 August, 2009
SC27-2445-00 SC27-2446-00 SC27-2447-00
Yes Yes No
SC27-2448-00
Yes
August, 2009
GI11-9410-00
Yes
August, 2009
Getting Started with GI11-9411-00 DB2 Installation and Administration on Linux and Windows
Yes
August, 2009
282
Table 26. DB2 technical information (continued) Name Globalization Guide Installing DB2 Servers Installing IBM Data Server Clients Message Reference Volume 1 Message Reference Volume 2 Net Search Extender Administration and Users Guide Partitioning and Clustering Guide pureXML Guide Query Patroller Administration and Users Guide Spatial Extender and Geodetic Data Management Feature Users Guide and Reference SQL Procedural Languages: Application Enablement and Support Form Number SC27-2449-00 GC27-2455-00 GC27-2454-00 SC27-2450-00 SC27-2451-00 SC27-2469-00 Available in print Yes Yes No No No No Last updated August, 2009 August, 2009 August, 2009 August, 2009 August, 2009 August, 2009
SC27-2453-00 SC27-2465-00 SC27-2467-00
Yes Yes No
SC27-2468-00
No
August, 2009
SC27-2470-00
Yes
August, 2009
SQL Reference, Volume 1 SC27-2456-00 SQL Reference, Volume 2 SC27-2457-00 Troubleshooting and Tuning Database Performance Upgrading to DB2 Version 9.7 Visual Explain Tutorial Whats New for DB2 Version 9.7 Workload Manager Guide and Reference XQuery Reference SC27-2461-00
Yes Yes Yes
SC27-2452-00 SC27-2462-00 SC27-2463-00 SC27-2464-00 SC27-2466-00
Yes No Yes Yes No
August, 2009 August, 2009 August, 2009 August, 2009 August, 2009
Table 27. DB2 Connect-specific technical information Name Form Number Available in print Yes Last updated August, 2009
Installing and SC27-2432-00 Configuring DB2 Connect Personal Edition Installing and Configuring DB2 Connect Servers SC27-2433-00
Yes
August, 2009
283
Table 27. DB2 Connect-specific technical information (continued) Name DB2 Connect Users Guide Form Number SC27-2434-00 Available in print Yes Last updated August, 2009
Table 28. Information Integration technical information Name Form Number Available in print Yes Last updated August, 2009
Information Integration: SC19-1020-02 Administration Guide for Federated Systems Information Integration: ASNCLP Program Reference for Replication and Event Publishing Information Integration: Configuration Guide for Federated Data Sources Information Integration: SQL Replication Guide and Reference Information Integration: Introduction to Replication and Event Publishing SC19-1018-04
Yes
August, 2009
SC19-1034-02
No
August, 2009
SC19-1030-02
Yes
August, 2009
GC19-1028-02
Yes
August, 2009
Ordering printed DB2 books

If you require printed DB2 books, you can buy them online in many but not all countries or regions. You can always order printed DB2 books from your local IBM representative. Keep in mind that some softcopy books on the DB2 PDF Documentation DVD are unavailable in print. For example, neither volume of the DB2 Message Reference is available as a printed book. Printed versions of many of the DB2 books available on the DB2 PDF Documentation DVD can be ordered for a fee from IBM. Depending on where you are placing your order from, you may be able to order books online, from the IBM Publications Center. If online ordering is not available in your country or region, you can always order printed DB2 books from your local IBM representative. Note that not all books on the DB2 PDF Documentation DVD are available in print. Note: The most up-to-date and complete DB2 documentation is maintained in the DB2 Information Center at http://publib.boulder.ibm.com/infocenter/db2luw/ v9r7. To order printed DB2 books: v To find out whether you can order printed DB2 books online in your country or region, check the IBM Publications Center at http://www.ibm.com/shop/ publications/order. You must select a country, region, or language to access publication ordering information and then follow the ordering instructions for your location. v To order printed DB2 books from your local IBM representative:
284
1. Locate the contact information for your local representative from one of the following Web sites: The IBM directory of world wide contacts at www.ibm.com/planetwide The IBM Publications Web site at http://www.ibm.com/shop/ publications/order. You will need to select your country, region, or language to the access appropriate publications home page for your location. From this page, follow the About this site link. 2. When you call, specify that you want to order a DB2 publication. 3. Provide your representative with the titles and form numbers of the books that you want to order. For titles and form numbers, see DB2 technical library in hardcopy or PDF format on page 281.
Displaying SQL state help from the command line processor

DB2 products return an SQLSTATE value for conditions that can be the result of an SQL statement. SQLSTATE help explains the meanings of SQL states and SQL state class codes. To start SQL state help, open the command line processor and enter:
? sqlstate or ? class code
where sqlstate represents a valid five-digit SQL state and class code represents the first two digits of the SQL state. For example, ? 08003 displays help for the 08003 SQL state, and ? 08 displays help for the 08 class code.
Accessing different versions of the DB2 Information Center

For DB2 Version 9.7 topics, the DB2 Information Center URL is http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/ For DB2 Version 9.5 topics, the DB2 Information Center URL is http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/ For DB2 Version 9 topics, the DB2 Information Center URL is http:// publib.boulder.ibm.com/infocenter/db2luw/v9/ For DB2 Version 8 topics, go to the Version 8 Information Center URL at: http://publib.boulder.ibm.com/infocenter/db2luw/v8/
Displaying topics in your preferred language in the DB2 Information Center

The DB2 Information Center attempts to display topics in the language specified in your browser preferences. If a topic has not been translated into your preferred language, the DB2 Information Center displays the topic in English. v To display topics in your preferred language in the Internet Explorer browser: 1. In Internet Explorer, click the Tools > Internet Options > Languages... button. The Language Preferences window opens. 2. Ensure your preferred language is specified as the first entry in the list of languages. To add a new language to the list, click the Add... button.
285
Note: Adding a language does not guarantee that the computer has the fonts required to display the topics in the preferred language. To move a language to the top of the list, select the language and click the Move Up button until the language is first in the list of languages. 3. Clear the browser cache and then refresh the page to display the DB2 Information Center in your preferred language. v To display topics in your preferred language in a Firefox or Mozilla browser: 1. Select the button in the Languages section of the Tools > Options > Advanced dialog. The Languages panel is displayed in the Preferences window. 2. Ensure your preferred language is specified as the first entry in the list of languages. To add a new language to the list, click the Add... button to select a language from the Add Languages window. To move a language to the top of the list, select the language and click the Move Up button until the language is first in the list of languages. 3. Clear the browser cache and then refresh the page to display the DB2 Information Center in your preferred language. On some browser and operating system combinations, you must also change the regional settings of your operating system to the locale and language of your choice.
Updating the DB2 Information Center installed on your computer or intranet server
A locally installed DB2 Information Center must be updated periodically. Before you begin A DB2 Version 9.7 Information Center must already be installed. For details, see the Installing the DB2 Information Center using the DB2 Setup wizard topic in Installing DB2 Servers. All prerequisites and restrictions that applied to installing the Information Center also apply to updating the Information Center. About this task An existing DB2 Information Center can be updated automatically or manually: v Automatic updates - updates existing Information Center features and languages. An additional benefit of automatic updates is that the Information Center is unavailable for a minimal period of time during the update. In addition, automatic updates can be set to run as part of other batch jobs that run periodically. v Manual updates - should be used when you want to add features or languages during the update process. For example, a local Information Center was originally installed with both English and French languages, and now you want to also install the German language; a manual update will install German, as well as, update the existing Information Center features and languages. However, a manual update requires you to manually stop, update, and restart the Information Center. The Information Center is unavailable during the entire update process. Procedure
286
This topic details the process for automatic updates. For manual update instructions, see the Manually updating the DB2 Information Center installed on your computer or intranet server topic. To automatically update the DB2 Information Center installed on your computer or intranet server: 1. On Linux operating systems, a. Navigate to the path where the Information Center is installed. By default, the DB2 Information Center is installed in the /opt/ibm/db2ic/V9.7 directory. b. Navigate from the installation directory to the doc/bin directory. c. Run the ic-update script:
ic-update
2. On Windows operating systems, a. Open a command window. b. Navigate to the path where the Information Center is installed. By default, the DB2 Information Center is installed in the <Program Files>\IBM\DB2 Information Center\Version 9.7 directory, where <Program Files> represents the location of the Program Files directory. c. Navigate from the installation directory to the doc\bin directory. d. Run the ic-update.bat file:
ic-update.bat
Results The DB2 Information Center restarts automatically. If updates were available, the Information Center displays the new and updated topics. If Information Center updates were not available, a message is added to the log. The log file is located in doc\eclipse\configuration directory. The log file name is a randomly generated number. For example, 1239053440785.log.
Manually updating the DB2 Information Center installed on your computer or intranet server
If you have installed the DB2 Information Center locally, you can obtain and install documentation updates from IBM. Updating your locally-installed DB2 Information Center manually requires that you: 1. Stop the DB2 Information Center on your computer, and restart the Information Center in stand-alone mode. Running the Information Center in stand-alone mode prevents other users on your network from accessing the Information Center, and allows you to apply updates. The Workstation version of the DB2 Information Center always runs in stand-alone mode. . 2. Use the Update feature to see what updates are available. If there are updates that you must install, you can use the Update feature to obtain and install them Note: If your environment requires installing the DB2 Information Center updates on a machine that is not connected to the internet, mirror the update site to a local file system using a machine that is connected to the internet and has the DB2 Information Center installed. If many users on your network will be installing the documentation updates, you can reduce the time required for
287
individuals to perform the updates by also mirroring the update site locally and creating a proxy for the update site. If update packages are available, use the Update feature to get the packages. However, the Update feature is only available in stand-alone mode. 3. Stop the stand-alone Information Center, and restart the DB2 Information Center on your computer. Note: On Windows 2008, Windows Vista (and higher), the commands listed later in this section must be run as an administrator. To open a command prompt or graphical tool with full administrator privileges, right-click the shortcut and then select Run as administrator. To update the DB2 Information Center installed on your computer or intranet server: 1. Stop the DB2 Information Center. v On Windows, click Start Control Panel Administrative Tools Services. Then right-click DB2 Information Center service and select Stop. v On Linux, enter the following command:
/etc/init.d/db2icdv97 stop
2. Start the Information Center in stand-alone mode. v On Windows: a. Open a command window. b. Navigate to the path where the Information Center is installed. By default, the DB2 Information Center is installed in the <Program Files>\IBM\DB2 Information Center\Version 9.7 directory, where <Program Files> represents the location of the Program Files directory. c. Navigate from the installation directory to the doc\bin directory. d. Run the help_start.bat file:
help_start.bat
v On Linux: a. Navigate to the path where the Information Center is installed. By default, the DB2 Information Center is installed in the /opt/ibm/db2ic/V9.7 directory. b. Navigate from the installation directory to the doc/bin directory. c. Run the help_start script:
help_start
The systems default Web browser opens to display the stand-alone Information Center. 3. Click the Update button ( ). (JavaScript must be enabled in your browser.) On the right panel of the Information Center, click Find Updates. A list of updates for existing documentation displays. 4. To initiate the installation process, check the selections you want to install, then click Install Updates. 5. After the installation process has completed, click Finish. 6. Stop the stand-alone Information Center: v On Windows, navigate to the installation directorys doc\bin directory, and run the help_end.bat file:
help_end.bat
288
Note: The help_end batch file contains the commands required to safely stop the processes that were started with the help_start batch file. Do not use Ctrl-C or any other method to stop help_start.bat. v On Linux, navigate to the installation directorys doc/bin directory, and run the help_end script:
help_end
Note: The help_end script contains the commands required to safely stop the processes that were started with the help_start script. Do not use any other method to stop the help_start script. 7. Restart the DB2 Information Center. v On Windows, click Start Control Panel Administrative Tools Services. Then right-click DB2 Information Center service and select Start. v On Linux, enter the following command:
/etc/init.d/db2icdv97 start
The updated DB2 Information Center displays the new and updated topics.
DB2 tutorials
The DB2 tutorials help you learn about various aspects of DB2 products. Lessons provide step-by-step instructions.
Before you begin

You can view the XHTML version of the tutorial from the Information Center at http://publib.boulder.ibm.com/infocenter/db2help/. Some lessons use sample data or code. See the tutorial for a description of any prerequisites for its specific tasks.
DB2 tutorials
To view the tutorial, click the title. pureXML in pureXML Guide Set up a DB2 database to store XML data and to perform basic operations with the native XML data store. Visual Explain in Visual Explain Tutorial Analyze, optimize, and tune SQL statements for better performance using Visual Explain.
DB2 troubleshooting information

A wide variety of troubleshooting and problem determination information is available to assist you in using DB2 database products. DB2 documentation Troubleshooting information can be found in the DB2 Troubleshooting Guide or the Database fundamentals section of the DB2 Information Center. There you will find information about how to isolate and identify problems using DB2 diagnostic tools and utilities, solutions to some of the most common problems, and other advice on how to solve problems you might encounter with your DB2 database products.
289
DB2 Technical Support Web site Refer to the DB2 Technical Support Web site if you are experiencing problems and want help finding possible causes and solutions. The Technical Support site has links to the latest DB2 publications, TechNotes, Authorized Program Analysis Reports (APARs or bug fixes), fix packs, and other resources. You can search through this knowledge base to find possible solutions to your problems. Access the DB2 Technical Support Web site at http://www.ibm.com/ software/data/db2/support/db2_9/
Terms and Conditions

Permissions for the use of these publications is granted subject to the following terms and conditions. Personal use: You may reproduce these Publications for your personal, non commercial use provided that all proprietary notices are preserved. You may not distribute, display or make derivative work of these Publications, or any portion thereof, without the express consent of IBM. Commercial use: You may reproduce, distribute and display these Publications solely within your enterprise provided that all proprietary notices are preserved. You may not make derivative works of these Publications, or reproduce, distribute or display these Publications or any portion thereof outside your enterprise, without the express consent of IBM. Except as expressly granted in this permission, no other permissions, licenses or rights are granted, either express or implied, to the Publications or any information, data, software or other intellectual property contained therein. IBM reserves the right to withdraw the permissions granted herein whenever, in its discretion, the use of the Publications is detrimental to its interest or, as determined by IBM, the above instructions are not being properly followed. You may not download, export or re-export this information except in full compliance with all applicable laws and regulations, including all United States export laws and regulations. IBM MAKES NO GUARANTEE ABOUT THE CONTENT OF THESE PUBLICATIONS. THE PUBLICATIONS ARE PROVIDED AS-IS AND WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO IMPLIED WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT, AND FITNESS FOR A PARTICULAR PURPOSE.
290
Appendix C. Notices
This information was developed for products and services offered in the U.S.A. Information about non-IBM products is based on information available at the time of first publication of this document and is subject to change. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the users responsibility to evaluate and verify the operation of any non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not grant you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing IBM Corporation North Castle Drive Armonk, NY 10504-1785 U.S.A. For license inquiries regarding double-byte character set (DBCS) information, contact the IBM Intellectual Property Department in your country or send inquiries, in writing, to: Intellectual Property Licensing Legal and Intellectual Property Law IBM Japan, Ltd. 3-2-12, Roppongi, Minato-ku, Tokyo 106-8711 Japan The following paragraph does not apply to the United Kingdom or any other country/region where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION AS IS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY, OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions; therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web
291
sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information that has been exchanged, should contact: IBM Canada Limited Office of the Lab Director 8200 Warden Avenue Markham, Ontario L6G 1C7 CANADA Such information may be available, subject to appropriate terms and conditions, including, in some cases, payment of a fee. The licensed program described in this document and all licensed material available for it are provided by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement, or any equivalent agreement between us. Any performance data contained herein was determined in a controlled environment. Therefore, the results obtained in other operating environments may vary significantly. Some measurements may have been made on development-level systems, and there is no guarantee that these measurements will be the same on generally available systems. Furthermore, some measurements may have been estimated through extrapolation. Actual results may vary. Users of this document should verify the applicable data for their specific environment. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements, or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility, or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. All statements regarding IBMs future direction or intent are subject to change or withdrawal without notice, and represent goals and objectives only. This information may contain examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious, and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrate programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
292
programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. The sample programs are provided AS IS, without warranty of any kind. IBM shall not be liable for any damages arising out of your use of the sample programs. Each copy or any portion of these sample programs or any derivative work must include a copyright notice as follows: (your company name) (year). Portions of this code are derived from IBM Corp. Sample Programs. Copyright IBM Corp. _enter the year or years_. All rights reserved.
Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at Copyright and trademark information at www.ibm.com/legal/copytrade.shtml. The following terms are trademarks or registered trademarks of other companies v Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both. v Java and all Java-based trademarks and logos are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. v UNIX is a registered trademark of The Open Group in the United States and other countries. v Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo, Celeron, Intel Xeon, Intel SpeedStep, Itanium, and Pentium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. v Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. Other company, product, or service names may be trademarks or service marks of others.
Appendix C. Notices
293
294
Index A
administration server stopping 261 AIX creating DB2 home file systems 49 creating required users 139 distributing commands to ESE workstations installation requirements 16 installing 41 installing DB2 servers 73 mounting CDs or DVDs 59 updating environment settings 45 verifying NFS is running 56 communications addresses 36 fast communication manager 36 configuration parameters fcm_num_buffers 33 configuring after manual installation 137 communication protocols for a local DB2 instance 217 for a remote DB2 instance 218 contact lists setting 169 Control Center configuring DB2 server communications 219 creating packages on SMS server 101 required users on AIX 139 required users on HP-UX 140 required users on Linux 142 required users on Solaris Operating System 143 response files using DB2 Setup wizard 92 rhosts file 197 sample databases 151
47
B
batch files response file installations books printed ordering 284 107
C
cataloging TCP/IP node 224 CDs mounting on AIX 59 mounting on HP-UX 60 mounting on Linux 60 mounting on Solaris Operating System changing DB2 database products 123, 124 Windows default language setting 7 code pages supported 5 command line processor (CLP) verifying the installation 152 commands db2_deinstall 263 db2fs 167 db2idrop 262 db2ilist 262 db2licm 231 db2ls 165 db2nchg 31 db2osconf 43 db2rfe - enabling root features 78, 82 db2sampl 152 db2secv82 168 db2setup 5 db2stop 262 doce_deinstall 263 enabling remote execution 197 force application 262 communication protocols configuring for a local DB2 instance 217 for a remote DB2 instance 218 DB2 instance 221 Copyright IBM Corp. 1993, 2009
D
daemons Information Center 213 database manager configuration file updating for TCP/IP 224 database partition servers enabling communications on UNIX 196 installing using a response file 95 Database Partitioning Feature (DPF) enabling communications 196 database servers overview 3 DB2 administration server (DAS) creating procedure 144 removing 261 stopping 261 DB2 copies changing default copy after installation 170 managing 182 multiple on same computer Linux 66 UNIX 66 Windows 35 uninstalling 267 DB2 database products changing editions 124 list 165 DB2 features packaging information 279 DB2 groups Linux 36 UNIX 36 DB2 High Availability (HA) Feature Tivoli System Automation for Multiplatforms (SA MP) 237
60
295
DB2 Information Center installing Linux 207 options 203 Windows 205 languages 285 updating 286, 287 versions 285 viewing in different languages 285 DB2 packaging information 279 DB2 product information 279 DB2 servers communications configuring 219 configuring after manual installation 137 installing Linux 73 UNIX 73 Windows 63 overview 3 partitioned Windows environment preparation 31 DB2 services Windows 25 DB2 Setup wizard creating response files 92 installing DB2 servers Linux 74 UNIX 74 installing DB2 servers on UNIX 74 installing IBM Tivoli Monitoring for Databases: DB2 Agent 253 language identifiers 6 db2_deinstall command removing DB2 products 263 db2_install command installing DB2 product 129, 209 DB2ADMNS group adding users 168 db2cli.ini file configuring 105 db2fcmr daemons 36 db2fcms daemons 36 db2icrt command creating instances 145 db2iprune 187 db2iupdt command updating 32-bit to 64-bit instances 169 db2licm command checking compliance 232 managing licenses 227 registering licenses 230 setting license policy 231 db2ls command listing installed products and features 165 db2nodes.cfg file format 188 netname field 31 updating 194 db2osconf command determining kernel configuration parameter values 43 db2rfe command enabling root features 78, 82 db2setup command language setting 5 DB2USERS user group adding users 168 db2val command 165
default DB2 copy changing after installation 170 default IBM database client interface copy changing after installation 170 default language setting Windows 7 directories shared access 98 directory schema extending Windows 33 directory structures Linux 160 root installations compared to non-root installations Windows 154 disk space requirements 10 doce_deinstall command procedure 263 doce_install command procedure 129, 209 documentation Information Center installing 203 overview 281 PDF 281 printed 281 terms and conditions of use 290 dropping non-root instances 265 root instances 262 DVDs mounting AIX 59 HP-UX 60 Linux 60 Solaris Operating System 60
78
E
errors response file error codes Linux 95 UNIX 95 Windows 106 exporting profiles 121
F
FCM (Fast Communications Manager) enabling communications between database partition servers 196 message buffers 33 overview 33 port numbers 196 port range 34 Windows 33 fcm_num_buffers configuration parameter 33 fenced user definition 39, 137 file sets db2fcmr daemons 36 db2fcms daemons 36 description 36 file systems creating for a partitioned DB2 server 49
296
file systems (continued) Linux 53 Solaris Operating System 54 files creating links 146 Firefox deleting a browser profile 168 First Steps deleting a Firefox profile 168 interface 167 product updates 183 verifying DB2 installation 151 fix packs applying 185 non-root installations 187 uninstalling 275
G
group IDs creating 39, 137 groups creating IDs 39, 137 overview 36
H
hardware requirements 9 AIX 16 HP-UX 17 Linux 18 Solaris Operating Environment 21 Windows 14 help configuring language 285 SQL statements 285 home file system AIX 49 HP-UX 51 overview 49 HP-UX DB2 home file system 51 installing DB2 servers 17, 73 IBM data server clients 17 kernel configuration parameters modifying 43 recommended values 43 mounting media 60 Network File System (NFS) verifying that it is running 56 partitioned database systems 51 user creation 140
I
IBM data server clients 3 connectivity using multiple DB2 copies 180 overview 3 IBM Data Server Driver for JDBC and SQLJ level by DB2 version level 11 IBM database client interface copies changing the default copy after installation 170
IBM database client interface copies (continued) uninstalling 267 IBM Tivoli Monitoring for Databases: DB2 Agent 253 IBM Tivoli SA MP 237 install log 247 installing 237, 238 using DB2 installer 238 using installSAM 240 license terms 248 system requirements 248 uninstall log 247 uninstalling 237, 243 using DB2 installer 244 using uninstallSAM 244 upgrading 237, 240 using DB2 installer 241 using installSAM 242 IBM Tivoli SA MP HADR scripts installing 245 manually 247 using DB2 installer 246 uninstalling 245 manually 247 using DB2 installer 246 upgrading 245 manually 247 using DB2 installer 246 importing profiles 121 Information Center installing 203, 205, 207 install file importing into SMS 100 installation configuring db2cli.ini 105 methods 3 installation image embedding in application 120 installation package distributing across a network 101 installing add-on products 182 database partition servers 49 response files 95 database partition servers using response files 87 DB2 database user accounts (Windows) 26 DB2 Enterprise Server Edition (Windows) 31 DB2 for Linux on S/390 38 DB2 products manually 144 methods that require manual configuration 127 DB2 products as a non-root user 81 embedding the DB2 installation image 120 Information Center 203, 205, 207 installing IBM Tivoli Monitoring for Databases: DB2 Agent 253 Linux on zSeries 38 listing DB2 database products 165 manual 144 manually DB2 component payloads 133 db2_install 129, 209 doce_install 129, 209 methods 3 db2_install 129, 209 doce_install 129, 209 requiring manual configuration 127 multiple DB2 copies 35 Index
297
installing (continued) prerequisites 9 requirements AIX 16, 41 HP-UX 17 Linux 18 Solaris Operating Environment 21 Windows 14 response files 97 error codes 95, 106 SMS (Microsoft Systems Management Server) types 91 security considerations 37 silent 93, 97 updating AIX environment settings 45 using response files 89 using SMS 100 verifying using CLP 152 verifying using First Steps 151 Windows elevated privileges 29 instances configuring TCP/IP communications 147, 223 creating using db2icrt 145 dropping 262 removing 262 removing non-root 265 root removing 262 setting communication protocols 221 stopping non-root 265 stopping non-root 265 stopping root 262 interactive installation killing DB2 processes 121 interface languages 5 changing UNIX 8 Windows 7
103
J
Java DB2 product support 11 Java Database Connectivity (JDBC) drivers versions 11
License Center checking compliance 232 managing licenses 227 registering licenses 231 setting license policy 232 updating a trial license 230 licenses applying 229 checking compliance 232 overview 227 registering db2licm command 230 License Center 231 setting policies db2licm command 231 License Center 232 updating a trial license 230 limitations non-root installations 78 linking creating directory links 146 Linux changing DB2 database product editions 123 creating file system for partitioned DB2 servers 53 creating required users 142 default port ranges 196 installation requirements 18 installing DB2 databases on zSeries 38 DB2 servers 73 DB2 Setup wizard 74 listing DB2 database products 165 modifying kernel parameters 43 mounting CDs or DVDs 60 removing DB2 (root) 261 DB2 non-root instances 265 DB2 root instances 262 response file installation overview 93 root 94 verifying NFS is running 56 Linux library libaio.so.1 18 libstdc++so.5 18 locales supported DB2 interface languages 5
M K
kernel configuration parameters db2osconf command (HP-UX) 43 modifying on HP-UX 43 modifying on Linux 43 modifying on Solaris Operating System recommended (HP-UX) 43 memory requirements 10 message buffers Fast Communications Manager (FCM) modifying kernel parameters (HP-UX) 43 modifying kernel parameters HP-UX 43 Linux 43 Solaris Operating System 45 mounting CDs or DVDs AIX 59 HP-UX 60 Linux 60 Solaris Operating System 60 33
45
L
LANG environment variable setting 5, 8 languages DB2 Setup wizard for language identifiers supported 5 6
298
moving between DB2 database products
124
N
national language support (NLS) displaying db2setup 5 network DB2 installation package, distributing 101 Network File System (NFS) installation on AIX 16 on HP-UX 17 on Linux 18 on Solaris Operating Environment 21 NFS (Network File System) verifying operation 56 node configuration files description 188 updating (UNIX) 194 nodes FCM daemon (UNIX) 36 non-root installations differences 78 directory structure 78 enabling root-based features 82 fix packs 187 installing 81 limitations 78 overview 77 ulimit settings 40 uninstalling 265 non-root instances dropping 265 removing 265 notices 291 notification lists setting 169
port number ranges (continued) UNIX availability 48, 196 default 196 Windows availability 34 post-installation tasks Main menu entries 184 problem determination information available 289 tutorials 289 processes stopping interactive installation 121 response file installation 121 profiles exporting 121 importing 121
R
recommended settings 40 reducing fix pack size 187 registry verifying access 88 remote commands, enabling on UNIX 197 remote access configuring to a server database 104 removing DAS 261 DB2 (root) Linux 261 UNIX 261 DB2 database Windows 259 DB2 non-root installations on UNIX 265 non-root instances 265 root instances 262 requirements disk 10 memory 10 ulimit settings 40 reserved ports DB2 database 34 response files creating DB2 Setup wizard 92 UNIX 93 Windows 98 exporting configuration profile 121 generator overview 106 importing configuration profile 121 installation batch files 107 database partition servers 87, 95 killing DB2 processes 121 Linux and UNIX 94 making DB2 files available for 97 types 91 UNIX 93 using SMS 103 Windows 97 installation error codes 95, 106 keywords 108 location 89, 92 Index
O
operating system requirements AIX 16 HP-UX 17 Linux 18 Solaris Operating Environment Windows 14 operating systems prerequisites 9 ordering DB2 books 284
21
P
partitioned database environments Control Center administration (UNIX) installation verification UNIX 153 Windows 152 setting up 85 passwords rules 23 payload files 133 port number ranges Linux availability 48, 196 default 196 199
299
response files (continued) overview 89 running setup 99 samples 108 uninstalling 96, 260 rhosts file creating 197 updating 197 root installations differences 78 directory structure 78 root instances dropping 262 removing 262 root-based features non-root installation 82 rsh 197 rules password 23
Solaris Operating System (continued) mounting CDs or DVDs 60 verifying NFS is running 56 SQL statements displaying help 285 ssh 197 starting the Information Center 213 stopping Administration Server 261 root instances 262 stopping the Information Center 213 system requirements for DB2 Database for Linux, UNIX, and Windows
T
TCP/IP communications updating the services file 224 configuring DB2 instances 147, 223 updating database manager configuration file terms and conditions use of publications 290 troubleshooting online information 289 tutorials 289 tutorials problem determination 289 troubleshooting 289 Visual Explain 289
S
S/390 installing 38 SAMPLE database verifying installation 151 warehousing 151 samples response files 108 SDK Java product levels 11 security user groups 168 servers configuring remote access 104 services file updating TCP/IP communications 224 set-up tool 167 setting contact lists 169 LANG environment variable 5, 8 notification lists 169 silent installation 93, 97 keywords 108 using response files 89 silent uninstall 96, 260 using response files 89 SMS (Systems Management Server) creating packages on the SMS server importing DB2 install file 100 installing DB2 products 100 software requirements 9 AIX 16 HP-UX 17 Linux 18 Solaris Operating Environment 21 Windows 14 Solaris Operating Environment installation requirements 21 Solaris Operating System creating file systems 54 creating required users 143 installing DB2 servers 73 modifying kernel parameters 45
224
U
ulimit settings 40 uninstalling DB2 copies 267 DB2 database Windows 259 db2_deinstall command 263 doce_deinstall command 263 fix packs 275 IBM database client interface copies 267 IBM Tivoli Monitoring for Databases: DB2 Agent non-root 265 non-root installations 265 root installations 261 using response files 89, 96, 260 UNIX changing DB2 database product editions 123 changing the DB2 interface language 8 creating a response file 93 DB2 groups 36 DB2 users 36 default port ranges 196 enabling Control Center administration 199 remote commands 197 installing using the DB2 Setup wizard 74 listing DB2 database products 165 removing DB2 (root) 261 DB2 non-root instances 265 DB2 products 263
255
101
300
UNIX (continued) removing DB2 non-root installations 265 removing DB2 root instances 262 response file installation 93, 94 updating the node configuration file 194 verifying a partitioned database server installation 153 updates checking for 183 DB2 Information Center 286, 287 db2nodes.cfg (UNIX) 194 node configuration file 194 rhosts file 197 updating 32-bit DB2 instances 169 to 64-bit DB2 instances 169 user accounts DB2 Administration Server (Windows) 26 instance user (Windows) 26 required for installation (Windows) 26 user groups DB2ADMNS 168 DB2USERS 168 security 168 user IDs creating 39, 137 user limit requirements 40 user privileges Windows 32 users creating required users on AIX 139 creating required users on HP-UX 140 creating required users on Linux 142 creating required users on Solaris Operating System 143 overview 36 utilities response file generator 106
Windows operating systems (continued) installation verification partitioned database environment 152 installing DB2 servers (procedure) 63 DB2 servers (requirements) 14 DB2 servers (with DB2 Setup wizard) 63 IBM data server clients (requirements) 14 response file method 99 response files editing 98 installing using 97 uninstalling DB2 259 user accounts DB2 server product installation 26 workload partitions installing DB2 database products 41
Z
zSeries installing DB2 Database for Linux 38
V
validating DB2 copies 165 verifying DB2 installation using First Steps 151 port range availability Linux 48 UNIX 48 Windows 34 registry access 88 Visual Explain tutorial 289
W
Windows operating systems DB2 services 25 default language setting changing 7 directories setting up shared access 98 granting user rights 32 installation packages distributing using Microsoft Systems Management Server (SMS) 103 installation using a non-Administrator user account setting up elevated privileges 29
Index
301
302
Printed in USA
GC27-2455-00
Spine information:
IBM DB2 9.7 for Linux, UNIX, and Windows

Db2 Step by Step Installation Guide

Uploaded by

Copyright:

Available Formats

Db2 Step by Step Installation Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Db2 Step by Step Installation Guide

Uploaded by

Copyright:

Available Formats

What are the main installation requirements discussed in the document?

What are the main installation requirements discussed in the document?

What are some of the methods discussed for installing DB2 products?

What are some of the methods discussed for installing DB2 products?

IBM DB2 9.

7 for Linux, UNIX, and Windows

Installing DB2 Servers

IBM DB2 9.7 for Linux, UNIX, and Windows

Installing DB2 Servers

Chapter 2. Installation requirements for DB2 database products . . . . . . . . 9

Chapter 6. Mounting product CDs or DVDs on Linux or UNIX . . . . . . . 59

Chapter 3. Password rules . . . . . . 23 Chapter 4. Additional Windows requirements . . . . . . . . . . . . 25

Chapter 7. Installing on Windows . . . 63

Chapter 8. Installing on Linux and UNIX 73

Chapter 5. Additional Linux and UNIX requirements . . . . . . . . . . . . 35

Chapter 9. Setting up a partitioned database environment . . . . . . . . 85

Chapter 10. Response file installation

. 143 . 144 . 145 . 146 . 147

Part 3. After you install a DB2 Server product . . . . . . . . . . 149

Chapter 11. Changing DB2 product editions . . . . . . . . . . . . . . 123

Chapter 16. Post-installation tasks

Installing DB2 Servers

167 168 168 169 169

Chapter 23. DB2 license files. . . . . 227

Part 6. Installing Tivoli System Automation for Multiplatforms . . . 235

Part 4. Installing the DB2 Information Center . . . . . . . . 201

240 240 241

Chapter 19. Post-installation tasks

Starting or stopping the Information Center (Linux and Windows) . . . . . . . . . . . . . 213

242 243 244

Part 5. Configuring . . . . . . . . 215

Part 7. IBM Tivoli Monitoring for Databases: DB2 Agent . . . . . . 251

Part 9. Appendixes . . . . . . . . 277

Part 8. Uninstalling . . . . . . . . 257

Appendix C. Notices . . . . . . . . 291 Index . . . . . . . . . . . . . . . 295

Installing DB2 Servers

Part 1. Installing DB2 Servers

Copyright IBM Corp. 1993, 2009

Installing DB2 Servers

Chapter 1. Before you install

DB2 installation methods

Installing DB2 Servers

Supported DB2 interface languages

where locale is a locale supported by the DB2 interface.

Installing DB2 Servers

Changing the DB2 product interface language (Windows)

Chapter 1. Before you install

Changing the DB2 interface language (Linux and UNIX)

Installing DB2 Servers

Chapter 2. Installation requirements for DB2 database products

Copyright IBM Corp. 1993, 2009

Disk and memory requirements

Installing DB2 Servers

Java software support for DB2 products

Solaris Operating System Windows x86

Chapter 2. Requirements for DB2 products

Operating System Platform Windows x64

SDK for Java level SDK 6 Service Release 3

Supported Java application development software