Ich unterrichte und schreibe seit vielen Jahren über häufige SQL Server-Fehler. Ich habe vor Jahren auch einen Blog darüber geschrieben, aber im Laufe der Zeit hat sich die Anleitung ein wenig geändert. Dieser Artikel erweitert meinen vorherigen Artikel und weist darauf hin, wie diese auf SQL Server, Azure SQL-Datenbank und Azure SQL Managed Instance angewendet werden.
Seit vielen Jahren beobachte ich Benutzer, die die gleichen Fehler machen. Ich nenne sie Fehler, aber in den meisten Fällen sind es eher Dinge, die nicht richtig gemacht werden, weil die Leute, die die Umwelt verwalten, es nicht besser wissen. Hier sind einige der wichtigeren Punkte, die jeder kennen sollte, der SQL Server installiert und unterstützt:
- Sicherungen
- DBCC-CHECKDB
- Speichereinstellungen
- Statistiken
- Indexpflege
- MAXDOP und Kostenschwelle für Parallelität
- Warnungen des SQL Server-Agenten
Sicherungen
Ich überprüfe immer zuerst die Sicherungen, wenn ich mir ein neues System anschaue. Es ist entscheidend, über geeignete Sicherungen zu verfügen, um die Wiederherstellungsziele zu erreichen. Datenverlust kann einem Unternehmen schaden. Wenn ich mir Backups anschaue, überprüfe ich das Wiederherstellungsmodell und den aktuellen Verlauf der Backups für jede Datenbank. Normalerweise finde ich eine Kombination der folgenden:
- Überhaupt kein Backup – keine Aufzeichnung eines Backups für die Datenbank
- Fehlende Sicherungen – keine Protokollsicherungen für eine Datenbank, die das vollständige Wiederherstellungsmodell verwendet
- Keine aktuellen Sicherungen – letzte Sicherung war Wochen/Monate/Jahre alt
Falsch konfigurierte Backups sind für ein Unternehmen schädlich, wenn eine Wiederherstellungssituation auftritt. Mit Kunden zu arbeiten und ihnen mitteilen zu müssen, dass sie Daten verloren haben, macht nie Spaß oder ist einfach. Das Vorhandensein geeigneter Backups zur Erfüllung von SLAs sollte für jedes Unternehmen oberste Priorität haben, zusätzlich zur Sicherstellung, dass Kopien dieser Backups an einem sekundären Standort außerhalb des Standorts gespeichert sind.
Diese Situation gilt für lokale SQL Server und IaaS. Azure SQL-Datenbank und Azure Managed Instance verfügen über verwaltete Sicherungen.
DBCC-CHECKDB
Datenbankbeschädigung passiert leider. Ohne regelmäßige Überprüfung auf Beschädigungen können sich Kunden an einem schlechten Ort wiederfinden, wenn sie keine Backups haben, um sie wiederherzustellen, wenn diese Beschädigung die physischen Daten betrifft. Um auf Beschädigungen zu prüfen, sollte DBCC CHECKDB regelmäßig für jede Datenbank ausgeführt werden. Was ich finde, ist Backups sehr ähnlich:
- Überhaupt keine DBCC CHECKDBs durchgeführt
- DBCC CHECKDBs werden nur für ausgewählte Datenbanken ausgeführt
- DBCC CHECKDBs wurden zuletzt vor Monaten oder Jahren durchgeführt
Der schlimmste Fall ist ein geplanter Job, der fehlgeschlagene DBCC CHECKDBs meldet
Es ist nie angenehm, eine Beschädigung zu finden oder einen Kunden mit einem Beschädigungsproblem ansprechen zu lassen, wenn die Beschädigung ein Heap oder ein gruppierter Index ist und es keine Sicherungen gibt, bevor die Beschädigung auftritt. In diesen Fällen handelt es sich bei der Beschädigung um die tatsächlichen Daten, und das Starten der Wiederherstellung vor der Beschädigung ist in den meisten Fällen die einzige Option. In Fällen, in denen die Beschädigung ein nicht geclusterter Index ist, ist die Wiederherstellung des Index die Lösung.
In einigen Situationen musste ich mit Kunden zusammenarbeiten, die ohne ordnungsgemäße Sicherungen eine schlimme Beschädigung hatten, wo ich in der Lage war, die Datenbank zu skripten und alle verwendbaren Daten manuell in eine neu erstellte Datenbank zu kopieren. Diese kostspieligen Situationen können leicht vermieden werden, indem Sie DBCC CHECKDB ausführen und eine ordnungsgemäße Aufbewahrung von Backups haben.
Ich rate Kunden, DBCC CHECKDB lokal, IaaS, Azure SQL-Datenbank und Azure SQL Managed Instance auszuführen. Azure leistet hervorragende Arbeit bei der Überprüfung auf physische Beschädigung; Ich bin jedoch der Meinung, dass Verbraucher auf logische Beschädigungen prüfen müssen.
Speichereinstellungen
Bei einer Standardinstallation von Microsoft SQL Server ist der Mindestspeicherwert auf 0 und der maximale Serverspeicherwert auf 2147483647 MB festgelegt, was 2 Petabyte entspricht. Vor SQL Server 2012 galt der maximale Serverarbeitsspeicherwert nur für den Pufferpool, sodass Kunden die Arbeitsspeichermenge begrenzen mussten, die der Pufferpool verwenden konnte, um Arbeitsspeicher für das Betriebssystem und andere Prozesse zu sparen. SQL Server 2012 hat eine Neuschreibung des Speichermanagers eingeführt, sodass der maximale Serverspeicherwert für alle SQL Server-Speicherzuweisungen gilt.
Es wird dringend empfohlen, einen Maximalwert für Ihre SQL Server-Instanz festzulegen. Jonathan Kehayias hat einen Blogbeitrag geschrieben, wie viel Arbeitsspeicher mein SQL-Server tatsächlich benötigt, mit einer Formel, die dabei hilft, die Basislinie für den maximalen Arbeitsspeicherwert festzulegen. Bei einem gemeinsam genutzten SQL Server empfehle ich meinen Kunden, den Mindestwert auf 30 % des Arbeitsspeichers auf dem Server festzulegen.
In Situationen mit mehreren Instanzen oder wenn der Server für SQL Server, SSIS, SSAS oder SSRS verwendet wird, müssen Sie bewerten, wie viel Arbeitsspeicher diese anderen Systeme benötigen, und den maximalen Serverarbeitsspeicherwert reduzieren, um ausreichend Arbeitsspeicher für das Betriebssystem und das andere zu ermöglichen Dienste.
Dieses Problem gilt für lokal, IaaS und teilweise für Azure SQL Managed Instance. Managed Instance legt einen maximalen Serverspeicherwert basierend auf der bereitgestellten Ebene fest, aber als ich die Größenänderung der Umgebung getestet habe, wurde der maximale Speicherwert nicht dynamisch geändert. In diesem Fall müssten Sie den Wert manuell aktualisieren. Dieses Problem gilt nicht für Azure SQL-Datenbank.
Statistiken
Der Abfrageoptimierer verwendet Statistiken zum Erstellen von Ausführungsplänen. Das bedeutet, dass SQL Server Statistiken auf dem neuesten Stand halten muss, damit der Abfrageoptimierer bessere Chancen hat, einen guten Ausführungsplan zu erstellen. Standardmäßig werden Statistiken aktualisiert, nachdem 20 % +500 Datenzeilen geändert wurden. Das kann bei größeren Tabellen sehr lange dauern. Ab Kompatibilitätsgrad 130 wurde der Schwellenwert für Statistikaktualisierungen für große Tabellen gesenkt. Für SQL Server 2008R – 2014 können Sie diesen Schwellenwert mithilfe des Ablaufverfolgungsflags 2371 senken.
Ich stelle regelmäßig fest, dass Kunden Statistiken nicht manuell aktualisieren, und selbst bei der niedrigeren Schwelle habe ich festgestellt, dass eine manuelle Aktualisierung eine Umgebung stabiler macht.
Ich empfehle, dass Kunden ein Skript eines Drittanbieters verwenden, um Statistiken zu aktualisieren. Ola Hallengren hat eine weit verbreitete Wartungslösung für SQL Server veröffentlicht. Teil dieses Prozesses ist sein Index Optimize-Verfahren, das zusätzliche Parameter zur Aktualisierung der Statistiken verwenden kann.
@UpdateStatistics
ALL = update index and column statistics
INDEX = update index statistics
COLUMNS = update column statistics
NULL = Do not perform statistics maintenance (this is the default)
@OnlyModifiedStatistics
Y = Update statistics only if rows have been modified since most recent stats update
N = Update statistics regardless of whether any rows have been modified
Ich habe festgestellt, dass Kunden, die Produkte oder Skripte von Drittanbietern verwenden, um Indexwartungen basierend auf dem Fragmentierungsgrad des Indexes durchzuführen, nicht berücksichtigen, dass Reorganisationen Statistiken nicht wie Neuerstellungen aktualisieren. Viele dieser Anwendungen von Drittanbietern haben Optionen zum Aktualisieren von Statistiken, genau wie Olas Index Optimize-Verfahren, Sie müssen es nur aktivieren.
Das Aktualisieren von Statistiken gilt für lokale, IaaS-, Azure SQL-Datenbank- und verwaltete Azure SQL-Instanzen.
Indexpflege
Die Durchführung der Indexwartung durch Entfernen der Fragmentierung aus Ihren Indizes ist nach wie vor wichtig. In einigen veralteten Dokumentationen von Microsoft heißt es, dass die Indexfragmentierung je nach Größe der Umgebung und Grad der Fragmentierung eine negative Auswirkung von 13 bis 460 % haben kann. Während Hardware wie intelligente SANs, Solid State Disk und andere Fortschritte dazu beigetragen haben, die Dinge zu beschleunigen, kann verschwendeter Speicherplatz im Index zu verschwendetem Speicherplatz im Pufferpool führen und mehr E/A verschwenden.
Die Fragmentierung erfolgt durch regelmäßige Vorgänge wie Einfügungen, Aktualisierungen und Löschungen. Um dies zu beheben, ist eine ordnungsgemäße Indexwartung erforderlich, um Ihre Indizes neu zu erstellen oder neu zu organisieren. Ich wende mich erneut an Ola Hallengren für sein Index Optimize-Skript. Das Skript von Ola bietet die Möglichkeit, basierend auf dem Grad der Fragmentierung und den Mindestseiten neu zu erstellen oder zu reorganisieren. Viele Tools von Drittanbietern bieten die gleiche Logik. SQL Server-Datenbankwartungspläne vor SQL Server 2016 durften nur alle Indizes neu erstellen oder neu organisieren. Ab SQL Server 2016 können Sie jetzt eine ähnliche Logik basierend auf Fragmentierungsebenen angeben. Vergessen Sie diese Statistiken jedoch nicht, wenn Sie eine intelligente Logik basierend auf Fragmentierungsstufen verwenden.
Ich mag Olas Skript und Tools von Drittanbietern, die sich in eine Tabelle einloggen. Ich kann dann die Tabelle abfragen, um zu sehen, ob ich Index-Hotspots habe, an denen die Fragmentierung ständig auf hohem Niveau auftritt, und beheben, warum die Fragmentierung so weit verbreitet ist, und was getan werden kann.
Es gibt Ausnahmen zu jeder Regel oder bewährten Methode. Einige Datenzugriffsmuster führen zu einer ständigen Fragmentierung. Die Kosten für die ständige Neuerstellung/Neuorganisation dieser Tabellen lohnen sich möglicherweise nicht und können von der Wartung ausgeschlossen werden. Diese Situationen sollten von Fall zu Fall bewertet werden.
Dies gilt für lokal, IaaS, Azure SQL-Datenbank und Azure SQL Managed Instance.
MAXDOP
Ich finde, dass der maximale Grad an Parallelität und der Kostenschwellenwert für Parallelität normalerweise auf den Standardwerten auf den Client-Servern belassen werden. Für MAXDOP ist der Standardwert Null, was bedeutet, dass eine „unbegrenzte“ Anzahl von CPUs verwendet werden kann, um einen parallelen Bereich einer Abfrage auszuführen. Technisch gesehen bis zu 64 Prozessoren, es sei denn, Sie aktivieren ein Trace-Flag, um mehr zu verwenden.
Vor einem Jahrzehnt, als Prozessoren weniger Kerne hatten, war dieser Wert akzeptabel. Heute, mit hoher Kerndichte und Multi-Socket-Servern, ist eine unbegrenzte Anzahl von CPUs für Parallelität nicht so gut. Microsoft hat Hinweise dazu gegeben, welche Werte für MAXDOP zu verwenden sind.
Wenn Sie SQL Server 2008 – SQL Server 2014 verwenden, halten Sie für einen einzelnen NUMA-Knoten mit weniger als 8 logischen Prozessoren MAXDOP auf oder unter der Anzahl logischer Prozessoren. Wenn Sie mehr als 8 logische Prozessoren haben, belassen Sie MAXDOP bei 8. Wenn Sie mehrere NUMA-Knoten mit weniger als 8 logischen Prozessoren pro NUMA-Knoten haben, belassen Sie MAXDOP bei oder unter der Anzahl logischer Prozessoren pro NUMA-Knoten. Größer als 8, MAXDOP auf 8 belassen.
SQL Server 2016 führte Soft-NUMA-Knoten ein. Wenn das Datenbankmodul während des Dienststarts mehr als 8 physische Kerne pro NUMA-Knoten oder Socket erkennt, werden automatisch Soft-NUMA-Knoten erstellt. Die Engine sorgt dafür, dass logische Prozessoren desselben physischen Kerns in verschiedenen Soft-NUMA-Knoten platziert werden. Aus diesem Grund haben wir etwas andere Anleitungen für MAXDOP für SQL Server 2016 und höher.
Wenn Sie SQL Server 2016 und höher verwenden, halten Sie für einen einzelnen NUMA-Knoten mit weniger als 16 logischen Prozessoren MAXDOP auf oder unter der Anzahl logischer Prozessoren. Wenn Sie mehr als 16 logische Prozessoren haben, belassen Sie MAXDOP bei 16. Wenn Sie mehrere NUMA-Knoten mit weniger als 16 logischen Prozessoren pro NUMA-Knoten haben, belassen Sie MAXDOP bei oder unter der Anzahl logischer Prozessoren pro NUMA-Knoten. Größer als 16, halten Sie MAXDOP auf der Hälfte der Anzahl logischer Prozessoren pro NUMA-Knoten mit einem MAX-Wert von 16.
Wenn Sie hauptsächlich auf Maschinen mit 8 oder weniger logischen Prozessoren mit einem Standard-MAXDOP virtualisiert sind, sind Sie wahrscheinlich in Ordnung. Wenn Sie große physische Hardware mit Standardeinstellungen haben, sollten Sie sich die Optimierung von MAXDOP ansehen.
Alle oben genannten Zahlen sind Richtlinien, keine harten Wahrheiten. Ihre Workloads sind unterschiedlich und es sollte berücksichtigt werden, welcher Wert für Ihre Workload am besten geeignet ist.
Das Konfigurieren von MAXDOP gilt für lokale, IaaS- und verwaltete Azure SQL-Instanzen. Es gibt jedoch eine datenbankbezogene Konfiguration, die ab SQL Server 2016 pro Datenbank angewendet werden kann, und dies gilt für Azure SQL-Datenbank.
Kostenschwelle für Parallelität
Der Kostenschwellenwert für Parallelität hat einen Standardwert von 5. Die Geschichte dieser Zahl reicht bis in die frühen Tage von SQL Server und der Arbeitsstation zurück, auf der Workload-Tests durchgeführt wurden. Bei moderner Hardware ist die Kostenschätzung von 5 überholt. Tests haben gezeigt, dass eine Erhöhung der Zahl von 5 auf einen höheren Wert kürzere Abfragen davon abhält, einen parallelen Plan zu haben. Ich empfehle eher, diesen Wert auf eine höhere Zahl zu erhöhen, nachdem Sie den Plan-Cache untersucht haben. In vielen Fällen fange ich am Ende mit einem Wert von 25 an und überwache dann weiter und passe von dort aus an, falls erforderlich. Weitere Informationen zum Optimieren des Kostenschwellenwerts für Parallelität finden Sie in Jonathan Kehayias:Optimieren des „Kostenschwellenwerts für Parallelität“ aus dem Plan-Cache.
Dies gilt für lokale, IaaS- und verwaltete Azure SQL-Instanzen.
SQL Server-Agent-Warnungen
Jeder sollte SQL Agent-Warnungen nutzen, es sei denn, er hat eine Drittanbieteranwendung, die dieselben Fehlerbedingungen überwacht. Das Konfigurieren von Warnungen ist einfach und kostenlos, und wenn Sie sie konfigurieren, erhalten Sie wichtige Informationen, wenn Ihre Server Probleme haben.
Ich habe einen Artikel mit dem Titel „SQL Server Agent Alerts“ geschrieben, der Schritt-für-Schritt-Anleitungen zum Erstellen von Alerts für Fehler mit Schweregrad 19–25 und Fehler 825 enthält Warnungen. Dies kann über die GUI oder mit T-SQL erfolgen. Ich ermutige alle, diesen Prozess mit T-SQL zu skripten und ihn zu einem Teil Ihres Standard-Server-Builds zu machen.
Dies gilt für lokale, IaaS- und verwaltete Azure SQL-Instanzen.
Zusammenfassung
Wie Sie sehen können, gibt es viele Einstellungen, die nach der Installation von SQL Server von den Standardeinstellungen geändert werden sollten. Dies ist keine vollständige Liste; Es deckt jedoch viele der kritischeren und die Leistung beeinträchtigenden Probleme ab, die ich finde und die ich unter meiner Kategorie „Missgeschicke bei SQL Server“ zusammengefasst habe.
