IBM released fix pack 3, mod pack 3 for Db2 11.1 earlier this year, and there was a high-severity problem in the initial version of that fix pack. IBM fixed the problem and re-released the fix pack within about a day, but the bug was reported far and wide, while I’m not sure the resolution of the bug was, so I thought I’d cover it quickly.
When IBM released fixpack 3 for 11.1 back on April 10, there were quickly reports of a very serious data corruption problem caused by db2support. This is most shocking because with Db2, we do not see a lot of data corruption – I have seen it fewer than 5 times in a 17-year career, and almost all are associated with major storage subsystem issues. The other reason this is shocking is because db2support is a utility we use to generate the output to share with IBM in the case of major system issues. It is not a command we consider risky or likely to cause a problem. It is not generally something we hesitate to run on a production system.
IBM says that a very small number of people actually downloaded the fix pack before the issue was discovered and fixed, and the fix pack re-issued, and IBM individually contacted each and every client who downloaded it to let them know of the issues.
The situation is a bit strange, because usually with an issue like this, we see a replacement fixpack with a slightly different name for issues similiar to this. Usually we would expect to see Fixpack 3a, and then have the original fix pack be unavailable. In this case, IBM re-issued the fix pack, but they did not rename it in any way. If you downloaded fix pack 3 prior to April 10, you may have ththe earlier version with this issue. If you want to check an existing installation, you can do the following to verify it is OK:
- Go to ~
/sqllib/bin and run:
strings -a db2support_internal | grep "Apr 10"
- If this yields a line with:
Apr 10 2018
Then you have the updated and OK version.
IBM published a tech note with all the details of the issues here. This issue only impacts Linux and UNIX environments.