SQL Server ve VM: kdy potřebujete SA

Krátká odpověď: Pro licencování jednotlivé virtuální OSE podle počtu virtuálních cores potřebujete předplatné nebo aktivní Software Assurance. U pevně umístěné instance Standard podle Server/CAL uvedené Product Terms samotný provoz ve VM na SA nevážou. Přesuny, failover a přístup klientů pak přidávají další podmínky. OSE znamená prostředí operačního systému, například OS uvnitř konkrétní VM. Článek pracuje s SQL Serverem 2025, Commercial Licensing a aktuálními Product Terms pro Microsoft Customer Agreement, ověřenými 12. října 2026. U jiné verze, OEM licence nebo smlouvy zkontrolujte její vlastní podmínky.

Proč dvě odpovědi mohou znít správně

V diskusi o SQL ve VM dostal správce od dvou dodavatelů různé odpovědi. Vlákno obsahuje spor i následnou opravu. Podobný dotaz na Microsoft Q&A z května 2026 řeší dvě VM a sto klientů. Jeho přijatá odpověď zdůrazňuje mobilitu, ale pro objednávku potřebujete podrobnější rozlišení.

Jedna strana může mluvit o virtuálních cores, druhá o serverové licenci s CAL. Další přitom předpokládá cluster, i když zadání popisuje jen jeden pevný host. Dříve než porovnáte cenu, napište: jaký model kupujeme, kde bude licence přiřazená a kam může pracovní zátěž přejít. Počet vCPU sám tento popis nenahradí.

Vyberte model před výpočtem

Produktový přehled Microsoftu rozlišuje per-core a Server/CAL. U Standard máte obě možnosti; Enterprise se běžně licencuje per-core. SQL CAL je právo přístupu, nikoli instalační klíč aplikace. Počet připojení v SQL Management Studiu proto není licenční inventura.

Tabulka je kontrola návrhu, nikoli seznam zaměnitelných produktů. Dodavatel musí v nabídce uvést přesné SKU, model, verzi a rozsah SA či předplatného. Pokud chybí model, nelze z částky poznat, zda nabídka odpovídá provozu.

Virtuální cores a minimum na každou VM

Podle aktuálních SQL Server Product Terms je licencování jednotlivé virtuální OSE per-core dostupné jen s předplatným nebo aktivní SA. Počet odpovídá virtuálním cores, minimálně však čtyřem na OSE. Specifické mapování jednoho virtuálního core na více hardwarových threads může počet zvýšit. Fyzické procesory, virtuální cores a prodejní balení proto v inventuře veďte odděleně.

Modelový příklad, nikoli nabídka: Máte dvě samostatné VM, první se dvěma vCPU a druhou se šesti. Při běžném mapování vychází první na čtyři a druhá na šest core licencí. Celkem deset. Chybný výpočet „2 + 6 = 8“ ignoruje minimum každé VM. Chybný je i závěr, že jedno čtyřjádrové oprávnění pokryje obě VM jen proto, že první někdy téměř nepracuje.

Licenční přehled SQL 2025 uvádí prodej core SKU v balení po dvou. Deset core licencí tedy v uvedeném příkladu představuje pět dvoujádrových balení. V nabídce si ověřte jednotku: položka „5 kusů“ může znamenat deset core licencí, ale také jiný produkt. Jednotka musí být napsaná přímo u množství.

Neodvozujte možnost provozu Standard ve VM z toho, že jste pokryli všechna fyzická jádra hostu. Aktuální přehled odlišuje práva fyzického per-core modelu Standard a Enterprise. Přepnutí způsobu počítání může změnit i povolený způsob nasazení.

Server/CAL: VM ano, nekonečno instancí ne

Současné Product Terms pro SQL 2025 v modelu Server/CAL dovolují za každou serverovou licenci jednu běžící instanci ve fyzické nebo virtuální OSE. U pevných VM proto nejprve zapište instance a fyzický host, kterému licenci přiřadíte. Neberte starší formulaci z jiného SQL průvodce jako důkaz práv pro SQL 2025.

