Deploying IBMDB2 on UNIX and Linux platforms

Deploy the IBMDB2 product-Linux Enterprise Application-Linux server application on UNIX and Linux platforms. For details, refer to the following section. Deploy IBM _ DB2 products on dozens, hundreds, or thousands of clients and servers based on UNIX and Linux platforms, including IBM DB2 Universal Database (DB2 UDB) and DB2 Connect, this seems like a daunting task.

This article describes how to quickly, easily, and consistently deploy DB2 products on UNIX and Linux platforms across multiple machines. This manual can be used to install clients, servers, parallel servers, and FixPak.

This article mainly discusses the DB2 Version 8 product family on UNIX and Linux platforms. This manual is similar to the previous version and will continue to be similar in the future.

For the sake of simplicity, the example in this article uses the Bourne shell syntax. Other shell users will need to make appropriate adjustments.

DB2 Products

The DB2 family that supports UNIX and Linux has more than 15 Version 8 products. You need to select products based on the platform. Therefore, if you are not familiar with the DB2 product line, choosing the right product is a challenging task. To help you determine which DB2 product to install in the computer operating environment, we provide the following product overview.

This overview is not intended to describe the license terms for each product in detail, but to summarize the features and Use Cases of each product. In addition, this overview does not cover all DB2 products, but only discusses those products that are most functionally obfuscated Based on PMR, newsgroup posts, and communications with IBM customers.

Note that not all products apply to all platforms.

DB2 Client

There are four DB2 client products with different levels of functionality.

DB2 Run-time Client is applicable to computers that only require the DB2 Client to support applications to communicate with remote DB2 servers without managing any servers. Therefore, no graphic tools are provided. However, any application that uses DB2 UDB or DB2 Connect should be able to run through this product. In general, this product is required for most applications, whether provided by a third party or developed internally.

The DB2 Administration Client is designed for DB2 administrators. It has all the functions of the DB2 Run-time Client and Adds all graphical tools. Note that the simplified installation of the DB2 Administration Client is functionally equivalent to the streamlined installation of the DB2 Run-time Client.

DB2 Application Development Client is designed for developers who write software to use DB2 products or compile DB2 API software. It has all the functions of the DB2 Administration Client and adds a new graphic tool that can be used for application development.

