Sqlserver
 sql >> Datenbank >  >> RDS >> Sqlserver

Bedeutung des Transaktionsprotokolls in SQL Server

Transaktionsprotokolle sind ein wesentlicher und wichtiger Bestandteil der Datenbankarchitektur. In diesem Artikel besprechen wir SQL Server-Transaktionsprotokolle, ihre Bedeutung und ihre Rolle bei der Datenbankmigration.

Einführung

Lassen Sie uns über verschiedene Optionen zum Erstellen von SQL Server-Sicherungen sprechen. SQL Server unterstützt drei verschiedene Sicherungstypen.
1. Voll
2. Differential
3. Transaktionsprotokoll

Bevor wir uns mit Transaktionsprotokollkonzepten befassen, lassen Sie uns andere grundlegende Sicherungstypen in SQL Server besprechen.

Ein vollständiges Backup ist eine Kopie von allem. Wie der Name schon sagt, wird alles gesichert. Es sichert alle Daten, jedes Objekt der Datenbank wie Dateien, Dateigruppen, Tabellen usw.:– Eine vollständige Sicherung ist eine Basis für alle anderen Arten von Sicherungen.

Eine differenzielle Sicherung sichert Daten, die sich seit der letzten vollständigen Sicherung geändert haben.

Die dritte Option ist eine Transaktionsprotokollsicherung, die alle Anweisungen, die wir an die Datenbank ausgeben, im Transaktionsprotokoll protokolliert. Das Transaktionsprotokoll ist ein Mechanismus, der als „WAL“ (Write-Ahead-Logging) bekannt ist. Es schreibt alle Informationen zuerst in das Transaktionsprotokoll und dann in die Datenbank. Mit anderen Worten, der Prozess aktualisiert die Datenbank normalerweise nicht direkt. Dies ist die einzige vollständig verfügbare Option mit dem vollständigen Wiederherstellungsmodell der Datenbank. Bei anderen Wiederherstellungsmodellen sind die Daten entweder unvollständig oder das Protokoll enthält nicht genügend Daten. Beispielsweise enthält der Protokolldatensatz beim Aufzeichnen des Starts einer neuen Transaktion (der LOP_BEGIN_XACT-Protokolldatensatz) die Zeit, zu der die Transaktion gestartet wurde, und die LOP_COMMIT_XACT- (oder LOP_ABORT_XACT)-Protokolldatensätze zeichnen die Zeit auf, zu der die Transaktion festgeschrieben (oder abgebrochen) wurde.

Um Interna des Online-Transaktionsprotokolls zu finden, können Sie die Funktion sys.fn_dblog abfragen.

Die Systemfunktion sys.fn_dblog akzeptiert zwei Parameter, erstens die Start-LSN und die End-LSN der Transaktion. Standardmäßig ist es auf NULL gesetzt. Wenn es auf NULL gesetzt ist, werden alle Protokolldatensätze aus der Transaktionsprotokolldatei zurückgegeben.

USE WideWorldImporters
GO
SELECT [Current LSN],
[Operation],
[Transaction Name],
[Transaction ID],
[Log Record Fixed Length],
[Log Record Length]
[Transaction SID],
[SPID],
[Begin Time],
*
FROM fn_dblog(null,null)

Wie wir alle wissen, werden die Transaktionen im Binärformat und nicht in einem lesbaren Format gespeichert. Um die Offline-Transaktionsprotokolldatei zu lesen, können Sie fn_dump_dblog.

verwenden

Lassen Sie uns die Transaktionsprotokolldatei abfragen, um zu sehen, wer das Objekt mit fn_dump_dblog abgelegt hat.

SELECT [Current LSN], [Operation], [Transaction Name], [Transaction ID], SUSER_SNAME ([Transaction SID]) AS DBUser
FROM fn_dump_dblog (
NULL, NULL, N'DISK', 1, N'G:\BKP\AdventureWorks_2016_log.trn',
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT)
WHERE
Context IN ('LCX_NULL') AND Operation IN ('LOP_BEGIN_XACT')
AND [Transaction Name] LIKE '%DROP%'

Wir werden die Funktion fn_dblog() verwenden, um den aktiven Teil des Transaktionsprotokolls zu lesen, um Aktivitäten zu finden, die an den Daten ausgeführt werden. Sobald das Transaktionsprotokoll gelöscht ist, müssen Sie die Daten aus einer Protokolldatei mit fn_dump_dblog() abfragen.

