Unboxing Db2 12.1 — Data Recovery & Availability

Posted By: Kelly Rodger Technical Content,

IBM Db2 12.1 — Now that the long-awaited release is out, let’s dive in to a quick overview of just some of what’s new in the areas of backup, restore, HADR, and transaction log management.

Backup Performance — ITP

Intra-Tablespace Parallelism brings the ability to apply multiple threads, and large numbers of CPU cores, to processing a single table space.

In busy systems, and especially when table space sizes are highly skewed, if your IO hardware has the capacity to read from a table space faster with multiple threads reading from different locations, that hardware will now be taken advantage of even more than before.

Perhaps most importantly, if your backup is compressed or encrypted, Db2 12.1 can now use many more CPU cores to process these CPU-bound operations.

For example, in a highly skewed system you could have your backup time and resource usage profile go from this:

To this:

 
Database History Enhancements

Three important changes are now available:

  1. Object size — now stored and available directly from the DB history, for backups, log archives, and load copy images.
  2. Encrypted or compressed — if your backup image is either of these, you can now find that in the DB history as well.
  3. Long comments — DB history comments can now be up to 254 characters. Bye bye, old limit.

Automatic Log Archive Validation

Available optionally since 11.5 via DB2_VALIDATE_LOG_ARCHIVE, log archive validation is now on by default. And, no, this does not add any additional IO overhead to your log archive processing.

The log buffer contents are validated in-memory, before and after archiving, so that IF there is ever a problem the source will be narrowed down for faster root cause analysis.

A new “VE:” comment in the DB history exists to confirm and record the verification. The admin notification log will note any errors, as well as the MON_GET_TRANSACTION_LOG monitor, and `db2pd -logs`.

Better Upgrade Availability with HADR

A new method for upgrades is now available, starting with a recent CSB release of Db2 11.5.8 and 11.5.9.

An HADR standby can remain active and serving read-only applications, continuing to use the older release while the primary is being upgraded, and it will not need to be re-initialized from a backup image.

Both the old procedure and the new procedure are now possible, depending on your needs. Do you need the best HA protection during the upgrade, or the best application availability. You now have options.

Recovery Through pureScale Cluster Size Changes

Dropping a pureScale member, or restoring from a big cluster to a small one? Db2 now fully supports seamless restore WITH roll forward recovery right through the change in the pureScale cluster topology!!!

You are no longer required to create a new full DB backup image after reducing your pS cluster size, for better application availability, and even incremental and table space images and restores are seamlessly supported on the new, smaller cluster.

You can even restore from your production pS system into a single-member pS test system. No problem.

Automatic Backup Enhancements

If you’re using Db2’s automated backup policy — AUTO_MAINT and AUTO_DB_BACKUP — there are two new enhancements available to you:

  1. Automated backups can now also specify DB2REMOTE, object storage targets
  2. Automatic DB history pruning will also now be the same as backups produced outside of automatic maintenance policies IF AUTO_DEL_REC_OBJ is enabled. Otherwise, the behaviour you’re familiar with, only maintaining the DB history from the most recent backup, continues as always.

Logical Backup / Logical Restore
  • DB2REMOTE Object Stores — Logical backup and logical restore now also fully support DB2REMOTE, object storage media instead of inline access keys.
  • Schema Row Modification Tracking By Default — there is a new DB CFG param, DFT_SCHEMAS_RMT, which can be set to have all newly create schemas be enabled for row modification tracking.
  • And, a new LOGICAL_BACKUP_DETAILS_TAB table function allows you to preview the high-level contents of a logical backup — the schemas, tables, and tenants of each image

And there’s lots more…

Including, fast log file allocation, and backup page verification, now by default, as well as new data columns and more readable (HH:MM:SS) BAR stats diagnostics.

Enjoy!


Bio

Kelly is a Program Director at the IBM Toronto Lab where he has decades of experience as a software developer designing and building enterprise data management solutions, and leading teams to do so.  He has long had a focus on data recovery, data protection, availability, and modernization.  Kelly has an MEng in Computer Engineering from the University of Toronto.