DB2 Connect Personal Edition is a licensed Client that provides all the functions of the DB2 Application Development Client and adds the ability to Connect to a host database (such as DB2 for MVSTM.

Because each client contains all the functions of its previous client, you almost do not need to install multiple clients on one machine. Multiple clients are installed only when the computer role is changed. For example, when a user initiates a new requirement to access the host database, the user needs to migrate to DB2 Connect Personal Edition. In these cases, you can simply install the new client on the old client and re-run all FixPak to perform the upgrade.

DB2 Server

　　

DB2 servers are extended in the same way as clients. All DB2 servers are licensed.

DB2 UDB Personal Edition is a strict desktop product because it does not allow remote client connections. To some extent, it is similar to the DB2 Application Development Client and adds the function of allowing only local clients to access the local database.

DB2 UDB Express Editions is designed for small and medium-sized enterprises with a few clients. They have all the features of DB2 UDB Personal Edition and allow remote connectivity.

DB2 UDB Workgroup Server Editions is designed for large-scale servers. They have all the features of DB2 UDB Express and have broader licensing.

DB2 Connect Enterprise Editions is designed for a client to Connect to a host database (such as DB2 for MVS) with the three-tier gating function. They have all the features of DB2 Connect Personal Edition and added the gateway feature.

DB2 UDB Enterprise Server Edition is designed for large and ultra-large databases. If you do not consider the database partition feature (DPF), it is functionally equivalent to a combination of DB2 UDB Workgroup Edition and DB2 Connect Enterprise Edition. With DPF, Enterprise Server Edition allows multiple machines to run together as a single shared-nothing cluster, and simulates a single database Server with multiple machines.

Because each server has all the functions of all clients, including graphical tools and application development tools, there is no reason to install the client on a computer on which the server is already installed. This significantly simplifies the deployment of DB2 products.

Developer version

The DB2 developer version is only different from the above in terms of license. However, there are indications that ensuring that the product is included in large-scale deployment in the development environment has caused a lot of confusion.

DB2 UDB Personal Developer's Edtion is a limited license version of DB2 UDB Personal Edition for small development teams. It includes a limited license for DB2 UDB Personal Edition and DB2 Application Development Client, allowing a single developer to write, compile, and test code for a local server. Although it allows development and use of remote databases, the remote database product is not included in this software package. Since DB2 API hides some details (such as the actual location of the database), Development in DB2 UDB Personal Edition is the same as development in any DB2 UDB Server (such as DB2 UDB Enterprise Server Edition.

DB2 UDB Universal Developer's Edition is a full-featured, all-in-one development product for large development teams. It contains almost all DB2 for Linux, UNIX, and Windows products, including products not covered in this article. Because it contains all server products on all platforms, it can be used for developing multiple platforms or developing platforms not supported by DB2 UDB Personal Developer's Edition.

In addition to its license terms, the Developer's Edition product is the same as the previous product, so you do not have to install these products on existing products, and vice versa.

Deployment Overview

To deploy DB2 on UNIX and Linux, follow these steps:

1. Create a code Server

2. Planned deployment

2.1 (optional) create a response file for automatic configuration.

3. Create a deployment script

4. Run the deployment script on all machines.

Create Code Server

The purpose of creating a code server is to accelerate the deployment process. In fact, transferring a CD from one system to another is not reasonably taking advantage of the Administrator's time, or even installing the CD on one machine, the installation through network file systems (such as NFS, DFS, and AFS) will slow down all deployment because the latter needs to continuously jump to respond to network requests.

By copying a CD to a hard disk, we can take full advantage of the shortened search time and increased buffer provided by most physical file system drivers.

In addition, some products in DB2 Version 8 provide compression for some platforms in their CD. For these products, we must copy them to a local disk and decompress and release the files because we cannot directly share the image files from the CD.

Depending on your products and platforms, you may be able to copy files directly. Otherwise, you must decompress the image file. If you can copy an image file, we recommend that you use the following command with the root permission:

# (Cd/cdrom; tar cf-*) | (cd/bigshareddisk; tar xf -)

The basic purpose of using a tape archive file is that not all platforms have cp commands that support symbolic link or symlink. On the contrary, any equivalent command that can maintain symbolic links, ownership, and permissions also applies.

If you have a pre-compressed image file, run the following command:

# (Cd/cdrom; zcat *. tar. Z) | (cd/bigshareddisk; tar xf -)

On Linux, you can use the Z option to execute the preceding command:

# Cd/bigshareddisk; tar xzf/cdrom/*. tar. Z

Note: We recommend that you do not use Microsoft®Windows®File Server. Windows File Server will lose the File Permission and cannot process files with different names. This situation exists in both DB2 for Solaris and DB2 for Linux products.

The next step is to export/bigshareddisk through the Network File System. The procedure is beyond the scope of this article. Note: Although DB2 itself cannot be installed in the NFS partition, DB2 can be installed through NFS.

Planned deployment

DB2 for UNIX and Linux can be installed in a variety of non-interactive ways. The method you choose depends on your preference. All methods can be used in turn. That is, you can perform the installation in one way, and then execute another installation on the same machine in another way. Selecting a method does not mean that you always need to use this method.

There is only one method available for FixPaks.

We strongly recommend that you test the installation on a test machine before any deployment to verify what is generated on each machine. In addition, we strongly recommend that you use a graphical installation program at least once before designing a non-interactive DB2 deployment, even before testing and deployment. The graphical installer helps you understand the terms and keywords in non-interactive installation mode. FixPaks does not have any graphical installer.

Response File Installation

The recommended method is to respond to File Installation. This method involves creating a response file (which will be described later in this article), and then running db2setup for the response file. This method is recommended because it provides many advantages:

• The pre-response File Syntax check means that if db2setup accepts the response file, it is likely to run.

• It allows you to choose the same or better granularity as the graphic installer.

• It allows you to configure all the content configured by the graphical installer without the need to know what is happening.

• It allows you to configure Database Management Program configuration (dbm cfg) and DB2 configuration file registry parameters synchronously with the installation.

• All output and log files can be fully interpreted.

Db2_install

Another method you can use is the db2_install script. It is a thin, coarse-grained packaging program that only calls the underlying operating system Installer (AIX®, Solaris, HP-UX, and installp, pkgadd, swinstall, or rpm on Linux operating systems) install the entire product. Compared with the installation of the response file, this method has the following limitations:

• Coarse-grained installation means that all alternative components cannot be selected during installation.

• Language selection is not included. You must use another method to install languages other than English.

• This does not include the configuration or instance of the DB2 Administration Server (DAS.

However, it does not need to set any response files.

Operating System Installer

This method involves calling the operating system installer that can be directly applied to the platform. For more information about how to execute this method, see the operating system documentation and related homepage. Compared with the response File Installation, this method has the following limitations:

• You must install components manually in the correct order.

• Component names are generally not as readable or intuitive as the response file identifier.

• It does not contain any DAS configurations or instances.

Compared with using db2_install, this method has the following differences:

• More flexible, because you have only installed the required components.

• You can install languages other than English.

• More time is required because you must select the component to be installed.

FixPak Installation

FixPak installation is usually non-interactive and is often used for large-scale deployment.

Create a response File

Creating a response file is an optional but recommended step. The response file significantly simplifies the installation script. The response file cannot be used for FixPak installation.

The response file may vary significantly depending on the target environment. This article mainly targets three environments: client, single-host Server (for example, any Server except Enterprise Server Edition with DPF), and Parallel Server (for example, Enterprise Server Edition with DPF ).

For machines deployed in combination with the preceding three environments (for example, the database server with Relational Connect for DB2 Data Sources installed must also serve as another database client ), these environments can be combined. However, this article does not discuss these combinations for the sake of simplicity.

Response File

The simplest way to create a response file is to use the db2setup GUI. By starting db2setup and saving the response file, you can select the component to be installed graphically. Then, you can adjust the response file by copying additional entries from the sample response file provided in CD.

Another way to create a response file is to copy the sample response file from the CD and modify the sample response file. The example is stored in the db2/pto/samples Directory. plat is the platform identifier. For example, db2/linux/samples/db2rtcl. rsp is the Run-time Client Sample Response file for Linux in DB2 for Linux CD.

Although it is strongly recommended to test on a machine before deployment, the response file is very easy to use.

The first thing you need to know about the response file is that any line starting with * or # Will be ignored as a comment.

* Thisisa comment.

All rows whose ends contain ** or # sequences are ignored as comments.

PROD = ENTERPRISE_SERVER_EDITION ** This is a comment.

All data is displayed in KEYWORD = VALUE format. In the above example, the keyword is PROD, and the given value of the PROD keyword is ENTERPRISE_SERVER_EDITION.

Each keyword is considered as a tag. That is, this keyword is retained without translation. Most values are also marked. For example

INSTALLJTYPE = TYPICAL

Keywords and values are tags, so they should not be considered as English words. The response file installer can recognize these tags, and all the tags it recognizes are the same, regardless of their language.

The entries in the uncommented Sample Response file are considered mandatory and must be entered before installation.

Finally, many keywords are directly mapped to problems you may encounter during graph installation. Therefore, mastering graph installation can help you understand the response file.

PROD

The PROD keyword specifies the product to be installed. This keyword is pre-filled in each sample response file. You do not need to change it.

INSTALL_TYPE

This keyword specifies the type of installation: simplified, typical, and custom. If you select a typical option, you can also select all the typical options. If you select Custom, you can select all components to be installed. If you select streamline, all these optional steps will be ignored.

TYPICAL_OPTION

If you have selected the installation type as TYPICAL (TYPICAL), you can select another TYPICAL option set. For example, if you want to install Enterprise Server Edition with the Data Warehouse option in a typical way, you can choose here. You only need to remove the asterisks before each option that does not need to be installed in the deployment. If the installation type is not TYPICAL, ignore this keyword.

COMP

If you have selected the installation type as CUSTOM (CUSTOM), you can select other components by removing the annotation characters from the required components. In contrast, the Linux and UNIX response files differentiate components by specifying which components are used for a typical installation and each typical option. If the installation type is not CUSTOM, ignore this keyword.

LANG

If you want to use a language other than English, select this keyword. Unlike the graphics installer, if the current language is not English, the response file installer does not automatically select the current language. The language tag here is the same as the one used by the installer with the-I option.

SELECT_INSTALLED_LANGS

If YES is set, all languages that have been installed in DB2 are automatically selected. This is ideal for installing the second product in the same system, while maintaining the original language settings for all new features.

ENCODING

If no encoding method is selected, all encoding methods are automatically installed. Different encoding methods are applicable to each language. If you do not need all encoding methods, you can select the desired subset. Note that the ISO or EUC encoding method must be used as an anti-encoding method (fall-back encoding) for some languages ).

LIC_AGREEMENT

This parameter indicates to the response file installer that you have read and agree to the license contained on the DB2 media. You can find this license in the db2/\ iceme/locale. encoding Directory. The default value is DECLINE ). You must change it to ACCEPT (ACCEPT) to continue the installation.

