LSN-Mismatch-Problem einer AlwaysOn Datenbankspiegelung lösen

Einführung

Bei einer AlwaysOn-Datenbankspiegelung von SQL Server kann es zu einem Mismatch der LSN (Log Sequence Number) kommen. Dieser Fehler tritt ein, wenn die Spiegeldatenbank nicht genügend Transaktionsprotokolldaten enthält, um die Protokollsicherungskette der Hauptdatenbank beizubehalten. Grund dafür ist ein nicht erstelltes Log-Backup der Hauptdatenbank, oder das Backup wurde in der Spiegeldatenbank nicht richtig wiederhergestellt. An diesem Punkt ist es schwierig, das fehlende Transaktionsprotokoll-Backup zu finden. Abhängig von der Häufigkeit, in dem das Transaktionsprotokolls gepflegt wird, werden Hunderttausende von Protokollen generiert und der Fehler kann auf jedem sekundären AlwaysOn-Datenbankserver liegen.

Mit dieser Anleitung leiten wir Sie durch die zwei mögliche Methoden, wodurch ein LSN Mismatch behoben werden kann und die AlwaysOn-Datenbanken wieder synchron laufen.

Beispielszenario

Nimmt man beispielsweise an, es gibt eine sehr große Datenbank (VLDB) mit einer Größe von 8 TB. Eine Sicherung dieser Datenbank wird in einem Disaster Recovery (DR)-Standort gespeichert, welches sich in einem anderen Rechenzentrum befindet. Aufgrund einer nicht übereinstimmenden LSN, ist die Datenbank am DR-Standort jedoch nicht mit der primären Datenbank synchronisiert.

Soll dieses Problem behoben werden, ist der übliche Ansatz, ein vollständiges oder differenzielles Backup der primären Datenbank zu erstellen und es am DR-Standort wiederherzustellen. Angesichts der Größe der Datenbank, würde jedoch das Erstellen eines Backups und deren Übertragung über das WAN zum DR-Standort zu viel Zeit und Ressourcen in Anspruch nehmen.

Hinzu kommt, dass die Sicherung der primären Datenbank in einem CIFS Share (Common Internet File System) in einem anderen Rechenzentrum gespeichert wird. Soll die Wiederherstellung der Sicherung über das WAN von einem externen Standort aus ausgeführt werden, würde das nur weiter die Leistung verringern und die benötigte Zeit in die Höhe treiben. Aus diesem Grund ist ein anderer Ansatz erforderlich, um die Datenbank am DR-Standort wieder mit der primären Datenbank zu synchronisieren.

Die Logs sind in unserem Beispiel folgendermaßen aufgebaut. In der ersten Log-Backup-File ist die erste LSN 100 und die letzte 200. In der zweiten File sollte die erste LSN 200 und die letzte 300 sein. Das dritte Backup sollte somit mit LSN 300 beginnen und darüber hinaus enden. Die Kette sollte so immer weiter geführt werden.

Wie wird die LSN in der Log-Backup-Chain verwendet

Jeder Eintrag des Transaktionsprotokolls einer Datenbank kann eindeutig durch eine LSN Kennung unterschieden werden. In diesen Einträgen stehen Änderungen, die an der Datenbank vorgenommen werden, um später diesen Verlauf nachverfolgen zu können. Jedes Backup dieses Protokolls umfasst dabei nur einen Teil der LSNs. Es wird mit der ersten LSN begonnen, die nicht in der vorherigen Sicherung enthalten war und endet mit der letzten LSN der aktuellen Sicherung.

In unserem Beispiel umfasst das erste Backup den LSN-Bereich von 100 bis 200. Das zweite Backup sollte somit mit der 200 beginnen, da dies die letzte LSN des ersten Backups war. Die letzte die LSN des Backups ist die 300. Folgt man diesem Schema, beginnt das dritte Backup mit der LSN 300 und endet irgendwo darüber. Das gilt auch für jedes weitere Backup.

