Some of my clients, instead of engaging me for day-to-day support, engage me for expert assistance only when it all really hits the fan. This issue occurred for one of those clients, who had other support performing the HADR failovers while the Linux kernel was upgraded. The version of RedHat did not change, but the kernel did.
Why Should a Database be Highly Available?
It is significantly easier to implement high availability at other levels than it is at the database level. Often the database server is one of the more powerful servers in an environment, and without some fancy footwork there can be only one live copy of data. Ignoring high availability at the database level due to expense can be a bankruptcy-inducing choice for an organization. Just imagine what would happen if your databases suddenly did not exist. Not only would your company be unable to perform daily business, but the data lost could actually drive a company out of business.
Updated 6/26/2017 to include links on details for DSM 2.1.4 and a link to the DB2Night Show replay.
I ran into an interesting problem installing 11.1, fix/mod pack 1 on Ubuntu, and thought I would share. Please read to the bottom before trying anything, as this entry goes through things I tried that did not work before I got to what did work.
I am a huge fan of always running a locking event monitor, and also using other event monitors when appropriate. This means that most databases I support have at least one event monitor, whether it is active or not. With some version changes, the structure of tables that event monitors write to are changed. This means that as you upgrade DB2, you must also run a command to upgrade your event monitors.
Some applications are really good at continually trying to re-establish connections to a database. This can be useful when I want to quickly bounce the database and have the app reconnect without also having to bounce the app. It is problematic when I need DB2 to be down and stay down, but still allow me to work with it. This can be needed to kick off a backup or to keep things down during an upgrade. When upgrading to DB2 8.1, there was actually a point in time where, if an application connected, the entire upgrade was hosed.
Like any software, DB2 requires frequent patching. A database should be one of the most secure parts of any enterprise, and keeping it secure means keeping up with the fixes that are delivered in fix packs.
With each new release of DB2, there is a list of three different categories of old functionality that is somehow different in the new version. The use of these terms can be confusing if you don’t look at them every day.
As always, when I feel pain, I share the knowledge that pain gained me with my blog readers. Man, that was a painful fixpack. I was upgrading an AIX HADR pair from 10.5 fixpack 3 to 10.5 fixpack 5. My experience has generally been that TSA is painful when patching DB2.
Explain tables change in structure from version to version of DB2. If you want to continue to use the same set of explain tables across a DB2 upgrade, you must take special action to upgrade them.