Allgemeine Best Practices

Auf dieser Seite finden Sie Best Practices für eine optimale Leistung, Langlebigkeit und Verfügbarkeit mit Cloud SQL.

Wenn Probleme mit Ihrer Cloud SQL-Instanz auftreten, prüfen Sie bei der Fehlerbehebung Folgendes:

Instanzkonfiguration und -verwaltung

Best Practice Weitere Informationen
Lesen und beachten Sie die Betriebsrichtlinien, um dafür zu sorgen, dass alle Instanzen das Cloud SQL-SLA erfüllen.
Konfigurieren Sie für die primäre Instanz ein Wartungsfenster, in dem betriebsunterbrechende Updates erfolgen können. Siehe Wartungsfenster.
Wenn Sie Instanzen regelmäßig löschen und neu erstellen, sollten Sie die Instanz-ID mit einem Zeitstempel versehen, um die Wahrscheinlichkeit zu erhöhen, dass neue Instanz-IDs verwendet werden können.
Starten Sie keinen neuen Verwaltungsvorgang, bevor der letzte Vorgang abgeschlossen ist.

Cloud SQL-Instanzen akzeptieren keine neuen Vorgangsanfragen, bis sie den vorherigen Vorgang abgeschlossen haben. Wenn Sie dennoch versuchen, einen neuen Vorgang zu starten, schlägt die Anfrage fehl. Das betrifft auch Neustarts der Instanz.

Der Instanzstatus in der Google Cloud Console gibt nicht an, ob gerade ein Vorgang ausgeführt wird. Das grüne Häkchen zeigt nur an, dass sich die Instanz im Status RUNNABLE befindet. Wenn Sie wissen möchten, ob gerade ein Vorgang ausgeführt wird, wechseln Sie zum Tab Vorgänge und sehen Sie sich den Status des letzten Vorgangs an.

Konfigurieren Sie den Speicher für eine kritische Datenbankwartung.

Wenn die Instanzeinstellung Automatische Speichererweiterungen aktivieren deaktiviert ist oder die automatische Begrenzung der Speichererweiterung aktiviert ist, müssen mindestens 20 % Speicherplatz verfügbar sein, um alle kritischen Datenbankwartungsvorgänge, die von Cloud SQL ausgeführt werden, zu ermöglichen.

Wenn Sie benachrichtigt werden möchten, sobald der verfügbare Speicherplatz unter 20 % liegt, erstellen Sie eine messwertbasierte Benachrichtigungsrichtlinie für den Messwert Laufwerkauslastung mit der Position über dem Schwellenwert und einem Wert von .8. Weitere Informationen zu Messwertbasierte Benachrichtigungsrichtlinien erstellen.
Verhindern Sie eine Überlastung der CPU.

Sie können den Prozentsatz der verfügbaren CPU, die von Ihrer Instanz verwendet wird, in der Google Cloud Console auf der Seite „Instanzdetails“ ansehen. Weitere Informationen finden Sie unter Messwerte. Sie können auch die CPU-Auslastung überwachen und Benachrichtigungen zu einem angegebenen Schwellenwert erhalten, indem Sie Benachrichtigungsrichtlinien mit Messwertschwellen erstellen.

Um eine Überlastung zu vermeiden, können Sie die Anzahl der CPUs für Ihre Instanz erhöhen. Zum Ändern von CPUs ist ein Neustart der Instanz erforderlich. Wenn Ihre Instanz bereits die maximale CPU-Anzahl erreicht hat, müssen Sie Ihre Datenbank auf mehrere Instanzen aufteilen.
Vermeiden Sie eine Erschöpfung des Arbeitsspeichers.

Wenn Sie nach Anzeichen für Speicherausschöpfung suchen, sollten Sie hauptsächlich den Messwert usage verwenden. Um Fehler aufgrund von Speicherplatzmangel zu vermeiden, sollte dieser Messwert unter 90 % bleiben.

Sie können auch den Messwert total_usage verwenden, um den Prozentsatz des verfügbaren Speichers zu beobachten, den Ihre Cloud-SQL-Instanz verwendet, einschließlich des vom Datenbankcontainer verwendeten Speichers und des vom Cache des Betriebssystems zugewiesenen Speichers.

