SQL Server işlem günlüğü yedekleri: kuyruk günlüğünün bilinen son günlük yedeklemesini izleyip izlemediğini test edin

SQL Server'ı tam kurtarma modunda kullanıyoruz. Tam bir yedekleme ve bir dizi günlük yedeklemesi göz önüne alındığında, günlük zincirinin son tam yedeklemeden geçerli kuyruk günlüğüne tamamlanıp tamamlanmadığını kontrol edebilmek istiyoruz. (Bu yedekleri gerçekten geri yüklemeden, buradaki amaç yedeklerin tutarlılığını test etmektir.)

Mevcut yedeklemeler için bunu nasıl yapacağımı zaten biliyorum: HEADERONLY RESTORE kullanarak, uyumlu olup olmadığını belirlemek için ardışık dosyalar için karşılaştırılabilir her dosyanın FirstLSN ve LastLSN olsun.

Ancak, kuyruk günlüğünün son günlük yedeklemesini izleyip izlemediğini nasıl denetleyeceğimi bilmiyorum.

Kuyruk günlüğünün FirstLSN'sine sahip olsaydım, bunu son günlük yedeklemesinin LastLSN'si ile karşılaştırabilirdim. Fakat kuyruk kütüğünün FirstLSN'sini nasıl alabilirim?

SQL Server 2005'ten (ideal olarak t-sql kullanarak) çalışan bir çözüme ihtiyacım var. Şimdiye kadar Google'ı boşuna aradım. Btw. Bunu ilk olarak stackoverflow'a gönderdim; ancak konu dışı olarak işaretlendiğinden buraya taşıdı.

DÜZENLE

Sağlanan iki çözümü küçük bir örnek üzerinde denedim (SQL Server 2005, 9.0.5057):

BACKUP DATABASE TestDb TO DISK = 'C:\temp\backup test\Full.bak' 

-- fire some update queries

BACKUP LOG TestDb TO DISK =  'C:\temp\backup test\Log1.bak' 

-- fire both queries from the provided answers: 
-- Martin Smith's answer yields: 838886656088920652852608
-- Shawn Melton's answer yields: 46000000267600001

RESTORE HEADERONLY FROM DISK = 'C:\temp\backup test\Log1.bak'  
-- yields: 46000000267600001

Öyleyse birincisi birkaç büyüklük sırası tarafından kapalı görünüyor.

Daha sonra aynı testi SQL 2008 SP1'de (10.00.2531) yaptım, burada her iki sorgu da doğru cevabı verdi.

SQL Server 2008 Internals kopyasına döndüm ve DMV sys.database_recovery_status bir sonraki günlük yedeklemesinin ilk LSN'sini bulmaya dikkat çekti. Hangi BOL gidiyor sütun last_log_backup_lsnsize sağlar:

En son günlük yedeklemesinin günlük sıra numarası. Bu, önceki günlük yedeklemesinin son LSN'si ve sonraki günlük yedeklemesinin başlangıç ​​LSN'sidir.
NULL = Günlük yedeklemesi yok. Veritabanı çevrimdışı veya veritabanı başlamıyor.

Sadece Kalen de veritabanı SIMPLE kurtarma modunda (otomatik kesme modu) veya hiçbir günlük yedekleme yoksa NULL değeri alacağınız noktasını ortaya koymaktadır.

Fakat kuyruk kütüğünün FirstLSN'sini nasıl alabilirim?

Aslında bir veritabanının kuyruk günlüğünü yedeklemeden (bunu denemek için bir test örneğiniz yok) mantıksal olarak, belirtilen sütunda döndürülen değerin bir sonraki günlük yedeklemenin ilk LSN'si olacağı sonucuna varabilirsiniz. kuyruk.

Yani aşağıdakileri yapmak aradığınızı düşündüğüm değeri döndürür:

SELECT 
   last_log_backup_lsn
FROM 
   sys.database_recovery_status
WHERE 
   databse_id = DB_ID('MyDb')

Bu DMV, SQL 2005'ten itibaren kullanılabilir.

DÜZENLE
BOL bağlantısını okumadığınız sürece, bu DMV'nin yalnızca çevrimiçi olan veya BOL tarafından referans verildiği gibi açılan veritabanlarına değerler döndüreceğini lütfen unutmayın. Bir veritabanının kuyruk günlüğü yedeklemesini almanızı gerektiren bir hata oluşursa, veritabanı erişilebilir olmadığı sürece bu değeri yukarıdaki kodla doğrulayamazsınız; ki bu bir başarısızlıkta muhtemelen olmazdı.

Aşağıdaki gibi bir şey yapmalı.

WITH LSN_CTE
AS
(
SELECT TOP 1
       LEFT( LogRecords.[Current LSN], 8 )          AS Part1,
       SUBSTRING( LogRecords.[Current LSN], 10, 8 ) AS Part2,
       RIGHT( LogRecords.[Current LSN], 4 )         AS Part3
FROM   sys.fn_dblog(NULL,NULL) AS LogRecords
ORDER BY [Current LSN]
)
SELECT CAST( CAST( CONVERT( varbinary, Part1, 2 ) AS int ) AS varchar ) +
       RIGHT( '0000000000' + CAST( CAST( CONVERT( varbinary, Part2, 2 ) AS int ) AS varchar ), 10 ) +
       RIGHT( '00000'      + CAST( CAST( CONVERT( varbinary, Part3, 2 ) AS int ) AS varchar ), 5 ) AS [Converted LSN]
FROM   LSN_CTE

Bu makaleden ondalık sayıya dönüştürme kodunu kullanma .

ORDER BY [Current LSN]İyi tamamen gereksiz havai olabilir. Emin değilim. Bu işlevin sonucu her zaman LSN düzeninde gibi görünüyor ve sanırım günlüğü sırayla okuyor ama her ihtimale karşı ...