Authorized User Single Install is one of the two metrics commonly used to license Db2, the other being Processor Value Unit. On its face the user metric looks simple: count the people authorized to use the program. In practice it carries a per core minimum that catches teams out, because the number you must license is not always the number of users you have. When a deployment sits on capable hardware with relatively few users, the minimum, not the head count, sets the bill. Auditors know this, and it is a frequent source of Db2 findings.
How the metric actually works.
An Authorized User is a unique individual given access to the program, directly or indirectly, regardless of whether they are active at any given moment. Single Install means the entitlement covers a single installation of the program. The detail that matters under audit is the minimum: for Db2 the metric requires a minimum number of Authorized Users per processor core that the program runs on. If your install spans cores whose minimum total exceeds your real user population, you must license to the minimum. A small analytics team on a multi core server can therefore owe far more user licenses than there are people on the team.
Where the minimum bites hardest.
The pattern that produces findings is consistent:
- Few users, many cores. A handful of named users on a large server, where the per core minimum multiplies into a number nobody counted.
- Indirect users overlooked. People reaching Db2 through an application or reporting layer still count as Authorized Users, and they are easy to miss.
- Metric chosen for the wrong workload. A deployment that would be cheaper under PVU left on the user metric, or the reverse, without anyone reconciling which actually applies.
- Headcount drift. User counts that grew over years while the licensed quantity stayed fixed at the original purchase.
User metric or PVU, the real comparison.
Because Db2 can be licensed either way, the right defensive move is often to model both. For a large user community the PVU metric may be cheaper; for a small, well defined community on modest hardware the user metric usually wins, provided the per core minimum does not overtake the head count. The mistake is to assume the metric on the purchase record is automatically the right one for the deployment as it exists today. Reconciling the actual install against both metrics is what reveals whether a finding is real or an artifact of the wrong measure.
A Db2 user metric finding usually comes from the per core minimum or from indirect users, not from reckless growth. The buyer side response is to count every direct and indirect Authorized User, apply the minimum correctly against the cores in scope, and compare the result to the PVU alternative. That reconciliation is what keeps the licensable count honest and the claim defensible.
The buyer side defense.
We start by containing the data request, then build the true Authorized User population, direct and indirect, for every Db2 install on the user metric. The per core minimum is applied exactly as the metric defines it, the user metric position is compared against PVU to confirm the cheaper and correct basis, and any genuine shortfall is confined to the specific install and period. The corrected count is written into the settlement with a forward plan that keeps the metric matched to the workload so the minimum never quietly outruns the entitlement again.