Durch die Fortführung dieser Reihe, wird eine Kette von Log-Backups erstellt, bei der jedes Backup einen Teil des Transaktionsprotokolls beinhaltet. Die Kette kann dafür verwendet werden, um die Datenbank zu einem bestimmten Zeitpunkt wiederherzustellen, indem Log-Backups der Reihe nach angewendet werden.

Daher ist es sehr wichtig, die Integrität der Log-Backup-Chain aufrechtzuerhalten. Wenn es nur ein fehlendes oder beschädigtes Backup gibt, wird die Kette unterbrochen und alle Backups danach sind für eine Wiederherstellung unbrauchbar.

Wie findet man den LSN Bruch heraus und repariert ihn

Es gibt verschiedene Methoden, an dieses Problem heranzugehen. Die Wahl der Lösung ist dabei abhängig von der Situation und Art des Problems. Im Folgenden will ich die verschiedenen Methoden erklären und beispielhaft anwenden.

Die Methoden sollten nicht in einer Produktionsumgebung getestet werden:
Es stellt eine einfache Möglichkeit dar, die LSN in der Always On-Datenbank zu beschädigen.

Reproduzieren des Fehlers

Zu Beginn wird eine Datenbank eines Sekundärknotens aus einer Always On-Gruppe entfernt.

ALTER DATABASE [dba3] SET HADR OFF;

Ersetzen Sie hierbei [dba3] durch Ihre eigene Datenbank.

Erstellen Sie weitere Log-Backups des primären Knotens.

DECLARE @MyFileName varchar(200)
SELECT @MyFileName=''\\Sharepatht\dba3_'' + REPLACE(convert(nvarchar(20),GetDate(),120),':','-') + '.trn'
--select @MyFileName
BACKUP log dba3 TO DISK=@MyFileName

Ersetzen Sie dabei in Zeile 2 den Dateipfad '\\Sharepatht\dba3_' durch Ihren eigenen.

Versuchen Sie anschließend, die Datenbank erneut zum sekundären Knoten hinzuzufügen.

ALTER DATABASE [dba3] SET HADR AVAILABILITY GROUP = [AG-Test];

Hierbei muss erneut [dba3] und [AG-Test] durch Ihre eigenen Namen ersetzt werden.

Wenn alles geklappt hat, sollte dieser Fehler ausgegeben werden.

Msg 1478, Level 16, State 211, Line 1

The mirror database, has insufficient transaction log data to preserve the log backup chain of the principal database.
This may happen if a log backup from the principal database has not been taken or has not been restored on the mirror database.

Verwenden Sie nun die Backup Tabelle in MSDB (Systemdatenbank in Microsoft SQL Server, die Metadaten und andere Informationen über die SQL Server-Instanz speichert), um den Backup Verlauf mit dynamischem SQL abzurufen.

Dafür muss die untenstehende Vorlage für Ihre eigene Umgebung angepasst werden.

DECLARE @dbname VARCHAR(50)
DECLARE @backup_type CHAR(1)

SET @dbname = 'YourDatabaseName'
SET @backup_type = 'F' -- F for Full, I for Differential, L for Log

DECLARE @sql NVARCHAR(MAX)

SET @sql = N'
SELECT TOP 10 
    CONVERT(CHAR(100), b.backup_start_date, 121) AS BackupStartDate,
    CONVERT(CHAR(100), b.backup_finish_date, 121) AS BackupFinishDate,
    b.database_name,
    CASE b.[type] 
        WHEN ''D'' THEN ''Full'' 
        WHEN ''I'' THEN ''Differential''
        WHEN ''L'' THEN ''Log'' 
    END AS BackupType,
    b.backup_size/1024/1024 AS BackupSizeMB,
    b.compressed_backup_size/1024/1024 AS CompressedBackupSizeMB,
    b.is_copy_only,
    b.first_lsn,
    b.last_lsn,
    b.checkpoint_lsn,
    b.database_backup_lsn,
    b.recovery_model,
    b.server_name,
    b.machine_name,
    b.recovery_fork_guid,
    b.database_version,
    b.database_creation_date,
    b.backup_set_uuid