Instance creation settings

These settings can be used to create instances as part of the installation. You can create multiple instances in one installation by using multiple INSTANCE names. For example, you can create INSTANCE = instancel and INSTANCE = instance2. For each instance, you must use the instance1 and instance2 prefixes to create the remaining parts of the settings.

Most of these settings are either database management program configuration settings or DB2 configuration file registry settings (all these configurable settings should be included in the response file ).

Other settings allow you to create new users, including passwords. If you choose to use the response file to create a new user, we recommend that you use the correct file system security to ensure that only the root user can read the response file on each machine that runs the installation, because the password is stored in plain text. Instead, you may want to create a user account and set a password before using the response file.

The instance is used to store DB2 configurations. This includes the local database of the server and the remote database of the client and server.

If you migrate an instance from the previous version, you do not need to create a new instance. DB2 requires an instance to perform all the operations, whether it is hosting a local database or connecting to a remote database.

Unlike storing all the settings in the response file, One alternative is to use the db2cf exp command to export the configurations from an existing instance. In this case, you can precisely configure the master instance (including performance tuning and cataloging remote nodes and databases, but not local databases) on the test machine as needed, and then use commands

"Db2cfexp Template to export the configuration. During deployment, you need to use db2cfimp to import the template stored in the specified file. For example, "db2cf exp db2inst. exp template" can create a file describing the current instance named db2inst. exp.

