Sao lưu nhật ký giao dịch SQL Server: kiểm tra xem nhật ký đuôi có theo dõi sao lưu nhật ký đã biết không


11

Chúng tôi đang sử dụng SQL Server với chế độ phục hồi đầy đủ. Đưa ra một bản sao lưu đầy đủ và một loạt các bản sao lưu nhật ký, chúng tôi muốn có thể kiểm tra xem chuỗi nhật ký đã hoàn thành từ bản sao lưu đầy đủ cuối cùng đến nhật ký đuôi hiện tại hay chưa. (Không thực sự khôi phục các bản sao lưu này; mục đích ở đây là để kiểm tra tính nhất quán của các bản sao lưu.)

Tôi đã biết cách thực hiện việc này cho các bản sao lưu hiện có: sử dụng RESTORE HeaderONLY Tôi nhận FirstLSN và LastLSN của mỗi tệp, có thể so sánh cho các tệp liên tiếp, để xác định xem chúng có tương thích hay không.

Tuy nhiên, tôi không biết cách kiểm tra xem nhật ký đuôi có theo bản sao lưu nhật ký cuối cùng hay không.

Nếu tôi có FirstLSN của nhật ký đuôi, tôi có thể so sánh nó với LastLSN của bản sao lưu nhật ký cuối cùng. Nhưng làm thế nào tôi có thể có được FirstLSN của nhật ký đuôi?

Tôi cần một giải pháp hoạt động từ SQL Server 2005 trở lên (lý tưởng nhất là sử dụng t-sql). Cho đến nay, tôi đã tìm kiếm Google vô ích. Btw. Lần đầu tiên tôi đăng bài này lên stackoverflow; nhưng di chuyển nó ở đây vì nó được gắn cờ ngoài chủ đề ở đó.

BIÊN TẬP

Tôi đã thử hai giải pháp được cung cấp trên một ví dụ nhỏ (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

Vì vậy, nó xuất hiện cái đầu tiên bị tắt bởi một số đơn đặt hàng cường độ.

Sau đó, tôi đã thực hiện bài kiểm tra tương tự trên SQL 2008 SP1 (10:00.2531), trong đó cả hai truy vấn đều cho câu trả lời đúng.


Tôi đã thực hiện một số nghiên cứu vì đó là một câu hỏi thú vị, nhưng tôi không đi xa lắm. Tôi không chắc SQL hỗ trợ điều này ra khỏi hộp.
Kinda Villyard

1
Tôi chắc chắn rằng có một cách để xác minh điều này, có thể sử dụng LSN không phải là cách để làm điều đó. Tôi sẽ đặt tiền thưởng cho câu hỏi sau vài giờ nữa, câu hỏi này cần nhiều lượt xem hơn ..

Câu trả lời:


12

Tôi đã chuyển sang bản sao SQL Server 2008 của tôi và DMV sys.database_recovery_status được chỉ ra để tìm LSN đầu tiên của bản sao lưu nhật ký tiếp theo. BOL sẽ last_log_backup_lsncung cấp cho bạn:

Số thứ tự đăng nhập của bản sao lưu nhật ký gần đây nhất. Đây là LSN cuối của bản sao lưu nhật ký trước và LSN bắt đầu của bản sao lưu nhật ký tiếp theo.
NULL = Không có bản sao lưu nhật ký tồn tại. Cơ sở dữ liệu ngoại tuyến hoặc cơ sở dữ liệu sẽ không bắt đầu.

Chỉ cần đề cập đến việc Kalen cũng đưa ra quan điểm rằng bạn sẽ nhận được giá trị NULL nếu cơ sở dữ liệu ở chế độ khôi phục SIMPLE (chế độ tự động ghi) hoặc nếu không có bản sao lưu nhật ký.

Nhưng làm thế nào tôi có thể có được FirstLSN của nhật ký đuôi?

Nếu không thực sự sao lưu nhật ký đuôi của cơ sở dữ liệu (không có phiên bản thử nghiệm để thử điều này), bạn có thể kết luận một cách hợp lý rằng giá trị được trả về trong cột được đề cập sẽ là LSN đầu tiên của bản sao lưu nhật ký tiếp theo, trong trường hợp của bạn đuôi.

Vì vậy, thực hiện các thao tác sau sẽ trả về giá trị mà tôi tin rằng bạn đang tìm kiếm:


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

DMV này có sẵn bắt đầu từ SQL 2005.

EDIT
Trừ khi bạn đọc liên kết BOL, xin lưu ý rằng DMV này sẽ chỉ trả về các giá trị cho cơ sở dữ liệu đang trực tuyến hoặc được mở dưới dạng tham chiếu BOL. Nếu xảy ra lỗi yêu cầu bạn thực hiện sao lưu nhật ký đuôi của cơ sở dữ liệu, bạn sẽ không thể xác minh giá trị này thông qua mã trên trừ khi cơ sở dữ liệu có thể truy cập được; mà trong một thất bại có lẽ sẽ không được.


Kết quả của truy vấn này dường như là chính xác.
Andreas

Chắc chắn có vẻ đúng với tôi. Last_log_backup_lsn bằng với First_lsn của đuôi của nhật ký. Vì vậy, nếu bạn có một tệp nhật ký được khôi phục với last_lsn bằng với last_log_backup_lsn từ mã của Shawn, thì bạn biết rằng bạn có một bản sao lưu ngay tới nhật ký đuôi. (Tất nhiên điều đó chỉ được đảm bảo đúng tại thời điểm truy vấn, thời điểm tiếp theo có thể bắt đầu sao lưu nhật ký mới.)
RLF

@RLF đã thêm một ghi chú vì điều này cũng đúng nếu cơ sở dữ liệu không truy cập được. Nó không thực sự là một giải pháp khả thi để sử dụng khi cần thực hiện kế hoạch khắc phục thảm họa của bạn. Hoàn toàn cho các bài tập trên bàn hoặc kiểm tra kế hoạch của bạn.

6

Một cái gì đó như sau nên làm điều đó.

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

Sử dụng mã chuyển đổi sang số thập phân từ bài viết này .

Cũng ORDER BY [Current LSN]có thể là hoàn toàn không cần thiết trên đầu. Tôi không chắc. Kết quả của chức năng này dường như luôn theo thứ tự LSN và tôi đoán nó chỉ đọc nhật ký tuần tự nhưng chỉ trong trường hợp ...


@MartinSmith: fn_dblogdường như không được ghi chép lại nhiều. Tôi giả sử kết quả của nó luôn giữ cho cơ sở dữ liệu hiện tại (vì không có WHERE DbName = 'XXX'trong đoạn trích)?
Andreas

@Andreas - Có nó là không có giấy tờ. Và có, nó trả về thông tin từ nhật ký của cơ sở dữ liệu hiện tại.
Martin Smith

xem chỉnh sửa của tôi cho câu hỏi ban đầu. Số được trả về bởi đoạn mã của bạn lớn hơn nhiều so với LSN của các bản sao lưu gần đây của cùng một DB.
Andreas

@Andreas - Lạ thật. Tôi chỉ thử nó trên một DB thử nghiệm duy nhất và nó hoạt động chính xác. Không chắc lỗi ở đâu. Phiên bản SQL Server nào bạn đang chạy này? Các CONVERTvới phong cách tham số 2có thể là vấn đề.
Martin Smith

(Mặc dù câu trả lời của Shawn có vẻ thích hợp hơn với câu hỏi này)
Martin Smith
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.