FROM msdb.dbo.backupset b
WHERE b.database_name = ''' + @dbname + '''
AND b.[type] = ''' + @backup_type + '''
ORDER BY b.backup_finish_date DESC
'

EXEC sp_executesql @sql

In der SELECT-Anweisung können Sie die Spalten anpassen, um die benötigten Informationen des Backup Verlaufs abzurufen. Das obige Beispiel fragt das Start- und Enddatum der Sicherung, den Datenbanknamen, den Sicherungstyp, die Sicherungsgröße und weitere Informationen ab.
Nachdem Sie die SELECT-Anweisung mit dynamischem SQL erstellt haben, können Sie diese mit der folgender Funktion ausführen.

sp_executesql

Erste Methode

Schritt 1

Zuallererst soll das neuste Transaktionsprotokoll Backup gefunden werden. Hierfür führen Sie ein dynamisches Backup-Skript (wie in der oben genannten Sektion erwähnt) auf allen AlwaysOn-Replikaservern aus.
Daraufhin, versuchen Sie die Datenbank mit diesem Backup wiederherzustellen. Der Versuch wird nicht funktionieren, jedoch steht in der Fehlermeldung eine LSN. Diese LSN wird benötigt, um die Datenbank tatsächlich wiederherzustellen. Mit dem erstellten dynamischen Backup, kann folgender Befehl ausgeführt werden ( die DB und Speicherpfad muss erneut von Ihnen entsprechend angepasst werden).

restore database dba3 from disk= '\\share\dba3_2016-08-29 09-43-58.trn' with norecovery

Mithilfe der Fehlermeldung kann man feststellen, ob die LSN, bei der das Programm abbricht, zu neu oder zu alt für das Backup ist, mit dem der Wiederherstellungsversuch unternommen wurde. Die Fehlermeldung sieht ungefähr so aus:

Msg 4326, Level 16, State 1, Line 1

The log in this backup set terminates at LSN 39000000023900001

Interpretation der Fehlermeldung

Um die Fehlermeldung besser verstehen zu können, sind hier einige Beispiele aufgeführt.

In meinem Fall sind die LSN-Nummern:

39000000023900001 – Alter LSN
41000000017300001 – Erforderlicher LSN
41000000017600001 – Aktueller LSN

Fehler bei einem alten Log-Backup:

Msg 4326, Level 16, State 1, Line 1

The log in this backup set terminates at LSN 39000000023900001,

Msg 3013, Level 16, State 1, Line 1

RESTORE DATABASE is terminating abnormally.

Es ist zu alt, um auf die Datenbank angewendet zu werden. Ein neueres Backup wird benötigt.

Fehler bei einem aktuellen Transaktionsprotokoll-Backup:

Msg 4305, Level 16, State 1, Line 1

The log in this backup set begins at LSN 41000000017600001,

Msg 3013, Level 16, State 1, Line 1

RESTORE DATABASE is terminating abnormally.

Es ist zu neu, um auf die Datenbank angewendet zu werden. Ein älteres Backup wird benötigt.

Soll eine Datenbank zu einem bestimmten Zeitpunkt wiederhergestellt werden, muss in der Regel die Backup-Datei gefunden werden, die die LSN zum gewünschten Zeitpunkt enthält. Bei einer großen Menge an Backups wird es schwierig, die richtige Backup-Datei mit der erforderlichen LSN zu bestimmen.

Eine Möglichkeit, besagte Backup-Datei zu finden, ist der Befehl restore headeronly. Mit diesem Befehl werden die Header-Informationen des Backups abgerufen, einschließlich des ersten und letzten LSNs. Vergleicht man nun die Ausgabe von restore headeronly mit dem erforderlichen LSN, kann die Liste der möglichen Backups eingegrenzt werden.

“restore headeronly from disk = ‘yourbackupfile.bak’”

Sobald die richtige Backup-Datei identifiziert wurde, kann mithilfe von restore database die Datenbank auf den gewünschten Zeitpunkt wiederhergestellt werden.

