Vollsicherung, Logsicherung,Vollsicherung,Logsicherung… – oder: ist die Backupsoftware verwirrt?

Für die tägliche Datenbanksicherung der von mir anvertrauten Systeme wird eine Drittherstellersoftware eingesetzt.

Darüber kann oder mag man sich streiten, ob man jetzt native Datenbanksicherungen selbst einrichtet, Wartungspläne verwendet oder die Lösung von Ola Hallengren verwendet. Es gibt ja bekanntlich viele Wege nach Rom und Hauptsache ist, dass es überhaupt Backups gibt und sich diese auch problemlos wiederherstellen lassen. (Der Klassiker schlechthin: ja, wir haben Backups….)

Auf einem Test-System, welches ebenfalls durch die Software abgedeckt ist, hatte ich jetzt ein interessantes Verhalten:

Anstatt des zu erwartenden Sicherungsablaufes

Vollsicherung, Logsicherung, Logsicherung, Logsicherung, Logsicherung  ..usw  hatte ich für eine Datenbank folgenden Ablauf:

Vollsicherung, Logsicherung,Vollsicherung,Logsicherung und so weiter.

Die Software erzwang bei jeder 2. Log Sicherung eine Vollsicherung der Datenbank, da ein Mechanismus namens „Log Gap Detection“ gegriffen hat.  Hiermit soll sichergestellt werden, dass keine Logsicherung fehlt. Dies kann mitunter ja passieren, wenn nativ eine Logsicherung gezogen wird oder vielleicht sogar unterschiedliche Sicherungsprodukte auf ein System losgelassen werden (ich hoffe nicht…)

Was hier konkret passiert: die Sicherungssoftware speichert eigenen Metadaten über die erfolgten  Datenbankensicherungen, darunter auch Log Sequence Number (LSN) Informationen. Oder wie es in der Übersetzung heisst: Protokollfolgenummern.

Ich hab mich dann folgender Abfrage bedient, um mal zu gucken, ob die LSNs wirklich nicht zusammen passen:

DECLARE @db_name VARCHAR(100)
SELECT @db_name = 'MeineDB'
SELECT
BS.recovery_model AS [Recovery Model]
,(CAST(BS.backup_size / 1000000 AS INT)) AS [Size of Backup (MB)]
,CASE BS.[type] WHEN 'D' THEN 'Full'
WHEN 'I' THEN 'Differential'
WHEN 'L' THEN 'Transaction Log'
END AS [Type of Backup]
,BS.backup_start_date AS [Backup Date]
,BS.first_lsn AS [First LSN]
,BS.last_lsn AS [Last LSN]
,bs.database_backup_lsn
FROM msdb.dbo.backupset BS
WHERE BS.database_name = @db_name
ORDER BY backup_start_date DESC;

Ergebnis:

LSN_Query1

Wenn man sich jetzt mal die Transaction Log Sicherungen genau anschaut, dann erkennt man, dass die „Last LSN“ der ersten Log Sicherung  und die „First LSN“ der nächsten übereinstimmen (125000000177500001). Da ist keine Lücke.

Was macht also die Sicherungssoftware?

Wenn die Sicherungssoftware eine Logsicherung macht, dann werden die Metadaten der Software nachgelagert wie folgt aktualisiert (diese Info konnte ich dem Support aus der Nase kitzeln):

SELECT TOP 1 last_lsn AS last_log_backup_lsn
FROM msdb..backupset WHERE database_name=N'%s'
AND TYPE LIKE 'L'
ORDER BY last_lsn DESC;

(Ggf. fällt dem einen oder anderen hier schon etwas auf… )

Beim nächsten Log Backup prüft die Backup Software die LSN, welche sie in den eigenen Metadaten gespeichert hat, wie folgt:
SELECT last_log_backup_lsn FROM sys.database_recovery_status
WHERE database_id = DB_ID(N'%s')

In dieser DMV ist immer die letzte Transaktionslogsicherungs – LSN hinterlegt bzw., um es direkt richtig zu formulieren: Hier findet sich die Startsequenznummer der kommenden Transaktionslogsicherung.

Und jetzt die spannende Sache: was ist denn, wenn ich ggf. meine Sicherungshistorie nicht so ganz sauber pflege um alte Einträge zu bereinigen? Oder aber ich hab so etwas doch implementiert, halte aber die letzten 30,60, 90 Tage an Informationen vor? Oder es gab eine Wiederherstellung und meine Datenbank hat jetzt den Stand von vor 3, 5 oder 9 Tagen? Ist dann die oben erwähnte Abfrage der Backup Software gegen msdb..backupset mit einem „Top 1“ und „order by last_lsn desc“  noch eine gute Prüfung?

Die Antwort lautet nein!

Was passiert denn mit der Tabelle msdb..backupset, wenn ich einen älteren Stand der Datenbank wiederherstelle? Genau, gar nichts. Der geneigte DBA verwendet ein „RESTORE… WITH REPLACE“ und das Thema ist erledigt.   Ich gebe zu, ich bereinige an der Stelle eben nicht die Sicherungs- Historie. Ich habe das automatisiert durch einen SQL Server Agent Job, der das für mich einmal am Tag erledigt und Einträge älter als X Tage löscht.

Würde ich vorher über die GUI die Datenbank löschen, dann hab ich ja die Option zu sagen: Lösche mir auch die Backup Historie.

LSN_Query2_optionen

Oder ich mache diesen Aufruf:
EXEC msdb.dbo.sp_delete_database_backuphistory @database_name = 'MeineDatenbank'

Aber nochmal: machen wir so was manuell? Meistens nicht.

Bei meinem speziellen Fall ist es nun so, dass die Sicherungssoftware mit Hilfe der „Log Gap Detection“  jetzt zum Beispiel etwas ermittelt wie:

LSN_Query3_results

Die LSNs stimmen nicht überein und die Sicherungssoftware entscheidet sich jetzt für eine Vollsicherung.

Das die erste Logsicherung nach einer Vollsicherung funktioniert liegt, so vermute ich, ebenfalls an den Metadaten der Sicherungssoftware. Wahrscheinlich haben die Programmierer gedacht: zuletzt wurde eine Vollsicherung gemacht, ergo ist dies die erste Transaktionslogsicherung und das passt.

Beim Hersteller hab ich das ganze Thema natürlich auch schon eingekippt und ein entsprechender HotFix ist jetzt in Arbeit.

Als Tipp habe ich mit auf den Weg gegeben, das ORDER By last_lsn DESC durch ein ORDER by backup_finish_date zu ersetzen. Dann bekommt man auch die passende LSN zurück, die zur Sicherungskette passt.

 

 

Advertisements

Über Dirk Hondong

A MS server and ms sql server admin guy from germany. want to improve my skills a little bit, sharing my daily experience
Dieser Beitrag wurde unter DMVs, Maintenance, SQL Server abgelegt und mit , , , , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s