SQL-Q & A: spielen die Karteikarte
SQL-Indizes können problematisch sein, wenn Sie sie aber gut im Auge behalten und auf mögliche Probleme achten, sollte ihre Verwaltung für Sie nicht allzu schwierig sein.
Paul S. Randal
Die versehentliche DBA
F: Ich kann die "inoffizielle DBA" in meinem Unternehmen. Wir verwenden SQL Server mehr, und Instanzen von SQL Server im Unternehmen bereits haben und wissen, dass wir eine tatsächliche DBA aushelfen benötigen. Während wir jemandem Vermietung, sollen verstehen, was macht, dass einige Instanzen langsamer ausgeführt werden. Haben Sie allgemeinen Empfehlungen zur ich suchen, in dem gestartet werden soll?
**A.**Dies ist eine gute Frage. Es kann zu eine Instanz von SQL Server, die nicht gut funktioniert haben und nicht wissen, wo Sie anfangen, Suche nach der Ursache ärgerlich sein. Es gibt verschiedene Möglichkeiten, die zu einem Leistungsabfall, beitragen könnten, damit ich immer am einfachsten, Fragen Sie einfach SQL Server selbst gefunden.
SQL Server verfolgt zwei Sätze von Informationen: e/a-Statistiken und Wartestatistiken. Dies sollte Ihnen eine gute Vorstellung davon, wo das Problem liegt.
Die meisten SQL Server-Installationen sind heutzutage e/A-gebundenen (d. h. ihre Leistung durch etwas zu tun mit dem Lesen und Schreiben von Daten eingeschränkt ist). Die Verlangsamung möglicherweise eine langsame e/a-Subsystem ein langsames Netzwerk verbinden eines SANs mit dem Server, auf dem Server, der SQL Server zum Austausch von Seiten von Arbeitsspeicher, schlechte Indizierungsstrategie oder etliche andere Dinge zu erzwingen, ist nicht genügend Arbeitsspeicher.
Die Dynamic Management View (DMV) sys.dm_io_virtual_file_stats können Sie sehen, was SQL Server i/o-Volumen, Stellplätze und Verzögerungen für alle e/A auf die Daten und Protokolldateien kennt. Unter Umständen das e/a-Teilsystem selbst nicht den Hotspot, aber i/O kann immer noch das Problem sein. Das e/a-Teilsystem konnte unzureichend mit der e/a-Last Umgang.
Hier kommt der andere Teil des Rätsels: Wartestatistik. SQL Server behält den Überblick über jedes Mal, wenn ein Ausführungs-Thread hat, warten Sie auf eine verfügbare Ressource, und wie lange der Thread warten mussten. Sie können auch arbeiten, wie lange der Thread gewartet wird, nachdem Sie benachrichtigt werden, der Verfügbarkeit der Ressource, aber bevor Sie auf einer CPU ausgeführt werden musste. Durch diese Datenaggregation ist es leicht zu finden in die oberen Bereichen wartet für SQL Server verursacht. Dadurch erhalten Sie einen Zeiger für den Grund werde.
Dies ist eine allgemeine Übersicht über diese Methodik. Das Lesen Sie für eine ausführlichere Erörterung, einschließlich eines Skripts, die, das Sie verwenden können meinen Blog-Post "Wartestatistik.” Er hat auch die Ergebnisse einer Leserumfrage von mehr als 1.800 SQL Server-Instanzen und weit verbreiteter Wait-Typen mit Erklärungen. Fazit: vergeuden Sie keine Zeit um in SQL Server, bis Sie gefragt haben, SQL Server über das Problem glaubt poking.
Fehlende Indexanalyse
F: Ich habe gerade entdeckt, Index DMVs fehlt. Jetzt sie mir erzählen habe ich Hunderte von fehlenden Indizes in einer SQL Server-Instanz. Sollte ich soeben erstellen aller Folien oder geht, Probleme zu verursachen?
**A.**Erstellen Sie die Indizes nicht sofort ohne ersten einige Analysen durchzuführen. Der Abfrageprozessor von SQL Server 2005 und höheren Versionen kann bestimmen, wann ein Index den Plan für eine Abfrage (oder Stapel oder gespeicherte Prozedur) profitieren würden. Dies erfolgt beim Kompilieren des Abfrageplans.
Jedes Mal, wenn er feststellt, ein fehlender Index vorhanden ist, enthält es diese Tatsache. Er hält auch zählen, wie oft jede fehlenden Index, zusammen mit der Verbesserung der projizierten im Abfrageplan aufgebraucht haben konnte diesen Index zu dem Zeitpunkt vorhanden gewesen wäre, die der Abfrageplan kompiliert wurde.
Sie können diese Informationen, die für die Verwendung von drei DMVs (sys. dm_db_missing_index_groups, sys. dm_db_missing_index_group_stats und sys. dm_db_missing_index_details) zugreifen. Es gibt auch eine DMV, die Ihnen mitteilt, welche Spalten in einer Tabelle über Indizes (sys.dm_db_missing_index_columns) fehlen. Die ersten drei DMVs sind häufiger. Fragen sie gemeinsam für die einfachste Möglichkeit, diese Daten abzurufen. Peter Brehm verwendet weit Skript "Verwenden Sie SQL fehlender Index DMVs?” kann auch helfen.
Diese Information ist wertvoll, jedoch sollten Sie es mit einer Körnung von Salz ausgeführt werden. Erstens ist gibt es ein potenzieller Bug in den fehlenden Index DMVs. Es können Sie feststellen, dass ein Index, der tatsächlich existiert nicht vorhanden ist. Dieser Fehler wird in der nächsten Version von SQL Server behoben werden. Weitere Informationen über Sie in meinem Blogbeitrag "Fehlender Index DMVs Bug, die Ihre Nerven Kosten konnte.”
Zweitens hält der Mechanismus, der einen fehlenden Index den Abfrageprozessor bestimmt nur, ob ein Index für die kompilierten Abfrage sinnvoll ist. Es nicht möglich Performance-Auswirkungen für Insert/Update/Delete-Operationen in Betracht ziehen, die diesen Index verwalten. Möglicherweise verfügt die Tabelle proportional viele weitere Änderungen als liest enormen. Die Größe des erstellten Indexes nicht auch in Betracht ziehen. Das ist ein Kompromiss, die, den nur Sie vornehmen können.
Zuletzt, sucht er nach den besten absoluten Index den kompilierten Abfrageplan zu helfen. Beispielsweise kann eine Tabelle mit 30 Spalten eines gruppierten Indexes und eine Abfrage, die 25 der Tabellenspalten fordert sein. Der fehlenden Index Bestimmung Mechanismus würde empfehlen, einen nicht gruppierten Index zur Deckung der Abfrage 25-Spalte erstellen. In den meisten Fällen, die wouldn't sinnvoll.
Verwenden Sie des Duncan-Skript, um die aggregierten fehlende Indizes Ausgabe betrachten. Dann sehen Sie sich die Top 10 oder 20-Indizes, und führen Sie einige Analysen, um zu bestimmen, ob sie sich wirklich lohnt sich erstellen sind. In den meisten Fällen, finden Sie, dass einige, lohnt sich erstellen, werden nicht immer ist daher gerechtfertigt diese Analyse durchführen.
Bekommen kann nicht wir alles zusammen?
F: Ich bin eine von einem Team von DBAs in unser Unternehmen, die mit verschiedenen Entwicklungsteams der Anwendung behandelt. Es ist Konstante Animosity zwischen den Teams. Es handelt sich negative Auswirkungen auf die Produktionsumgebung. Haben Sie alle Anregungen zum Glätten der Beziehungen zwischen den Teams?
**A.**Dies ist ein häufiges Problem, das eine Arbeitsumgebung mit Animosity, misstrauen und Grudges unangenehmen vornehmen kann. Überhaupt nicht hilft, Produktivität und das Unternehmen leidet. Glücklicherweise dafür gibt es eine Lösung. Es ist leicht zu beschreiben, aber schwieriger, in die Praxis umsetzen:
- Sie müssen einander zu informieren. Jedes Team muss zu verstehen, des andere Teams Motivationen und ihre Meinung ihrer Grenzen verantwortlich sind. Sie werden überrascht, was jedes Team glaubt, dass das andere Team machen soll.
- Jedes Team muss die Problembereiche für die anderen Teams zu verstehen. Anonym, dabei ohne persönliche macht.
- Jedes Team muss dann informieren Sie die anderen Teams auf, wie Sie die Arbeit der anderen Teams auswirkt. Wenn z. B. der Dev Team einige Code schreibt nur mit einer kleinen Gruppe von Daten überprüft und dann über die Wand in der Produktionsumgebung--ausgelöst, und es schlägt spektakulär. Wenn das Entwicklungsteam erwartet das DBA-Team zu behandeln und beheben den Code, ist eines fehlerhaften Prozesses eindeutig.
Bestätigen und die Beschreibung des Problems ist die einzige Möglichkeit, motivieren beide Seiten arbeiten an einer Lösung, die die Arbeitsumgebung friedlichen und produktive erneut vorgenommen werden.
Umfangreicherensteigenden Indizierung
F: Ich bin ein SharePoint-Administrator, und ich weiß, dass auch eine gewisse Informationen zu SQL Server. Die SQL Server 2008, das unsere SharePoint-Datenbanken hostet hat viel Indexfragmentierung. Dies wirkt sich auf SharePoint-Leistung. Weiß ich ich nicht die Indizes ändern, aber gibt es etwas, das ich tun, kann außer dass ständig neu erstellen?
**A.**Ständig Indizes neu erstellt werden, setzt starken Auslastung auf SQL Server hinsichtlich der e/a- und CPU-Ressourcen, Generierung des Transaktionsprotokolls und möglicherweise andere Prozesse blockieren. Selbst dm_db_index_physical_stats-DMV bestimmen die fragmentierten Indizes ausgeführt wird, kann ein starker Ressourcenaufwand sein.
Viele Indizes fragmentiert in einer SharePoint-Umgebung, da SharePoint-Datenbank Schema verwendet GUID Indexschlüssel gruppiert. Meine Frau Kimberly erläutert dies in ihrem Blogbeitrag"GUIDs als Primärschlüssel und/oder den Gruppierungsschlüssel.”
Wenn ein Index hat, was im Wesentlichen einen zufälligen Schlüssel ist, wird Index Einfügungen zufällig geschehen und dazu führen, dass ein Prozess als Seitenteilung bezeichnet. Eine Seite Split Ursachen Fragmentierung, was ein kostenträchtiger verarbeiten (finden Sie in meinem Blogbeitrag"Wie teuer sind hinsichtlich des Transaktionsprotokolls Seitenteilungen?”). Eine Seitenteilung geschieht, wenn eine Seite voll ist, aber Erforderlicher Speicherplatz auf dieser Seite (tritt beispielsweise auf, wenn eine INSERT-Anweisung in einem Index mit einem zufälligen Schlüssel-Wert, der auf dieser Seite gespeichert werden muss). Eine neue Seite wird zugewiesen, und ungefähr die Hälfte der Datensätze aus der vollständigen Seite auf die neue Seite, wodurch Speicherplatz verschoben werden. Das ist der grundlegende Prozess.
Die Indizes in einer SharePoint-Datenbank kann nicht geändert werden, wie die, die die Support-Vereinbarung beeinträchtigt würde. Sie können jedoch ihre Standardfüllfaktor ändern. Beim Erstellen oder Neuerstellung eines Indexes können Sie SQL Server für eine bestimmte Menge an freiem Speicherplatz auf den Seiten des Indexes zu zufälligen Einfügungen lassen anweisen. Das bedeutet, ist es wahrscheinlicher, dass Indexseiten bereits Speicherplatz auf diese für neue Datensätze, verfügen ohne eine kostenintensive Seitenteilung. Einen Füllfaktor von 80 bedeutet, die Seiten ausgefüllt werden festlegen auf 80 % Kapazität, wenn der Index neu erstellt wird, wobei 20 Prozent freien Speicherplatz.
Dann wird die Frage, "Was ist die beste Füllfaktor?" Leider ist keine gute Antwort. Für ein Datawarehouse, in denen Daten werden nicht geändert, und es gibt keine Insert-Aktivitäten in online Transaction Processing (OLTP) ist der beste Füllfaktor in der Regel die SQL Server-Standardwert von 100 (d. h. kein freien Speicherplatz).
Für eine OLTP-Umgebung hängt die Antwort wie schnell die Fragmentierung tritt auf, und wie oft Sie es zum Entfernen der Fragmentierung neu erstellen. Es ist eine gute Idee mit 70 (30 Prozent freien Speicherplatz) starten und Überwachen der Fragmentierung, um festzustellen, ob Sie nach oben oder unten zu optimieren müssen oder Wartung mehr oder weniger häufig indizieren.
.jpg)
Paul S. Randal ist die Verwaltung von Direktor von SQLskills.com, Microsoft regional Director und ein SQL Server-MVP. Er widmete sich das SQL Server-Speichermodul Team bei Microsoft von 1999 bis 2007. Er schrieb DBCC CHECKDB/Repair für SQL Server 2005 und war bei der Entwicklung von SQL Server 2008 für das Kernspeichermodul zuständig. Paul Randal ist Experte für Notfallwiederherstellung, hohe Verfügbarkeit und Datenbankwartung und regelmäßiger Referent bei Konferenzen in aller Welt. Er bloggt auf SQLskills.com/blogs/paul und Sie können ihn auf Twitter unter twitter.com/PaulRandal finden.