Anhand des Unterschieds zwischen den beiden Messwerten können Sie ermitteln, wie viel Arbeitsspeicher von Prozessen verwendet wird und wie viel vom Cache des Betriebssystems verwendet wird. Sie können den Arbeitsspeicher in diesem Cache wiederverwenden.

Um Probleme mit unzureichendem Speicherplatz vorherzusagen, prüfen Sie beide Messwerte und interpretieren Sie sie gemeinsam. Wenn die Messwerte hoch erscheinen, hat die Instanz möglicherweise zu wenig Arbeitsspeicher. Dies kann an einer benutzerdefinierten Konfiguration, an der zu niedrigen Instanzgröße für die Arbeitslast oder an einer Kombination dieser Faktoren liegen.

Skalieren Sie Ihre Cloud SQL-Instanz, um den Arbeitsspeicher zu erhöhen. Zum Ändern der Speichergröße der Instanz ist ein Neustart der Instanz erforderlich. Wenn Ihre Instanz bereits die maximale Speichergröße erreicht hat, müssen Sie Ihre Datenbank auf mehrere Instanzen aufteilen. Weitere Informationen zum Überwachen beider Messwerte in der Google Cloud Console finden Sie unter Messwerte.
Legen Sie SQL Server-Einstellungen so fest, dass sie für Cloud SQL optimal funktionieren. Siehe SQL Server-Einstellungen.
Passen Sie die Instanz optimal für Testläufe an. Die folgende Tabelle enthält die für Testläufe geeigneten Konfigurationswerte.
  • vCPU: 40
  • Arbeitsspeicher: 262144 MB
  • MAXDOP: 8
  • Cost threshold for parallelism: 120
  • tempdb-Dateien: 8. Vorskaliert, um eine automatische Vergrößerung zu verhindern.
  • Nutzerdatenbankdateien: Automatische Vergrößerung in 64-128 MB festgelegt. Vorgröße zur Verhinderung einer automatischen Vergrößerung.
  • Speicher: >= 4TB für die besten IOPS
Bestimmen Sie die Kapazität des E/A-Subsystems, bevor Sie SQL Server bereitstellen.

Testen Sie verschiedene E/A-Typen und -Größen. Die Größe der E/A, die vom nichtflüchtigen Serverspeicher von SQL Server ausgegeben wird, wirkt sich auf die IOPS und den Durchsatz aus. Die SQL Server-Arbeitslast wird gedrosselt, wenn sie das IOPS- oder Durchsatzlimit erreicht. Der in Cloud SQL verwendete Speichertyp ist PD SSD, das für Hochleistungs-Arbeitslasten auf Unternehmensebene geeignet ist.

Passen Sie die VM so an, dass die Leistung maximiert wird:

  • Eine Laufwerkgröße von 4 TB oder mehr bietet mehr Durchsatz und IOPS.
  • Eine höhere vCPU bietet mehr IOPS und Durchsatz. Überwachen Sie bei Verwendung einer höheren vCPU die DB-Wartezeit auf Parallelität, was auch zunehmen kann.
  • Für eine optimale Leistung sollten Sie E/A-Vorgänge parallel ausführen, um eine höhere E/A-Warteschlangentiefe zu erreichen.
Fragmentierung von Indexen und fehlende Indexe verhindern. Organisieren Sie den Index neu oder richten Sie einen Zeitplan ein, um den Index neu zu erstellen, je nachdem, wie oft sich Ihre Daten ändern. Legen Sie außerdem einen geeigneten Füllfaktor fest, um die Fragmentierung zu reduzieren. Überwachen Sie SQL Server auf fehlende Indexe, die möglicherweise eine bessere Leistung bieten.
Statistiken regelmäßig aktualisieren Wenn Statistiken veraltet sind, generiert die SQL-Abfrageoptimierung möglicherweise suboptimale Abfragepläne. Aktualisieren Sie die Statistiken, insbesondere nachdem große Datenmengen geändert wurden. Verwenden Sie den Abfragespeicher, um den SQL-Server mit suboptimalen Abfrageplänen zu überwachen und Fehler zu beheben.
Verhindern, dass Datenbankdateien unnötig groß werden.

Legen Sie autogrow in MB und nicht als Prozentsatz fest, indem Sie die Schritte verwenden, die für die Anforderung geeignet sind. Verwalten Sie das Wachstum außerdem proaktiv, bevor das automatische Wachstum beginnt.

