Db2 pureScale licensing explained.

Db2 pureScale is IBM's shared data clustering technology for Db2. Instead of a single server holding the database, several Db2 members run active against the same data, coordinated by one or more cluster caching facilities, often written CF. The architecture delivers continuous availability and the ability to scale by adding members, which is exactly why organizations adopt it for systems that cannot go down. The same architecture that makes it attractive also widens the licensing surface, because the metric follows the processors, and a pureScale deployment has processors in more places than a standalone Db2.

Db2 in this form is a processor based product, licensed in value units tied to the cores allocated to the software. In a clustered topology that means the cores on each active member count, and the cores on the hosts running the caching facility have to be accounted for as well. An estate that licensed only the obvious member nodes and quietly left the CF hosts unlicensed is carrying a gap that an audit will find, because the cluster cannot function without the caching tier and IBM treats it as part of the deployment.

What actually has to be counted

• The cores allocated to each active Db2 member in the cluster
• The cores on the hosts running the cluster caching facility
• Any standby or secondary members that are installed and capable of running the workload
• The correct value units per core for the processor type underneath each node

The precise treatment of the caching facility and of standby capacity is governed by the License Information document and the Db2 edition you are entitled to. Editions and their pureScale rights have changed over time, so the entitlement on record, not a general assumption, is what determines the count. The point to carry into any planning conversation is that the caching tier is not free overhead, it is part of the licensed deployment.

Where sub-capacity fits

If the pureScale nodes run virtualized on eligible technology, sub-capacity licensing can limit the count to the virtual cores actually allocated to Db2 rather than the full physical capacity of each host. That position only holds with the usual evidence behind it: an approved measurement tool deployed within ninety days of first eligible use, running continuously, with the quarterly reports retained. Without that evidence IBM defaults the cluster to full capacity, and across several physical hosts that default is expensive.

How we defend it

The defense maps the full cluster topology, members and caching hosts alike, and counts cores against the edition rights you actually hold. Where sub-capacity applies, we assemble the measurement evidence so the virtual count stands. Where IBM has counted full capacity on hosts that were genuinely eligible for sub-capacity, we reverse the default with your own reporting data. The aim is a number that reflects the cores running Db2, supported by entitlement records, rather than IBM's broadest reading of every processor in the cluster.