First Article – DB2 Fix Packs
6 December 2006
Two new fix packs have just been released. Fix Pack 14 for DB2 v8.2 was released last week and Fix pack 1 for DB2 v9 was released this week. You can down load them at:
When installing DB2 clients on your PC or an application server, you only need the latest fix pack. That is, you do not need to install the base build of the DB2 client and then apply the fix pack. By installing just the fix pack you get that version of the DB2 client and save a little time. This works because DB2 client software is not licensed. This does NOT work for DB2 servers, so please always install the base build before installing a DB2 database server.
Support for all DB2 products eventually ends. To keep tabs on end of support dates, you can visit this site: http://www-1.ibm.com/support/docview.wss?rs=71&uid=swg21168270
When should I apply fix packs?
The following diatribe represents my opinion only and is not the official propaganda of IBM. However, I have been maintaining DB2/LUW systems for a number of years and this may at least give you something to consider.
For new databases supporting new systems where you will be doing significant testing I recommend using the latest fix pack available. If there are any issues with the fix pack you have time to find them in your testing and can go to an older one or get a special build if you need it. If there are no issues then you will have all of the latest DB2 fixes available for your new system.
For new databases supporting new systems where you will be doing very little testing, I recommend using a fix pack that has aged for at least a month or two. This may mean using the next most recent fix pack, but this allows time for others to find any “unexpected features” that the newest fix pack may have. Those features are called APARS and you should review the list of APARS to see if any of them affect the specific fix pack that you are installing. Fix packs are quite reliable, but over the years I have become paranoid of all software changes from too many late night spent fixing problems.
For existing databases you should establish a DB2 maintenance schedule and stick to it for applying DB2 fix packs. For example, you may want to upgrade to a newer fix pack annually. Keeping reasonably up-to-date is a good idea as it can help you avoid unplanned outages that occur from hitting an APAR. Fix packs are released about once per quarter. It is not imperative to always be on the newest pack, but you also do not want to get too out of date either. It is also not a bad idea to let a fix pack age for a month or two before applying it, which may mean that you will use the second most recent fix pack available. You should make sure to test your application with any new fix packs as thoroughly as possible to ensure that the new fix pack does not cause any new behavior for your existing application that is currently running along nicely. By using the DB2 HADR feature, you can limit your outages due to maintenance to a few seconds by doing rolling upgrades. Don’t know what HADR is? Just ask db2Dean at dean@db2Dean.com
I am occasionally asked if the DB2 Client should be at the same fix pack as the DB2 server. This is not mandated in the IBM documentation and I have never seen an issue with out of sync fix packs. However, just as you should keep your databases well maintained with fix pack upgrades you should keep your clients up to date as well.
If you are running purchased software that is using DB2 for its database, then you should consult your vendor for their recommendation as to which DB2 Version and fix pack you should use with their software. You should always their recommended version, as some will stop giving you adequate support if you are on a different fix pack. They will just blame all of your problems on the unsupported fix pack and not do any real investigation. DO NOT LET THIS HAPPEN TO YOU. Many vendors will update their recommended fix pack from time to time, so you should stay update with their recommendations and upgrade as appropriate.
Whether you are implementing a new system or applying a fix pack to an old system, the fix pack should be extensively tested on your database while exercising your application that uses the database. Every fix pack comes with Release Notes and a Readme file. Make sure you perform the upgrade by following those sets of instructions as occasionally a new fix pack will specify additional commands that need to be run to get the most out of your database. “But db2Dean, those documents are boring!” Yep, there’s lots of useless junk in them, but you must follow the instructions to the letter or bad things can result. One of the frequently over looked sets of commands that should be run whenever a fix pack is applied are the binds. After applying a fix pack to either a database or client, the following two commands should be run from the machine where the fix pack was applied after all of the other commands are run:
db2 “BIND @db2cli.lst BLOCKING ALL GRANT PUBLIC"
db2 “BIND @db2ubind.lst BLOCKING ALL GRANT PUBLIC"