Achten Sie außerdem darauf, dass das Feature Automatische Speichererweiterungen aktivieren für Cloud SQL aktiviert ist, damit Cloud SQL Speicherplatz hinzufügen kann, wenn der Speicherplatz der Datenbank und der Instanz aufgebraucht ist.

Erkennen Sie Probleme mit der Datenbankintegrität durch Ausführen von DBCC CHECKDB mindestens einmal pro Woche. DBCC CHECKDB prüft die Integrität aller Objekte in einer Datenbank. Mit der wöchentlichen Ausführung von DBCC CHECKDB können Sie dafür sorgen, dass Ihre Datenbanken nicht beschädigt sind. DBCC CHECKDB ist ein ressourcenintensiver Vorgang, der sich auf die Leistung Ihrer Instanz auswirken kann.
Führen Sie DBCC CHECKDB nicht auf einem Produktionsserver aus.
Wir empfehlen, eine der folgenden Optionen zu verwenden, anstatt DBCC CHECKDB auf einem Produktionsserver auszuführen:
  • Klonen Sie eine Datenbank und führen Sie DBCC CHECKDB auf der Klondatenbank aus.
  • Stellen Sie eine Sicherung in einer anderen Instanz wieder her und führen Sie dann DBCC CHECKDB in den Datenbanken der wiederhergestellten Instanz aus. Weitere Informationen zum Wiederherstellen einer Instanz finden Sie unter Instanz wiederherstellen.

Verwenden Sie die folgenden Code-Snippets, um DBCC CHECKDB für eine Datenbank auszuführen:

  • (Empfohlen) Führen Sie DBCC CHECKDB mit EXTENDED_LOGICAL_CHECKS aus. Dies ist eine umfassende, aber ressourcenintensivere Prüfung. 
          USE DATABASE_NAME
      DBCC CHECKDB WITH EXTENDED_LOGICAL_CHECKS,
      DATA_PURITY,NO_INFOMSGS, ALL_ERRORMSGS
  • Führen Sie DBCC CHECKDB mit PHYSICAL_ONLY aus: 
          USE DATABASE_NAME
      DBCC CHECKDB WITH PHYSICAL_ONLY,
      NO_INFOMSGS, ALL_ERRORMSGS

Datenarchitektur

Best Practice Weitere Informationen
Teilen Sie große Instanzen nach Möglichkeit in kleinere Instanzen auf. Mehrere kleine Cloud SQL-Instanzen sind oft besser als eine große Instanz. Die Verwaltung einer einzigen großen, monolithischen Instanz bringt einige Probleme mit sich, die bei einer Gruppe kleinerer Instanzen nicht auftreten.
Verwenden Sie nicht zu viele Datenbanktabellen.

Beschränken Sie die Anzahl der Tabellen Ihrer Instanz auf weniger als 10.000. Zu viele Datenbanktabellen können sich auf die Zeit für das Datenbankupgrade auswirken.

Datenbanksortierung Unabhängig davon, ob Sie eine neue Instanz von SQL Server installieren, eine Datenbanksicherung wiederherstellen oder einen Server mit Clientdatenbanken verbinden, ist es wichtig, dass Sie die Sprachanforderungen, die Sortierreihenfolge sowie die Groß- und Kleinschreibung der Daten, mit denen Sie arbeiten, kennen. Wenn Sie eine Sortierung für Ihren Server, Ihre Datenbank, Ihre Spalte oder Ihren Ausdruck auswählen, weisen Sie Ihren Daten bestimmte Merkmale zu. Diese Merkmale wirken sich auf die Ergebnisse vieler Vorgänge in der Datenbank aus. Wenn Sie beispielsweise eine Abfrage mithilfe von ORDER BY erstellen, kann die Sortierreihenfolge Ihrer Ergebnismenge von der Sortierung abhängen, die auf die Datenbank angewendet oder in einer COLLATE-Klausel auf der Ausdrucksebene der Abfrage vorgegeben wird. Weitere Informationen finden Sie unter Unterstützung von Datenbanksortierung und Unicode.
Abfragedesign Achten Sie für eine optimale Datenbank- oder Abfrageleistung darauf, dass Sie nicht eine große Anzahl von Tabellen (sechzehn oder mehr) in derselben Abfrage verwenden.
Abfragemonitoring Abfragen können mit der Zeit abnehmen. Es ist wichtig, die Leistung Ihrer Anwendung und der Abfrage im Laufe der Zeit zu überwachen. Ein Grund für diese Verschlechterung sind Hash-Bailouts.
Rekursive Hash-Joins oder Hash-Bailouts führen zu einer geringeren Leistung auf einem Server. Wenn in einem Trace viele Hash-Warnungsereignisse angezeigt werden, aktualisieren Sie die Statistiken zu den zu verknüpfenden Spalten. Weitere Informationen finden Sie unter Hash Bailouts.