Zu erwähnen ist, dass in einigen Fällen die ersten und letzten LSNs der Befehle restore headeronly und restore database identisch sein können. Dies kann dann eintreten, wenn die gesamten Transaktionen des Backups an des Ende gehängt wurde, ohne dass eine Lücke oder Unterbrechung entsteht. In diesem Fall können Sie sicher sein, dass die Backup-Datei den erforderlichen LSN enthält.

Schritt 2

Führen Sie erneut das Backup-Skript mithilfe der aus Schritt 1 erhaltenen LSN aus. Diesmal wird eine Bedingung eingefügt, um die Transaktionsprotokoll-Backups abzurufen, die entweder den erforderlichen LSN enthalten oder davor entstanden sind. Zur Wiederherstellung, sollte das Backup mit der ältesten LSN gewählt werden.

BSP: Erforderlicher LSN aus Schritt 1: "41000000017300001"

Erweitern Sie das dynamische Backup-Skript um folgende Bedingung:

“and b.first_lsn<=41000000017300001”

Um den LSN zu erhalten, der die erforderliche LSN oder eine ältere enthält, muss mit folgendem Befehl sortiert werden:

“order by b.first_lsn  desc”

Kopiere first_LSN in der ersten Zeile. Das ist der Punkt, an dem der Bruch ist.

Beispiel eines Fehlers:

Error: log backup that includes LSN “41000000017300001” can be restored.

Schritt 3

Wie zuvor bereits erwähnt, müssen die Backup-Dateien der Reihe nach angewendet werden, wenn die Datenbank zu einem bestimmten Zeitpunkt wiederhergestellt werden soll. Der Grund dafür ist, dass jedes Transaktionsprotokoll-Backup eine Teilmenge der Datenbankänderungen enthält, die seit dem letzten Backup vorgenommen wurden. Daher, um alle Änderungen korrekt anzuwenden, müssen die Transaktionsprotokoll-Backups in der richtigen Reihenfolge angewendet werden, beginnend mit dem vollständigen Backup und gefolgt von der Sequenz der Transaktionsprotokoll-Backups.

Das zuvor erwähnte dynamische Backup-Skript kann so modifiziert werden, dass es nur die erforderlichen Backup-Dateien abruft und in der richtigen Reihenfolge anwendet.

Die nötige Bedingung ist:

"and b.first_lsn>=41000000016700001"

Es werden nur die Transaktionsprotokoll Backups abgerufen, die die erforderliche LSN enthalten oder älter sind.

"ORDER BY b.backup_finish_date"

Durch Hinzufügen von ORDER BY [FINISH TIME] zum Skript, werden die Backup-Dateien nach ihrem Abschlussdatum in aufsteigender Reihenfolge sortiert. Somit werden die Backups in der Reihenfolge angewendet, in der sie erstellt wurden.

Leistungspakete der Mainzer Datenfabrik

Als professioneller SQL Server Support und zertifizierter Microsoft Partner unterstützen wir Sie in allen Fragen und individuellen Problemen rund um Ihre Serverumgebung, egal ob vor Ort oder remote. Überzeugen Sie sich selbst von unserem vielfältigen Angebot und den individuellen Leistungspaketen.

Assessments & Support_backup SQL Server SQL Server auf Azure

Zweite Methode

Der zweite Lösungsansatz macht sich Fähigkeiten des AlwaysOn-Clusters zu nutze. In einer Always On Verfügbarkeitsgruppe gibt es zwei oder mehr Repliken einer Datenbank, die entweder synchron oder asynchron sein können. Die Repliken kommunizieren miteinander über ein spezielles Protokoll namens "Database-Mirroring-Endpoint", das TCP/IP verwendet, um Daten zwischen den Repliken zu übertragen. Bei einem Austausch von Daten, wird für jede Transaktion ein neuer Eintrag im Transaktionsprotokoll (auch als LSNs oder Log Sequence Numbers bekannt) auf der Zielreplika gespeichert.