Diese Funktion stellt das gleiche Rowset wie fn_dblog() bereit, verfügt jedoch über einige interessante Funktionen, die sie in einigen Problembehandlungs- und Wiederherstellungsszenarien nützlich machen. Insbesondere kann es nicht nur das Transaktionsprotokoll der aktuellen Datenbank lesen, sondern auch Transaktionsprotokollsicherungen auf Platte oder Band.

Führen Sie die folgende Abfrage aus, um die Liste der Objekte abzurufen, die mithilfe der Transaktionsdatei gelöscht werden. Zunächst werden die Daten in die temporäre Tabelle ausgegeben. In einigen Fällen dauert die Ausführung von fun_dump_dblog() etwas länger. Daher ist es besser, die Daten in der temporären Tabelle zu erfassen.

Führen Sie die folgende Abfrage aus, um eine Objekt-ID aus der Spalte Sperrinformationen abzurufen.

SELECT * INTO TEMP
FROM fn_dump_dblog (
NULL, NULL, N'DISK', 1, N'G:\BKP\AdventureWorks_2016_log.trn',
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT)
WHERE
[Transaction ID] in(
SELECT DISTINCT [Transaction ID]
FROM fn_dump_dblog (
NULL, NULL, N'DISK', 1, N'G:\BKP\AdventureWorks_2016_log.trn',
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT)
WHERE
[Transaction Name] LIKE '%DROP%')
and [Lock Information] like '%ACQUIRE_LOCK_SCH_M OBJECT%'

Führen Sie die folgende Abfrage aus, um eine Objekt-ID aus der Spalte Sperrinformationen abzurufen.

SELECT DISTINCT [Lock Information],PATINDEX('%: 0%', [Lock Information])+4,(PATINDEX('%:0%', [Lock Information])-PATINDEX('%: 0%', [Lock Information]))-4,
Substring([Lock Information],PATINDEX('%: 0%', [Lock Information])+4,(PATINDEX('%:0%', [Lock Information])-PATINDEX('%: 0%', [Lock Information]))-4) objectid
from temp

Die object_id kann gefunden werden, indem der Wert der Sperrinformationsspalte manipuliert wird. Um den Objektnamen für die entsprechende Objekt-ID zu finden, stellen Sie die Datenbank aus der Sicherung wieder her, bevor die Tabelle gelöscht wurde. Nach der Wiederherstellung können Sie die Systemansicht abfragen, um den Objektnamen zu erhalten.

USE AdventureWorks2016;
GO
SELECT name, object_id from sys.objects
WHERE object_id = '1815677516';

Lassen Sie uns nun die verschiedenen Formen derselben Transaktionsdetails mit sys.dn_dblog, sys.fn_full_dblog sehen. Die Systemfunktion fn_full_dblog funktioniert nur mit SQL Server 2017.

Abfrage zum Abrufen der Top-10-Transaktionen mit fn_dblog.

SELECT TOP 10 * FROM sys.fn_dblog(null,null)

Ab SQL Server 2017 können Sie fn_full dblog.

verwenden 
SELECT TOP 10 * FROM sys.fn_full_dblog(null,null,DB_ID(),null,null,null,null,NULL)

Mit sp_helptext fn_full_dblog.

können Sie sich weiter mit der Systemfunktion befassen

Als nächstes fragen Sie die Sicherungsdatei mit der Systemfunktion mit fn_full_dblog ab. Auch dies gilt erst ab SQL Server 2017.

Wiederherstellung zu einem bestimmten Zeitpunkt

Nehmen wir an, Sie haben die Liste der gesamten Protokollsicherung, und wenn Sie beabsichtigen, die Protokolle wiederherzustellen, haben Sie die Möglichkeit, eine Point-in-Time-Wiederherstellung der Daten durchzuführen. Bei der Protokollwiederherstellung müssen Sie also nicht unbedingt alle Daten wiederherstellen, Sie können sie direkt vor, vor oder nach einer einzelnen Transaktion wiederherstellen. Wenn also die Datenbank zu einem bestimmten Zeitpunkt abstürzt und wir sowohl vollständige Sicherungen als auch Protokollsicherungen haben, sollten wir in der Lage sein, zuerst die vollständige Sicherung und dann die Protokollsicherung wiederherzustellen und dabei das letzte Protokoll bis zu einem bestimmten Zeitpunkt wiederherzustellen , und das würde die Datenbank in genau dem Zustand belassen, in dem sie sich befand, bevor dieses Problem auftrat.