Anwendungsimplementierung

Best Practice Weitere Informationen
Greifen Sie auf Best Practices für das Verbindungsmanagement zurück, z. B. Verbindungs-Pooling und exponentieller Backoff. Diese Methoden optimieren die Nutzung der Ressourcen durch die Anwendung und erleichtern die Einhaltung der Verbindungslimits für Cloud SQL. Weitere Informationen und Codebeispiele finden Sie unter Datenbankverbindungen verwalten.
Testen Sie die Reaktion der Anwendung auf Wartungsupdates, die im Rahmen eines Wartungsfensters jederzeit auftreten können. Mit einer Selfservice-Wartung können Sie ein Wartungsupdate simulieren. Während der Wartung ist Ihre Instanz für einen kurzen Zeitraum nicht verfügbar und bestehende Verbindungen werden getrennt. Durch das Testen von Wartungs-Rollouts erhalten Sie ein besseres Verständnis dafür, wie Ihre Anwendung mit geplanten Wartungsarbeiten umgeht und wie schnell das System wiederhergestellt werden kann.
Testen Sie die Reaktion der Anwendung auf Failover, die jederzeit vorkommen können. Sie können ein Failover manuell über die Google Cloud Console, die gcloud CLI oder die API starten. Weitere Informationen finden Sie unter Failover initialisieren.
Vermeiden Sie große Transaktionen. Kleine, kurze Transaktionen sind zu bevorzugen. Umfangreiche Datenbankupdates führen Sie besser in mehreren kleinen Transaktionen statt in einer einzelnen großen Transaktion durch.
Falls Sie den Cloud SQL Auth-Proxy verwenden, achten Sie darauf, dass es die neueste Version ist. Weitere Informationen finden Sie unter Cloud SQL Auth-Proxy auf dem aktuellen Stand halten.

Datenimport und -export

Best Practice Weitere Informationen
Beschleunigen Sie Importe für kleine Instanzen. Bei kleinen Instanzen können Sie vorübergehend die CPU-Zahl und den RAM einer Instanz erhöhen, um beim Importieren großer Datasets die Leistung zu optimieren.
Wenn Sie Daten für den Import in Cloud SQL exportieren, müssen Sie auf das richtige Vorgehen achten. Weitere Informationen finden Sie unter Daten exportieren.

Sicherung und Wiederherstellung

Best Practice Weitere Informationen
Schützen Sie Ihre Daten mit den jeweils am besten geeigneten Cloud SQL-Funktionen.

Sicherungen und Exporte sind zwei Möglichkeiten, um für Datenredundanz und Datenschutz zu sorgen. Beide ergänzen sich, schützen vor unterschiedlichen Szenarien und sind Teil einer effektiven Datenschutzstrategie.

Sicherungen benötigen nicht viele Ressourcen. Damit können Sie die Daten einer Instanz zum Zeitpunkt der Sicherung wiederherstellen. Es gelten jedoch einige Einschränkungen. Wenn Sie eine Instanz löschen, werden auch ihre Sicherungen gelöscht. Sie können keine einzelne Datenbank oder Tabelle sichern. Wenn die Region, in der sich die Instanz befindet, nicht verfügbar ist, können Sie die Instanz aus dieser Sicherung nicht wiederherstellen, auch nicht in einer verfügbaren Region.

Exporte dauern länger, da in Cloud Storage eine externe Datei erstellt werden muss, die zum Wiederherstellen der Daten verwendet werden kann. Exporte sind vom Löschen einer Instanz nicht betroffen. Außerdem können Sie je nach Exportformat auch eine einzelne Datenbank oder sogar nur eine Tabelle exportieren.

Wenn Sie die Exportsicherungsfunktion auf einer Enterprise- oder Standard-SQL Server-Instanz verwenden, sollten Sie keine GZ-Archivdatei erstellen, da sie versucht, eine Sicherung zu komprimieren, die bereits nativ von SQL Server komprimiert ist.

