Common Db2 Audit Findings and How to Challenge Them

Db2 sits in almost every IBM estate, which is exactly why it draws audit attention. The findings IBM raises against Db2 follow a small set of recurring patterns, and most of them are answerable with evidence rather than a checkbook. Knowing the pattern is the first step to challenging the number.

Why Db2 draws audit findings

Db2 is licensed in several editions and on more than one metric, and it ships bundled inside other IBM products. That combination produces ambiguity, and ambiguity is where audit findings grow. A single physical host can run a chargeable Db2 edition, a restricted edition bundled with another product, and a developer instance that should never be counted, all at once. When IBM measures the estate, it tends to resolve that ambiguity in its own favor, so the buyer side job is to resolve it correctly with documentation.

The findings buyers see most often

• Full-capacity charging where sub-capacity should apply: ILMT was missing, broken, or installed late, so IBM counts every physical core on the host rather than the cores allocated to Db2
• Wrong PVU values: the value units per core were taken from the wrong processor row, inflating the count for a given core total
• Restricted bundled Db2 used beyond its allowed scope: a Db2 that came inside another product, used as a general purpose database it was never entitled to be
• Edition mismatch: a deployment counted against a higher edition than the one actually installed
• Non production instances counted: development, test, or cold standby instances treated as chargeable production

How each finding is challenged

Full-capacity charging is reversed wherever continuous sub-capacity evidence exists. Sub-capacity licensing lets you license only the virtual cores running Db2 instead of the whole physical host, but it requires an approved tool such as ILMT deployed within 90 days of first eligible deployment, running continuously, with quarterly reports retained two years. Where that record exists for a period, the full-capacity default for that period does not hold, and the count drops to the allocated cores. Where reports were missing, the record is rebuilt from whatever continuous data the tool retained before the number is accepted.

Wrong PVU values are challenged against the published PVU table. The metric ties cost to hardware capacity at value units per core, so the processor model has to map to the correct row. A finding that uses a higher value than the chip is rated for is an arithmetic error, not a compliance gap, and it is corrected by pointing to the right entry. Bundled and restricted Db2 are challenged with the parent product entitlement, which defines exactly what the bundled database is allowed to do. Non production instances are removed with deployment evidence showing they carry no production load.