Um die Datenkonsistenz zwischen Repliken aufrechtzuerhalten, verwendet Always On einen Mechanismus namens Log-Truncation. Dieser entfernt unnötige Protokolleinträge aus dem Transaktionsprotokoll. Die Log-Truncation wird durch den Log-Truncation-LSN (auch als Truncationpunkt bezeichnet) gesteuert. Er gibt den ältesten Protokolleintrag an, der sicher aus dem Protokoll gelöscht werden kann, ohne die Integrität der Datenbank zu beeinträchtigen.

Vorgehen

Um die Truncation LSN in einer Always On Verfügbarkeitsgruppe zu finden, können Sie die DMV (Dynamic Management View) verwenden.

sys.dm_hadr_database_replica_states

Diese DMV liefert Informationen über den Replikationsstatus jeder Datenbank-Replik in der Verfügbarkeitsgruppe. Um die Truncation-LSN mithilfe von sys.dm_hadr_database_replica_states zu finden, können Sie folgende Abfrage verwenden:

SELECT s.truncation_lsn, s.recovery_lsn, s.last_hardened_lsn
FROM sys.dm_hadr_database_replica_states AS s
WHERE s.is_local = 1 AND s.database_id = DB_ID('YourDatabaseName');

In dieser Abfrage ersetzen Sie 'YourDatabaseName' durch den Namen Ihrer Datenbank. Der Parameter is_local filtert die Ergebnisse, damit nur die lokale Replika (d.h. die Replika auf dem aktuellen Server) angezeigt wird. Der Parameter database_id gibt an, welche Datenbank abgefragt werden soll.

Das Ergebnis dieser Abfrage zeigt die Truncation-LSN in der Spalte s.truncation_lsn an. Darin befindet sich der älteste Log-Eintrag, der sicher aus dem Transaktionsprotokoll gelöscht werden kann. Der Recovery-LSN in der Spalte s.recovery_lsn stellt den Punkt dar, bis zu dem die Log-Einträge auf der sekundären Replik abgearbeitet wurden. Der Eintrag in der Spalte s.last_hardened_lsn stellt den zuletzt bearbeiteten LSN auf der sekundären Replik dar.

Die vollständige Abfrage, um das Ergebnis zu erhalten, ist:

select database_id,db_name(database_id),name,replica_server_name,synchronization_health_desc,synchronization_state_desc,
s.truncation_lsn,s.recovery_lsn,s.last_hardened_lsn,s.last_sent_time,s.last_received_time,s.last_redone_lsn,
s.end_of_log_lsn,s.last_commit_lsn,s.last_sent_lsn,s.last_received_lsn,s.last_commit_lsn
from sys.dm_hadr_database_replica_states S join  sys.availability_groups G on (s.group_id=g.group_id)
join sys.availability_replicas   GR on (GR.group_id=g.group_id)
--where synchronization_health_desc <>'HEALTHY'
and db_name(database_id)='dba3'
and synchronization_health_desc ='NOT_HEALTHY'

In unserem Beispiel ist die Truncation LSN 41000000016700001. Das bedeutet, dass alle Protokolldatensätze vor diesem LSN sicher aus dem Transaktionsprotokoll gelöscht werden können, ohne die Integrität der Datenbank zu beeinträchtigen. Die Recovery LSN und last_hardened_lsn sind 41000000017300001. Dies bedeutet, dass die sekundäre Replikat alle Protokolldatensätze bis zu diesem LSN abgearbeitet hat.

Erweitern sie den Filter des dynamischen Backup-Skripts mit dem gefunden s.truncation_lsn.

