Compatibility between DB2 for LUW Version 11.1 Mod-Packs and Fix-Packs

The term 'Update' refers to the process where DB2 is initially running on a lower fix-pack or mod-pack of Version 11.1, the new fix-pack or mod-pack is deployed, and DB2 is now running on a higher fix-pack or mod-pack of Version 11.1. The term 'Fallback' refers to the opposite action, where DB2 is running on a higher fix-pack or mod-pack of Version 11.1, the older fix-pack or mod-pack is deployed, and DB2 is now running on a lower fix-pack or mod-pack of Version 11.1.

Updates (and Fallbacks to compatible levels) of both fix-packs and mod-packs follow a well documented process: Applying fix packs in DB2 database environments.

Prior to Version 11.1, the delivery vehicle for long term database bug fixes was solely through "Fix-packs". Historically, fix-packs were often both Update and Fallback compatible, but not always. When a fix-pack contained significant new features, it's Update or Fallback compatibility statement might change, and was often documented within the fix-pack release notes.

Starting in Version 11.1, a new "Mod-pack" identifier value was added to the release signature (see Modification Packs). When significant new features are added, the Mod-pack identifier value is incremented.. For example, Version 11.1.2.2 refers to Version 11.1 mod-pack 2 fix-pack 2. For deliverables without significant new features, only the fix-pack identifier value will be incremented.

Update and Fallback compatibility between "Fix-packs":

Because a Fix-pack (or an intermediate Fix-pack iFix) are constrained to non significant features, unless it is otherwise noted in the release notes it can be assumed that Fix-packs and iFixes (within the same mod-pack value) are both Update and Fallback compatible.
For example, a database running at Version 11.1.3.4 (Version 11.1 modpack3 fixpack4) can fallback to Version 11.1.3.3 (Version 11.1 modpack3 fixpack3) without compatibility concerns since this is a fix-pack only transition.

A "special build" (within the same mod-pack value) can also be assumed to be both Update and Fallback compatible, unless otherwise noted by the support analyst who provided the special build (if compatibility is pertinent to you, it would be wise to confirm this matter with the support analyst).

Update and Fallback compatibility between "Mod-packs":

Because a Mod-pack contains significant features, it may introduce changes to on-disk structures. Compatibility between mod-packs is more complex.

Backup & Restore (not including Rollforward through transaction logs):

Because a mod-pack may introduce changes to on-disk structures (such as record formats, and other meta data), the Restore of a backup image acquired on an uplevel mod-pack may not be compatible when DB2 is running on a downlevel mod-pack.

²see 'Version 11.1.3.3+ non-unique indexes and modification-state indexes on columnar tables' section at bottom.

When a Fallback to an incompatible mod-pack is needed, the restore of a backup image which was previously acquired on this mod-pack is required. Further, the ability to Rollforward through transaction log data is limited to log data which was generated on this mod-pack, as described in the 'Rollforward'' section below. Also see the section 'Fallback to an incompatible mod-pack' at bottom.

Rollforward:

Because a mod-pack may introduce structural changes to log records and log files, the Rollforward of transaction log data from one mod-pack may not be compatible when replayed on a database running on a different mod-pack.

When an Update (or Fallback) to an incompatible mod-pack is needed, and a rollforward operation is desired after the restore of the backup image, the compatibility of the transaction log data will depend on whether the log data was generated while the database was running on the down-level (or up-level in the case of Fallback) mod-pack or not. For example, imagine a backup image is acquired while a database is running on Version 11.1.0.0, some workload occurs, and then the database is updated to Version 11.1.2.2 and some more workload occurs. If the instance is reverted to Version 11.1.0.0 (which is incompatible) and this backup image is restored and a rollforward to end-of-logs is performed, then transaction log data which was generated while the database was running on Version 11.1.2.2 will not be compatible. In such a scenario, the Rollforward can only be performed to a point-in-time before the database was updated to the higher mod-pack. Thus any changes made after this point would not be recoverable on the downlevel mod-pack.   

Online Member or CF Updates in a pureScale environment:

HADR:

In an HADR environment, the procedure for avoiding Standby database re-initialization by performing a 'rolling update' is well documented (Performing rolling updates in a DB2 high availability disaster recovery (HADR) environment).

Since an HADR standby database is in perpetual rollforward mode, when an Update or Fallback to a mod-pack is desired, this rolling update procedure is only supported when the Standby database is compatible with the transaction log data that is being generated by the Primary database. Thus, the compatibility for HADR Primary and Standby releases is defined by the compatibility matrix for Rollforward described above.

When a Fallback to an incompatible mod-pack is needed, the HADR Standby database must be deactivated; the Primary database instance fallen back using the normal procedure for a standard database (Applying fix-packs in DB2 database environments), taking note of the potential incompatibilities of backup images and log data described above; and the Standby database reinitialized (Initializing High Availability Disaster Recovery (HADR)).

Database Activation

After the database instance is updated to a newer mod-pack, when the database is first activated some on-disk changes might occur to meta data files (necessitated by the significant new features in the mod-pack). Because of this, a fallback to a previous mod-pack may not be compatible, (When attempting to fallback to Version 11.1.1.1, an SQL5055C error will be returned).

Version 11.1.1.1 Override:

In Version 11.1.1.1 many operations which detected the fallback from an uplevel mod-pack were explicitly blocked regardless of their compatibility, and an error code returned.

When a fallback is compatible (based on the compatibility matrices provided above), in Version 11.1.1.1 the following registry variable must be set to override these blocks.

"db2set DB2_VERSION_COMPATIBILITY=FORWARD:OBJECT=ALL"
This is not required for other mod-packs.

Version 11.1.3.3+ non-unique indexes and modification-state indexes on columnar tables:
Starting in Version 11.1.3.3, users have the ability to create non-unique indexes on columnar tables. Furthermore, if a create[unique] index statement was performed on version 11.1.3.3 or later, then a modification-state index was also created.  Also, if the DB2_EXTEND_COL_UNIQUE_INDEX_ACCESS registry variable was enabled when a unique or primary key constraint was created via the create/alter table commands, a modification-state index was created.

Before falling back to modification pack 11.1.2.2 or earlier,  all non-unique indexes and modification-state indexes on columnar tables must first be dropped.

The following query will list all modification-state indexes:
db2 "SELECT indschema, indname FROM syscat.indexes WHERE indextype='MDST' "

These modification-state indexes can then be dropped using the DROP INDEX command.

The following query will list all non-unique indexes on columnar tables:
db2 -v "SELECT b.indschema, b.indname FROM SYSCAT.TABLES a, SYSCAT.INDEXES b WHERE a.tableorg='C' AND b.UNIQUERULE='D' AND a.tabschema=b.tabschema AND a.tabname = b.tabname" 

These non-unique indexes on columnar tables can then be dropped using the DROP INDEX command.

A Fallback to an incompatible mod-pack (such as falling back from Version 11.1.1.1 or 11.1.2.2 back to Version 11.1.0.0/GA), may necessitate loss of transaction data changes that were made while the database was running on the uplevel mod-pack as highlighted in the 'Rollforward' section above.

Thus, when planning for an Update to an uplevel mod-pack which is incompatible with the mod-pack which is currently in use, it is highly recommended to stress and performance test the uplevel mod-pack in a non-production QA environment, so as to flush out any potential problems.

Details of the fallback procedure for incompatible mod-packs can be found in the Knowledge Center: