SQL Server für Startups

Lizenzmodell wählen, bevor Sie Anwendungsserver zählen

Vergleichen Sie bei SQL Server 2022 Standard vor dem Kauf die Lizenzierung nach Server + CAL mit der Lizenzierung pro Core. Bei Server + CAL benötigt jeder Nutzer bzw. jedes Gerät, das auf SQL Server zugreift, eine passende CAL. Das gilt auch für indirekte Zugriffe über Ihre Anwendung. Verbindungspooling, gemeinsam genutzte Anmeldungen und Middleware verringern die Zahl der erforderlichen CALs nicht. Die Lizenzierung eines einzelnen Dienstkontos auf dem Anwendungsserver deckt die dahinterstehenden Nutzer nicht ab. Für ein kundenorientiertes SaaS-Produkt mit wechselndem oder nicht zählbarem Nutzerkreis ist die Lizenzierung pro Core meist der praktikablere Ausgangspunkt.

Bei der Lizenzierung pro Core sind keine SQL Server CALs erforderlich. Damit sind jedoch nicht automatisch alle Fragen zur SaaS-Lizenzierung geklärt. Die Rechte zur Bereitstellung gehosteter Softwaredienste hängen von Ihrem Vertrag und dem Bereitstellungsmodell ab. Microsoft sieht separate Lizenzvereinbarungen für Serviceprovider sowie an Bedingungen geknüpfte Self-Hosting-Rechte vor. Ein Aktivierungsschlüssel allein belegt diese Berechtigungen nicht. Halten Sie fest, wem die Anwendung gehört, wer darauf zugreift und wo sie betrieben wird. Prüfen Sie anschließend vor dem Lizenzkauf die geltenden Microsoft Product Terms oder die Serviceprovider-Vereinbarung.

• Zählen Sie auch indirekt zugreifende Nutzer und Geräte, nicht nur Datenbankanmeldungen oder gleichzeitige Sitzungen.
• Wählen Sie User CALs oder Device CALs danach, wer oder was auf den Server zugreift.
• Die CAL-Versionen müssen die verwendete SQL Server-Version abdecken. Ältere CALs berechtigen nicht zum Zugriff auf neuere Serverversionen.
• Dokumentieren Sie SaaS-Hosting-Rechte unabhängig von der Berechnung der Core-Lizenzen oder CALs.
• Prüfen Sie die Windows Server-Lizenzierung separat, wenn SQL Server unter Windows läuft.

SQL Server 2022 Standard nach tatsächlichen Editionsgrenzen dimensionieren, nicht nach Hardwaredaten

Die Database Engine von SQL Server 2022 Standard kann pro Instanz höchstens vier Prozessorsockel oder 24 Kerne nutzen, je nachdem, welcher Grenzwert zuerst erreicht wird. Die Grenze von 128 GB bezieht sich auf den Bufferpool-Speicher pro Instanz und ist keine absolute Obergrenze für den installierten Arbeitsspeicher oder den gesamten Speicherverbrauch von SQL Server. Diese Unterschiede sind bei der Host-Auswahl wichtig: Ein leistungsstärkerer Rechner kann weitere Workloads unterstützen, aber eine einzelne Standard-Instanz kann nicht zwangsläufig alle Prozessoren nutzen oder jedes zusätzliche Gigabyte als Datenbankcache verwenden.

Erfassen Sie vor einem Editionswechsel repräsentative Messwerte Ihrer Workloads: CPU-Auslastung, Speicherlatenz, Arbeitsspeicherdruck, Blockierungen und die ressourcenintensivsten Abfragen. Nutzen Sie Query Store, um Leistungsverschlechterungen zu erkennen und Ausführungspläne nach Änderungen zu vergleichen. Enterprise ersetzt nicht die Behebung fehlender Indizes, übergroßer Ergebnismengen oder langsamer Speichersysteme. Prüfen Sie außerdem die genaue Funktionsübersicht, statt davon auszugehen, dass jede erweiterte Funktion Enterprise voraussetzt: Transparent Data Encryption ist in SQL Server 2022 Standard verfügbar, während Online-Indexoperationen weiterhin ein wichtiges Unterscheidungsmerkmal der Editionen sind.

• Messen Sie Spitzenlasten durch Kundenaktivitäten und Batchjobs, nicht nur Tagesdurchschnittswerte.
• Reservieren Sie bei der Konfiguration von SQL Server ausreichend Arbeitsspeicher für das Betriebssystem und andere Prozesse.
• Testen Sie Indexänderungen sowohl auf ihre Leseleistung als auch auf den zusätzlichen Aufwand bei Schreibvorgängen.
• Sichern Sie bei Verwendung von TDE das zur Absicherung verwendete Zertifikat und den privaten Schlüssel an einem sicheren Ort.
• Prüfen Sie editionsabhängige Speichergrenzen für spezielle Funktionen wie In-Memory OLTP separat.

Wiederherstellung anhand von Datenbankgrenzen und getesteten Restores planen

Eine Basis-Verfügbarkeitsgruppe in SQL Server 2022 Standard unterstützt zwei Replikate und eine Datenbank. Das sekundäre Replikat kann weder schreibgeschützte Workloads bedienen noch Backups ausführen. Es eignet sich daher nicht zur Erweiterung der Reporting-Kapazität. Bei einer SaaS-Anwendung, die sich über mehrere Datenbanken erstreckt, bilden auch separate Basis-Verfügbarkeitsgruppen keine gemeinsame, koordinierte Failover-Einheit. Erfassen Sie Transaktionen, gemeinsame Abhängigkeiten und die Verteilung der Mandanten, bevor Sie die Topologie auswählen. Das ist besonders wichtig, wenn die Anwendung voraussetzt, dass mehrere Datenbanken bei einer Umschaltung konsistent bleiben.

Hochverfügbarkeit ersetzt keine Backups: Versehentliche Löschungen und schädliche Anwendungsänderungen können auf ein anderes Replikat übertragen werden. Definieren Sie Wiederherstellungspunktziele und Wiederherstellungszeitziele, wählen Sie ein geeignetes Wiederherstellungsmodell und planen Sie je nach Bedarf vollständige Sicherungen, differenzielle Sicherungen und Transaktionsprotokollsicherungen. Stellen Sie diese anschließend in einer isolierten Umgebung wieder her und messen Sie das Ergebnis. Nehmen Sie Verschlüsselungsschlüssel, Anmeldungen auf Serverebene, SQL Agent-Jobs und Verbindungseinstellungen der Anwendung in das Betriebshandbuch auf. Die Wiederherstellung einer Datenbank allein stellt nach einem Ausfall möglicherweise noch keinen funktionsfähigen Dienst wieder her.

• Testen Sie Failover mit Anwendungsverkehr, erneuten Verbindungsversuchen und laufenden Transaktionen.
• Schützen Sie Sicherungskopien so, dass mit den Zugangsdaten der produktiven Anwendung nicht darauf zugegriffen werden kann.
• Richten Sie für eine zeitpunktgenaue Wiederherstellung eine gültige Kette von Transaktionsprotokollsicherungen ein und halten Sie diese lückenlos aufrecht.
• Messen Sie die Wiederherstellungsdauer mit realistischen Datenbankgrößen und der verfügbaren Speicherbandbreite.
• Prüfen Sie die Lizenzrechte für passives Failover, bevor Sie eine zweite SQL Server-Instanz dauerhaft bereitstellen.

Lizenzrechte für VMs, Testumgebungen und Kaufangebote vor der Bereitstellung prüfen

Bei SQL Server 2022 setzt die Lizenzierung einer einzelnen virtuellen Maschine nach virtuellen Kernen Abonnementlizenzen oder Lizenzen mit aktiver Software Assurance voraus. Bei dieser Option lizenzieren Sie die der VM zugewiesenen virtuellen Kerne, mindestens jedoch vier Core-Lizenzen pro VM. Wenden Sie diese Berechnung nicht automatisch auf eine unbefristete Lizenz ohne Software Assurance an. Server + CAL ist eine separate Option für Standard. Für die Lizenzierung nach physischen Kernen gelten andere Zählregeln; sie gewährt bei Standard keine unbegrenzten Virtualisierungsrechte.

Führen Sie ein Bereitstellungsverzeichnis mit Version, Edition, Lizenzmodell, zugewiesenem Server bzw. zugewiesener VM und Lizenznachweisen. Developer Edition darf für Entwicklung, Tests und Demonstrationen verwendet werden, nicht jedoch für den produktiven Kundenbetrieb oder operatives Reporting im Produktivbetrieb. Die Bezeichnung als Staging-Umgebung ändert nichts an der tatsächlichen Nutzung. Prüfen Sie vor dem Kauf, ob der angebotene Artikel die benötigte Serverlizenz, die erforderliche Anzahl an Core-Lizenzen oder die passende CAL umfasst und ob der Lizenzkanal Ihren geplanten Einsatz erlaubt. Eine erfolgreiche Aktivierung ist kein Nachweis dafür, dass diese Anforderungen erfüllt sind.

• Prüfen Sie den aktuellen Microsoft SQL Server Licensing Guide gemeinsam mit den geltenden Product Terms.
• Dokumentieren Sie die Ablaufdaten von Software Assurance oder Abonnements, wenn Bereitstellungsrechte davon abhängen.
• Prüfen Sie die Regeln zur Lizenzneuzuweisung und Lizenzmobilität, bevor Sie die automatische Migration zwischen Hosts aktivieren.
• Trennen Sie Entwicklungs- und Testworkloads von Diensten, die den laufenden Geschäftsbetrieb unterstützen.
• Prüfen Sie beim Weiterverkauf einer Lizenz die Dokumentation zur Lizenzübertragung.

SQL Server 2022 Standard: Prüfpunkte für Lizenzierung und Bereitstellung