Manage Server Settings

These settings can be used to create a DAS. If a section in the sample response file shows that some products allow the use of Management Servers, these products must have management servers. If there is no management server on the target machine, you must use this section to create a management server. The user associated with the DAS must be different from the user used by any instance.

For the first installation of this version, you only need to create a new DAS. For example, if you have installed Workgroup Server Edition and need to upgrade to Enterprise Server Edition, the existing DAS in the previous installation is sufficient. In this case, you can comment out the Administration Server settings.

Client deployment

Because the main purpose of Client installation is to communicate with the remote server, exporting the client configuration file from the running client can simplify the deployment, as this makes it easier to edit nodes and database directories.

Single Server deployment

A local database cannot be created when the response file is installed. These databases must be created as part of the deployment script.

Parallel Server deployment

Server instances in the parallel environment only need to be created on one computer. It is usually the first computer installed and created on the local disk of the computer. This computer is called "instance owning computer ". Other computers in the cluster do not have to have any created instances. These computers are called "nodes )".

As you can see, two different types of installation are deployed here. First, you must install DB2 Enterprise Server Edition and the response file for creating a local instance on the computer on which the instance is created. Second, for each node, DB2 Enterprise Server Edition needs to be installed without creating a response file for any instance. The second response file can be created from scratch: delete all the parts of the response file related to the instance, or, in other words, only the keywords that involve the product, installation type, component, language, or license are retained.