Modelový příklad: Dvě pevné VM obsahují každá jednu běžící instanci SQL Standard. Jejich ERP používá sto konkrétních pracovníků, každý s platnou SQL User CAL příslušné verze. Základ inventury tvoří dvě serverové licence a sto uživatelských CAL. CAL nemusíte automaticky násobit dvěma kvůli dvěma SQL serverům; oprávnění uživatele se vztahuje na odpovídající licencované servery zákazníka. Další zařízení, automatické přístupy nebo uživatelé mimo tuto skupinu mohou výsledek změnit.

Tento příklad nepotvrzuje mobilitu, záložní instanci ani nárok na novou verzi. Je to inventura základního provozu. Do nabídky přidejte samostatné řádky pro to, co se má stát při údržbě nebo poruše.

Jeden účet ERP nenahradí CAL pracovníků

Microsoftův průvodce multiplexingem řeší přístup přes prostředníka. Pokud zaměstnanci zapisují nebo čtou SQL data přes ERP či webovou aplikaci, jeden společný databázový účet jejich přístup nesloučí do jediné CAL. Zkoumejte cestu dat až ke koncovým příjemcům.

Do mapy zapište například: obchodník → ERP → aplikační server → SQL; analytik → automaticky aktualizovaný report → SQL; integrační zařízení → API → SQL. Počítejte oprávněné uživatele či zařízení podle vhodného modelu, ne počet řádků v seznamu SQL loginů. U automatizace musí být jasné, kdo data poskytuje a kdo je využívá.

Microsoft odlišuje některé ruční předání dat od automatického zpřístupnění. Proto nerozhodujte podle koncovky souboru: ručně odeslaný statický Excel bez připojení a report automaticky obnovovaný z SQL jsou různé cesty. Nejasnou integraci zakreslete a nechte posoudit před výběrem Server/CAL. Pro per-core pokrytý SQL se SQL CAL nevyžadují; práva k Windows Serveru či další aplikaci tím ale nezanikají.

Přesun VM je druhé rozhodnutí

Licence je přiřazena fyzickému serveru. Obecné pravidlo z přehledu SQL 2025 počítá s nejméně devadesáti dny mezi změnami přiřazení; SA či předplatné umožňují za stanovených podmínek časté přesuny v jedné serverové farmě. Pouhé vypnutí automatického vyvažování není dostatečný popis provozu, pokud správce ručně migruje VM při každé údržbě.

U Server/CAL aktuální podmínky pro tuto mobilitu vyžadují odpovídající předplatné nebo aktivní SA také u CAL použitých k přístupu. Zkontrolujte tedy serverovou licenci i klientská práva. Neomezte dotaz na „má SQL server SA?“.

Také neplatí, že každý přesun bez SA musí být automaticky nepovolený: cílový host může mít vlastní dostatečné licenční pokrytí nebo může být použitelná jiná smluvní podmínka. Ověřuje se celý návrh. Správná otázka pro partnera zní: „Jak je konkrétní instance pokryta na každém hostu, na kterém může běžet, a jaká práva používáme při přesunu?“

Co musí obsahovat podklad k objednávce

1. Topologii. Fyzické hosty, VM, běžící instance, vCPU a možnost přesunu; také oddělené SQL komponenty.
2. Přístupovou mapu. Přímé uživatele, zařízení, ERP, reporty a integrace. U Server/CAL přesné přiřazení a verzi CAL.
3. Provoz při poruše. Kde běží primární a pasivní zátěž, co záložní server skutečně dělá a které failover právo se použije. Server sloužící reportům nepovažujte bez ověření za pasivní.
4. Licenční doklady. SKU, smluvní program, datum pořízení, rozsah a platnost SA nebo subscription; jednotku každé položky.
5. Písemné zdůvodnění variant. Nabídku Server/CAL a per-core porovnejte nad stejnou topologií, stejnou skupinou uživatelů a stejnými požadavky na dostupnost.

Výsledkem je podklad, který může druhý správce zkontrolovat bez znalosti předchozí debaty. Šetří i čas partnerovi: už se neptá, co ve vašem zadání znamená „jeden SQL server“. Vlastnictví evidence a pravidelné kontroly změn topologie začleňte do správy licencí napříč organizací.