Freigeben über

Checkliste: Bewährte Methoden für SQL Server auf Azure-VMs

  • Artikel

Gilt für: SQL Server auf Azure-VMs

Bietet bewährte Methoden und Richtlinien für den Speicher, um die Leistung Ihrer SQL Server-Instanz auf Azure Virtual Machines (VM) zu optimieren.

Ausführliche Informationen finden Sie in den anderen Artikeln dieser Reihe: VM-Größe, Speicher, Sicherheit, HADR-Konfiguration, Baseline erfassen.

Aktivieren Sie SQL-Bewertung für SQL Server auf Azure-VMs, und Ihr SQL Server wird anhand bekannter bewährter Methoden mit Ergebnissen auf der Seite SQL VM-Verwaltung des Azure-Portals ausgewertet.

Videos zu den neuesten Features zur Optimierung der Leistung von SQL Server-VMs und zur Automatisierung der Verwaltung finden Sie in den folgenden „Data Exposed“-Videos:

Übersicht

Es empfiehlt sich, beim Ausführen von SQL Server auf Azure Virtual Machines weiterhin die gleichen Optionen zur Optimierung der Datenbankleistung zu verwenden, die für SQL Server in lokalen Serverumgebungen gelten. Die Leistung einer relationalen Datenbank in einer öffentlichen Cloud hängt jedoch von vielen Faktoren ab, z. B. der Größe eines virtuellen Computers und der Konfiguration der Datenträger für Daten.

In der Regel kommt es zu einem Kompromiss zwischen einer Kostenoptimierung und einer Leistungsoptimierung. Diese Folge von bewährten Methoden zur Leistung konzentriert sich darauf, die beste Leistung für SQL Server auf Azure Virtual Machines zu erzielen. Wenn Ihre Workload weniger anspruchsvoll ist, sind möglicherweise nicht alle empfohlenen Optimierungen erforderlich. Berücksichtigen Sie bei der Evaluierung dieser Empfehlungen Ihre Leistungsanforderungen und -kosten sowie Ihre Workloadmuster.

Größe des virtuellen Computers

In der Checkliste in diesem Abschnitt werden die bewährten Methoden für die VM-Größe für SQL Server auf Azure-VMs behandelt.

  • Die Ebdsv5-Serie bietet das höchste E/A-Durchsatz-zu-vCore-Verhältnis in Azure zusammen mit einem Speicher-zu-vCore-Verhältnis von 8. Diese Serie bietet das beste Preis-Leistungs-Verhältnis für SQL Server-Workloads auf Azure-VMs. Für die meisten SQL Server-Workloads sollten Sie diese Serie also zuerst berücksichtigen.
  • Verwenden Sie VM-Größen mit 4 oder mehr vCPUs wie z. B. E4ds_v5 oder höher.
  • Verwenden Sie VM-Größen mit Arbeitsspeicheroptimierung, um die bestmögliche Leistung für SQL Server-Workloads zu erzielen.
  • Die Serie Edsv5 und die Ebdsv5-Serie, die Msv3- und Mdsv3-Serie bieten ein optimales Speicher-zu-vCore-Verhältnis, das für OLTP-Workloads erforderlich ist.
  • Die VMs der M-Serie bieten das höchste Speicher-zu-vCore-Verhältnis in Azure. Berücksichtigen Sie diese virtuellen Computer für unternehmenskritische OLTP- und Data Warehouse-Workloads.
  • Verwenden Sie Azure Marketplace-Images zur Bereitstellung Ihrer SQL Server-VMs, weil die SQL Server-Einstellungen und -Speicheroptionen für optimale Leistung konfiguriert sind.
  • Erfassen Sie die Leistungsmerkmale des Zielworkloads, und nutzen Sie sie zum Ermitteln der passenden VM-Größe für Ihr Unternehmen.
  • Verwenden Sie den Datenmigrations-Assistenten und das SKU-Empfehlungstool, um die richtige VM-Größe für Ihre vorhandene SQL Server-Workload zu ermitteln.
  • Verwenden Sie Azure Data Studio, um zu Azure zu migrieren.

Warnung

Das Installieren von SQL Server auf Systemen mit mehr als 64 Kernen pro NUMA-Knoten wird derzeit nicht unterstützt. Diese Einschränkung gilt derzeit für die Azure-VM-Größen Standard_M176s_3_v3 und Standard_M176s_4_v3 in der Msv3- und Mdsv3-Reihe mit mittlerem Arbeitsspeicher.

Storage

In der Checkliste in diesem Abschnitt werden die bewährten Speichermethoden für SQL Server auf Azure-VMs behandelt.

  • Überwachen Sie die Anwendung, und bestimmen Sie die Anforderungen an die Speicherbandbreite und Wartezeit für SQL Server-Daten-, Protokoll- und tempdb-Dateien, bevor Sie den Datenträgertyp auswählen.
  • Wenn verfügbar, konfigurieren Sie die tempdb-Daten und -Protokolldateien auf dem lokalen SSD-Volume von Laufwerk D. Die SQL IaaS-Agent-Erweiterung verarbeitet den Ordner und die Berechtigungen, die bei der erneuten Bereitstellung erforderlich sind.
  • Um die Speicherleistung zu optimieren, planen Sie für die höchsten verfügbaren nicht zwischengespeicherten IOPS, und verwenden Sie Datenzwischenspeicherung als Leistungsmerkmal für Datenlesevorgänge, während Sie die Begrenzung virtueller Computer und Datenträger vermeiden.
  • Wenn Sie die SQL Server-VMs der Serien Ebdsv5 oder Ebsv5 verwenden, sollten Sie SSD Premium v2 einsetzen, um die beste Leistung zu erzielen. Sie können Ihre SQL Server-VM mit SSD Premium v2 über das Azure-Portal bereitstellen (derzeit in der Vorschau).
  • Platzieren Sie Daten- und Protokoll- und tempdb-Dateien auf separaten Laufwerken.
    • Verwenden Sie für das Datenlaufwerk Premium P30- und P40-Datenträger oder kleinere Datenträger, um die Verfügbarkeit der Cacheunterstützung sicherzustellen. Bei Verwendung der Ebdsv5-VM-Serie nutzen Sie Premium SSD v2, die eine bessere Preisleistung für Workloads bietet, die einen hohen IOPS- und E/A-Durchsatz erfordern.
    • Für das Protokolllaufwerk planen Sie die Kapazität und testen die Leistung im Verhältnis zu den Kosten, während Sie entweder die Premium SSD v2- oder Premium SSD-Datenträger P30-P80 bewerten
      • Wenn eine Speicherwartezeit von weniger als einer Millisekunde erforderlich ist, verwenden Sie entweder Premium SSD v2 oder Azure Ultra-Disks für das Transaktionsprotokoll.
      • Für Bereitstellungen von virtuellen Computern der M-Serie sollten Sie eine Schreibbeschleunigung der Verwendung von Azure-Ultra-Datenträgern vorziehen.
    • Platzieren Sie tempdb auf dem temporären SSD-Laufwerk (das temporäre Laufwerk ist kurzlebig und standardmäßig D:\) für die meisten SQL Server-Workloads, die nicht Teil der Failoverclusterinstanz (FCI) sind, nachdem Sie die optimale VM-Größe ausgewählt haben.
    • Für Failoverclusterinstanzen (FCI) platzieren Sie tempdb auf dem gemeinsamen Speicher.
      • Wenn die FCI-Workload stark von der tempdb-Datenträgerleistung abhängig ist, platzieren Sie tempdb als erweiterte Konfiguration auf dem lokalen kurzlebigen SSD-Laufwerk (standardmäßig D:\), das nicht Teil des FCI-Speichers ist. Für diese Konfiguration sind benutzerdefinierte Überwachung und Aktionen erforderlich, um sicherzustellen, dass das lokale kurzlebige SSD-Laufwerk (standardmäßig D:\) immer verfügbar ist, da Fehler dieses Laufwerks keine Aktion der FCI auslösen.
  • Erstellen Sie ein Stripeset mehrerer Azure-Datenträger mithilfe von Speicherplätzen, um die E/A-Bandbreite bis zum IOPS- und Durchsatzlimit des virtuellen Zielcomputers zu erhöhen.
  • Legen Sie Hostzwischenspeicherung für Datenträger mit Datendateien auf Schreibgeschützt fest.
  • Legen Sie Hostzwischenspeicherung für Protokolldateidatenträger auf Keine fest.
    • Aktivieren Sie kein Lese-/Schreib-Caching auf Festplatten, die SQL Server-Daten oder Protokolldateien enthalten.
    • Beenden Sie immer den SQL Server-Dienst, bevor Sie die Cache-Einstellungen Ihrer Festplatte ändern.
  • Bei der Migration mehrerer verschiedener Workloads in die Cloud kann Azure Elastic SAN eine kostengünstige konsolidierte Speicherlösung sein. Bei Verwendung von Azure Elastic SAN muss jedoch oft eine überhöhte Kapazität bereitgestellt werden, um den gewünschten IOPS/Durchsatz für SQL Server-Workloads zu erreichen. Wenn auch in der Regel für einzelne SQL Server-Workloads nicht geeignet, kann beim Zusammenlegen von Workloads mit geringer Leistung mit SQL Server dennoch eine kostengünstige Lösung erzielt werden.
  • Für Workloads in Entwicklungs- und Testumgebungen sowie für die langfristige Archivierung von Sicherungskopien sollten Sie Standardspeicher verwenden. Es wird nicht empfohlen, HDD/SSD Standard für Produktionsworkloads zu verwenden.
  • Auf Guthaben basierendes Datenträgerbursting (P1-P20) sollte nur für kleinere Dev-/Test-Workloads und Abteilungssysteme in Betracht gezogen werden.
  • Um die Speicherleistung zu optimieren, planen Sie für die höchsten verfügbaren nicht zwischengespeicherten IOPS, und verwenden Sie Datenzwischenspeicherung als Leistungsmerkmal für Datenlesevorgänge, während Sie Drosselung von VMs und Datenträgern vermeiden.
  • Formatieren Sie den Datenträger, um die Größe der Zuordnungseinheiten von 64 KB für alle Datendateien zu verwenden, die auf einem anderen Laufwerk als dem temporären Laufwerk D:\ abgelegt werden (Standardwert: 4 KB). SQL Server über Azure Marketplace bereitgestellten virtuellen Computer verfügen über Datenträger, die mit der Größe der Zuordnungseinheit formatiert sind, und Interleave für den Speicherpool auf 64 KB.
  • Konfigurieren Sie das Speicherkonto in derselben Region wie die SQL Server-VM.
  • Deaktivieren Sie den georedundanten Azure-Speicher (Georeplikation), und verwenden Sie LRS (lokal redundanter Speicher) für das Speicherkonto.
  • Aktivieren Sie die SQL-Best-Practices-Bewertung, um mögliche Leistungsprobleme zu identifizieren und zu ermitteln, ob Ihre SQL Server-VM so konfiguriert ist, dass bewährte Methoden befolgt werden.
  • Überprüfen und überwachen Sie Datenträger- und VM-Grenzwerte mithilfe von Speicher-E/A-Auslastungsmetriken.
  • Schließen Sie SQL Server-Dateien von der Antivirensoftwareüberprüfung aus, einschließlich Datendateien, Protokolldateien und Sicherungsdateien.

