Installing DB2 Products Across Your Enterprise

Document options Document options requiring JavaScript are not displayed New site feature Check out our new article design and features. Tell us what you think. Rate this page Help us improve this content

Level: Introductory

Paul Zikopoulos (paulz_ibm@yahoo.com), Database Specialist, IBM Canada
Roman Melnyk (roman_b_melnyk@hotmail.com), Senior Administrator, IBM Canada

01 Feb 2002

This article describes the advantages and disadvantages of various methods of installing DB2 products in a distributed environment. Interactive, response file, Citrix or Windows Terminal Server, and code server or thin-client installations are discussed.

Introduction

Product installation has become much easier over the years with the help of graphical user interfaces (GUIs) and a focus on user-centered design (UCD). There has been a strong focus on installation because the deployment of code across an enterprise, including maintenance of that code, can be expensive and time-consuming. Imagine the costs associated with running DB2® on 185,000 DB2 clients and 15,000 DB2 servers! It has become important, in fact, necessary for DB2 experts to understand the various methods and options available for deploying DB2.

To be useful to an enterprise, an installation program must be easy to use, it must be mass deployable, and it must be able to configure the installed code. For example, if you installed a DB2 client on an accountant's workstation, there would be a problem if the DB2 client did not know which databases to connect to, or how to do it. For example, the workstation may use the PeopleSoft Financials package. If the workstation doesn't understand that this database is at a specific node (which, among other things, contains the IP addressing information required to make the connection), having DB2 isn't going to help.

Moreover, configuration information may change. For example, if you were to configure database connections to every client in your enterprise, and then had to add a new database (the Human Resources package, for example), you would have to add that connection to every workstation. If you were using a relational database management system (RDBMS) that was not designed to be flexible and extendable like DB2, you would certainly have a problem!

In this article, we will take you through the installation options that you can use to easily deploy DB2 software across your enterprise.

Back to top

Installation methodologies

You can use one of four installation methodologies to distribute DB2 across your enterprise:

• Interactive installation
• Response file installation
• Citrix (also referred to as a Windows ^TM Terminal Server installation)
• Code server (Thin-client) installation

We will discuss each of these methodologies in turn. Keep in mind that a distributed version of DB2 refers to DB2 on the AIX®, HP-UX, OS/2 Linux, Sequent/PTX, and Windows environments; a mainframe version of DB2 often refers to DB2 for iSeries, (formerly known as the AS/400 server); and a host version of DB2 refers to DB2 for zSeries (formerly known as the OS/390 server). Only the distributed version of DB2 is covered in this article.

Back to top

Interactive installation

In UNIX and Linux environments, you can use the operating system's native installation tools (for example, installp on AIX and rpm on Linux) to perform manual installation of DB2 code. However, if you use the native installation tools for your platform (and even if you write scripts that interact with your operating system's installation commands and distribute code that way), you cannot take advantage of the intelligence built into the DB2 installation tools to auto-configure your system, set it up for inbound DB2 communications, and so on.

You have likely had many experiences with interactive installation. This installation type derives its name from the one-on-one interaction between the code and the individual charged with the responsibility of performing the installation; the code configures the installation based on the user's responses.

With this type of installation, the code can be taken directly from a CD-ROM, or that CD-ROM can be mounted on a network drive for access by all users. DB2 can then be installed with the help of GUI-driven installation windows. Another option is to copy the installation code to a shared drive and to perform the installation without reading directly from the CD-ROM device, thereby reducing the potential impact on performance.

Interactive installation, in one form or another, is available on all DB2 platforms and for all DB2 products. In the Windows environment, the installation program is called setup.exe, and is set to auto-start each time you insert the CD-ROM into the CD-ROM drive. In UNIX and Linux environments, the installation program is called db2setup, and is often referred to as the DB2 Installer. On OS/2, the program is called install.exe.

There are advantages and disadvantages to interactive installation. Because the code is installed locally on each machine, performance can be very good. However, any maintenance must be completed on every machine. For example, each FixPak (released quarterly) must be applied (if needed) to each workstation. Another disadvantage is that each person performing the installation must be somewhat knowledgeable about the product. This may not be a huge problem (after all, online help is available to guide you through the installation). Moreover, the installation program comes with default selections and settings that are designed to run in a typical DB2 environment. If you must have inexperienced users install DB2 software using this method, they can simply accept the defaults and perform the installation.

Nevertheless, interactive installation is prone to error when performed by inexperienced users. There may be complexity in setting up user accounts, selecting components, and so on. There are likely to be inconsistent outcomes throughout the enterprise.

