Sekundární SQL Server čeká na výpadek primáru. Správce na něj přesune zálohy, analytik si přidá pravidelný report a provozní dokumentace dál označuje server jako pasivní. První změna může spadat do výslovně povolené údržby. Druhá z něj udělá server poskytující SQL data uživatelům. Stejné slovo „secondary“ přitom zůstane v obou technických diagramech.
Pasivní failover právo neznamená bezplatný druhý produkční SQL Server. Rozhoduje oprávnění primární zátěže, účel a chování repliky, její velikost a konkrétní smluvní podmínky. Reporting z read-only repliky je aktivní využití dat, i když na ni nikdo nezapisuje.
Obsah ověřen k 21. říjnu 2026. Vycházíme z SQL Server 2025 Commercial Licensing guidance a aktuálních Product Terms pro Microsoft Customer Agreement. Jiná smlouva, OEM, hostingový program nebo starší licence mohou vyžadovat odlišné posouzení. Modely jsou hypotetické; nenahrazují inventuru konkrétního clusteru.
Sekundární a pasivní znamenají něco jiného
Technický pojem secondary popisuje roli v replikačním řešení. Licenční pasivita podle SQL Server guidance znamená, že replika neposkytuje SQL data klientům a neprovozuje aktivní SQL pracovní zátěže. Ani režim jen pro čtení proto není automaticky pasivní.
Dotaz z BI nástroje, pravidelný export pro analytiky nebo aplikační čtení z repliky není čekání na výpadek. Naopak běžící databázový proces a průběžná synchronizace samy o sobě neznamenají, že musí jít o samostatně licencovaný aktivní reportingový server. Rozlišujte činnost od pouhého stavu „zapnuto“.
Do evidence u každé repliky přidejte účel, replikační režim, možnost převzetí role, plánované úlohy a skutečné klientské přístupy. Prohlášení vlastníka „sem se nikdo nepřipojuje“ ověřte také proti reportovacím connection stringům a naplánovaným jobům. Zapomenutý pravidelný export může změnit výsledek posouzení.
Jaká práva přidávají SA a předplatné
Aktuální Product Terms SQL Server pro MCA rozlišují k primární zátěži jednu failover OSE pro libovolný účel včetně vysoké dostupnosti a dvě další OSE výhradně pro disaster recovery. Jedna z DR OSE je na příslušném serveru, druhá na Microsoft Azure za uvedených podmínek včetně poměru kvalifikovaných licencí k Azure vCores.
OSE je prostředí operačního systému, například OS v konkrétní VM. Právo se neodvozuje pouze od počtu fyzických hostitelů ani od počtu databází v diagramu. Primární zátěž musí být správně pokrytá a doplňující failover prostředí musí splnit podmínky příslušné kategorie.
| Kategorie v tomto smluvním modelu | Co ověřit | Čím ji nelze nahradit |
|---|---|---|
| Jedna failover OSE, například pro HA | Pasivní provoz, odpovídající primární zátěž a další podmínky | Aktivním druhým aplikačním serverem |
| Jedna další DR OSE na příslušném serveru | DR účel, asynchronní a ruční převzetí role | Další automatickou HA kopií bez rozlišení |
| Jedna další DR OSE v Azure | DR účel, asynchronní a ruční převzetí i Azure podmínky | Obecným nárokem na libovolný počet cloudových replik |
Product Terms požadují Software Assurance pro licencovaný server i CAL, pokud se používají. U subscription licencí uvádějí odpovídající SA práva po dobu předplatného. Samotná trvalá licence bez těchto práv nevytváří popsaný failover benefit. Skončí-li pokrytí, změna není pouze položka ve fakturaci; přestáváte mít doložený původní návrh užívacích práv.
Podmínky také výslovně vylučují použití těchto failover práv při nasazení pod License Mobility through SA. Nezaměňujte tento specifický benefit pro nasazení u poskytovatele se všemi přesuny VM mezi vlastními servery. U outsourcingu a sdílené infrastruktury zkontrolujte konkrétní smluvní cestu, než přenesete vlastní on-premises výpočet do nabídky hostingu.
Zálohy a CheckDB nejsou totéž co reporting
Product Terms jmenují povolené údržbové operace pro příslušnou failover OSE: kontroly konzistence databáze / CheckDB, log backups, full backups a sledování využití prostředků. Tyto výjimky jsou důvodem, proč neplatí zkratka „jakýkoli job znamená aktivní licenci“. Současně z nich neplyne obecná výjimka pro všechny dotazy nebo ETL úlohy.
| Činnost | Jak ji posoudit |
|---|---|
| Full backup nebo log backup | Patří mezi výslovně uvedené údržbové operace; ověřte další podmínky a technickou podporu |
| CheckDB / kontrola konzistence | Uvedená údržba, nikoli oprávnění k obchodním dotazům |
| Monitoring využití CPU, paměti a dalších prostředků | Rozlišit sledování prostředků od čtení produkčních dat pro uživatele |
| Read-only report pro finanční oddělení | Poskytování SQL dat uživatelům; nesplňuje popsanou pasivitu |
| Export produkčních tabulek do datového skladu | Aktivní využití dat; nelze jej přejmenovat na monitoring |
Rozhodující je skutečný výsledek úlohy. Job, který se jmenuje „health check“, ale vytváří obchodní report, není doložen jen svým názvem. U každé výjimky zapište účel a vazbu na konkrétní povolenou operaci, nikoli jen souhlas člověka, který job vytvořil.
Technická možnost zálohy závisí i na verzi
Licenční svolení k údržbě nezaručuje, že vybraný backup příkaz funguje na každé sekundární replice. Návod k zálohám z availability group secondary rozlišuje podporované typy a topologii. U starších verzí popisuje plné zálohy typu copy-only; od SQL Serveru 2025 přidává podporu běžných plných a diferenciálních záloh na sekundárních replikách.
Článek rovněž upozorňuje, že u distributed availability group nelze paušálně zálohovat z každé sekundární repliky sekundární skupiny. Důležitá je komunikace s globálním primárem. Při návrhu proto uveďte verzi, edici, roli a topologii, ne pouze informaci „máme Always On“.
Zálohovací preference availability group je navíc nastavení pro směrování úloh, nikoli důkaz dokončené obnovitelné zálohy. Ověřte umístění jobů, skutečný výstup a následnou obnovu. Úspěšný licenční výpočet neopravuje nefunkční backup plán a technicky úspěšná záloha sama neprokazuje licenční pokrytí.
Větší pasivní replika nemusí být pokrytá
Product Terms omezují počet licencí, který by jinak vyžadovala failover OSE, počtem potřebným pro odpovídající primární zátěž. Nestačí tedy označit podstatně větší prostředí za „rezervu“. Posuzujte licenční potřebu podle příslušného modelu, nikoli pouze procento využitého CPU.
Hypotetický příklad: firma licencuje jednotlivé Enterprise VM podle virtuálních cores s aktivní SA. Každý vCore je mapovaný na jeden hardware thread, dodržuje minimum čtyř core licencí na VM a nejde o unlimited virtualization celého hostitele. Primární VM má 8 vCores. Do příkladu nezahrnujeme Azure ani cenu operačního systému.
| VM | Kapacita a skutečná činnost | Licenční výsledek modelu |
|---|---|---|
| P — primární | 8 vCores, produkční provoz | 8 core licencí s příslušným pokrytím |
| H — HA | 8 vCores, pasivní HA bez aplikačních čtení | Lze posuzovat v příslušném failover benefitu při splnění všech podmínek |
| D — DR | 8 vCores, asynchronní a ruční DR, bez reportingu | Lze posuzovat v samostatné příslušné DR kategorii |
| R — reporting | 4 vCores, aktivně obsluhuje reporty | Samostatně 4 core licence podle předpokladů modelu |
Pro aktivní P a R vychází 8 + 4 = 12 core licencí, tedy šest dvoucore balení. H a D nejsou „servery bez podmínek“: jejich pokrytí stojí na doloženém benefitu, pasivitě a navázání na primární P. Výpočet nepřidává SQL CAL, protože používá per-core model; neřeší však ostatní produkty.
Pokud by D mělo místo 8 vCores dvanáct a jinak stejné mapování, nelze jeho plnou potřebu dvanácti licencí pokládat za pokrytou osmijádrovou primární zátěží. V takovém případě upravte velikost či návrh a nechte potvrdit oprávnění pro cílovou konfiguraci. Neodečítejte automaticky osm od dvanácti a neprezentujte rozdíl jako univerzální pravidlo tohoto benefitu.
Report na DR kopii mění celý návrh
Přesuňte v předchozím modelu reporting z R na D a samostatné R odstraňte z provozu. D nyní obsluhuje obchodní čtení, takže nepoužijete původní závěr o pasivní DR kopii. Pro aktivní P a D vychází při uvedeném per-VM modelu 8 + 8 = 16 core licencí. Levnější technické spojení funkcí nemusí znamenat nižší licenční potřebu.
To není automatický návod přesunout čtyři stávající licence nebo doplnit přesně čtyři nová práva bez dalších kontrol. Přiřazení a změny umístění mají vlastní pravidla. Smyslem příkladu je porovnat požadované pokrytí dvou návrhů při stejném zadání, nikoli obejít jejich platnost v čase.
Základní modely a minimální počty vysvětluje SQL Server ve VM: kdy potřebujete SA. Teprve po jejich volbě má smysl přidávat HA a DR práva. U hostitelského clusteru samostatně řešte také licence Windows Serveru pro cluster; SQL benefit se automaticky nepřenáší na operační systém.
Test obnovy a skutečný výpadek jsou různé situace
Product Terms dovolují souběh primární zátěže a DR failover OSE po krátkou dobu pro DR test každých 90 dnů. Nevytvářejte z toho trvalý paralelní reporting ani paušální oprávnění k celodenním testům v libovolném intervalu. Dokumentujte účel, začátek, konec a návrat do původního stavu; konkrétní smluvní text neobsahuje univerzální počet hodin pro každý test.
Při skutečném převzetí provozu přestává být původní popis „P aktivní, D čeká“ pravdivý. Zaznamenejte změnu rolí a dalšího provozu, včetně klientských connection stringů a následného návratu. Evidenci aktualizujte i tehdy, když se názvy VM nezměnily.
Kontrola před potvrzením návrhu
- Určete verzi, edici, smluvní program a model licencování každé primární zátěže.
- Doložte aktivní SA či odpovídající předplatné; u Server/CAL prověřte i CAL.
- Přiřaďte každé další OSE konkrétní HA nebo DR kategorii, ne obecný štítek secondary.
- Zkontrolujte její licenční velikost, replikační režim a způsob failoveru.
- Projděte klientská připojení a joby. Oddělte výslovně uvedenou údržbu od reportingu a exportů.
- Ověřte technickou podporu záloh podle verze a topologie a proveďte test obnovy.
- Zapište postup při změně rolí, rozšíření workloadu, změně hostingu nebo skončení SA.
Často kladené otázky
Je read-only replika automaticky pasivní?
Ne. Pokud poskytuje SQL data uživatelům nebo zařízením, nesplňuje popsanou podmínku pasivity. Čtení pro reporting je aktivní využití.
Mohu na příslušné pasivní kopii zálohovat?
Product Terms výslovně uvádějí full a log backups mezi povolenou údržbou. Zároveň ověřte podporu konkrétního typu zálohy v dané verzi a topologii.
Stačí trvalá licence bez SA pro uvedené HA/DR benefity?
Ne podle popsaného současného modelu. Doložte aktivní SA nebo odpovídající subscription práva; u Server/CAL také relevantní pokrytí CAL.
Může být pasivní VM libovolně větší než primární?
Ne. Podmínky porovnávají počet jinak potřebných licencí s odpovídající primární zátěží. Samotná nízká aktuální vytíženost větší VM to neřeší.
Znamená SQL failover benefit také licenci Windows Serveru?
Ne automaticky. Operační systém a případné další komponenty potřebují vlastní posouzení. Tento článek počítá SQL práva, nikoli celou infrastrukturu.
