DB2 Version 9.7 for Linux, UNIX, and Windows
DB2 Version 9.7 for Linux, UNIX, and Windows
Consider the following best practices when planning your DB2® server upgrade.
Upgrading in a test environment allows you to learn about possible issues, evaluate the impact on your environment and find a resolution.
The support for UNIX, Linux and Windows operating systems has changed in DB2 Version 9.7. Review Installation requirements for DB2 database products to determine whether your operating system version is supported and if you need to upgrade your operating system before installing DB2 Version 9.7. Note that newer versions of operating systems can also bring new hardware requirements.
Even when you are not required but decide to upgrade, performing hardware and operating system upgrades separately from DB2 database product upgrade simplifies problem determination if you encounter upgrade difficulties. If you upgrade your software or hardware prior to a DB2 database product upgrade, ensure that your system is operating as expected before attempting the upgrade process.
If you have a DB2 Version 9.1 copy on Windows XP or Windows 2003, first apply a fix pack that supports Windows Vista before you upgrade the operating system to Windows Vista to ensure that your DB2 copy performs as expected after the operating system upgrade. The support for Windows Vista starts from DB2 Version 9.1 Fix Pack 2. If you have a DB2 UDB Version 8 copy on Windows XP or Windows 2003, first upgrade to DB2 Version 9.7 and then upgrade the operating system to Windows Vista.
If you have a DB2 UDB Version 8.1 32-bit copy on Linux on POWER®, update your current DB2 copy to DB2 UDB Version 8.1 FixPak 7 or higher and then upgrade your operating system to SUSE Linux Enterprise Server (SLES) 10 before installing DB2 Version 9.7.
If you have a DB2 version 9.5 or DB2 Version 9.1 copy on SLES 10, first apply Version 9.5 Fix Pack 4 or later, or Version 9.1 Fix Pack 7 or later before you upgrade the operating system to SLES 11. If you have a DB2 UDB Version 8 copy on SLES 10, first upgrade to DB2 Version 9.7 and then upgrade the operating system to SLES 11.
If you are upgrading a pre-Version 9.7 copy on POWER3 processor-based systems, first upgrade to POWER4 processor-based systems before upgrading to DB2 Version 9.7. POWER3 processor-based systems are not supported in DB2 Version 9.7.
Run a number of performance tests before upgrading your DB2 server. The db2batch benchmark tool helps you to collect elapsed and CPU times for running queries. You can use this tool to develop performance tests. Record the exact environment conditions where you run your tests.
Also, keep a record of the db2expln command output for each test query. Compare the results before and after upgrade. This practice can help to identify and correct any performance degradation that might occur.
There is no utility to reverse an upgrade or falling back from DB2 Version 9.7 to a pre-Version 9.7 release. See Reversing DB2 server upgrade to learn all the required steps to reverse a database upgrade.
There are several pre-upgrade tasks that you should execute for a successful upgrade, such as backing up DB2 configuration parameters settings, increasing table spaces and log files, and verifying that databases are ready for upgrade.
To avoid performance degradation after the upgrade, perform pre-upgrade tasks such as converting type-1 indexes to type-2 indexes. If you do not convert your type-1 indexes before the database upgrade, the type-1 indexes are marked invalid during the database upgrade, and they will be rebuilt on your first access to the table. You cannot access the table until the index rebuild is completed
Consider upgrading to DB2 Version 9.7 64-bit database product instead, to avoid running into any of the 32-bit kernel limitations.
Upgrading your DB2 servers before upgrading your data server clients is the traditional approach to avoid any known restrictions and limitations such as support of new DB2 database product functionality, network protocols, and connectivity. These restrictions and limitations are not associated with DB2 Connect™.
Upgrading your data server clients first requires that you manage any incompatibilities between releases. If you must upgrade your client due to a software requirement, make sure that the software supports the DB2 database product version that you are running on your DB2 server. In this case, the software will manage any incompatibilities between releases. See Best practices for upgrading clients for details.
If you upgrade your DB2 server, you might also need to upgrade your database applications and routines to support changes for 64-bit instances, SQL stored procedures, Java™ Virtual Machine (JVM), and development software.
Upgrade essentials for database applications and Upgrade essentials for routines describe the factors that can impact your database application upgrade or routine upgrade. Review these factors and make any necessary changes to your database applications and routines to ensure that they run after the upgrade to DB2 Version 9.7.
In an upgrade testing environment, you can test and verify that your database applications and routines run successfully in DB2 Version 9.7 to find out if you need to upgrade them. You can also upgrade your database applications and routines before you upgrade your production environment.
Upgrading a primary database to DB2 Version 9.7 changes the database role from primary to standard. Upgrading standby databases to DB2 Version 9.7 is not supported because these databases are in roll forward pending state. Because of these restrictions, upgrading an HADR environment to DB2 Version 9.7 requires that you stop HADR, upgrade your DB2 server where the primary database resides, and then re-initialize HADR.
Before you activate your standby database, you must move the log files from the previous version of DB2 out of the log path of the new version of DB2. If you do not move the log files, DB2 might try to use the old files and fail to initialize.
After upgrading your database servers, you can optionally migrate your SQL replication environment to DB2 Version 9.7.
If you had DB2 Spatial Extender installed and you upgraded your spatially-enabled databases to DB2 Version 9.7, see Upgrading to DB2 Spatial Extender Version 9.7 for upgrade details specific to DB2 Spatial Extender.
In a Microsoft Cluster Server (MSCS) environment, you should install DB2 Version 9.7 as a new copy and then run the db2iupgrade command to upgrade the MSCS instance. See Upgrading DB2 servers in Microsoft Cluster Server environments for details.
If you are upgrading from DB2 Version 9.1 or earlier, DB2 Version 9.7 enables additional autonomic computing functionality introduced in Version 9.5 such as automatic agent configuration and real-time statistics. However, when you upgrade your database to DB2 Version 9.7, agent configuration is not automatic and real-time statistics are not enabled. You should consider adopting this autonomic functionality introduced in DB2 Version 9.5 to gain performance and manageability improvements.
However, this autonomic computing functionality is not enabled when you upgrade your databases to DB2 Version 9.7. You should consider adopting this autonomic functionality introduced in DB2 Version 9.1 in your upgraded databases.