Dieser Artikel wurde maschinell übersetzt.
SQL Q & A: Geschwindigkeit und Größe spielen eine Rolle
Die relative Geschwindigkeit von SQL Server-Abfragen und die Größe der Datendateien und Transaktionsprotokolle scheinen die wichtigsten Leistungsfaktoren zu sein.
Paul S. Randal
Planen Sie Ihre Abfrage
F: Wir hatten vor kurzem ein Problem mit einer Abfrage, die eine Weile ausgeführt wurde unter. Die Abfrage liefen schneller, nachdem wir den gruppierten Index für die Tabelle neu erstellt, die es beteiligt. Ich konnte nicht sehen, alle Scans im Abfrageplan, also warum Fragmentierung würde haben beeinträchtigt die Query-Laufzeit?
**A.**In diesem Fall scheint es, dass Indexfragmentierung nichts zu tun mit dem Query-Laufzeit gehabt. Ein nicht optimale Abfrage-Plan war wahrscheinlich die Ursache des Problems.
Wenn Sie eine Indexneuerstellung tun, werden alle Spaltenstatistiken für diesen Index automatisch neu erstellt. Es ist das Äquivalent eines vollständigen Scans. Alle Spaltenwerte gelten, Erstellung der Statistik, so es eine vollständige Darstellung der gemeinsamen Wert-Verteilung schafft.
Alle Abfragepläne mit diesen Statistiken erstellt werden im wesentlichen ungültig und werden erneut kompiliert. Kompilieren eines Plans bedeutet das nächste Mal, wenn Sie eine Abfrage ausführen, der Abfrageoptimierer wird durch den Prozess der Auswahl einer neuen, mehr optimalen Weise des Produzierens der Abfrageergebnisse. Dies ist der Abfrageplan.
In diesem Fall Ihre Indexneuerstellung ausgelöst eine erneute Kompilierung Abfrage-Plan. Der neue Plan war mehr optimal als die vorherige. Es gibt eine Reihe von möglichen Gründen. Schlechter Leistung Abfrageplan hätte sehr optimal und erlaubte schnelle Abfragen beim Uraufführung kompiliert. Wie die Verteilung der Datenwerte innerhalb der Tabelle, die im Laufe der Zeit geändert hätte der Abfrageplan weniger optimale werden können.
Alte Abfrageplan konnte einen nicht gruppierten Index verwendet haben, eine bestimmte Spalte (Teil von der nicht gruppierte Index) sehr selektiv war. Daher war es sinnvoll, den nicht gruppierten Index verwenden, um Datenwerte zu finden und dann weitere Spalten aus der Tabelle selbst. Einen Schlüssel Suchvorgang wird genannt.
Wenn die Datenverteilung drastisch geändert, so dass die Spalte nicht mehr hochselektive war, könnte dies eine große Anzahl von teuren Schlüssel suchen verursacht haben. In Anbetracht der neuen Datenverteilung ein besserer Plan wäre gewesen, einen anderen nicht gruppierten Index zu verwenden.
Wenn der gruppierte Index neu erstellt wurde, wurden die Statistiken aktualisiert. Dies verursacht eine Neukompilierung der Plan, die selektiver nicht gruppierten Indexes entschieden haben. Daraus ergab sich wiederum um einen effizienteren Plan.
Während ich über die Ursache der Beschleunigung Abfrage Wassertheorie bin, können Sie sehen, was ich über die Indexneuerstellung einfach als Auslöser für Plan Neukompilierung bedeuten. Es könnte nicht direkt die Hauptursache für das Performance-Problem in erster Linie behoben haben.
Weitere Dateien, mehr Platz
F: Ich habe eine Dateigruppe mit zwei Dateien, und beide sind sehr voll. Ich möchte etwas mehr Platz in die Dateigruppe hinzufügen, so werde ich zwei weitere Dateien hinzufügen und dann noch SQL Server die Daten über alle vier Dateien auszugleichen. Ist das möglich?
**A.**Leider gibt es keine gute Möglichkeit, Daten in Dateien in der Dateigruppe auszugleichen, nach dem Hinzufügen neuer Dateien für zusätzlichen Platz. Gebloggt habe ich in der Vergangenheit über wie mehr als eine Datei pro Dateigruppe zu Leistungssteigerungen für einige Arbeitsauslastungen führen können. Es ist allgemein bekannt, dass dies der Fall ist.
Das ist eine große Verallgemeinerung, though. Wie viel Gewinn Sie erzielen werde hängt von der i/o-Subsystem, das Datenlayout-Datei und die Arbeitsauslastung ab. Gibt es ein Punkt, an dem die Anzahl der Datendateien wird zu viele und ist eigentlich eine Leistung zum Nachteil. Schauen Sie sich diese Blog-Posts auf benchmarking mehrerer Datendateien und mehrere Datendateien auf Solid-State-Laufwerke (SSDs).
SQL Server muss nicht einfach einen ausgleichenden Mechanismus für Daten in einer Dateigruppe. Die Datendatei, woher die nächste Zuteilung kommen, bestimmt Roundrobin-Zuweisung und proportional füllen. Round-Robin ist wo Zuweisungen aus jeder Datendatei wiederum geschehen. Gibt es eine Zuordnung von eine Datei, und dann eine Zuweisung aus Datei zwei, dann zurück zu eine Datei wieder. Allerdings sind die Zuweisungen in anteilig geleistet. Weitere Zuordnungen erfolgen aus Datendateien, die proportional mehr als andere Dateien in der Dateigruppe Speicherplatz.
Der Grundgedanke des proportionale ist, dass jede Datei eine Gewichtung, wo Dateien mit weniger freien Speicherplatz eine höhere Gewichtung haben. Dateien mit sehr viel freien Platz haben eine geringere Gewichtung. Die Dateien mit geringeren Gewichtungen werden aus häufiger, was bedeutet diese Dateien mit mehr freiem Speicherplatz zugeteilt werden von den meisten.
All dies bedeutet, dass beim Hinzufügen neuer Dateien zu einer vollständigen Dateigruppe nachfolgende Zuweisungen vor allem aus den neuen Dateien kommen. Sie haben viel niedrigere Proportional-füllen-Gewichtung als die älteren Dateien, die von Natur aus mehr Daten haben. Die neuen Dateien werden Zuweisung-Hot-Spots, zu potenziell geringere Gesamtleistung mit einige Arbeitsauslastungen.
Den proportionale Algorithmus kann nicht umgangen werden. Noch können Sie die Gewichtung ändern. Auch nur zu versuchen so etwas wie Neuerstellen von Indizes in der Dateigruppe wird nicht funktionieren, werden als die Zuweisungen für die neuen Indizes aus den neuen Datendateien kommen.
Wenn Sie eine Dateigruppe weitere Dateien hinzufügen möchten, ist der beste Weg, eine neue Dateigruppe mit mehr Dateien zu erstellen. Dann verschieben Sie die Tabelle und Index-Daten in die neue Dateigruppe mit der CREATE INDEX... MIT (DROP_EXISTING = ON) Befehl, die neue Dateigruppe als Zielspeicherort angeben. Nachdem Sie alle Daten verschoben haben, können Sie die alte, leere Dateigruppe löschen. Sie können sogar LOB-Daten in die neue Dateigruppe zu verschieben, mit einigen Trick von Kimberly Tripp.
Löschen Sie das Protokoll
F: Vor kurzem hatte ich ein Problem mit einer Transaktionsprotokolldatei, die sehr große wuchs. Ich habe nicht in der Lage, es zu verkleinern. Können Sie vorschlagen, einige Dinge für mich zu überprüfen?
**A.**Es gibt zwei häufige Ursachen für eine Datenbank-Konsistenzüberprüfung (DBCC) SHRINKFILE auf das Transaktionsprotokoll nicht korrekt funktioniert. Als seitliche Anmerkung vorstellen nicht Verkleinern einer Protokolldatei Indexfragmentierung nachteilig auf die Leistung auswirken, in der Weise, die ein Daten-Datei-schrumpfen wird. Allerdings sollte es noch eine seltene Operation sein.
Eine Protokolldatei verkleinert werden einfach entfernt, die inaktiv oder derzeit ungenutzten Teile der Transaktion am Ende die Transaktionsprotokolldatei zu melden. Diese "Teile" des Transaktionsprotokolls werden als virtuelle Protokolldateien (VLFs) bezeichnet. Es gibt zwei Probleme, die Sie verhindern können, VLFs zu verkleinern: nicht auf der Bühne des eigentlichen Vorgangs, der VLFs inaktiv werden kann, und nicht inaktiv VLFs am Ende des Transaktionsprotokolls.
VLFs inaktiv mit einem Prozess namens "Löschen des Protokolls". Hierzu können Sie mit einem Checkpoint wenn das einfache Wiederherstellungsmodell verwenden. Sie können dies mit einer Transaktionsprotokollsicherung auch wenn die vollständigen oder massenprotokollierten Wiederherstellungsmodell verwendet. Solange die Transaktionsprotokoll-Datensätze in die VLFs SQL Server in keiner Weise erforderlich sind nicht, machen Sie die VLFs inaktiv.
SQL Server kann noch verlangen das Protokoll zeichnet für bestimmte Situationen, wie z. B. Wenn sie sind Teil einer lang andauernde Transaktion, wenn sie noch nicht durch die Replikation Protokolllese-Agent-Auftrag gescannt worden oder sind sie gerade auf einen Datenbankspiegel oder Availability Group Replikat gesendet. Sie können SQL Server Fragen, warum ein bestimmtes Transaktionsprotokoll "klar wird nicht" mithilfe des folgenden Befehls:
SELECT [log_reuse_wait_desc] FROM sys.databases WHERE [name] = N'MyDBName';
Verwenden Sie die Ausgabe dieses Befehls als Indikator für was als nächstes zu tun. Sobald das Transaktionsprotokoll zu löschen kann wenn DBCC SHRINKFILE nicht noch verkleinern, das Protokoll ist, bedeutet dies, dass es nur der derzeit aktiven VLF (bzw. dem VLFs) verkleinern konnte. Dies können passieren, in der Mitte der Transaktionsprotokolldatei werden. In diesem Fall führen Sie den Protokoll-Clearing-Vorgang erneut, und dann eine weitere Verkleinerung.
Möglicherweise müssen Sie dies einige Male zu tun, und letztlich ist es eventuell schwierig oder unmöglich, das Transaktionsprotokoll auf die minimale Größe auf einer belebten Produktionsdatenbank zu verkleinern. Allerdings sollten diese gemeinsame Probleme Hilfe, die Sie verkleinern die Transaktion genug zufrieden sein Protokolldatei. Lesen Sie mehr über diese Themen in meinem Februar-2009 TechNet Magazin Artikel, "Verständnis Protokollierung und Wiederherstellung in SQLServer."
I/o-Integrität
F: Ich sehe immer Nachrichten im Fehlerprotokoll eines meiner SQL Server-Instanzen wieder i/OS, die mehrfach versucht werden, bevor sie erfolgreich sein. Das sieht mir bedrohlich. Können Sie erklären, was bedeuten die Meldungen?
**A.**Diese Meldungen sind Instanzen von Message 825. Diese Nachricht wurde in SQL Server 2005 eingeführt. Es ist eine frühzeitige Warnung, dass Ihre i/o-Subsystem Integritätsprobleme hat.
Wenn SQL Server gibt eine lesen I/O und die I/O scheitert (entweder das OS weist SQL Server die i/o ist fehlgeschlagen, oder vom Betriebssystem zurückgegebene Daten von SQL Server als fehlerhaft beurteilt werden), wird SQL Server den Lesevorgang noch viermal wiederholen, um festzustellen, ob einer von ihnen gelingen wird. Die Voraussetzung hierfür ist, dass manchmal i/o Subsystemen vorübergehenden Fehler, also erneuter Versuch eine fehlgeschlagene e/a auf ein anschließender Versuch funktioniert. Dies vermeidet die sofortige Möglichkeit der Ausfallzeit.
Wenn keines der Wiederholungsversuche erfolgreich, SQL Server löst einen Fehler 823 oder 824, und die Verbindung ist unterbrochen (wie diese Fehler schwere 24). Wird es die Wiederholungsversuche gelingt, die Arbeitsbelastung weiter als normal und SQL Server schreibt die 825 Meldung in das Fehlerprotokoll.
Die 825-Nachricht hat das folgende Format:
Msg 825, Level 10, State 2, Line 1.
Dies bedeutet eine Lesen der Datei "J:\SQLskills\MyDatabase_DF1. NDF"bei Versatz 0 × 000004AA188000 gelang es, nachdem es nicht einmal mit Fehler: Falsche Prüfsumme (erwartet: 0 × 33d1d136; tatsächliche: 0 × 0a844ffd). Weitere Informationen finden möglicherweise zusätzliche Fehlermeldungen im SQL Server Fehler protokollieren und System-Ereignisprotokoll.
Diese Fehlerbedingung Datenbankintegrität und du musst die Situation zu korrigieren. Führen Sie eine vollständige DBCC CHECKDB. Dieser Fehler kann durch viele Faktoren verursacht werden. Weitere Informationen finden Sie unter SQL Server-Onlinedokumentation. Was ist es wirklich sagen, dass das i/o-Subsystem, zum Scheitern verurteilt gestartet wird ist. Eine vergleichbare Einrichtung existiert im Exchange Server, wo die Idee für diesen Mechanismus entstanden.
Obwohl diese Funktion nützlich ist, ist die 825 Botschaft nur Schweregrad 10 (d.h. informative). Es sei denn, Sie sind auf der Suche durch die Fehlerprotokolle oder ein Agent-Alert-Meldung 825 eingerichtet haben, können diese kritischen Nachrichten unbemerkt. Dennoch sollten Sie eine Warnung für 825-Nachrichten festlegen und Maßnahmen zu ergreifen, sobald eine Nachricht lesen-Retry passiert haben. Lesen Sie mehr über diese Nachricht und eine Warnung einrichten, um es zu fangen, in diesem Blog-post.
.jpg)
Paul S. Randal ist der Geschäftsführer der SQLskills.com, Microsoft regional Director und SQL Server MVP. Er arbeitete an der SQL Server-Speicher-Engine-Team bei Microsoft von 1999 bis 2007. Er schrieb DBCC CHECKDB/Repair für SQL Server 2005 und war verantwortlich für das Kernspeichermodul während der Entwicklung von SQL Server 2008. Randal ist Experte für Disaster Recovery, hohe Verfügbarkeit und Datenbankwartung und ein regelmäßiger Referent auf Konferenzen weltweit. Er Blogs auf SQLskills.com/blogs/paul, und Sie finden ihn auf Twitter bei twitter.com/PaulRandal.