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 this configuration include:
- The ability to run applications that require different DB2 versions on the same host at
the same time.
- The ability to run independent copies of DB2 products for different functions.
- The ability to test on the same computer before moving the production
database to a later version of the DB2 product.
- 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 is a group of DB2 products that are installed
at the same location.
Differences when only one DB2 copy is installed
- During installation, a unique default DB2 copy name is generated. You can 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.
- 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
- DB2 Version 8 can coexist
with DB2 Version 9.1, DB2 Version 9.5, and DB2 Version 9.7 with the following restrictions.
- The DB2 Version 8 copy must
be the default copy even if you have multiple copies of DB2 Version 9.1, Version 9.5, or Version 9.7.
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 of the DB2 Version 9.1, Version 9.5, or Version 9.7
copies.
- 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 host. You can however configure the DB2 database server to access these DB2 Information Centers remotely.
- 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.
- Each DB2 copy must have
unique instance names. For a silent installation with the NO_CONFIG flag
set to YES, the default instance is not created.
However, when you create the instance after the installation, it
must be unique. The default name of the instance is "DB2". If an instance of the "DB2" name exists, a unique name for the instance
is generated. The unique name is generated by using the "DB2" name and adding an underscore
and generating the last two characters in numeric sequence. The subsequent
instance names generated are "DB2_01", "DB2_02", and so
on. For performance reasons, the DB2 Control
Center should be used from only one DB2 copy
at a single time on a host.
- For Microsoft COM+
applications, use and distribute the IBM Data
Server Driver Package (installer) or IBM Data
Server Driver for ODBC and CLI (compressed
file) 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 (compressed
file) 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 DB2Universal
Database (UDB) Version 8 installed, you must use the DB2 UDB Version 8 copy to run these applications.
If you have DB2 Version 9 or
later installed, you can change the default DB2 copy with the Default DB2 Copy Selection Wizard, but you cannot use
them concurrently.
Choosing a default when installing a new 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, imagine a scenario where you install one DB2 copy (DB2COPY1).
It is the default DB2 copy and
the 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.)
However,
consider the same scenario but you respond "Yes" when asked if
you want 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 can coexist with DB2 Version 9 and later versions of DB2 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 migrate 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:
- If the DAS is on Version 9, then it can administer Version 8 and
Version 9 instances.
- If the DAS is on Version 8, then it can administer only Version
8 instances. You can migrate your Version 8 DAS, or drop it and create
a Version 9 DAS to administer the Version 8 and Version 9 instances.
A Version 9 or later DAS is required only if you want to use the Control
Center to administer instances that are at Version 9 level or higher.
Version 8 and Version 9 coexistence and the DB2 .NET Data Provider
In DB2 Version 9, the DB2 .NET Data Provider has System.Transactions namespace
support. However, this support 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 is registered in the Global Assembly Cache by the Version
8 installation. The 2.0 provider is registered by the Version 9 installation.
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.
Applications that run as a service
Applications
that dynamically bind DB2 DLL
files, for example applications that are linked with
db2api.lib,
find the DB2 DLL files in the
PATH.
This means that existing applications that were not developed for
multipleDB2 versions use the
default DB2 copy. To work around
this behavior, the application can use the
db2SelectDB2Copy API
before loading any DB2 libraries.
Note: When
linking with db2api.lib, the functions resolve
to different DLL files on Windows 32-bit
and Windows 64-bit platforms.
The runtime DLL files on a 64-bit platform have the same base name
as the 32-bit version with the addition of the "64" suffix. For example, db2app.dll on
a Windows 32-bit operating
system is equivalent to db2app64.dll on a Windows 64-bit operating system.
For
more information, see the
Call Level Interface Guide and Reference, Volume 1.
32-bit and 64-bit versions on Windows x64
DB2 does not support multiple DB2 32-bit and 64-bit versions installed on Windows, because the DB2 32 and 64-bit registries are
stored in different locations. If you install the DB2 64-bit version, the 32-bit version is removed
from the system.
LDAP and CLI configuration
With DB2 Version 8, if an application
needs different LDAP settings, it must authenticate
with a different LDAP user. Otherwise, the CLI configuration affects
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.
Applications that dynamically link DB2 DLL files
Applications that link
to DB2 DLL files directly or
that use LoadLibrary instead of LoadLibraryEx with
the LOAD_WITH_ALTERED_SEARCH_PATH flag must ensure
that the initial dependent library is loaded properly. You can use
your own coding technique to check that the library loads, or you
can call the db2envar.bat file to set up the
environment before running the application, or you can call the db2SelectDB2Copy API,
which can be statically linked into the application.
Visual Studio plug-ins
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 plug-ins registered on the same computer
at the same time. The version of the plug-ins that is active is the
version that is included with the default DB2 copy.
Licensing
Licenses must be registered for
each DB2 copy. They are not
system-wide. Copy dependent licensing provides the ability for both
restricted versions of DB2 products
and full versions of DB2 products
on the same host.
Windows Services
DB2 services on Windows platforms use the <servicename_installationname>
naming convention. 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 DLL
files. 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: The db2SelectDB2Copy API
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 DLL files
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 with Multiple DB2 Resources
Each DB2 resource
must be configured to run in a separate resource monitor.