Sicherheit

In der Checkliste in diesem Abschnitt werden die bewährten Sicherheitsmethoden für SQL Server auf Azure-VMs behandelt.

SQL Server-Features und -Funktionen bieten Methoden zum Sichern von Daten auf Datenbankebene, die mit Sicherheitsfeatures auf Infrastrukturebene kombiniert werden können. Gemeinsam bieten diese Features umfassende Verteidigungstiefe auf Infrastrukturebene für cloudbasierte und Hybridlösungen. Darüber hinaus ist es mit den Azure-Sicherheitsmaßnahmen möglich, sensible Daten zu verschlüsseln, VMs vor Viren und Malware zu schützen, den Netzwerkdatenverkehr abzusichern, Bedrohungen zu identifizieren, Complianceanforderungen zu erfüllen. Außerdem wird durch diese Sicherheitsmaßnahmen eine einheitliche Methode zur Verwaltung und Berichterstattung für sämtliche Sicherheitsanforderungen in der Hybrid Cloud bereitgestellt.

  • Verwenden Sie Microsoft Defender für Cloud, um die Sicherheitslage Ihrer Datenumgebung zu bewerten und Maßnahmen zur Verbesserung zu ergreifen. Funktionen wie Microsoft Defender for Identity können über in Ihren hybriden Workloads genutzt werden, um die Sicherheitsbewertung zu verbessern und auf Risiken reagieren zu können. Aufgrund der Registrierung Ihrer SQL Server-VM bei der SQL-IaaS-Agent-Erweiterung werden die Microsoft Defender für Cloud-Bewertungen in der Ressource SQL-VM des Azure-Portals angezeigt.
  • Verwenden Sie Microsoft Defender für SQL, um potenzielle Sicherheitsrisiken von Datenbanken zu ermitteln und zu entschärfen sowie anomale Aktivitäten zu erkennen, die auf eine Bedrohung Ihrer SQL Server-Instanz und Datenbankebene hindeuten könnten.
  • Die Sicherheitsrisikobewertung ist Bestandteil von Microsoft Defender für SQL. Durch sie können potenzielle Risiken für Ihre SQL Server-Umgebung erkannt und beseitigt werden. Sie bietet einen Überblick über Ihren Sicherheitsstatus und schlägt Maßnahmen zum Beheben von Sicherheitsproblemen vor.
  • Verwenden Sie vertrauliche Azure-VMs, um Ihre Daten während der Verwendung und im Ruhezustand vor Zugriffen durch den Hostoperator zu schützen. Vertrauliche Azure-VMs ermöglichen Ihnen, Ihre vertraulichen Daten in der Cloud zu speichern und dabei strenge Complianceanforderungen zu erfüllen.
  • Wenn Sie mit SQL Server 2022 arbeiten, sollten Sie die Microsoft Entra-Authentifizierung für die Verbindung zu Ihrer SQL Server-Instance verwenden.
  • Der Azure Advisor analysiert Ihre Ressourcenkonfiguration und Nutzungstelemetrie und empfiehlt dann Lösungen, mit denen Sie die Kosteneffizienz, Leistung, Hochverfügbarkeit und Sicherheit Ihrer Azure-Ressourcen verbessern können. Nutzen Sie den Azure Advisor auf der Ebene von VMs, Ressourcengruppen oder Abonnements, um Best Practices zur Optimierung Ihrer Azure-Bereitstellungen zu identifizieren und anzuwenden.
  • Verwenden Sie Azure Disk Encryption, wenn Ihre Compliance- und Sicherheitsanforderungen eine umfassende Datenverschlüsselung mithilfe von Verschlüsselungsschlüsseln verlangen, einschließlich der Verschlüsselung der kurzlebigen (lokal angeschlossenen und temporären) Festplatte.
  • Verwaltete Datenträger im Ruhezustand werden standardmäßig mit der Azure-Speicherdienstverschlüsselung verschlüsselt. Dabei sind die Verschlüsselungsschlüssel von Microsoft verwaltete Schlüssel, die in Azure gespeichert werden.
  • Einen Vergleich der Optionen für die Verschlüsselung von verwalteten Datenträgern finden Sie in der Vergleichstabelle für die Verschlüsselung von verwalteten Datenträgern.
  • Verwaltungsports sollten auf Ihren VMs geschlossen werden: Offene Ports zur Remoteverwaltung setzen Ihre VMs einem hohen Risiko durch internetbasierte Angriffe aus. um Administratorzugriff auf den Computer zu erhalten.
  • Aktivieren Sie den JIT-Zugriff (Just-In-Time) für virtuelle Azure-Computer.
  • Verwenden Sie Azure Bastion über das Remotedesktopprotokoll (RDP).
  • Sperren Sie Ports, und lassen Sie nur den notwendigen Anwendungsverkehr zu. Verwenden Sie dazu Azure Firewall (eine verwaltete FaaS-Lösung [Firewall-as-a-Service]), die den Serverzugriff auf Grundlage der IP-Adresse des Absenders gewährt oder verweigert.
  • Verwenden Sie Netzwerksicherheitsgruppen (NSGs), um den Netzwerkverkehr an und von Azure-Ressourcen in virtuellen Azure-Netzwerken zu filtern.
  • Nutzen Sie Anwendungssicherheitsgruppen, um Server mit ähnlichen Anforderungen an die Portfilterung und mit ähnlichen Funktionen (z. B. Webserver und Datenbankserver) in Gruppen zusammenzufassen.
  • Nutzen Sie für Web- und Anwendungsserver Azure DDoS Protection (Distributed Denial of Service). DDoS-Angriffe zielen darauf ab, die Netzwerkressourcen zu überlasten und zu erschöpfen, sodass Apps langsam werden oder nicht mehr reagieren. DDoS-Angriffe zielen in der Regel auf Benutzeroberflächen ab. Der Azure DDoS Protection-Dienst blockiert unerwünschten Netzwerkverkehr, bevor er die Dienstverfügbarkeit beeinträchtigt.
  • Verwenden Sie VM-Erweiterungen, um mithilfe von Antischadsoftware, Desired State-Konfigurationen, Bedrohungserkennung, -prävention und -beseitigung Bedrohungen auf Betriebssystem-, Computer- und Netzwerkebene zu bekämpfen:
  • Verwenden Sie Azure Policy, um Geschäftsregeln zu erstellen, die auf Ihre Umgebung angewendet werden können. Azure-Richtlinien bewerten Azure-Ressourcen, indem sie die Eigenschaften dieser Ressourcen mit Regeln vergleichen, die im JSON-Format definiert sind.
  • Azure Blueprints ermöglicht es Cloudarchitekten und zentralen IT-Gruppen, eine wiederholbare Gruppe von Azure-Ressourcen zu definieren, mit der die Standards, Muster und Anforderungen einer Organisation implementiert und erzwungen werden. Azure Blueprints unterscheidet sich von Azure Policy.
  • Verwenden Sie Windows Server 2019 oder Windows Server 2022, um mit SQL Server auf Azure-VMs FIPS-kompatibel zu sein.

