DB2 Version 9.7 for Linux, UNIX, and Windows
Installing DB2 Servers > Installing on Windows >

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:

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

Differences when multiple DB2 copies are installed on the same computer

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

Your system environment includes several DB2 copies one which is the 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.

As you are installing a new DB2 copy, you decide not to make the new DB2 copy the default DB2 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.)

However, consider the same scenario but you respond "Yes" when asked if you want to make the new DB2 copy the default DB2 copy.

As you are installing a new DB2 copy, you decide to make the new DB2 copy the default DB2 copy.

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:

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 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.

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.

[ Top of Page | Previous Page | Next Page | Contents ]