Upgrading Db2 servers in HADR environments (without standby reinitialization)

Use this procedure in a high availability disaster recovery (HADR) environment when you upgrade your Enterprise Server Edition Db2 version 10.5 Fix Pack 7 or later databases to Db2 version 11.1. This procedure maintains the database role and relies on normal log shipping and log replaying characteristics common to HADR functionality. The procedure avoids the need to stop HADR for upgrade and avoids the need to reinitialize HADR. This reduces the window where no standby database exists and eliminates the cost of sending a backup image to the standby site for reinitialization.

The procedure depends on the Db2 version 10.5 Fix Pack 7 or later primary database having shipped all log data to the Fix Pack 7 or later standby databases and the standby databases having replayed all log data received.

The Db2 version 11.1 standby database cannot replay log data from earlier Db2 versions. The procedure enforces this restriction through db2ckupgrade that is run during db2iupgrade or any db2ckupgrade invocation that establishes an exclusive connection to the database to do proper database consistency checking.

This procedure can be applied to HADR databases in Enterprise Server Edition environments that use single standby or multiple standby configurations.

Before you begin

  • Review the system requirements for HADR. For more details, see System requirements for Db2 high availability disaster recovery (HADR).
  • If you have two HADR databases (database A and database B) set up the following way, perform a role switch on one database so that both primaries are on the same system during the upgrade:
    • The primary for database A runs on system 1, and the standby runs on system 2
    • The primary for database B runs on system 2, and the standby runs on system 1
  • Ensure that you are familiar with the steps involved in upgrading a Db2 instance and Db2 databases.
  • Using High availability disaster recovery (HADR) monitoring, ensure that both the primary's log shipping functionality and the standby's log replaying functionality is working properly before running db2ckupgrade.
  • If you are using the reads on standby feature, ensure that the database configuration parameter logindexbuild is turned on, on the primary database so that index recreation that is done during upgrade is sent to the standby database for replay. This allows read connections to resume post upgrade on the standby database.
  • In case of failures during the HADR upgrade procedure, ensure that you are familiar with Dealing with failures while upgrading Db2 servers in HADR environments (without standby reinitialization).
  • All Db2 upgrades, hardware upgrades, and software upgrades should be implemented in a test environment before being applied to your production system.

About this task

This upgrade task describes the steps to upgrade HADR databases in an Enterprise Server Edition single standby environment to Db2 version 11.1 from 10.5 Fix Pack 7 or later. Both the primary and standby database should be using the same fix pack level of Db2.
Important: Each time you run the db2iupgrade command to upgrade a server, be sure to follow up by running the db2licm -a <license file> command to re-apply your Db2 license.


Restrictions

The primary and standby database must be from Db2 version 10.5 Fix Pack 7 or later. It is recommended that both databases use the same fix pack level.

Procedure

To upgrade databases in an HADR environment to Db2 version 11.1:

  1. On the primary instance, monitor the database by using the db2pd -hadr or MON_GET_HADR command to ensure that primary log shipping and standby log replay are not lagging and are functioning properly. Monitoring the HADR database, reduces the chance of failures in the upgrade process. Also, ensure that replay delay is turned off on the standby to avoid significant time delay or lag.
  2. Ensure that replay delay is turned off on all the standby databases by setting the database configuration parameter hadr_replay_delay to 0 to ensure the standby log replay position can catch up to the primary in a reasonable amount of time.
  3. On the primary instance, deactivate the database by using the DEACTIVATE DATABASE command to ensure that log shipping is completed on the primary database and data is transferred to the standby database.
  4. On the primary instance, stop the Db2 instance by using db2stop command. Ensure that applications do not connect so that no new log data is generated and the log replay position on the standby database eventually matches the log shipping position on the primary database.
  5. On the primary instance, upgrade the Db2 instance by using the db2iupgrade command. The db2iupgrade command calls the db2ckupgrade command to verify that the database is ready for upgrade. The db2iupgrade does not run when the db2ckupgrade command reports errors. Check the log file if you encounter any errors. For an HADR primary database from 10.5 Fix Pack 7 or later, the db2ckupgrade command verifies that a valid standby database can be connected to the primary database. Once a connection is established, log shipping functionality begins and ships any pending log data, if necessary. The db2ckupgrade command also verifies that the log shipping position of the primary database matches the log replay position on the standby database.
  6. On the standby instance, deactivate the database by using the DEACTIVATE DATABASE to ensure that log shipping is completed on the primary database and data is transferred to the standby database.
  7. On the standby instance, stop the Db2 instance by using db2stop command.
  8. On the standby instance, upgrade the Db2 instance by using the db2iupgrade command. The db2iupgrade command calls the db2ckupgrade command to verify that the standby database is ready for upgrade.
  9. On the standby instance, issue the UPGRADE DATABASE command. This upgrades the database metadata objects and if log validation succeeded in the earlier steps the principal standby starts up and wait for a connection from the primary. The replay functionality begins in the background and wait for upgrade log data to be sent by the primary. At this point, the standby is considered upgrade in progress and the UPGRADE DATABASE command will return with SQL1103W. No user connections are allowed while in this upgrade in progress state. The progress on the standby database can be monitored using db2pd -hadr in conjunction with the Db2 diagnostics log. Connect attempts can also be issued and receives SQL1776N, reason code 9 as long as the standby is in upgrade in progress state.
  10. On the primary instance, issue the UPGRADE DATABASE command to upgrade the primary database. This upgrades any database metadata files, like the database configuration, table pace definitions, log header control files, storage group files. Once these metadata files are upgraded, the primary database looks to connect to the standby database within the HADR timeout window. Once a connection is formed, upgrade processing begins and log data is sent to the standby database for replay.
  11. On the primary instance, issue the ACTIVATE DATABASE command to start using the database in the new Db2 version.

What to do next

After upgrading the Db2 server, perform the recommended post-upgrade tasks such as resetting the diagnostic error level to its pre-upgrade value, adjusting log space size, and rebinding packages. In addition, verify that the upgrade of your Db2 server was successful. For more information see, Post-upgrade tasks for Db2 servers and Verifying upgrade of Db2 servers.