SELECT  'restore database dba3 from disk= ''' +f.physical_device_name+''' with norecovery',
b.backup_finish_date,b.first_lsn,b.last_lsn,b.database_backup_lsn,b.checkpoint_lsn,
b.type,b.is_copy_only,b.recovery_model,b.backup_size /1024/1024 AS size_MB,
b.server_name ,b.database_name,b.user_name, f.physical_device_name,b.*
FROM MSDB.DBO.BACKUPMEDIAFAMILY F
JOIN MSDB.DBO.BACKUPSET B
ON (f.media_set_id=b.media_set_id)
WHERE database_name like'dba3'
--and b.backup_finish_date>='2016-08-29 05:50:00.000'
AND b.first_lsn>=41000000016700001
AND B.type='L'
ORDER BY b.backup_finish_date

Nachdem das dynamische Backup-Skript mit der Filterklausel s.truncation_lsn ausgeführt wurde, können wir das Backup identifizieren, welches wir zur Wiederherstellung auf die sekundäre Datenbank (LSN-Break-Server) benötigen. Das generierte Wiederherstellungsskript kann auf dem Sekundärserver ausgeführt werden, um die Datenbank in den gleichen Zustand wie auf dem Primärserver zum Zeitpunkt des Backups wiederherzustellen.

Sobald die Datenbank auf dem Sekundärserver wiederhergestellt wurde, müssen wir sie in die Always On-Verfügbarkeitsgruppe aufnehmen, um sicherzustellen, dass sie am automatischen Failover-Prozess teilnehmen kann. Dies wird mit dem ALTER DATABASE-Statement und der Option SET HADR AVAILABILITY GROUP durchgeführt.

ALTER DATABASE [dba3] SET HADR AVAILABILITY GROUP = [AG-Test];

Was passiert, wenn Log-Backups auf mehreren sekundären Repliken laufen

Wenn das Log-Backup auf mehreren sekundären Repliken ausgeführt wird und ein Failover auftritt, ist es möglich, dass das Log-Backup nicht auf allen sekundären Replikaten vor dem Failover angewendet wird. In diesem Fall müssen wir die Transaktions-Log-Backup-Datei identifizieren, die die fehlenden Transaktions-Logs enthält und sie auf der sekundären Replika wiederherstellen.

Dazu können wir folgende Schritte ausführen:

Holen Sie sich den erforderlichen LSN entweder aus "DMV of AlwaysON" oder aus der Wiederherstellungsfehlermeldung. Dieser LSN hilft uns, die Transaktions-Log-Backup-Datei zu identifizieren, die die fehlenden Logs enthält.
Verwenden Sie das "Dynamische Backup-Skript", das in den Methoden zuvor benutzt wurde. Dieses Mal wird der erforderlicher LSN als Filter übergeben, um die Backup-Datei zu identifizieren, die fehlende Logs enthält.
Das Skript gibt Namen von Backup-Dateien aus. Diese müssen mit den Backup-Dateien, die im Backup-Ordner verfügbar sind, verglichen werden. Hierfür kann xp_cmdshell verwendet werden, um eine Liste von Dateien in einem Ordner zu erhalten und sie in eine Tabelle einzufügen. Dadurch können wir die Backup-Datei identifizieren, die die fehlenden Logs enthält.

Sobald wir die Transaktions-Log-Backup-Datei identifiziert haben, können wir sie auf der sekundären Replika wiederherstellen, um sicherzustellen, dass alle fehlenden Transaktions-Logs angewendet werden. Wir können dieselbe RESTORE LOG-Anweisung verwenden, die wir bereits verwendet haben. Diesmal nutzen wir den Backup-Dateinamen, der die fehlenden Logs enthält.

Schritt 1: Aktivieren Sie die xp_cmdshell

EXEC sp_configure 'show advanced options', 1; 
RECONFIGURE; 
EXEC sp_configure 'xp_cmdshell', 1; 
RECONFIGURE;

Dieser Schritt aktiviert die Funktion xp_cmdshell. Es ermöglicht, Befehlszeilenanweisungen innerhalb von SQL Server auszuführen.

Schritt 2: Erstellen Sie eine Tabelle, um die Sicherungsdateien zu exportieren

create table tbl_backup_filename (id int identity, Bak_filename varchar(500))
insert into tbl_backup_filename
exec xp_cmdshell 'dir \\share\SQL-Backup\QA\DBA_Test /b /O:D' -- Bare format sort by date

Dieser Schritt erstellt eine temporäre Tabelle namens „tbl_backup_filename“ mit einer einzelnen Spalte namens „Bak_filename“. Mit dem Befehl „xp_cmdshell“ wird dann ein „dir“-Befehl auf den angegebenen Sicherungsordner ausgeführt und die Ergebnisse in die Tabelle exportiert. Die Option „/b“ gibt nur die Dateinamen zurück, und die Option „/O:D“ sortiert die Ergebnisse nach Datum in absteigender Reihenfolge (neueste Dateien zuerst).

Schritt 3: Vergleichen Sie den Namen der Backup-Datei mit dem Namen der Export-Backup-Datei und notieren Sie sich die ID.

select * from tbl_backup_filename
select * from tbl_backup_filename where Bak_filename like '%dba3_2016-08-30 05-10-00%'

Dieser Schritt wählt alle Zeilen aus der Tabelle "tbl_backup_filename" aus, um die Namen der Backup-Dateien anzuzeigen. Sie können dann die Ergebnisse filtern, indem Sie eine "like" Klausel verwenden, um nach einem bestimmten Backup-Dateinamen zu suchen. Sobald Sie den richtigen Backup-Dateinamen identifiziert haben, notieren Sie den entsprechenden "id"-Wert aus der Tabelle "tbl_backup_filename".

Schritt 4: Führen Sie den dynamischen SQL-Wiederherstellungsbefehl aus, um das Wiederherstellungsskript mit der Bedingung der Identitätsnummer zu generieren, die Sie aus dem obigen Schritt erhalten haben.

select 'restore headeronly from disk=''\\sclfilip13\MFGProcess\SQL-Backup\QA\DBA_Test\'+Bak_filename+'''', *
from tbl_backup_filename where id >=76