Another way to create these response files is to use a graphical installer to install nodes with instances. During graph installation, there is an option to save the response file for all nodes. If you are deploying a single cluster, this usually makes the operation easier.

The response File Installation in the parallel environment cannot set the. rhosts file for rsh access between nodes, or set the db2nodes. cfg file.

Create deployment script

This script is usually written in shell scripts, but can be used in any language, including Perl, JavaTM, or C. This can be simply seen as a wrapper that handles the installation and configuration of DB2 that is not handled during the DB2 installation process. A script is a file that runs on the target machine and is called as part of the deployment process.

The first step is to decide what to execute. If you have created a complete response file, this step is very simple. Otherwise, this step will be quite complex, especially when you do not use the response file for installation.

In all examples, we assume that/share is a remote file system and is installed as/share on all machines to be deployed. If no shared file system is available, it is possible to install the file system remotely or write scripts to automatically install and uninstall the file system. (How to fix a file system is beyond the scope of this article .)

The file system can be NFS, AFS, DFS, or any non-local file system. We recommend that you do not use the Samba File System. The reason is described in the "Create Code server" section above.

DB2 Run-time Client is used as a sample product, but the steps are the same as those for all products.

Deployment response File Installation

This is the simplest case. Because the product definition, component selection, and instance settings are almost completely encapsulated by the response file, a lot of work can be done by simply calling the response file:

// Share/rtcl/db2setup-r/share/rtcl/db2rtcl. rsp

Here, we have stored the custom response file in the/share/rtcl directory of the product.

Post-Installation

Because the normal use of the Run-time Client also includes directory editing for remote servers and databases, we can also automate directory editing. We can use db2cfimp (if we use db2cfexp to export them according to the above operations) to automatically complete the operation, or manually edit the directory. For example, you can use the created instance db2instl to use db2cfimp:

Su-db2instl-c ". sqllib/db2profile;

Db2cfimp/share/rtcl/db2inst. exp"

Use the same instance to manually edit the directory:

Su-db2instl-c ". sqllib/db2profile;

Db2 catalog tcpip node ..."

In the second case, it is best to store the directory editing command in another file and then allow the DB2 command line handler to read the file:

Su-db2instl-c ". sqllib/db2profile;

Db2? Tvf/share/rtcl/catalog. db2"

Another file can perform other operations required to set DB2. For example,

Catalog tcpip node server remoteserverhostname;

Catalog databasesampleatnodeserver;

Updatedbm cfg usingjdk_path/opt/lBMJava2-141;

Server issues

In server deployment, you usually need to add commands to create and set databases, tablespaces, tables, and so on. For the client, you can create a single/share/ddi/createdb. db2 script to simplify the deployment script.

Parallel Server issues

In addition to the preceding server issues, the deployment script must be able to update the. rhosts and db2nodes. cfg files as needed in a parallel environment.

Use db2_install to deploy and install

Although this method bypasses the process of creating a response file, it also misses all the conveniences brought about by the installation of the response file.

The installation phase is quite simple:

/Share/rtcl/db2_install-p DB2.RTCL-n

Product identifiers are unique for each product: refer to the product documentation to obtain