If you have mounted the CD-ROM or created a code image on the server, performing the installation over a network can give rise to other considerations. Is the network connection suitable for mobile users? Is the LAN fast enough to accommodate local and remote users, or does it introduce a latency factor? Is the LAN robust enough?

When multiple installations of a DB2 product are required, an interactive installation is impractical. If users are remote or spread across the company, you have to ensure that costly support staff is available for installation and support at each location. The fact is, your business units should not have to install their own software.

In summary, the interactive installation deployment strategy is not suitable for mass deployments. This method can be appropriate for three-tier solutions where only a few copies of the product exist and users have local or dedicated support staff for each system. For a deployment that includes thousands of DB2 clients, but only a handful of DB2 servers, it may very well make sense to use an interactive installation to install the DB2 servers, and another process to install the DB2 clients. Table 1 summarizes the advantages and disadvantages of using an interactive installation.

Back to top

Response file installation

One approach to dealing with the disadvantages associated with an interactive installation is to use a response file installation, which is sometimes called a silent installation because no one has to interact with the installation program. You can use various DB2 utilities to make this option even more attractive for mass deployments.

Response file installation can be performed on any DB2-distributed platform, and it can be performed with or without system management tools, which give you the ability to push installations to target workstations without any interaction from the users of those workstations. This is in contrast to a pull configuration, in which users on the target workstations request that something be done (by typing in the setup command to launch the DB2 installation program, or double-clicking a .bat file, for example).

Response file installations can be used with any configuration installation distribution (CID)–compliant installation management program. Response file installations are fully integrated with Microsoft's System Management Server® (MS SMS); for more information, refer to the DB2 and DB2 Connect Installation and Configuration Supplement.

If you are a database administrator (DBA) responsible for large-scale DB2 code deployments, use the response file installation method for greater control, predictable results, and increased productivity.

• Control A response file installation gives DBAs control over what is installed on a system and how it is configured. Most DB2 environments have multiple DB2 Run-Time clients that are used to provide applications with connections to DB2 databases, and these deployed systems are quite often clones of each other. Such environments usually have DB2 Administration clients that are used for remote administration purposes, and which are almost always identical as well. A DBA may have to invoke the installation program (it can be pushed via management tools or scripts, or pulled by a command or e-mail), but does not need to interact with it.
• Predictable results Response file installation dramatically reduces the number of installation errors, and guarantees outcomes. Users do not have to interpret and answer questions during the installation process.

• Increased productivity Instead of having thousands of employees install their own copy of DB2, or a team of 15 specialists going to each local or remote workstation and installing the code, one DBA at a central site can work on a perfect DB2 installation, test it, and then roll it out across the enterprise.

  A silent installation is controlled by a response file, which is an ASCII file that can be edited using any text editor, such as vi, emac, or Notepad. A response file contains keywords for all the options in an interactive installation, as well as keywords for configuration parameters and DB2 registry variables that you cannot specify during an interactive installation. Response files are available for most DB2 products and for all DB2 server and DB2 client installations. The files are located in the following directories:

  • DB2 clients on Windows x:\db2\windows\common on the DB2 Client Pack CD
  • DB2 servers on Windows x:\db2\common\
  • DB2 clients on UNIX and Linux /cdrom/db2/<platform>/install/samples
  • DB2 servers on UNIX and Linux /cdrom/db2/install/samples
  where x represents a local or remotely mapped drive or device, and <platform> represents the platform. UNIX and Linux paths are assumed to mount the CD-ROM in the /cdrom directory.

Figure 1 shows part of the db2udbwe.rsp sample response file for DB2 Universal Database (UDB) Workgroup Edition. The entire response file is very large and contains keywords to set all kinds of parameters and registry variables. Ellipses (…) show where sections have been deleted to simplify the example.

When applying maintenance FixPaks using a response file in a Windows environment, you cannot add new components, update database manager configuration parameters, or change any DB2 registry values. Because you cannot add new components, only those components that are installed on the system before applying the FixPak are maintained. If you are applying maintenance in a UNIX or Linux environment, you must install the FixPak using the operating system's update utilities. (For AIX, use smit update_all; for Solaris, use installallpatch; and for Linux, use installpatch.)

Back to top

The DB2 response file generator

The response file generator (db2rspgn), available on Windows and OS/2 workstations, can be used to create identical copies of DB2 code across your enterprise. After installing a DB2 product on your workstation, and when you are happy with the installation and its configuration, you can use this tool to generate a response file that reflects the workstation's installation profile. You can also use this tool to generate profiles for the workstation's configuration settings (its database connections and configuration settings for the database manager, the run-time environment, and Open DataBase Connectivity, or ODBC).