Protokollsicherungen sind ziemlich häufige VLDB (Very Large Database) und die wichtigsten Datenbanken. Es wird immer empfohlen, den Wiederherstellungsprozess zu testen. Wann immer Sie Datenbanksicherungen durchführen, ist es ratsam, gut über den Wiederherstellungsprozess nachzudenken, und Sie sollten den Wiederherstellungsprozess immer öfter testen.

Es ist immer gut, den Wiederherstellungsprozess von Zeit zu Zeit zu testen, also stellen Sie einfach sicher, dass der Prozess die Backups normal durchläuft.

Szenarien

Lassen Sie uns über ein Szenario sprechen, in dem Sie eine sehr große Datenbank wiederherstellen müssen und wir alle wissen, dass dies normalerweise mehrere Stunden dauern kann, und das ist etwas, dessen sich jeder bewusst sein sollte. Wenn Sie eine Datenbankmigration ohne Datenverlust und mit kleineren Ausfallfenstern planen, könnte dies immer noch ein ziemlich großes Problem darstellen. Verlassen Sie sich also auf die Sicherung des Transaktionsprotokolls, um den Vorgang zu beschleunigen.

Betrachten wir ein anderes Szenario, in dem Sie eine parallele Datenbankmigration zwischen zwei verschiedenen Versionen von SQL Server durchführen. Sie sind an der Migration der Datenbank auf dieselbe Softwareversion auf dem Ziel beteiligt, und dazu gehört die Übertragung von Betriebssystem, Datenbank, Anwendung und Netzwerk usw.:-; Migrieren der Datenbank von einem Hardwareteil zu einem anderen; Änderung von Software und Hardware. Der Prozess der Datenbankmigration ist immer eine Herausforderung, bei der Datenverlust immer möglich ist und der Umgebung ausgesetzt ist.

Best Practices für die Datenbankmigration

Lassen Sie uns die Standardpraktiken des Datenbankmigrationsmanagements besprechen.

Die Migration muss transaktional erfolgen, um Inkonsistenzen in den Daten zu vermeiden. Die üblichen Schritte des Migrationsprozesses sind herkömmlicherweise die folgenden:

  • Beenden Sie den Anwendungsdienst – hier beginnt die Ausfallzeit
  • Log-Sicherung einleiten, es hängt von Ihren Anforderungen ab
  • Versetzen Sie die Datenbank in den Wiederherstellungsmodus, sodass keine weiteren Änderungen an der Datenbank vorgenommen werden
  • Verschieben Sie die Protokolldatei(en)
  • Stellen Sie die Datenbank-Transaktionsprotokolldatei(en) wieder her – vorausgesetzt, Sie haben bereits die vollständige Datenbanksicherung auf dem Ziel wiederhergestellt und belassen die Datenbank im Wiederherstellungsstatus.
  • Klonen Sie die Anmeldungen und reparieren Sie die verwaisten Benutzer
  • Jobs erstellen
  • Installieren Sie die Anwendung
  • Netzwerk konfigurieren – DNS-Einträge ändern
  • Anwendungseinstellungen neu konfigurieren
  • Anwendungsdienst starten
  • Testen Sie die Anwendung

Erste Schritte

In diesem Artikel besprechen wir, wie die Migration sehr großer OLTP-Datenbanken gehandhabt wird. Wir werden Strategien zur Verwendung von SQL-Server-Techniken und Tools von Drittanbietern für die Datensicherheit zusammen mit null oder minimaler Unterbrechung der Verfügbarkeit des Produktionssystems erörtern. Während des Vorgangs besteht immer die Möglichkeit, dass die Daten verloren gehen. Halten Sie die reibungslose Abwicklung von Transaktionen für eine gute Strategie? Wenn „Ja“, was sind Ihre bevorzugten Optionen?

Sehen wir uns die verfügbaren Optionen genauer an:

  • Sichern und Wiederherstellen
  • Protokollversand
  • Datenbankspiegelung
  • Tools von Drittanbietern

Sichern und Wiederherstellen

Die Backup-and-Restore-Datenbanktechnik ist die praktikabelste Option für jede Datenbankmigration. Wenn es richtig geplant und getestet wird, werden wir viele unvorhergesehene Migrationsfehler vermeiden. Wir alle wissen, dass die Sicherung ein Online-Prozess ist. Es ist einfach, die Sicherung des Transaktionsprotokolls rechtzeitig zu initiieren, um die Anzahl der Transaktionen einzugrenzen, die an die neue Datenbank geliefert werden sollen. Während des Migrationsfensters können wir den Zugriff der Benutzer auf die Datenbank einschränken und eine letzte Protokollsicherung initiieren und an das Ziel übertragen. Auf diese Weise kann die Ausfallzeit deutlich verkürzt werden.