SQL Server-Funktionen

Im Folgenden finden Sie eine kurze Checkliste der Best Practices für SQL Server-Konfigurationseinstellungen, wenn Sie Ihre SQL Server-Instanzen auf einem virtuellen Azure-Computer in der Produktion ausführen:

Azure-Features

Im Folgenden finden Sie eine kurze Checkliste der Best Practices zur Azure-spezifischen Anleitung bei der Ausführung Ihrer SQL Server-Instanzen auf Azure-VM:

HADR-Konfiguration

In der Checkliste in diesem Abschnitt werden die bewährten HADR-Methoden für SQL Server auf Azure-VMs behandelt.

HADR-Features (High Availability and Disaster Recovery) wie die AlwaysOn-Verfügbarkeitsgruppe und die Failoverclusterinstanz basieren auf der zugrunde liegenden Windows Server-Failovercluster-Technologie. Sehen Sie sich die bewährten Methoden zum Ändern Ihrer HADR-Einstellungen an, um die Cloudumgebung besser zu unterstützen.

Erwägen Sie für Ihren Windows-Cluster die folgenden bewährten Methoden:

  • Stellen Sie Ihre SQL Server-VMs nach Möglichkeit in mehreren Subnetzen bereit, um die Abhängigkeit von einem Azure Load Balancer oder einem verteilten Netzwerknamen (DNN) zur Weiterleitung des Datenverkehrs an Ihre HADR-Lösung zu vermeiden.
  • Ändern Sie den Cluster in weniger aggressive Parameter, um unerwartete Ausfälle durch vorübergehende Netzwerkfehler oder Wartung der Azure-Plattform zu vermeiden. Weitere Informationen finden Sie unter Heartbeat- und Schwellenwerteinstellungen. Verwenden Sie für Windows Server 2012 und höher die folgenden empfohlenen Werte:
    • SameSubnetDelay: 1 Sekunde
    • SameSubnetThreshold: 40 Heartbeats
    • CrossSubnetDelay: 1 Sekunde
    • CrossSubnetThreshold: 40 Herzschläge
  • Platzieren Sie Ihre VMs in einer Verfügbarkeitsgruppe oder verschiedenen Verfügbarkeitszonen. Weitere Informationen finden Sie unter VM-Verfügbarkeitseinstellungen.
  • Verwenden Sie eine einzelne NIC pro Clusterknoten.
  • Konfigurieren Sie die Clusterquorumabstimmung so, dass eine ungerade Anzahl von mindestens drei Stimmen verwendet wird. Weisen Sie DR-Regionen keine Stimmen zu.
  • Überwachen Sie Ressourcengrenzwerte sorgfältig, um unerwartete Neustarts oder Failover aufgrund von Ressourceneinschränkungen zu vermeiden.
    • Stellen Sie sicher, dass Betriebssystem, Treiber und SQL Server den neuesten Builds entsprechen.
    • Optimieren Sie die Leistung für SQL Server auf Azure-VMs. Weitere Informationen finden Sie in den anderen Abschnitten dieses Artikels.
    • Reduzieren oder verteilen Sie die Workload, um Ressourcengrenzwerte zu vermeiden.
    • Wechseln Sie zu einer VM oder einem Datenträger mit höheren Grenzwerten, um Einschränkungen zu vermeiden.