select 'restore database dba3 from disk=''\\sclfilip13\MFGProcess\SQL-Backup\QA\DBA_Test\'+Bak_filename+''' with norecovery', *
from tbl_backup_filename where id >=76

Dieser Schritt generiert ein Wiederherstellungsskript unter Verwendung einer dynamischen SQL-Anweisung, die den im vorherigen Schritt identifizierten Backup-Dateinamen enthält. Der Befehl "restore headeronly" wird verwendet, um Informationen aus dem Backup-Header abzurufen, wie z.B. den Datenbanknamen, den Backup-Typ und die LSN-Werte. Mit diesen Informationen können Sie überprüfen, ob Sie die richtige Backup-Datei ausgewählt haben. Der Befehl "restore database" wird dann verwendet, um die Datenbank aus der Backup-Datei mit der Option "norecovery" wiederherzustellen, die es Ihnen ermöglicht, zusätzliche Transaktionsprotokoll-Backups anzuwenden. Das "*" in der Select-Anweisung gibt alle Spalten aus der Tabelle "tbl_backup_filename" zurück, was für Fehlerbehebungen nützlich sein kann.

Schritt 5: Deaktivieren Sie die xp_cmdshell

EXEC sp_configure 'xp_cmdshell', 0; 
RECONFIGURE; 
EXEC sp_configure 'show advanced options', 0; 
RECONFIGURE;

Dieser Schritt deaktiviert die Funktion "xp_cmdshell", um unbefugten Zugriff auf die Befehlszeile innerhalb von SQL Server zu verhindern.

Wenn Sie Backup-Ordner für jede Replikaserver haben, müssen Sie den Befehl "xp_cmdshell" auf jedem Ordner ausführen und die Ergebnisse in separate Tabellen exportieren. Sie können dann die Backup-Dateinamen aus jeder Tabelle vergleichen, um die richtige Backup-Datei zu identifizieren.

Wir hoffen Ihnen mit dieser Anleitung bei Ihren Mismatch-Problemen durch eine Datenspiegelung helfen zu können.

Sollten Sie Fragen dazu haben oder weiterführenden Support benötigen, stehen unsere IT-Experten jederzeit zur Verfügung. Vereinbaren Sie gerne über unser Kontaktformular ein unverbindliches Beratungsgespräch!