Was sind die wichtigsten Probleme und in welcher Reihenfolge von Bedeutung, während Sie eine bestehende (aber Ihnen unbekannte) Datenbank untersuchen (Performance-Tuning, Fehlerbehebung)?
Welche Aktionen / Maßnahmen in Ihren vorherigen Optimierungen haben den größten Effekt (mit möglicherweise dem Minimum an Arbeit)?
Ich möchte diese Frage in folgende Kategorien einteilen (in der Reihenfolge, die für mich von Interesse ist):
Aktualisierung:
Angenommen, ich habe eine Kopie einer Datenbank auf der Dev-Maschine ohne Zugriff auf die Produktionsumgebung, um Statistiken, die meisten verwendeten Abfragen, Leistungsindikatoren usw. im realen Gebrauch zu beobachten.
Dies ist eine entwicklungsbezogene, aber nicht DBA-bezogene Frage.
Update2:
Angenommen, die Datenbank wurde von anderen entwickelt und wurde mir zur Optimierung (Überprüfung) gegeben, bevor sie an die Produktion geliefert wurde.
Es ist durchaus üblich, dass die Entwicklung von den Endnutzern losgelöst ist.
Außerdem gibt es ein Datenbank-Design-Paradigma, bei dem eine Datenbank im Gegensatz zu einem Anwendungsdatenspeicher selbständig ein Wert sein sollte, unabhängig von bestimmten Anwendungen, die sie verwenden, oder im Zusammenhang mit ihrer Verwendung.
Update3: Danke an alle Beantworter! Sie alle haben mich gedrängt, Teilfrage zu öffnen
Wie betonen Sie Datenbank (Server) lokal laden?
Wenn Sie nicht an dem Laufzeitverhalten der Datenbank interessiert sind, z. Was sind die am häufigsten ausgeführten Abfragen und diejenigen, die am meisten Zeit verbrauchen, können Sie nur eine "statische" Analyse der Datenbankstruktur selbst durchführen. Das hat viel weniger Wert, denn Sie können nur nach einer Reihe von Schlüsselindikatoren für schlechtes Design suchen - aber Sie können nicht viel über die "Dynamik" des verwendeten Systems sagen.
Dinge, die ich in einer Datenbank suchen würde, die ich als .bak -Datei bekomme - ohne die Möglichkeit, Live- und tatsächliche Laufzeitleistungsstatistiken zu sammeln - wäre:
Normalisierung - Ist die Tabellenstruktur auf die dritte Normalform normiert? (zumindest die meiste Zeit - es könnte einige Ausnahmen geben)
Haben alle Tabellen einen Primärschlüssel? ("Wenn es keinen Primärschlüssel hat, ist es schließlich keine Tabelle")
Für SQL Server: Haben alle Tabellen einen guten Clustering-Index? Ein eindeutiger, enger, statischer und vorzugsweise immer zunehmender Clusterschlüssel - idealerweise eine INT IDENTITY und definitiv kein großer zusammengesetzter Index vieler Felder, keine GUIDs und keine großen VARCHAR-Felder (siehe Kimberly Tripps ausgezeichnete Blog-Posts zu den Themen für Details)
Gibt es Prüf- und Standardeinschränkungen für die Datenbanktabellen?
sind alle Fremdschlüsselfelder, die von einem nicht gruppierten Index gesichert werden, um JOIN-Abfragen zu beschleunigen?
Gibt es noch andere, offensichtliche "Todsünden" in der Datenbank, z. übermäßig komplizierte Ansichten oder wirklich schlecht entworfene Tabellen usw.
Aber noch einmal: Ohne tatsächliche Laufzeitstatistiken sind Sie ziemlich eingeschränkt in dem, was Sie aus Sicht der "statischen Analyse" tun können. Die eigentliche Optimierung kann nur dann wirklich stattfinden, wenn Sie von einem regulären Arbeitstag eine Auslastung haben, um zu sehen, welche Abfragen häufig verwendet werden und die Datenbank am stärksten belasten - & gt; Verwenden Sie Mitchs Checkliste, um diese Punkte zu überprüfen.
Erstellen Sie eine Leistungsbasislinie (nicht aufdringlich, verwenden Sie Leistungsindikatoren)
Identifizieren Sie die teuersten Abfragen (nicht intrusiv, verwenden Sie SQL Profiler)
Identifizieren Sie die am häufigsten ausgeführten Abfragen (nicht eingreifend, verwenden Sie SQL Profiler)
Identifizieren Sie übermäßig komplexe Abfragen oder solche, die langsam ablaufende Konstrukte oder Muster verwenden. (nicht intrusiv zu identifizieren, verwenden Sie SQL Profiler und / oder Code-Inspektionen; möglicherweise aufdringlich, wenn geändert, möglicherweise erhebliche erneute Tests erfordern)
Beurteilen Sie Ihre Hardware
Identifizieren Sie Indizes, die der gemessenen Arbeitslast zugutekommen (nicht aufdringlich, verwenden Sie SQL Profiler)
Messen und vergleichen Sie sie mit Ihrer Grundlinie.
Wenn Sie sehr große Datenbanken oder extreme Betriebsbedingungen haben (z. B. 24/7 oder extrem hohe Abfragen), sollten Sie sich die High-End-Funktionen Ihres RDBMS ansehen, z. B. die Tabellen- / Indexpartitionierung.
Dies könnte von Interesse sein: Wie kann ich Die teuersten Abfragen protokollieren und finden?
Wenn Ihnen die Datenbank unbekannt ist und Sie unter Druck stehen, haben Sie möglicherweise keine Zeit für Mitchs Checkliste. Das ist eine bewährte Methode zur Überwachung des Serverzustands.
Sie müssen auch Zugriff auf die Produktion haben, um echte Informationen aus verschiedenen Abfragen zu erhalten, die Sie ausführen können. Ohne dies bist du verloren. Das Server-Lademuster ist wichtig: Sie können viele Probleme nicht selbst auf einem Entwicklungsserver reproduzieren, da Sie das System nicht wie ein Endbenutzer verwenden werden.
Konzentrieren Sie sich auch auf "den größten Knall für den Bock". Eine teure Abfrage, die einmal täglich um 3 Uhr morgens ausgeführt wird, kann ignoriert werden. Ein nicht so teures Gerät, das jede Sekunde läuft, ist es wert, optimiert zu werden. Sie können dies jedoch nicht wissen, ohne das Server-Lademuster zu kennen.
Also, grundlegende Schritte ..
Angenommen, Sie sind Feuerwehrleute:
Langsame Antwort:
Dinge, die Sie haben sollten:
Bearbeiten: Nach dem Update
Bei der statischen Analyse handelt es sich lediglich um bewährte Methoden: Sie können die Verwendung nicht optimieren. Das ist alles was du tun kannst. Dies ist die Antwort von marc_s.
Sie können erraten, welche Abfrage am häufigsten verwendet wird, aber Sie können nicht erraten, wie viele Daten geschrieben werden oder wie stark eine Abfrage mit mehr Daten skaliert wird
In vielen Shops bieten Entwickler Unterstützung, entweder direkt oder als * 3. Zeile "
Wenn Sie von einem anderen Team eine Datenbank zur Überprüfung erhalten haben, die Sie einem anderen Team zur Bereitstellung übergeben: das ist seltsam.
Am wichtigsten ist es, aktuelle Statistiken zu sammeln. Die Leistung einer Datenbank hängt ab von:
Wenn man sich isoliert betrachtet, ist es viel weniger nützlich als das Ganze.
Sobald Sie die Statistiken gesammelt haben, dann beginnen Sie mit der Identifizierung von untergeordneten Operationen.
Die meisten der von uns behobenen Performance-Probleme bestanden darin, entweder Indizes hinzuzufügen, zusätzliche Spalten und Trigger hinzuzufügen, um die Kosten der Berechnungen von select auf insert/update zu verlagern, und dies taktvoll Informieren der Benutzer, dass ihre Abfragen, sagen wir, nicht optimal sind: -)
Sie freuen sich normalerweise, dass wir ihnen eine äquivalente Abfrage geben können, die viel schneller ausführt.
Tags und Links configuration sql-server database performance database-design