SQL – Fragen und Antworten: Spurlos
Sicherungen, Wiederherstellungen und Konsistenzprüfungen sind Prozesse, die manchmal zu unerwartetem Verhalten führen können, aber sie sind sinnvoll.
Paul S. Randal
Die strenge der Wiederherstellung
F: Ich arbeite Ausfallzeiten Vorschriften für einige unserer Instanzen von SQL Server als Teil der Disaster Recovery-Planung. Ist es ausreichend, nur die Zeit betrachten, dauert es Sicherungen wiederherstellen?
**A.**Nein, es gibt ein paar andere Dinge, die Sie berücksichtigen müssen. Sehen Sie sich zuerst die Gesamtzeit, die es braucht, um alle erforderliche Sicherungen wiederherstellen. Dazu gehören Ihre neuesten vollständigen Datenbanksicherung, die neuesten differenzielle Sicherung und alle Sicherungen des Transaktionsprotokolls. Immer davon ausgehen das Worst-Case-Szenario — wo gerade vor der Einnahme der nächsten vollständigen Sicherung die Datenbank zerstört ist, so haben Sie die größtmögliche Anzahl von Protokollsicherungen.
Als nächstes sollten Sie die zusätzliche Zeit, die es dauert, um Daten und Transaktionsprotokolldateien zu erstellen, wenn sie nicht bereits vorhanden sind die erste vollständige Sicherung wiederherstellen. Wenn Sie die sofortige Dateiinitialisierung aktiviert haben, werden fast augenblicklich Datendateien erstellt werden. Die Transaktionsprotokolldatei muss jedoch NULL initialisiert werden.
Haben Sie eine große Datei, die nach oben Hunderte von Gigabyte ist, könnte eine Wiederherstellung mehrere Stunden dauern. Wenn Sie dann eine differenzielle Sicherung wiederherstellen müssen, das wird wieder vollständig Null-die Transaktionsprotokolldatei initialisieren. Sie müssen für diese Zeit zu berücksichtigen. Wenn gibt es eine weitere Transaktion Protokolldateien, die vorübergehend wurden hinzugefügt (aber nicht entfernt) müssen Sie 0 (null)-diese auch initialisieren — möglicherweise zweimal.
Die letzte Phase des Wiederherstellungsvorgangs Datenbank ist zur Wiederherstellung nach eine Systemabsturz führen. Die benötigte Zeit für das wird davon abhängen, wie viele Transaktionsprotokolleinträge Sie benötigen einen Rollback. Sie sind Teil von Transaktionen ohne Commit zum Zeitpunkt der letzten Protokollsicherung. Wenn Sie langlebige Transaktionen in Ihrer Datenbank haben, nehmen Sie das Schlimmste an. Vorausgesetzt, dass Sie fast alle längste mögliche Transaktionen ein Rollback. Sie müssen die Gleichung dieser Zeit hinzu.
Schließlich auch prüfen Sie, wie lange es dauert, den physischen Server, an den Punkt gelangen, wo Sie beginnen können Sie Sicherungen wiederherstellen. Mit anderen Worten, wie lange dauert es den Booten (POST, Arbeitsspeicher Überprüfungen ausgeführt und so weiter) und starten Sie Windows-Server? Dies könnte auch die Ausfallzeit hinzufügen.
Bedenkt man all diese Dinge in ihrer schlimmsten Fälle geben, die Ihnen eine maximale mögliche Ausfallzeiten. Sie könnten überrascht sein, wenn Sie alles summieren.
Unterbrechen Sie nicht
F: Vor kurzem stieß ich auf ein interessantes Problem. Ich versuchte, einen DBCC CHECKDB-Prozess zu unterbrechen, der länger als üblich war. Ich fand, ich könnte nicht unterbrechen und musste warten, eine lange Zeit für den Prozess zu beenden. Können Sie erklären, was geschah?
**A.**Dieses Verhalten ist, aber nicht intuitiv überhaupt erwartet. Wenn DBCC CHECKDB gestartet wird, erstellt er einen versteckten Datenbanksnapshot. Der Datenbanksnapshot wird benötigt, um DBCC CHECKDB mit Blick auf die Datenbank transaktionell konsistent, unveränderlichen bieten. Auf diese Weise weiß DBCC CHECKDB, dass es die Konsistenz einer statischen Datenbank überprüft, die Beschädigungen nicht haben sollte.
Der Prozess erstellt einen Datenbanksnapshot von ersten Checkpoints der Datenbank. Dann wird die leere Datenbank-Momentaufnahme und Transaktionslog der Datenbank Crash-Recovery auf der Datenbanksnapshot ausgeführt verwendet. Mit anderen Worten, es aktiven Transaktionen ein Rollback in der Datenbanksnapshot tatsächlich ohne die eigentliche Datenbank. So wird der Datenbanksnapshot transaktionell konsistent.
Die Zeit, die es braucht, Crash-Recovery ausgeführt, während die Datenbankmomentaufnahme erstellen proportional zur Menge und Länge der Transaktionen ohne Commit in der Datenbank beim Starten des Datenbanksnapshots ist. Wenn eine lang andauernde Transaktion vorhanden ist, kann es Rollback für eine lange Zeit dauern. Dies bedeutet, dass die Schaffung der Datenbanksnapshot und DBCC CHECKDB-Prozess dauert länger.
In extremen Fällen wenn die Datenbankmomentaufnahme erstellen wesentlich länger als normal dauert und Sie entscheiden, den DBCC CHECKDB-Prozess beenden passiert sofort nichts. Sie müssen warten, bis die Datenbank Snapshot Absturzreparatur abschließen, bevor der Prozess mit dem Kill Signal reagiert. Wiederherstellung nach einem Systemabsturz kann nicht unterbrochen werden, und es gibt keine Unterscheidung in den Absturz Wiederherstellungs-Code in SQL Server zwischen echten Crash-Recovery nach einem unerwarteten Herunterfahren und Wiederherstellung nach einem Systemabsturz für einen Datenbanksnapshot.
Die einzige alternative ist in diesem Fall die Instanz von SQL Server neu starten, wodurch den versteckten Datenbanksnapshot entfernt wird. Dies funktioniert nicht bei regulären Datenbankwiederherstellung real Absturz. In diesen Fällen wird Absturzreparatur weiter, nachdem eine Instanz neu starten.
Es gibt mehrere Möglichkeiten, die Sie in diesem Szenario vermeiden können. Versuchen Sie, nur die DBCC CHECKDB ausgeführt, wenn Sie wissen, dass es gibt keine lang andauernden Transaktionen in der Datenbank aktiv sind. Sie müsste wieder im Rahmen der Erstellung des DBCC CHECKDB versteckte Datenbanksnapshots diese gerollt haben. Sie können auch einen Konsistenzüberprüfung Mechanismus, der zum Wiederherstellen der Datenbank auf einen anderen Server ist und dann die Konsistenzprüfung der wiederhergestellten Kopie. Dies vermeidet die Möglichkeit einer lange andauernden Transaktionen insgesamt.
Zum richtigen Zeitpunkt zu finden
F: Letzte Woche hatte ich zum Wiederherstellen von Sicherungen, um einer Tabelle versehentlich gelöscht hatte jemand zu retten. Die Standardablaufverfolgung verlor bereits Informationen über, wenn die Tabelle gelöscht wurde, so war es ein langwieriger Prozess, die Sicherung Position zu finden, auf die ich brauchte, um wieder herzustellen. Gibt es eine Möglichkeit, den richtigen Punkt finden in der Zeit, dem ich wiederherstellen soll?
**A.**Jeder Zeit, die Sie versuchen zu bestimmen, wann eine Tabelle gelöscht wurde, überprüfen Sie die Standardablaufverfolgung. Das macht die Kenntnis (Data Definition Language, Datendefinitionssprache). Lesen Sie mehr über die Standardablaufverfolgung auf SQL Server-Onlinedokumentation.
Das einzige Problem mit Standardablaufverfolgung ist, dass es eine endliche Größe. Es ist auch zu Gunsten der Extended Events in SQL Server 2012 veraltet. Also könnte gibt es eine Menge Aktivität auf dem Server, die Bilanz der wenn die Tabelle gelöscht wurde nicht in der Ablaufverfolgung nicht mehr vorhanden.
Das bedeutet, der einzige Weg zu finden, wenn die Tabelle gelöscht wurde ist zu tun, nenne ich "durch das Transaktionsprotokoll Tippbetrieb." Wiederherstellen einer Kopiedes der Datenbank auf einen Zeitpunkt, wann die Tabelle bekannt war, zu existieren. Dann wiederholt führen Sie Point-in-Time-Wiederherstellung mithilfe der WITH STOPAT und WITH STANDBY aus. Verschieben Sie leicht nach vorn, in der Zeit jedes Mal. Wenn Sie die Zeit finden, wenn die Tabelle nicht mehr vorhanden ist, stellen Sie die Datenbank nur bis dahin und Sie können die Daten der Tabelle abrufen.
Dieser Prozess ist sehr langwierig und kann sehr lange dauern. Jedes Mal, wenn Sie die Datenbank mithilfe von wiederherstellen WITH STANDBY, werden alle Transaktionen ohne Commit an diesem Punkt in eine Undo-Datei zurückgesetzt. Die nächste Wiederherstellung im Prozess macht das rückgängig zu machen, stellt ein kleines bisschen mehr, und wieder Rollback für Transaktionen in der Rückgängigdatei. Sie müssen diesen Vorgang wiederholen, bis Sie die richtige Uhrzeit finden.
Es gibt eine ordentliche alternative Weise, dies zu tun. Alysieren Sie die Datensätze in die Transaktionsprotokollsicherungen Transaktionen aufgerufen DROPOBJ suchen an. Hierzu eine undokumentierte Tabellenfunktion aufgerufen Fn_dump_dblog. Dies verhält sich genauso wie die bekanntesten Fn_dblog, die Müllkippen Datensätze aus einer aktive Transaktionsprotokoll arbeitet gegen eine Datenbanksicherung zu protokollieren.
Diese Funktion können Sie um die Transaktion zu finden, die das Objekt gelöscht, in dem Sie sich interessieren. Dann können Sie der Transaktion Log Sequence Number (oder LSN) zum Ausführen einer Wiederherstellungs mit STOPBEFOREMARK = ' Lsn: < die LSN der Transaktion >'. Dies wird das Transaktionsprotokoll bis zu wiederherstellen, aber nicht einschließlich die Transaktion, die die Tabelle gelöscht. Auf diese Weise erspart Ihnen auf "Zoll durch das Protokoll," wie oben beschrieben. Erfahren Sie mehr über diese Funktion und wie man es benutzt auf meinem Blog.
Ereignisfilterung
F: Nun, da die SQL-Ablaufverfolgung in SQL Server 2012 eingestellt wurde, möchte ich mehr über Extended Events zu verstehen. Können Sie erklären, wie Extended Events einfacher als die SQL-Ablaufverfolgung werden sollen?
**A.**Der Hauptgrund für die Leistung zwischen den beiden Mechanismen ist wie Ereignisse gefiltert werden. Wenn Sie eine Ablaufverfolgung oder Event-Sitzung definieren, können Sie Ereignisse in beiden Fällen auf der Grundlage verschiedener Kriterien der Veranstaltung filtern. Tätigkeit in einer bestimmten Datenbank Filtern ist ein gutes Beispiel dafür.
Mit SQL-Ablaufverfolgung werden Ereignisse ständig generiert. Der Ereignisconsumer wird die Filterung. Dies bedeutet, dass SQL Server mit Generieren von allen Ereignissen, aufgebürdet werden, obwohl einige wird nicht verzehrt werden. Dieser Prozess ist sehr ineffizient.
Mit Extended Events führt das innerhalb von SQL Server Extended Events-Modul Ereignisfilterung. Das Extended Events-Modul wertet die Prädikate angegeben, wenn die Sitzung definiert wurde. Das heißt, wenn das Ereignis ausgelöst wird, sind nur minimale Arbeitsschritte erforderlich Basisereignis Daten sammeln. Auf diese Weise können das Events-Modul, das Prädikat zu bewerten. Wenn das Prädikat zu False ausgewertet wird, wird das Ereignis sofort verworfen. Das Events-Modul führt ohne weitere Verarbeitung. Dies minimiert den Leistungsaufwand von Sammeln von Ereignissen im Vergleich zu SQL-Ablaufverfolgung.
Auch die SQL-Ablaufverfolgung sammelt alle Spalten mit einem Ereignis verknüpft und verwirft alle Spalten nicht erforderlich. Erweiterte Ereignisse auf der anderen Seite nur sammelt Spalten und andere Daten angegeben. Weiter minimiert den Aufwand zum Auslösen eines Ereignisses.
Zwar Extended Events einen weit überlegenen Mechanismus für das Sammeln von Daten zur Problembehandlung, kann es noch die SQL Server-Leistung beeinträchtigen, wenn die Sitzung ist nicht sorgfältig konstruiert. Wenn eine Ereignissitzung erfordert die Herstellung eines T-SQL-Aufruf-Stacks, jedes Mal, wenn ein sehr häufiges Ereignis geschieht (z. B. eine Sperre oder ein Thread warten zu erwerben), wird dies natürlich die Leistung beeinträchtigen.
Mit beiden Mechanismus sollten Sie testen, Ereignisauflistung vor der Umsetzung in die Produktion. Sie müssen sicherstellen, dass Arbeitsauslastungsleistung wird nicht gefährdet werden.
.jpg)
Paul S. Randal ist der Geschäftsführer der SQLskills.com, Microsoft regional Director und ein 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.