Schützen Sie Ihre Instanz und Sicherungen vor versehentlichem Löschen.

Eine Cloud SQL-Instanz, die Sie in der Google Cloud Console oder über Terraform erstellen, ermöglicht standardmäßig den Schutz vor versehentlichem Löschen.

Verwenden Sie das Exportfeature in Cloud SQL, um Ihre Daten für zusätzlichen Schutz zu exportieren. Cloud Scheduler mit der REST API verwenden, um die Exportverwaltung zu automatisieren. Für komplexere Szenarien verwenden Sie zur Automatisierung Cloud Scheduler mit Cloud Run-Funktionen.

SQL Server-Einstellungen

Einige SQL Server-Einstellungen werden für Cloud SQL empfohlen. In den folgenden Themen werden einige Empfehlungen beschrieben.

Globale Konfigurationseinstellungen

Einstellung Empfehlung
max worker threads Behalten Sie den Standardwert 0 bei. Diese Einstellung definiert die Anzahl der für SQL Server verfügbaren Threads basierend auf der Anzahl der CPUs. Der Wert wird vom SQL Server-Engine beim Start automatisch berechnet.
max server memory (MB)

Wenn Sie für diese Einstellung keinen Wert angeben, verbraucht SQL Server im Laufe der Zeit so viel Arbeitsspeicher wie möglich, bis 100 % erreicht ist. Wenn die Arbeitsspeichernutzung für eine Cloud SQL for SQL Server-Instanz zu hoch wird, kann dies zu Leistungsproblemen führen. Weitere Informationen zur Arbeitsspeichernutzung für SQL Server finden Sie unter Arbeitsspeichernutzung überwachen.

Wir empfehlen, die folgende Formel zu verwenden, um das Datenbank-Flag
max server memory festzulegen:

  • Reservieren Sie 1,4 GB Arbeitsspeicher für das Betriebssystem und die Agents.
  • Wenn der RAM auf dem Server kleiner oder gleich 16 GB ist, reservieren Sie 1 GB Arbeitsspeicher für jeweils 4 GB RAM.
  • Wenn der RAM auf dem Server größer als 16 GB ist, lassen Sie 4 GB Arbeitsspeicher und reservieren Sie 1 GB Arbeitsspeicher für 8 GB RAM, das größer als 16 GB ist.

Wenn der RAM für Ihre Instanz beispielsweise 104 GB
(106.496 MB) beträgt, reservieren Sie Folgendes:

  • 1,4 GB Arbeitsspeicher für das Betriebssystem und die Agents
  • 4 GB Arbeitsspeicher, da 104 GB größer als 16 GB ist
  • 11 GB Arbeitsspeicher, da 88 GB RAM größer als 16 GB sind (104 − 16=88) und 88 geteilt durch 8 gleich 11 ist

Für dieses Beispiel müssen Sie 16, 4 GB Arbeitsspeicher reservieren. Geben Sie daher für den Wert dieses Flags 89702 MB
[(104 - 16,4) × 1024 = 89702] an.

In der folgenden Tabelle finden Sie empfohlene Werte und Prozentsätze des Gesamt-RAM für einige beliebte VM-Stufen:

Instanzstufe (MB) max server memory <<<<<<8MB) % Summe
3.840 1440 37
4.096 1632 39
5792 2912 50
8.192 4704 57
11584 7248 62
16.384 10848 66
23168 16800 72
32.768 25200 76
46336 37072 80
65568 53888 82
92704 77648 83
131136 111248 84
185440 158784 85
262272 226000 86
370880 321056 86
524544 455488 86
741792 645600 87

Verwenden Sie die folgenden metrics, um die Speichernutzung für Ihre Instanz zu überwachen:

  • database/memory/usage
  • database/sqlserver/memory/buffer_cache_hit_ratio
  • database/sqlserver/memory/memory_grants_pending
  • database/sqlserver/memory/page_life_expectancy

Weitere Informationen finden Sie unter Cloud SQL-Instanzen überwachen.

Zu ändernde Datenbankeinstellungen

Um die Leistung der SQL Server-Datenbank optimal zu gestalten, legen Sie die folgenden SQL Server-Einstellungen wie unten beschrieben fest.

Einstellung Empfehlung
cost threshold for parallelism

