License Optimization

The report under Reports → License Optimization answers a question conventional monitoring software never asks: are you paying for a SQL Server edition you do not actually need?

How the verdict is reached

Three things are checked per monitored instance:

  1. Enterprise features per database. SQL Server keeps its own record of which edition-gated features a database actually uses, in sys.dm_db_persisted_sku_features — partitioning, compression, columnstore, in-memory OLTP, TDE. The query runs per database, because the view only ever reports on the current one.
  2. Instance-wide Enterprise features that no per-database view reports: Resource Governor, database snapshots, and enabled availability groups.
  3. Hardware against the Standard ceiling: 24 cores and 128 GB of memory. Above that, a downgrade would mean downsizing the machine.

The part that matters: version awareness

With SQL Server 2016 SP1, Microsoft moved most of the previously Enterprise-only programmability surface into Standard edition — compression, partitioning, columnstore, in-memory OLTP, change data capture. Transparent Data Encryption followed only with SQL Server 2019.

Every reported feature is therefore evaluated against the running version. A tool that merely reads the DMV and treats each hit as a blocker would tell you to keep Enterprise on a 2019 instance because of data compression — plainly wrong, and the most expensive possible mistake in this report.

Features that are not blockers on this version are still listed (expandable under "reported features that are not blockers"), so you can see that they were examined and why they were dismissed.

A feature the report does not recognise is treated as a blocker. Being wrong in that direction costs nothing; the opposite costs a migration.

Cores and core packs

Microsoft bills cores, not sockets — with a minimum of four cores per physical processor, sold in 2-core packs. A two-socket box with one core each is still billed as eight.

Where the instance reports its real topology (socket_count / cores_per_socket, available from SQL Server 2016 SP2 and 2017 CU), that is used. Otherwise cpu_count serves as the fallback — it is inflated by hyper-threading, so it errs toward over- rather than under-estimating.

Configuring prices

The report deliberately ships no Microsoft price list. Without prices it reports cores and 2-core packs; enter your own terms and it reports amounts in your currency:

"LicenseCostSettings": {
  "Currency": "EUR",
  "EnterpriseCorePackAnnualPrice": 0,
  "StandardCorePackAnnualPrice": 0
}

Use your actual terms (EA, SPLA, Open Value) — not guessed list prices.

Consolidation candidates

The report also lists instances whose peak load stayed below 25 % across the window. Deliberately peak rather than average: month-end batch is often the only reason a box is that size, and an average would hide it.

Utilisation comes from our own history (PerformanceHistory), not from a live query. A freshly added instance therefore has no consolidation verdict at first.

When does it run?

Automatically once a day in the background. Administrators can trigger it immediately from the report — for a single instance or the whole fleet.

Permissions

The monitoring login needs VIEW SERVER STATE plus read access to the databases being checked. Databases it cannot reach are skipped and counted — the assessment does not fail outright, but it is then incomplete.

Limits

This report is technical decision support, not licensing advice. It does not know your agreement, your Software Assurance, or your virtualisation and data-centre rights. It checks what is technically detectable. Confirm every downgrade with your licensing partner.

Also undetectable: Enterprise features used only at runtime that leave no trace in the database — online index rebuilds or parallel index operations, for instance. Review your maintenance jobs before downgrading.