Protokollversand

Wir alle verstehen die Bedeutung der Protokolldateien in der Datenbankwelt. Die Protokollversandtechnik bietet eine gute Notfallwiederherstellungslösung und unterstützt eingeschränkten schreibgeschützten Zugriff auf sekundäre Datenbanken während des Intervalls zwischen Wiederherstellungsaufträgen. Es ist im Wesentlichen ein Konzept zum Sichern des Transaktionsprotokolls und wird bei einem vollständigen Backup auf einer weiteren sekundären Datenbank wiedergegeben. Diese sekundären Datenbanken sind doppelte Kopien der primären Datenbank und stellen die Transaktionsprotokollsicherungen kontinuierlich in ihrer eigenen Kopie wieder her, um sie mit der primären Datenbank synchron zu halten. Da sich die sekundäre Datenbank auf separater Hardware befindet, steht im Falle eines Ausfalls der primären aus irgendeinem Grund die vollständig gesicherte Kopie des Systems sofort zur Verfügung und der Netzwerkverkehr kann einfach auf den sekundären Server umgeleitet werden, ohne dass die Benutzer davon erfahren a Störung ist aufgetreten. Der Protokollversand bietet in den meisten Fällen eine einfache und effektive Möglichkeit, die Migration in größerem Umfang zu verwalten.

Spiegelung

Die Datenbankspiegelung ist auch eine Option für die Datenbankmigration, vorausgesetzt, dass Quelle und Ziel dieselben Versionen und Editionen aufweisen. Im Wesentlichen erstellt die Spiegelung zwei doppelte Kopien einer Datenbank auf zwei Hardwareinstanzen. Transaktionen würden auf beiden Datenbanken gleichzeitig stattfinden. Sie haben die Möglichkeit, eine Produktionsdatenbank offline zu schalten, auf die gespiegelte Version dieser Datenbank umzuschalten und Benutzern den Zugriff auf die Daten zu ermöglichen, als ob nichts passiert wäre. Bei der Implementierung haben wir es mit einem Prinzipalserver, einem Spiegelserver und einem Zeugen zu tun. Aber es wird eine veraltete Funktion sein und aus zukünftigen Versionen von SQL Server entfernt werden.

Zusammenfassung

In diesem Artikel haben wir die Arten von Sicherungen, Transaktionsprotokollsicherungen im Detail, Datenmigrationsstandards, Prozesse und Strategien besprochen und gelernt, SQL-Techniken für eine effektive Handhabung von Datenmigrationsschritten zu verwenden.

Der Schreibmechanismus für Transaktionsprotokolle WAL stellt sicher, dass Transaktionen immer zuerst in die Protokolldatei geschrieben werden. Auf diese Weise garantiert SQL Server, dass die Auswirkungen aller festgeschriebenen Transaktionen letztendlich in die Datendateien (auf die Festplatte) geschrieben werden und dass alle Datenänderungen auf der Festplatte, die aus unvollständigen Transaktionen stammen, ein ROLLBACK sind und sich nicht in den Datendateien widerspiegeln.

In den meisten Fällen ist die Verzögerung bei der Datensynchronisierung unvorhergesehen und der Datenverlust ist dauerhaft. In den meisten Fällen hängt alles von der Größe der Datenbank und der verfügbaren Infrastruktur ab. Als empfohlene Vorgehensweise ist es besser, Migrationen manuell als Teil der Bereitstellung durchzuführen, um die Dinge getrennt zu halten, damit die Ausgabe besser vorhersehbar ist.

Ich persönlich würde den Protokollversand aus verschiedenen Gründen bevorzugen:Sie können rechtzeitig eine vollständige Sicherung der Daten vom alten Server erstellen, diese auf den neuen Server übertragen, wiederherstellen und dann die verbleibenden Transaktionen anwenden (t-log backup ) vom Zeitpunkt bis zum Zeitpunkt des Cutovers. Der Prozess ist eigentlich ganz einfach.

Die Datenbankmigration ist nicht schwierig, wenn sie richtig durchgeführt wird. Ich hoffe, dieser Beitrag hilft Ihnen dabei, die Datenbankmigrationen reibungsloser durchzuführen.