Dies ist der Schwellenwert, an dem das SQL-Optimierungstool eine Abfrage mit Parallelität ausführt. Der Standardwert von 5 kann dazu führen, dass zu viele Abfragen parallel ausgeführt werden, was wiederum die Wartezeit der Datenbank bei parallelen Threads erhöht. Erhöhen Sie den Wert, um diese Art von Konflikten zu reduzieren.

Der Wert wird ignoriert, wenn maxdop auf 1 gesetzt ist.

max degree of parallelism (MAXDOP)

Wenn Sie Datenbankwartezeiten aufgrund der Parallelität reduzieren möchten, passen Sie diesen Wert anhand bestimmter Empfehlungen für die Anzahl der verfügbaren logischen Prozessoren an. Messen Sie die Leistung sorgfältig, wenn Sie diese Option auf 1 festlegen.

optimize for ad hoc workloads

Vermeiden Sie große Pläne zur einmaligen Verwendung im Tarif-Cache. Setzen Sie diese Option auf 1, um die Effizienz des Tarifcaches für Arbeitslasten zu verbessern, die viele einmalige Ad-hoc-Batches enthalten.

tempdb

Geben Sie tempdb vorab so an, dass es nicht automatisch wachsen muss. Alle Dateien in tempdb sollten gleich groß sein und dasselbe Dateiwachstum haben.

Der Datenbank-Wartetyp für tempdb-Konflikte wird als PAGELATCH_UP angezeigt. Um die Konflikte zu reduzieren, fügen Sie weitere Dateien hinzu.

Wenn die Anzahl der Prozessoren kleiner oder gleich 8 ist, verwenden Sie dieselbe Anzahl von Dateien wie für logische Prozessoren. Wenn die Anzahl der Prozessoren größer als 8 ist, verwenden Sie acht Datendateien. Wenn die Konflikte weiterhin bestehen, erhöhe die Anzahl der Dateien um ein Vielfaches von 4, bis keine Konflikte mehr auftreten.

Abhängig von Ihrer Arbeitslast sollten Sie auch die folgenden Einstellungen ändern.

Einstellung Empfehlung
Close Cursor on Commit Enabled Der Standardwert ist off. Das bedeutet, dass Cursor nicht automatisch geschlossen werden, wenn Sie einen Commit für eine Transaktion durchführen.
Default Cursor Mit dieser Option wird der Bereich eines Cursors gesteuert, der im T-SQL-Code verwendet wird. Wenn Sie diese Einstellung ändern, sollten Sie den Anwendungscode auf etwaige negative Auswirkungen prüfen.
Page Verify Mit dieser Option kann SQL Server eine Prüfsumme für eine Datenbankseite berechnen, bevor sie auf das Laufwerk geschrieben wird, und die Prüfsumme im Seitenheader speichern. Beim nochmaligen Lesen einer Seite wird die Prüfsumme neu berechnet, um die Integrität der Seite zu prüfen. Der empfohlene Wert ist checksum.
Parameterization Der Standardwert ist simple. Die einfache Parametrisierung ermöglicht es SQL Server, Literalwerte in einer Abfrage durch Parameter zu ersetzen. Microsoft stellt Richtlinien zum Ändern dieses Werts und zur Verwendung mit Tarifleitfäden zur Verfügung.

Beizubehaltende Datenbankeinstellungen

Für eine optimale Leistung der SQL Server-Datenbank sollten Sie die Standardwerte der folgenden SQL Server-Einstellungen beibehalten.