The response file generator creates a response file for the installation and instance profiles associated with each instance that you specify. The instance profile contains instance configuration and database connection information. The response file generator gives you the option to create just the installation response file, without any instance profile, if your goal is just to install the code. Response file names have the extension .rsp, and instance profiles have the file extension .ins. Figure 2 shows an example of an instance profile.

The installation response file that is created by the response file generator automatically calls each instance profile. You must ensure that the instance profiles are located in the same directory as the installation response file.

With response file installation, the DB2 code is still local on each machine. Although you have performance benefits, you also have to contend with maintenance issues, but you can use a response file for that as well. The maintenance costs are high, but not nearly as high as those associated with an interactive installation.

A potential disadvantage of this method is the learning curve. While this type of installation is not difficult to learn, it does require some experience.

In summary, the response file installation deployment strategy is very suitable for mass deployments. Response file installation allows you to leverage the skills of one experienced employee to effectively distribute a DB2 product across your enterprise. You also have control over database connection, registry, and configuration settings at the time of installation. Table 2 summarizes the advantages and disadvantages of using a response file installation.

Back to top

Citrix installation

A Citrix installation is a special type of DB2 installation that can be used only with Citrix environments, in which the code is installed (and maintained) on a Citrix server. Clients in a Citrix environment (called dumb terminals) do not run code locally; instead, a Citrix client runs its code in cycles allocated to it on the Citrix server. The fact that code is installed and maintained locally on the Citrix server is a major benefit, because it allows us to leverage the skills of one person for both deployment and maintenance. Figure 3 shows a typical Citrix environment.

The major drawback of this solution is that it applies only to a Citrix environment, and not all DB2 products are supported in this environment. Only DB2 clients and DB2 Connect Personal Edition (PE) servers are supported. Table 3 summarizes the advantages and disadvantages of using a Citrix installation.

Code server installation

In a Windows environment, you can install a DB2 client or DB2 Connect PE on workstations and have these workstations act as code servers to DB2 Thin-client or DB2 Thin-connect workstations in your enterprise. (The term Thin-client is often used to represent a DB2 Thin-client or a DB2 Thin-connect workstation when discussing this architecture.)

Thin workstations load the DB2 client or DB2 Connect PE code across a LAN network connection from their respective code servers. A thin workstation functions like any other DB2 client or DB2 Connect PE workstation; the architecture is transparent to the user. The main difference is that the code is installed on a code server, and not on individual workstations. In a thin environment, no processing in done at the code server; the code is simply loaded from the code server. Each thin workstation needs only a minimal amount of code and configuration to establish links to a code server. This is in sharp contrast to a locally installed DB2 client or DB2 Connect PE workstation, which is sometimes referred to as a Fat-client.

To install a DB2 Thin-client, you must install a DB2 Administration client with the Thin Client Code Server component. After some configuration, this machine will be known as a DB2 Thin-client code server.

Figure 4 shows a typical DB2 Thin-client and DB2 Thin-connect environment. The arrows represent the code that is being loaded on the DB2 Thin-client from the DB2 Thin-client code server. The lightning bolts represent the connection to the database. Once the code is loaded, all processing and activity is handled on the DB2 Thin-client.

A DB2 Administration client is the only type of client that can act as a code server for Thin-client workstations. The DB2 Thin-client workstations access the code server to dynamically load any required code. Once the code is loaded, all processing is done locally on the DB2 Thin-client workstations. Using local database configuration information—or a central repository like an LDAP (Lightweight Directory Access Protocol) or Active Directory—a connection is made to a target DB2 server and the data can be retrieved from this database. Note that the DB2 code is actually run on the Thin-client or Thin-connect workstations; the code is loaded only from its respective code servers—there is no DB2 code installed on the thin workstations.

The major advantage of this solution is that the code is installed at only one location: the code server. This gives you the benefits of touch one, touch all maintenance that you get in a Citrix environment. After the initial loading of required dynamic-link libraries (DLLs), the thin workstation no longer needs to communicate with its code server, so performance is unaffected.

The major drawback of this solution is that it is not suitable for occasionally connected users. Mobile laptop users cannot be expected to load code over a telephone line to acquire the run-time environment that they need for their applications. It may be prudent to use thin workstations locally and to provide mobile users with the Fat-client architecture. Table 4 summarizes the advantages and disadvantages of using a code server installation.

