DB2 10.5 for Linux, UNIX, and Windows

Upgrade restrictions for DB2 servers

Before you start to upgrade your DB2® server, you must understand what the support for upgrade is and what the restrictions are.

What is supported?

Upgrading to DB2 Version 10.5 is supported from DB2 Version 10.1, DB2 Version 9.8 and DB2 Version 9.7. If you have an earlier version of DB2, you must upgrade to DB2 Version 9.7 or DB2 Version 10.1 before upgrading to DB2 Version 10.5.
Upgrading to a DB2 Version 10.5 non-root installation is supported from a DB2 Version 10.1 and DB2 Version 9.7 non-root installation. Upgrading to a DB2 Version 10.5 non-root installation from a pre-DB2 Version 10.5 root installation is not supported.
On Windows operating systems, the upgrade action shows for existing DB2 copies that can be upgraded during the installation of DB2 Version 10.5. This action automatically installs DB2 Version 10.5 and upgrades all of your instances and your DB2 Administration Server (DAS) running on the DB2 copy. This action also uninstalls the DB2 copy and any add-on products installed in this copy. If you do not choose the upgrade action, you must manually upgrade your instances and your DAS after installation.
On Linux and UNIX operating systems, the upgrade action is not available and you can only install a new copy of DB2 Version 10.5. You have to manually upgrade your instances after installation. You can manually upgrade your existing DAS.
Instance bit size is determined by the operating system where DB2 Version 10.5 is installed, and support for 32-bit kernels and 64-bit kernels has changed. See Table 1.
Upgrading from a system with multiple copies of DB2 Version 9.7 and DB2 Version 10.1 of all levels is supported. On Windows operating systems, you must be aware of the restrictions on coexistence of previous versions of the DB2 database products.
Upgrading from a partitioned database environment with multiple database partitions is supported.
Restoring full database offline backups from pre-DB2 Version 10.5 copies is supported. However, rolling forward of logs from a previous level is not possible. Review Backup and restore operations between different operating systems and hardware platforms for complete details about upgrade support using the RESTORE DATABASE command.
In upgraded databases with the RESTRICT_ACCESS database configuration parameter set to YES, you must grant the USAGE privilege to non-DBADM users on SYSDEFAULTUSERWORKLOAD. Otherwise, these users are unable to submit any work to the database.
Upgrading a database that contains encrypted data in a DB2 instance that does not support encryption (where the IBM Global Security Kit is not installed) is supported. The encrypted data is included in the upgraded database, but you cannot access the encrypted data. To access the encrypted data, upgrade or restore the database to an instance that supports encryption.

What is unsupported?

DB2 Version 10.5 installation fails if the following situations exist:

The operating system is not supported. You must upgrade to a supported version of the operating system before you upgrade to DB2 Version 10.5 or upgrade to a new DB2 server that meets the operating system requirements. See Upgrading to a new DB2 server.
A version of DB2 before Version 9.7 is installed.

The db2iupgrade command fails if the following situations exist:

You do not have authorization to upgrade the instance.
The instance that you are trying to upgrade is active. Run the db2stop command to stop the instance.
The instance is already at DB2 Version 10.5 or later. Run the db2iupdt command to update to a different fix pack levels or copies of DB2 Version 10.5.
You try to upgrade from DB2 Version 10.5 back to DB2 Version 10.1 or DB2 Version 9.7. Reversing DB2 server upgrade is possible, however, you must follow the prerequisites and steps in this procedure.

The type of instance that you are trying to upgrade to the DB2 Version 10.5 copy is unsupported. The following table describes the upgrade support for each type of instance by DB2 database product:

Table 1. Instance upgrade support for DB2 Version 10.5 database products
Instance type	Node type	Upgrade support
client - default type for DB2 clients ¹	Client	Upgrade to a client, a standalone, a wse, or an ese instance is supported.
standalone	Database server with local clients	Upgrade to a standalone, a wse, or an ese instance is supported. Upgrade to a client instance is unsupported.
ese - default type for DB2 Enterprise Server Edition, DB2 Advanced Enterprise Server Edition, DB2 Workgroup Server Edition, and DB2 Advanced Workgroup Server Edition.	Partitioned database server with local and remote clients or Enterprise Server Edition with local and remote clients	Upgrade to an ese instance is supported. Upgrade to a standalone or a wse instance from single database partition environments creates a standalone or wse instance²(Linux and UNIX only) Upgrade to a client instance is unsupported.
dsf - default type for DB2 pureScale® feature	Enterprise Server Edition with local and remote clients	Upgrade to a dsf instance is supported.

Note:

The highest level for each DB2 database product is the default instance type as indicated in Table 1 ordered from lower to higher-level. Each instance type supports instance types of a lower-level. For example, the ese instance type supports wse, standalone, and client. You can use the db2icrt command with the -s parameter to create instances of a lower-level. If you do not specify the -s parameter, the instance is created using the highest level of instance type supported by the DB2 database product installed.
During upgrade, the previous database manager configuration parameters will be retained and available after the instance is upgraded to a new version.

The db2ckupgrade command fails and causes the db2iupgrade command to fail. The db2iupgrade command calls the db2ckupgrade command to verify whether cataloged local databases are ready for upgrade to DB2 Version 10.5.

The UPGRADE DATABASE command fails if the following situations exist:

You do not have authorization to upgrade the database.
A cataloged database does not exist.
Database upgrade encounters any of the problems described in the reason codes of error message SQL1704N.
User-defined distinct types (UDTs) are encountered with the names ARRAY, BINARY, CURSOR, DECFLOAT, ROW, VARBINARY, or XML. You must drop these UDTs and re-create them with different names before database upgrade.
Database objects were created using restricted schema names described in the error message SQL0553N. The list of restricted schema names now includes SYSPUBLIC.
A database is enabled as a high availability disaster recovery (HADR) standby database.