Die Wartung leistungsstarker SQL Server-Instanzen ist ein großer Teil der Aufgaben eines DBA. Das Versäumnis, ungewöhnliche Aktivitäten zu erkennen und zu korrigieren, kann den internen Betrieb beeinträchtigen und das Geschäftsergebnis beeinträchtigen.
Wenn Sie Änderungen oder Anomalien der Spitzenaktivität in einer SQL Server-Instanz bemerken, finden Sie hier drei Stellen, an denen Sie mit der Suche nach Antworten beginnen können.
Seitenlebenserwartung
Die Seitenlebenserwartung (PLE) einer Instanz sollte einen ziemlich konsistenten Wertebereich beibehalten. Wenn dieser Wert sinkt und niedrig bleibt, ist dies ein Zeichen dafür, dass der Pufferpool eine erhöhte Nachfrage erfährt.
Bevor Sie den Arbeitsspeicher ausschöpfen und aufstocken, werfen Sie einen Blick auf die Workload-Aktivität. Wenn die Arbeitsbelastung zugenommen hat, würde dies den zusätzlichen Druck auf den Pufferpool erklären. Wenn sich die Arbeitslast jedoch nicht geändert hat, müssen Sie genauer hinschauen, um herauszufinden, was den zusätzlichen Speicher verwendet.
Mögliche Gründe für einen Rückgang der PLE sind aktiv ausgeführte Wartungsjobs, Indexwiederherstellungen oder Statistikaktualisierungen, DBCC-Vorgänge und Änderungen am Abfrageplan.
Wenn Sie einen Rückgang der PLE bemerken, der nicht mit einer Erhöhung der Arbeitslast verbunden ist, gibt es einige Dinge, die Sie versuchen können, um die PLE einer Instanz zu verbessern:
- Nicht verwendete Indizes löschen
- Doppelte Indizes zusammenführen
- Achten Sie auf große Abfragen
- Defragmentieren
- Daten löschen
WRITELOG-Wartezeit
Wenn die WRITELOG-Wartezeit einen zu großen Anteil an der Gesamtwartezeit hat, liegt wahrscheinlich ein Engpass in Ihrer SQL Server-Instanz vor. Der Engpass wird wahrscheinlich entweder durch ein Problem auf der Festplatte verursacht, auf der das Transaktionsprotokoll gespeichert ist, oder durch ineffizientes Festschreiben von Daten.
Um festzustellen, mit welcher Art von Engpass Sie es zu tun haben, analysieren Sie zunächst die Anzahl der SQL-Anweisungen, die auf das WRITELOG-Ereignis warten. Wenn viele Anweisungen warten, liegt ein Festplattenengpass vor. Wenn nur wenige Anweisungen warten, werden Daten wahrscheinlich zu oft festgeschrieben.
Es gibt mehrere Möglichkeiten, die hohe WRITELOG-Wartezeit zu beheben, sobald Sie herausgefunden haben, ob Ihr Engpass mit der Festplatte oder mit dem Commit zusammenhängt:
- Fügen Sie der Festplatte, auf der das Transaktionsprotokoll gespeichert ist, E/A-Bandbreite hinzu
- Nicht-Transaktionsprotokoll-E/A von der Festplatte verschieben
- Verschieben Sie das Transaktionsprotokoll auf eine weniger ausgelastete Festplatte
- Reduzieren Sie die Größe des Transaktionsprotokolls
- Stellen Sie sicher, dass die COMMIT-Anweisung in den Code eingefügt wird, damit die Daten nicht zu häufig festgeschrieben werden
TempDB
TempDB ist ein temporärer Arbeitsbereich in SQL Server, der temporäre Objekte enthält. Da die in TempDB enthaltenen Objekte vorübergehend sind, erstellt eine SQL Server-Instanz TempDB bei jedem Neustart neu. Daher ist die Optimierung von TempDB entscheidend für die Aufrechterhaltung der Leistung und die Vermeidung von betrieblichen Engpässen.
TempDB-Konflikte sind eine der Hauptursachen für Leistungseinbußen. Konflikte treten auf, wenn mehrere Ressourcen Zugriff auf TempDB benötigen, aber nur eine TempDB-Datendatei vorhanden ist. Dies verursacht einen Engpass, da Prozesse nicht schnell genug auf TempDB zugreifen können, was zu Zeitüberschreitungen bei Verbindungen und der Aufhebung der Zuweisung von Prozessen führt.
Glücklicherweise können TempDB-Engpässe relativ einfach behoben werden, indem die Anzahl und Größe der TempDB-Dateien angepasst werden. Bei der Installation ist der SQL Server-Standard eine TempDB-Datendatei. Wenn Sie feststellen, dass Konflikte auftreten, wird empfohlen, dass Sie acht neue Datendateien hinzufügen und feststellen, ob das Problem dadurch behoben wird. Wenn das Problem nicht behoben ist, versuchen Sie, zusätzliche Datendateien in Vielfachen von vier hinzuzufügen, bis die Leistung wiederhergestellt ist.
Es ist zwar gut zu wissen, wo man bei Leistungsproblemen suchen muss, aber jedes der oben genannten Probleme und die daraus resultierenden Engpässe könnten gemildert oder ganz vermieden werden, indem eine feste Regel implementiert wird:Die Überwachung von Leistungsmetriken ist nicht optional. Hier sind einige Beispiele für wichtige zu verfolgende Messwerte:
Lebenserwartung von Seiten:Verfolgen Sie PLE mit kontinuierlicher Überwachung und handeln Sie proaktiv, wenn sie sinkt und unter dem typischen Wert für eine bestimmte SQL Server-Instanz bleibt.
WRITELOG-Wartezeiten:Überwachen Sie Metriken wie Protokollzunahme, Protokollverkleinerung, Protokollnutzung in Prozent und Protokolllöschwartezeiten/Sek.
TempDB-Ineffizienz:Überwachen Sie, was Benutzerobjekten, dem Versionsspeicher oder internen Objekten zugewiesen wird. Verfolgen Sie, wie sie sich im Laufe der Zeit entwickeln, und bestimmen Sie dann, welche Sitzungen TempDB verbrauchen und wie viel.
Es gibt einige ausgezeichnete, funktionsreiche, erschwingliche SQL Server-Leistungsüberwachungstools auf dem Markt, die Ihnen helfen können, leistungsmindernden Problemen vorzubeugen. Machen Sie sich zum DBA MVP des Unternehmens, indem Sie proaktiv nach Lösungen suchen, die sowohl den nach innen gerichteten Betrieb als auch die nach außen gerichteten Geschäftsservices auf Höchstleistung halten.