Back to top

Configuration methodologies

Once your DB2 code is installed on both the server and client workstations, you will need to configure these workstations so that they will be able to connect to databases on the server. You may have efficiently installed 2000 clients using response files, but if these clients cannot connect to the DB2 server that stores enterprise information, they are not going to be of much use to your business.

We have already discussed setting up database connections during an installation. This may not be an appropriate solution if the administrator prefers separate installation and connection procedures, or if the database connections require maintenance.

DB2 gives you two options with respect to the location of database connection information: local maintenance and centralized maintenance.

Local maintenance

In a local maintenance deployment, all database connection information is stored locally on each machine in your enterprise. DB2 offers many methods to set up local database connection information:

• The Client Configuration Assistant
• The command line processor
• The response file generator
• Client and server profiles
• System management tools

The Client Configuration Assistant

The Client Configuration Assistant (CCA), available on Windows and OS/2 workstations, is a graphical tool that helps you to quickly set up remote connections to DB2 severs. The CCA contains a launching point for the Add Database wizard, shown in Figure 5. This wizard helps you to define database connections to remote DB2 servers where your applications can access data. The Add Database wizard catalogs nodes and databases while shielding you from the inherent complexities of these tasks.

The list of available databases appears in the CCA's main window. For example, in Figure 6, 12 databases are cataloged on the computer called CR689923-A.

The CCA can add database connections to your workstation by using a profile, searching the network, or by letting you configure the connection manually using known configuration information.

Using a Profile
The CCA gives you the option of generating or importing profiles that can be used to automatically set up connection and configuration information for your DB2 workstations. Information in a profile can be used to configure clients using the CCA's Import function. Clients can import all or a subset of the configuration information in a profile.

Searching the Network
You can search a network to add databases when Discovery is configured and enabled on the client and server systems. (This is automatically done for you in a default DB2 installation.) Discovery is a feature of DB2 that is used to gather information from DB2 servers located on a network. This information can, in turn, be used by DB2 clients to make automatic connections to those servers using the CCA.

Your database administrator can provide the names of DB2 servers on which the databases that you need to access reside; this way, you can add those systems to the Known Systems list, as shown in Figure 7.

You can set your client system to search the network for databases in one of two modes:

• Known Systems (Directed Discovery)
  When the discovery mode database manager configuration parameter (discover) is set to KNOWN, you can specify the connection information to a DAS on the network, and all instance and database information found on that DB2 server system will be returned to the client. To search for databases known to the local machine, you can expand the database object tree until you find the DB2 server and database that you want.
• Other Systems (Search Discovery)
  When discover is set to SEARCH, the wizard uses the protocols specified in the search discovery communications protocols configuration parameter (discover_comm) to search the network for databases. To search for databases in other systems, expand the database object tree. Doing so initiates a search discovery request on the network.

To disable discovery on your system, you can set the discovery mode to DISABLE. Change the discovery mode by clicking Client Settings in the first window of the CCA. You will find these parameters on the Communications tab.

Configuring the Connection Manually Using Known Configuration Information
The CCA also gives you the option of configuring database connections using a graphical interface to dress up the command line processor. To use this method, you must be familiar with your communication protocol's configuration parameters. For example, when setting up a TCP/IP connection, you need to understand the svcename and the TCP/IP port_number of the remote server with which you are attempting to establish communications.

The Command Line Processor (CLP)
You can use the CLP to manually set up communications between DB2 clients and DB2 servers. To configure DB2 communications using the CLP, you must add entries to catalogs that a DB2 client can use when trying to reach a DB2 server. For example, to catalog a remote DB2 server, you need to add an entry to a node directory and a database directory. If you are attempting to reach a DB2 server that resides on an iSeries or a zSeries machine, you also need to catalog the Database Connection Services (DCS) directory.

The Response File Generator
As discussed earlier, the response file generator (available on Windows and OS/2 workstations) can be used to generate profiles for the workstation's configuration settings (its database connections and configuration settings for the database manager, the run-time environment, and Open Database Connectivity, or ODBC).

Client and Server Profiles
DB2 provides the option to create profiles that contain database manager configuration, database connection, and ODBC/CLI (Call Level Interface) settings. Using import and export commands, you can import or export this information to and from files, and easily deploy configuration information across an enterprise.

System Management Tools
As discussed earlier, DB2 is tightly integrated with MS SMS; therefore, you can use SMS to “push” script commands to target DB2 clients. This means that the DB2 clients receive and process scripted instructions that they haven't requested. For example, when you replicate your e-mail, you are pulling messages from your mail server. If you do not have a replication scheme set up, and receive e-mail when it is sent to you, this e-mail is being pushed to your system.

Using MS SMS, you can distribute database connection information using a push strategy. Suppose that your workforce needed a new database connection. An administrator who uses MS SMS could push out a batch file that imports a client profile or adds a database connection to target workstations—all of this transparent to the users of those workstations.

Back to top

Central Maintenance

In a central maintenance deployment, all database connection information is stored on a server. A central maintenance configuration deployment is set up using a supported LDAP or an Active Directory server acting as an LDAP server. LDAP servers can be set up on AIX, Solaris, or Windows NT/2000–based workstations.

LDAP is an industry standard method to access directory services. A directory service is a repository of information about multiple systems and services within a distributed environment, and it provides client and server access to these resources. Each database server instance publishes its existence to an LDAP server and provides database information to the LDAP directory when databases are created. When a client connects to a database, the catalog information for the server can be retrieved from the LDAP directory. Each client is no longer required to store catalog information locally. Client applications search the LDAP directory for information that they need to connect to the database.

The easiest way to think of a central maintenance setup is to think of an Internet phone book. In a local maintenance setup, DB2 clients have to maintain their own “personal phone book” (node and database directories) with an entry for every database to which they want to connect. Each client has its own distinct node and database directories. In a central maintenance architecture, DB2 clients connect to an LDAP server that has a listing of all the published resources in the enterprise, and DB2 clients can use this information on the server to connect to these databases. This is just like looking up someone's phone number on the Internet. You don't have it locally, so you go to an appropriate resource.

Administrators who set up this type of environment have to make sure that the LDAP server is highly available. If the LDAP server were not available, DB2 clients would not be able to connect to it and retrieve the database connection information that they need. (If your Internet connection is down, you cannot connect to your online phone book.)

Figure 8 shows a typical LDAP implementation.

In DB2, a caching mechanism exists so that the DB2 client searches the LDAP directory only once. When the information is retrieved, it is stored or cached locally. Subsequent access to the same information is based on the values of the dir_cache database manager configuration parameter and the DB2LDAPCACHE registry variable as follows:

• If DB2LDAPCACHE=NO and dir_cache=NO, then always read the information from LDAP.
• If DB2LDAPCACHE=NO and dir_cache=YES, then read the information from LDAP once and insert it into the DB2 cache.
• If DB2LDAPCACHE=YES or is not set, and if the required information is not found in the local cache, then read the information from the LDAP directory and refresh the local cache.

LDAP allows you to update catalog connection information in one location (the LDAP server), and then all DB2 clients can leverage that information to make their database connections. If you are already using LDAP in your enterprise, this may be a better solution than one of the local maintenance options. LDAP is a touch one, touch many database connection architecture.

You can set up a central maintenance environment using the CCA or the CLP, along with the LDAP software that you are implementing. The CCA has fields that are enabled for LDAP servers, and the CATALOG NODE and CATALOG DATABASE commands have LDAP extensions in their syntax.

About the authors

		Paul C Zikopoulos, BA, MBA,is a Database Specialist with the IBM Global Sales Support team. He has more than six years of experience with DB2 and has written numerous magazine articles and books about DB2. Paul has written articles for such magazines as DB2 Magazine, Linux Journal, DB2 Update, IDUG Solutions Journal, and more. Most recently, Paul co-authored the books DB2 For Dummies (Hungry Minds Inc., 2000) and DB2 Fundamentals Certification for Dummies (Hungry Minds Inc., 2001). Paul is a DB2 Certified Advanced Technical Expert (DRDA and Cluster/EEE) and a DB2 Certified Solutions Expert (Business Intelligence and Database Administration). You can reach him at paulz_ibm@yahoo.com.

		Roman B. Melnyk, PhD, is a senior member of the DB2 Information Development team, specializing in database administration and DB2 utilities. During more than six years at IBM, Roman has written numerous books for the DB2 product library and other related materials. Most recently, Roman coauthored DB2 Fundamentals Certification for Dummies (Hungry Minds, in press) and DB2 For Dummies (IDG Books, September 2000). You can reach him at roman_b_melnyk@hotmail.com.

Rate this page

Please take a moment to complete this form to help us better serve you. Did the information help you to achieve your goal? Yes No Don't know   Please provide us with comments to help improve this page:   How useful is the information? 1 2 3 4 5 Not useful Extremely useful

Share this.... Digg this story del.icio.us Slashdot it!

Back to top