Als DBA ist das Beheben von Leistungsproblemen oft ein reaktives Ereignis; Problem auftritt, müssen Sie reagieren. Manchmal sehen Sie sich eine SQL Server-Instanz an, die Sie gut kennen, manchmal ist es Ihre erste Begegnung mit einer Umgebung. Dies geschieht auch in der Beratungswelt. Wenn ich einem langjährigen Kunden helfe, habe ich die Details zur Umgebung bereits abgelegt. Wenn wir jedoch eine E-Mail von jemandem erhalten, mit dem wir noch nie zuvor zusammengearbeitet haben, und es sich um eine Notsituation handelt, in der er sofortige Hilfe wünscht, haben wir keinen Hintergrund über die Umwelt und wissen nicht, worauf wir uns einlassen. Wir bieten Unterstützung, ohne den umfangreichen Datenerfassungs- und Analyseprozess durchlaufen zu müssen, der mit jeder neuen Kundenbeziehung beginnt.
Aus diesem Grund habe ich einen Satz von fünf Punkten, die ich sofort überprüfe, wenn ich mich einer neuen Umgebung stelle. Die Informationen, die ich sammle, bilden die Grundlage dafür, wie ich die Fehlerbehebung in Zukunft angehe, und obwohl sie selten THE lokalisieren spezifisches Problem, es hilft mir auszuschließen, was NOT ist das Problem, das manchmal genauso wichtig ist.
Datenerfassungsmethoden
Ich erkenne an, dass jeder eine andere Herangehensweise an eine neue Umgebung hat. Es gibt mehrere kostenlose, weithin verfügbare Skripts, die Sie herunterladen und ausführen können, um Ihnen die „Lage der Erde“ für eine SQL Server-Instanz zu geben (Glenn Berrys DMV-Skripts kommen mir in den Sinn). Der Fokus liegt hier nicht auf dem wie Sie sammeln die Daten, es ist was Daten, die Sie sammeln, und was Sie zuerst analysieren .
Servereigenschaften
Das allererste, was ich wissen möchte, wenn ich mir eine Instanz ansehe, ist die Version und Edition von SQL Server. Am schnellsten erhalten Sie diese Informationen, indem Sie Folgendes ausführen:
SELECT @@VERSION;
Mit dieser Ausgabe kann ich den Build überprüfen, um die angewendeten Service Packs, kumulativen Updates und Hotfixes zu ermitteln, und ich weiß, welche Edition verwendet wird. Ich möchte auch wissen, ob die Instanz geclustert ist, also führe ich auch Folgendes aus:
SELECT SERVERPROPERTY('IsClustered'); Ich habe diese Informationen manchmal vom Kunden, aber es schadet nie, sie zu überprüfen, da Version und Edition nachfolgende Fehlerbehebungsschritte und Empfehlungen beeinflussen können. Beispielsweise kontaktierte uns kürzlich ein Kunde wegen eines zeitweiligen Leistungsproblems, das er bei SQL Server 2008 beobachtete. Eine schnelle Überprüfung der Version ergab, dass er SQL Server 2008 SP3 ausführte, und dass nach SP3 mehrere kumulative Updates veröffentlicht wurden, die eine Reihe von Problemen betrafen Performance-Probleme. Obwohl ich weitere Informationen gesammelt habe, bevor ich die Empfehlung abgegeben habe, dass sie das neueste CU anwenden, war dies ein sofortiges Warnsignal hinsichtlich der möglichen Ursache des Problems.
sys.konfigurationen
Diese Katalogansicht hilft uns, auf der Grundlage aufzubauen, die mit Servereigenschaften begonnen wurde, und hilft uns zu verstehen, wie die Instanz konfiguriert ist. Mit dieser Ansicht suche ich nach Einstellungen, die von den Standardeinstellungen geändert wurden, aber nicht hätten geändert werden sollen, und nach solchen, die nicht geändert wurden wurde geändert, sollte aber.
SELECT [name], [value], [value_in_use], [description] FROM [sys].[configurations] ORDER BY [name];
Berücksichtigen Sie die Einstellung max server memory (MB), die die für den Pufferpool verfügbare Speichermenge begrenzt. Der Standardwert ist 2147483647, sollte aber auf einen Wert kleiner als der Gesamtspeicher auf dem Server geändert werden, um sicherzustellen, dass ausreichend Speicher für das Betriebssystem, andere Anwendungen und andere SQL Server-Aufgaben vorhanden ist, die Speicher benötigen, der nicht aus dem Pufferpool entnommen wird . Als Anleitung zum Festlegen des geeigneten Werts für den maximalen Serverspeicher (MB) empfehle ich Jonathans Post, Wie viel Speicher benötigt mein SQL Server tatsächlich?
Umgekehrt hat die Priority Boost-Einstellung einen Standardwert von Null und sollte immer so belassen werden. Tatsächlich empfiehlt Microsoft, sie nicht zu ändern, und die Option wird in einer zukünftigen Version von SQL Server entfernt.
sys.datenbanken
Nachdem ich verstanden habe, wie die Instanz konfiguriert ist, schaue ich als Nächstes nach, was auf Datenbankebene vorhanden ist.
SELECT * FROM [sys].[databases] ORDER BY [database_id];
Wenn ich die Ausgabe dieser Katalogansicht überprüfe, suche ich in den Daten nach Anti-Mustern – alles, was als unerwartet oder atypisch auffällt. Die Ausgabe eignet sich für eine schnelle Analyse – viele der Einstellungen führen eine 0 oder 1 für den Wert auf (aus oder an), und ich mache mir eine mentale Notiz, was anders ist. Ich gehe davon aus, dass die automatische Erstellung von Statistiken und die automatische Aktualisierung von Statistiken aktiviert sind (auf 1 gesetzt). Ich erwarte, dass Auto-Close und Auto-Shrink deaktiviert sind (auf 0 gesetzt). Ich schaue nach, was die Sortierung für die Benutzerdatenbanken ist, insbesondere, ob sie alle dieselbe Sortierung haben und ob diese Sortierung mit tempdb identisch ist. Ich bemerke auch Sicherheitsoptionen wie datenbankübergreifende Verkettung und die Option is_trustworthy, die beide standardmäßig deaktiviert (0) sind. Wenn ich feststelle, dass eine dieser Einstellungen von meinen Erwartungen abweicht, notiere ich es und gehe weiter. Ich unterbreche meine Sammlung oder Analyse zu keinem Zeitpunkt, um eine Änderung vorzunehmen, da ich einfach so schnell wie möglich Informationen sammle, um ein gutes Verständnis der Umgebung zu erhalten.
Neben der Überprüfung der Einstellungen für die Datenbanken achte ich auch auf die Anzahl der Benutzerdatenbanken. Es gibt keine „richtige Anzahl“ von Benutzerdatenbanken für eine Instanz – eine Instanz kann mit einer Datenbank schlecht und mit 100 hervorragend funktionieren. Es spielen unzählige Faktoren eine Rolle, und die Anzahl der Datenbanken ist einfach ein Datenpunkt erwähnenswert.
Fehlerprotokolle
Ich gebe zu, ich habe früher das SQL Server ERRORLOG vernachlässigt; Es war wie ein nachträglicher Gedanke, als ich ein SQL Server-Problem untersuchte. Dann erkannte ich den Fehler meiner Wege, und ich habe es seitdem nicht mehr als selbstverständlich angesehen. Ich neige dazu, durch Management Studio zu navigieren, um auf das Protokoll zuzugreifen (innerhalb von Management | SQL Server-Protokolle), obwohl Sie die gespeicherte Prozedur sp_readerrorlog verwenden oder zu der Datei navigieren und sie in Ihrem bevorzugten Texteditor öffnen können.
Im ERRORLOG suche ich nach kürzlich aufgetretenen Fehlern – z. B. nach allem, was mit dem Arbeitsspeicher zu tun hat – und ich schaue auch nach, welche Trace-Flags, falls vorhanden, verwendet werden. Ich überprüfe auch, ob Lock Pages in Memory aktiviert ist, ob der Cache geleert wird (entweder absichtlich oder nicht) und ob andere ungewöhnliche Aktivitäten regelmäßig auftreten. Je nachdem, wie dringend das Problem ist, schaue ich auch in die Windows-Protokolle (Ereignis, Anwendung und Sicherheit) und suche wieder nicht nur nach Fehlern, sondern auch nach unerwarteten Meldungsmustern.
Wartestatistik
Der letzte Bereich von SQL Server, den ich beim Betrachten eines Leistungsproblems auf einer unbekannten Instanz überprüfe, sind Wartestatistiken. Bei jeder SQL Server-Instanz gibt es Wartezeiten – egal, wie gut der Code abgestimmt ist, egal, wie viel Hardware dahintersteckt. Als DBA möchten Sie wissen, was Ihre typischen Wartezeiten für eine Instanz sind, und wenn ich mir eine neue Umgebung anschaue, weiß ich nicht sofort, ob die Wartezeiten, die ich sehe, typisch sind oder auf das Leistungsproblem zurückzuführen sind. Ich frage den Kunden, ob er eine Baseline für Wartestatistiken erstellt, und wenn nicht, frage ich, ob ich sie löschen und sie ansammeln lassen kann, während das Leistungsproblem auftritt. Um Wartestatistiken zu überprüfen, können Sie das Skript in Paul Randals oft zitiertem Post oder die Version in Glenns DMV-Abfragen verwenden.
Sobald Sie die gesammelten Wartestatistiken überprüft haben, haben Sie das letzte Stück, das das „große Bild“ der SQL Server-Instanz liefert, und die Informationen, die Sie benötigen, um mit der Fehlerbehebung zu beginnen. Es ist nicht ungewöhnlich, bei der Fehlerbehebung zuerst die Wartestatistiken zu überprüfen, aber Wartezeiten allein reichen nicht aus, um festzustellen, was Sie als Nächstes untersuchen müssen, es sei denn, Sie verstehen auch die grundlegende SQL Server-Konfiguration.
Nächste Schritte
Wie ich bereits angedeutet habe, gibt es in der Regel keine einzelnen Daten, die Ihnen sagen, wo das Leistungsproblem liegt. Es sind mehrere erhaltene Datenpunkte, die Sie in die richtige Richtung weisen. Wie Sie diese Informationen erfassen, bleibt Ihnen überlassen, aber sobald Sie die Ausgabe überprüft haben, sollten Sie ein gutes Verständnis dafür haben, wie die SQL Server-Umgebung konfiguriert ist, und dieses Wissen kann Ihnen in Kombination mit den Wartestatistiken bei der Entscheidung helfen, was Sie als Nächstes untersuchen möchten. Die Fehlersuche funktioniert am besten mit einem methodischen Ansatz, also beginnen Sie mit den Grundlagen und arbeiten Sie sich nach oben, und wenn Sie glauben, die Grundursache ermittelt zu haben, graben Sie noch ein bisschen mehr und finden Sie ein oder zwei zusätzliche Beweise, die Ihre Feststellung stützen. Sobald Sie diese Daten haben, können Sie eine Empfehlung zur Verbesserung oder Lösung des Problems aussprechen.
