Ein sekundärer SQL Server wartet auf den Ausfall des primären Servers. Der Administrator verlagert Sicherungen darauf, ein Analyst ergänzt einen regelmäßigen Bericht, und die Betriebsdokumentation nennt ihn weiterhin passiv. Die erste Änderung kann unter ausdrücklich erlaubte Wartung fallen. Die zweite macht ihn zum Server, der Benutzern SQL-Daten liefert. In beiden technischen Diagrammen kann weiterhin „secondary“ stehen.
Passive Failover-Rechte ergeben keinen kostenlosen zweiten SQL-Produktionsserver. Entscheidend sind Rechte der primären Workload, Zweck und Verhalten des Replikats, seine Größe und die konkreten Vertragsbedingungen. Berichte von einem schreibgeschützten Replikat nutzen Daten aktiv, auch wenn niemand darauf schreibt.
Inhaltlich geprüft am 21. Oktober 2026. Grundlage sind die Commercial Licensing Guidance für SQL Server 2025 und aktuelle Product Terms für das Microsoft Customer Agreement. Andere Verträge, OEM-, Hostingprogramme oder ältere Lizenzen können eine andere Prüfung erfordern. Die Modelle sind hypothetisch und ersetzen keine Clusterinventur.
Sekundär und passiv sind unterschiedliche Begriffe
Der technische Begriff secondary beschreibt die Rolle in einer Replikationslösung. Lizenzrechtlich passiv bedeutet laut SQL Server Guidance, dass das Replikat Clients keine SQL-Daten bereitstellt und keine aktiven SQL-Workloads ausführt. Schreibgeschützter Betrieb ist deshalb nicht automatisch passiv.
Eine BI-Abfrage, ein regelmäßiger Analystenexport oder lesender Anwendungszugriff ist kein Warten auf einen Ausfall. Umgekehrt machen ein laufender Datenbankprozess und kontinuierliche Synchronisierung allein noch keinen separat zu lizenzierenden aktiven Berichtsserver aus. Unterscheiden Sie tatsächliche Tätigkeit vom bloßen Zustand „eingeschaltet“.
Erfassen Sie je Replikat Zweck, Replikationsmodus, Übernahmemöglichkeit, geplante Aufgaben und tatsächliche Clientzugriffe. Prüfen Sie die Aussage „hier verbindet sich niemand“ auch gegen Reporting-Verbindungszeichenfolgen und geplante Jobs. Ein vergessener regelmäßiger Export kann die Bewertung ändern.
Welche Rechte SA und Abonnement ergänzen
Die aktuellen SQL Server Product Terms für MCA unterscheiden je primärer Workload eine Failover-OSE für beliebige Zwecke einschließlich Hochverfügbarkeit und zwei weitere OSEs ausschließlich zur Notfallwiederherstellung. Eine DR-OSE liegt auf einem zulässigen Server, die andere auf Microsoft Azure unter den genannten Bedingungen einschließlich des Verhältnisses qualifizierter Lizenzen zu Azure-vCores.
Eine OSE ist eine Betriebssystemumgebung, beispielsweise das OS in einer bestimmten VM. Das Recht ergibt sich nicht allein aus physischen Hosts oder Datenbanken im Diagramm. Die primäre Workload muss korrekt abgedeckt sein; zusätzliche Failover-Umgebungen müssen die Bedingungen ihrer Kategorie erfüllen.
| Kategorie im beschriebenen Vertragsmodell | Was zu prüfen ist | Was sie nicht ersetzt |
|---|---|---|
| Eine Failover-OSE, etwa für HA | Passiver Betrieb, zugehörige primäre Workload und weitere Bedingungen | Ein aktiver zweiter Anwendungsserver |
| Eine zusätzliche DR-OSE auf einem zulässigen Server | DR-Zweck, asynchrone Replikation und manuelles Failover | Eine weitere automatische HA-Kopie ohne Unterscheidung |
| Eine zusätzliche DR-OSE in Azure | DR-Zweck, asynchrone Replikation, manuelles Failover und Azure-Bedingungen | Allgemeines Recht auf beliebig viele Cloudreplikate |
Die Product Terms verlangen Software Assurance für den lizenzierten Server und gegebenenfalls CALs. Abonnementlizenzen erhalten während ihrer Laufzeit entsprechende SA-Rechte. Eine unbefristete Lizenz ohne diese Rechte begründet den beschriebenen Failover-Vorteil nicht. Endet die Abdeckung, ist das mehr als eine Rechnungsposition: Der ursprüngliche Nutzungsrechteentwurf ist nicht mehr belegt.
Die Bedingungen schließen diese Failover-Rechte bei Bereitstellung über License Mobility through SA ausdrücklich aus. Verwechseln Sie diesen konkreten Vorteil beim Provider nicht mit sämtlichen VM-Verschiebungen zwischen eigenen Servern. Bei Outsourcing und geteilter Infrastruktur ist der Vertragsweg zu prüfen, bevor eine eigene On-Premises-Berechnung in ein Hostingangebot übernommen wird.
Sicherungen und CheckDB sind kein Reporting
Die Product Terms nennen zulässige Wartungsoperationen für die entsprechende Failover-OSE: Datenbankkonsistenzprüfungen / CheckDB, Protokollsicherungen, vollständige Sicherungen und Überwachung der Ressourcennutzung. Deshalb ist die Kurzform „jeder Job benötigt eine aktive Lizenz“ falsch. Daraus folgt aber keine allgemeine Ausnahme für beliebige Abfragen oder ETL-Aufgaben.
| Tätigkeit | Einordnung |
|---|---|
| Vollständige Sicherung oder Protokollsicherung | Ausdrücklich genannte Wartung; weitere Bedingungen und technische Unterstützung prüfen |
| CheckDB / Konsistenzprüfung | Genannte Wartung, keine Berechtigung für Geschäftsabfragen |
| Überwachung von CPU, Arbeitsspeicher und anderen Ressourcen | Ressourcenüberwachung von Produktionsdatenabfragen für Benutzer trennen |
| Schreibgeschützter Finanzbericht | Bereitstellung von SQL-Daten an Benutzer; erfüllt die beschriebene Passivität nicht |
| Export von Produktionstabellen ins Data Warehouse | Aktive Datennutzung; Umbenennung in Monitoring ändert das nicht |
Entscheidend ist das tatsächliche Ergebnis des Jobs. Ein „Health Check“, der einen Geschäftsbericht erzeugt, ist nicht durch seinen Namen gerechtfertigt. Dokumentieren Sie je Ausnahme Zweck und Bezug zu einer konkret erlaubten Operation statt nur die Zustimmung des Joberstellers.
Backup-Unterstützung hängt auch von der Version ab
Eine lizenzrechtlich erlaubte Wartung belegt nicht, dass ein Backup-Befehl auf jedem sekundären Replikat funktioniert. Die Anleitung zu Sicherungen auf sekundären Availability-Group-Replikaten unterscheidet unterstützte Sicherungstypen und Topologien. Für ältere Versionen beschreibt sie vollständige Copy-only-Sicherungen. SQL Server 2025 ergänzt gewöhnliche vollständige und differenzielle Sicherungen auf sekundären Replikaten.
Bei einer verteilten Availability Group sind Sicherungen laut Anleitung außerdem nicht pauschal auf jedem sekundären Replikat einer sekundären Gruppe möglich. Wichtig ist die Kommunikation mit dem globalen primären Replikat. Nennen Sie daher Version, Edition, Rolle und Topologie statt nur „wir verwenden Always On“.
Eine Backup-Präferenz der Availability Group steuert die Jobauswahl, belegt aber keine abgeschlossene wiederherstellbare Sicherung. Prüfen Sie Jobplatzierung, tatsächliche Ausgabe und anschließende Wiederherstellung. Eine richtige Lizenzrechnung repariert keinen defekten Sicherungsplan; eine technisch erfolgreiche Sicherung belegt keine Lizenzabdeckung.
Ein größeres passives Replikat ist nicht zwingend abgedeckt
Die Product Terms begrenzen die sonst für eine Failover-OSE nötigen Lizenzen auf die Zahl für die zugehörige primäre Workload. Eine deutlich größere Umgebung als „Reserve“ zu bezeichnen reicht nicht. Prüfen Sie den Lizenzbedarf nach dem jeweiligen Modell statt nur anhand der CPU-Auslastung.
Hypothetisches Beispiel: Ein Unternehmen lizenziert einzelne Enterprise-VMs nach virtuellen Kernen mit aktiver SA. Jeder vCore ist einem Hardwarethread zugeordnet; das Minimum von vier Core-Lizenzen je VM ist erfüllt. Es handelt sich nicht um unbegrenzte Virtualisierung des gesamten Hosts. Die primäre VM hat 8 vCores. Azure und Betriebssystemkosten bleiben unberücksichtigt.
| VM | Kapazität und tatsächliche Tätigkeit | Lizenzergebnis des Modells |
|---|---|---|
| P — primär | 8 vCores, Produktionsbetrieb | 8 Core-Lizenzen mit passender Abdeckung |
| H — HA | 8 vCores, passive HA ohne Anwendungslesezugriffe | Im entsprechenden Failover-Vorteil bei erfüllten Bedingungen zu prüfen |
| D — DR | 8 vCores, asynchrone Replikation und manuelles DR-Failover, kein Reporting | In der eigenen passenden DR-Kategorie zu prüfen |
| R — Reporting | 4 vCores, bedient aktiv Berichte | Separat 4 Core-Lizenzen unter den Modellannahmen |
Für aktive P und R ergeben sich 8 + 4 = 12 Core-Lizenzen, also sechs Zweikernpakete. H und D sind keine bedingungslos kostenlosen Server. Ihre Abdeckung beruht auf belegtem Vorteil, Passivität und Zuordnung zu P. SQL-CALs kommen im Per-Core-Modell nicht hinzu; andere Produkte sind damit nicht abgedeckt.
Hätte D bei gleicher Zuordnung zwölf statt 8 vCores, ließe sich sein voller Bedarf von zwölf Lizenzen nicht als durch die achtkernige primäre Workload abgedeckt behandeln. Passen Sie Größe oder Entwurf an und lassen Sie die Rechte der Zielkonfiguration bestätigen. Ziehen Sie nicht automatisch acht von zwölf ab, um den Rest als allgemeine Regel dieses Vorteils darzustellen.
Reporting auf der DR-Kopie ändert den Entwurf
Verlagern Sie im vorherigen Modell Reporting von R nach D und nehmen R außer Betrieb. D bedient nun geschäftliche Lesezugriffe; die ursprüngliche Einordnung als passive DR-Kopie entfällt. Für aktive P und D ergeben sich im genannten Per-VM-Modell 8 + 8 = 16 Core-Lizenzen. Eine technische Zusammenlegung senkt also nicht zwingend den Lizenzbedarf.
Das ist keine automatische Empfehlung, vier vorhandene Lizenzen zu verschieben oder ohne weitere Prüfung genau vier Rechte nachzukaufen. Zuweisung und Standortänderung haben eigene Regeln. Der Vergleich zeigt den nötigen Umfang zweier Entwürfe für denselben Bedarf, ohne deren zeitliche Gültigkeit zu umgehen.
Grundmodelle und Mindestzahlen erläutert SQL Server in VMs: Wann ist SA nötig?. Erst nach deren Auswahl sind HA- und DR-Rechte sinnvoll zu ergänzen. Prüfen Sie für einen Hostcluster auch Windows Server: Cluster lizenzieren. Ein SQL-Vorteil überträgt sich nicht automatisch auf das Betriebssystem.
Wiederherstellungstest und echter Ausfall unterscheiden sich
Die Product Terms erlauben den gleichzeitigen Betrieb der primären Workload und ihrer DR-Failover-OSEs für kurze DR-Testphasen alle 90 Tage. Daraus entsteht weder dauerhaftes paralleles Reporting noch eine pauschale Erlaubnis für ganztägige Tests in beliebigen Abständen. Dokumentieren Sie Zweck, Beginn, Ende und Rückkehr. Der konkrete Wortlaut nennt keine universelle Stundenzahl für jeden Test.
Bei einer echten Übernahme stimmt „P aktiv, D wartet“ nicht mehr. Erfassen Sie Rollenwechsel und weiteren Betrieb einschließlich Client-Verbindungszeichenfolgen und späterer Rückkehr. Aktualisieren Sie die Nachweise auch bei unveränderten VM-Namen.
Prüfung vor Bestätigung des Entwurfs
- Version, Edition, Vertragsprogramm und Lizenzmodell jeder primären Workload bestimmen.
- Aktive SA oder entsprechende Abonnementrechte nachweisen; bei Server/CAL auch CALs prüfen.
- Jede zusätzliche OSE einer konkreten HA- oder DR-Kategorie zuordnen statt pauschal secondary zu nennen.
- Lizenzgröße, Replikationsmodus und Failover-Verfahren kontrollieren.
- Clientverbindungen und Jobs prüfen. Ausdrücklich genannte Wartung von Reporting und Exporten trennen.
- Backup-Unterstützung nach Version und Topologie prüfen und Wiederherstellung testen.
- Verfahren bei Rollenwechsel, Workloaderweiterung, Hostingänderung und SA-Ende dokumentieren.
Häufig gestellte Fragen
Ist ein schreibgeschütztes Replikat automatisch passiv?
Nein. Liefert es Benutzern oder Geräten SQL-Daten, erfüllt es die beschriebene Passivität nicht. Reporting-Lesezugriffe sind aktive Datennutzung.
Darf ich auf einer zulässigen passiven Kopie sichern?
Die Product Terms nennen vollständige und Protokollsicherungen ausdrücklich als Wartung. Prüfen Sie zusätzlich die technische Unterstützung des Sicherungstyps in Version und Topologie.
Reicht eine unbefristete Lizenz ohne SA für diese HA/DR-Vorteile?
Nicht im beschriebenen aktuellen Modell. Aktive SA oder entsprechende Abonnementrechte nachweisen; bei Server/CAL auch relevante CAL-Abdeckung.
Darf die passive VM beliebig größer als die primäre sein?
Nein. Die Bedingungen vergleichen die sonst erforderlichen Lizenzen mit der zugehörigen primären Workload. Niedrige Auslastung einer größeren VM löst das nicht.
Deckt der SQL-Failover-Vorteil auch Windows Server ab?
Nicht automatisch. Betriebssystem und weitere Komponenten benötigen eine eigene Prüfung. Hier werden SQL-Rechte berechnet, nicht die gesamte Infrastruktur.