Erwägen Sie für die SQL Server Verfügbarkeitsgruppe oder Failoverclusterinstanz die folgenden bewährten Methoden:

  • Wenn häufig unerwartete Fehler auftreten, befolgen Sie die leistungsbezogenen bewährten Methoden, die im restlichen Teil dieses Artikels beschrieben werden.
  • Falls sich die unerwarteten Failover durch Optimierung der Leistung der SQL Server-VMs nicht beheben lassen, erwägen Sie eine Lockerung der Überwachung für die Verfügbarkeitsgruppe oder Failoverclusterinstanz. Dadurch wird jedoch möglicherweise nicht die zugrunde liegende Ursache des Problems behoben, und durch Verringerung der Fehlerwahrscheinlichkeit können Symptome maskiert werden. Möglicherweise müssen Sie die zugrunde liegende Ursache dennoch untersuchen und beheben. Verwenden Sie für Windows Server 2012 oder höher die folgenden empfohlenen Werte:
    • Leasetimeout: Verwenden Sie diese Gleichung, um den maximalen Leasetimeoutwert zu berechnen:
      Lease timeout < (2 * SameSubnetThreshold * SameSubnetDelay).
      Beginnen Sie mit 40 Sekunden. Wenn Sie die zuvor empfohlenen gelockerten SameSubnetThreshold- und SameSubnetDelay-Werte verwenden, darf der Leasetimeoutwert 80 Sekunden nicht überschreiten.
    • Maximale Fehler in einem angegebenen Zeitraum: Legen Sie diesen Wert auf 6 fest.
  • Wenn Sie den virtuellen Netzwerknamen (VNN) und einen Azure Load Balancer verwenden, um sich mit Ihrer HADR-Lösung zu verbinden, geben Sie MultiSubnetFailover = true in der Verbindungszeichenfolge an, auch wenn sich Ihr Cluster nur über ein Subnetz erstreckt.
    • Wenn der Client MultiSubnetFailover = True nicht unterstützt, müssen Sie möglicherweise RegisterAllProvidersIP = 0 und HostRecordTTL = 300 festlegen, um Clientanmeldeinformationen für kürzere Zeiträume zwischenzuspeichern. Dies kann jedoch zu zusätzlichen Abfragen an den DNS-Server führen.
  • Beim Herstellen einer Verbindung mit der HADR-Lösung mithilfe des Namens des verteilten Netzwerks (Distributed Network Name, DNN) ist Folgendes zu beachten:
    • Sie müssen einen Clienttreiber verwenden, der MultiSubnetFailover = True unterstützt, und dieser Parameter muss in der Verbindungszeichenfolge enthalten sein.
    • Verwenden Sie einen eindeutigen DNN-Port in der Verbindungszeichenfolge, wenn Sie eine Verbindung mit dem DNN-Listener für eine Verfügbarkeitsgruppe herstellen.
  • Verwenden Sie eine Verbindungszeichenfolge für Datenbankspiegelung für eine Basic-Verfügbarkeitsgruppe, um die Notwendigkeit eines Lastenausgleichs oder DNN zu umgehen.
  • Überprüfen Sie die Sektorgröße Ihrer VHDs, bevor Sie Ihre Hochverfügbarkeitslösung bereitstellen, um falsch ausgerichtete E/A zu vermeiden. Weitere Informationen finden Sie unter KB3009974.
  • Wenn die SQL Server-Datenbank-Engine, der Always On-Verfügbarkeitsgruppenlistener oder der Integritätstest der Failoverclusterinstanz so konfiguriert sind, dass ein Port zwischen 49152 und 65536 (der standardmäßige dynamische Portbereich für TCP/IP) verwendet wird, fügen Sie einen Ausschluss für jeden Port hinzu. Dadurch wird verhindert, dass anderen Systemen dynamisch derselbe Port zugewiesen wird. Im folgenden Beispiel wird ein Ausschluss für Port 59999 erstellt:
    netsh int ipv4 add excludedportrange tcp startport=59999 numberofports=1 store=persistent

Behandeln von Problemen mit der Leistung

Im Folgenden finden Sie eine Liste hilfreicher Ressourcen zur weiteren Problembehandlung von SQL Server-Leistungsproblemen.

Zugehöriger Inhalt

Erwägen Sie die Aktivierung von SQL-Bewertung für SQL Server auf Azure-VMs.

Weitere Artikel zu virtuellen SQL Server-Computern finden Sie unter Übersicht zu SQL Server auf virtuellen Azure-Computern. Falls Sie Fragen zu SQL Server-VMs haben, finden Sie in den häufig gestellten Fragen weitere Informationen.