Einstellung Standardwert, der beibehalten werden soll
Auto Close False Wenn diese Einstellung aktiviert ist, werden Verbindungen geöffnet und geschlossen und der Prozedur nach jeder Verbindung geleert. Dies kann zu Leistungseinbußen bei Datenbanken führen, auf die häufig zugegriffen wird.
Auto Shrink False Das Aktivieren kann zu Datenbank- und Indexfragmentierung und anderen Leistungsproblemen führen. Einige davon werden in diesem SQL Server-Blog erläutert.
Date Correlation Optimization Enabled False Wenn diese Funktion aktiviert ist, kann das Optimierungsprogramm Beziehungen zwischen Datumsangaben in zwei verwandten Tabellen ermitteln und optimieren. Dieses Tracking in SQL Server weist einen gewissen Leistungsaufwand auf.
Legacy Cardinality Estimation False In einigen Fällen kann SQL Server die Kardinalitäten nicht genau berechnen, wenn diese Einstellung aktiviert ist.
Parameter Sniffing ON Das Ausschneiden von Parametern aus Datenbanktabellen kann bei der Erstellung von Ausführungsplänen helfen. Wenn die Tabellen ungleichmäßig verteilte Daten haben, können die Ausführungspläne zu Leistungsproblemen führen. Verwenden Sie für solche Daten andere Optionen aus dem Query Store, anstatt diese Einstellung zu ändern.
Query Optimizer Fixes False Wenn diese Option aktiviert ist, kann sich dies auf die Leistung des SQL Server-Kardinalitätsschätzungens auswirken. Wenn Sie sie aktivieren, testen Sie, ob es keine Abfrageregression gibt.
Auto Create Statistics True Mit dieser Option kann SQL Server Spalten-Statistiken erstellen, die die Kardinalitätsschätzungen von Abfrageplänen verbessern können.
Auto Update Statistics True Mit dieser Option kann SQL Server veraltete Statistiken mithilfe eines Schwellenwerts für die Neukompilierung aktualisieren, der auf der Tabellenkardinalität basiert.
Auto Update Statistics Asynchronously False Wenn diese Option aktiviert ist, wird das SQL-Abfrageoptimierungstool angewiesen, die veralteten Statistiken für die aktuelle Abfrageausführung zu verwenden, und die Statistiken asynchron aktualisieren, um zukünftige Arbeitslasten zu nutzen.

Wenn Sie jedoch eine vorhersehbare Antwortzeit für eine häufig ausgeführte Abfrage erwarten oder wenn in Ihrer Anwendung häufig Clientanfragezeitüberschreitungen auftreten, während sie auf Statistikaktualisierungen warten, sollten Sie diese Option aktivieren und Auto Update Statistics deaktivieren.

Target Recovery Time (Seconds) 60 Diese Einstellung legt eine Obergrenze für die Wiederherstellungszeit für eine Datenbank fest, indem Sie schmutzige Seiten mehr oder weniger häufig aus dem Pufferpool auf das Laufwerk leeren. Bei transaktionalen Arbeitslasten kann ein niedrigerer Wert für diese Einstellung in Kombination mit den Speicher-IOPS nahe dem Höchstwert zu einem Leistungsengpass führen.

Trace-Flag-Einstellungen

Mit Trace-Flags in SQL Server können Sie bestimmte Merkmale festlegen, das Verhalten von SQL Server-Datenbanken ändern oder Probleme in SQL Server beheben.

Einige SQL Server-Trace-Flags werden in Cloud SQL unterstützt und können mit Datenbank-Flags festgelegt werden. Folgende Einstellungen werden empfohlen:

Trace flag Empfohlen
1204 Yes, mit Ausnahme von arbeitslastintensiven Servern, die viele Deadlocks generieren.

Gibt die Ressourcen und Typen der Sperren zurück, die an einem Deadlock beteiligt sind, sowie den aktuell betroffenen Befehl.
1222 Yes, mit Ausnahme von arbeitslastintensiven Servern, die viele Deadlocks generieren.
1224 No Dies kann zu einer höheren Speichernutzung und zu Speicherdruck auf der Datenbank führen.
2528 No Die parallele Überprüfung von Objekten ist die Standardeinstellung und wird empfohlen. Der Grad der Parallelität wird vom Datenbankmodul automatisch berechnet.
3205 No Bandlaufwerke für Sicherungen sind eine Funktion von Cloud SQL for SQL Server.
3226 No, es sei denn, Sie benötigen häufige Sicherungen, z. B. TLOG-Sicherungen.
3625 No Da das Root-Konto keinen Systemadministratorzugriff hat, werden möglicherweise nicht alle Fehlermeldungen angezeigt.
4199 No Das wirkt sich auf den Estimator für Kardinalität aus und kann zu Regressionsabfragen führen.
4616 No Diese Einschränkung verringert die Sicherheit um Anwendungsrollen. Sie muss gemäß den Anwendungsanforderungen validiert werden.
7806 Yes Wenn der Datenbankserver nicht mehr reagiert, ist die dedizierte Administratorverbindung (DAC) möglicherweise die einzige Möglichkeit, um eine Verbindung zur Diagnose herzustellen.

Nächste Schritte

Weitere Informationen zu den Best Practices je nach Datenbank-Engine: