Không thể khôi phục (lỗi 3456)

Tôi có một tình huống không dễ để tìm ra và nghĩ rằng tôi sẽ hỏi trên diễn đàn này nếu những người khác có thể có đề xuất.

Tôi đang chạy SQL Server 2008 R2 Standard SP3 trên Windows Server 2008R2 Enterprise.

Một cơ sở dữ liệu cần một số bảo trì và sau thực tế tôi cần khôi phục trên một máy chủ khác. Tôi có một bản sao lưu db đầy đủ được thực hiện với COPY_ONLY cộng với một bộ 4 bản sao lưu tlog.

1. trước khi bắt đầu, hãy tạo tlogbackup1
2. thay đổi từ FULLđể BULK_LOGGEDmô hình phục hồi
3. thêm nhóm mới
4. thêm tập tin vào tập tin mới
5. đặt newf đặc quyền thành mặc định
6. chọn vào bảng (trên newfilegroup)
7. thả bảng gốc
8. xóa tập tin gốc
9. xóa tập tin gốc
10. thay đổi tên của bảng mới để khớp với bảng gốc
11. thay đổi tên tệp của newfilegroup để khớp với tập tin gốc
12. thay đổi tên tệp trong danh mục để khớp với tên tệp gốc
13. thay đổi tên tệp ở cấp độ hệ điều hành để khớp với tên tệp gốc
14. đặt filegroup mặc định là bản gốc
15. mang db trực tuyến
16. thay đổi từ BULK_LOGGEDđể FULLmô hình phục hồi
17. Sau khi hoàn thành tất cả các bước, hãy tạo tlogbackup2

Việc khôi phục tất cả các bản sao lưu phải sử dụng VỚI M CHUYỂN, do thay đổi ký tự ổ đĩa trên máy chủ khôi phục.

Các bước phục hồi:

RESTORE database SomeDB FROM DISK = 'D:\REPRO\SomeDB.bak'   
WITH 
MOVE 'SystemData' TO 'D:\SQLDATA\SomeDB.mdf'
,MOVE 'SystemDataPDS' TO 'D:\SqlData\SomeDB.ndf'
,MOVE 'SystemData_log' TO 'D:\SQLLogs\SomeDB.LDF'
,NORECOVERY
,stats = 1

RESTORE LOG SomeDB FROM DISK = 'D:\REPRO\tlogbackup1.trn'   
WITH 
MOVE 'SystemData' TO 'D:\SQLDATA\SomeDB.mdf'
,MOVE 'SystemDataPDS' TO 'D:\SqlData\SomeDB.ndf'
,MOVE 'SystemData_log' TO 'D:\SQLLogs\SomeDB.LDF'
,NORECOVERY
,stats = 1

RESTORE LOG SomeDB FROM DISK = 'D:\REPRO\tlogbackup2.trn'   
WITH 
MOVE 'SystemData' TO 'D:\SQLDATA\SomeDB.mdf'
,MOVE 'SystemDataPDS' TO 'D:\SqlData\SomeDB.ndf'
,MOVE 'SystemData_log' TO 'D:\SQLLogs\SomeDB.LDF'
,NORECOVERY
,stats = 1

Khôi phục tlog cuối cùng đạt 100% và sau đó không thành công với lỗi 3456:

Đã xử lý 368 trang cho cơ sở dữ liệu 'Một sốDB', tệp 'SystemData' trên tệp 1.

Đã xử lý 7656520 trang cho cơ sở dữ liệu 'Một sốDB', tệp 'SystemDataPDS' trên tệp 1.

Đã xử lý 172430 trang cho cơ sở dữ liệu 'Một sốDB', tệp 'SystemData_log' trên tệp 1.

Msg 3456, Cấp 16, Trạng thái 1, Dòng 1
Không thể làm lại bản ghi nhật ký (210388: 123648: 232), cho ID giao dịch (0: 1016710921), trên trang (4: 8088), cơ sở dữ liệu 'Một số cơ sở dữ liệu' (ID cơ sở dữ liệu 6) . Trang: LSN = (0: 0: 1), loại = 11. Nhật ký: OpCode = 4, bối cảnh 11, PrevPageLSN: (210388: 122007: 1). Khôi phục từ bản sao lưu của cơ sở dữ liệu hoặc sửa chữa cơ sở dữ liệu. Msg 3013, Cấp 16, Bang 1, Dòng 1 RESTORE LOG đang chấm dứt bất thường.

Chỉ cần xác minh rằng bản sao lưu db đầy đủ là ổn, tôi đã khôi phục nó chạy CHECKDBvà không có lỗi.

Tất cả thông tin phản hồi hoan nghênh.

Cảm ơn trước,

Rái cá Ned

Để hiểu tại sao lỗi 3456 sẽ bị ném, chúng ta cần lùi lại một chút và hiểu cách SQL Server xử lý góc phục hồi này.

Khi SQL Server đang làm lại một hoạt động và làm lại đó là một sửa đổi trang, nó sẽ kiểm tra nhanh. Trong tiêu đề trang cuối cùng sẽ có một PageLSN, đó là dấu hiệu của LSN cuối cùng đã sửa đổi trang đó, được ghi lại bởi trang. Hãy suy nghĩ về nó như thế này, trang theo dõi LSN cuối cùng đã thực hiện sửa đổi cho nó. Đây là PageLSN.

Mỗi lần có một hoạt động sửa đổi trang được ghi lại, bản ghi nhật ký đó bao gồm một vài LSN. Cụ thể, LSN của bản ghi nhật ký (nghĩ ... LSN hiện tại ), và sau đó nó có LSN của Trang trước ( PrevPageLSNtiếp theo). Vì vậy, khi chúng tôi sửa đổi một trang, một trong những phần dữ liệu được đưa vào bản ghi nhật ký là những gì trang cho biết là LSN cuối cùng trước khi bạn sửa đổi trang .

Hãy suy nghĩ về nó như thế này ... Xe của bạn cần phải hoàn thành công việc. Cơ khí John làm việc trên xe của bạn, và trong khoang động cơ, nó có một thẻ nhỏ và Cơ khí John viết "John làm việc trên chiếc xe này lần cuối". Sau đó, lần tới khi bạn đưa xe vào một cửa hàng khác, Mechanic Mark nhìn vào khoang máy và thấy rằng Cơ khí John làm việc trên chiếc xe này lần cuối. Trên bảng dữ liệu của mình, ông viết thông tin này. Ý tưởng tương tự với SQL Server.

Điều này có thể hơi khó hiểu, vì vậy hãy xem hình ảnh này bên dưới về các sửa đổi trang liên tiếp và cách thức PageLSNvà PrevPageLSNliên quan:

Hãy quay lại, vì tất cả sẽ hoạt động khi bạn cần làm lại một thao tác trên một trang (khôi phục, khôi phục, HA, v.v.). Khi SQL Server cần làm lại một thao tác trang, nó sẽ kiểm tra độ tỉnh táo để xem liệu PageLSNtrên trang có khớp với PrevPageLSNbản ghi nhật ký bao gồm không. Nếu điều đó không bằng nhau, thì bạn sẽ thấy lỗi 3456 bị ném.

Liệu PageLSN bằng PrevPageLSN ? Không??? Dừng và tăng lỗi 3456 ...

Hãy phân tích thông báo lỗi của bạn, bao gồm cách thức:

Không thể làm lại bản ghi nhật ký (210388: 123648: 232), cho ID giao dịch (0: 1016710921), trên trang (4: 8088), cơ sở dữ liệu 'Một sốDB' (ID cơ sở dữ liệu 6). Trang: LSN = (0: 0: 1) , loại = 11. Nhật ký: OpCode = 4, bối cảnh 11, PrevPageLSN: (210388: 122007: 1) . Khôi phục từ bản sao lưu của cơ sở dữ liệu hoặc sửa chữa cơ sở dữ liệu. Msg 3013, Cấp 16, Bang 1, Dòng 1 RESTORE LOG đang chấm dứt bất thường.

Tôi đã in đậm hai phần dữ liệu có bất đẳng thức gây ra lỗi. Bạn có thể thấy rằng chúng tôi PageLSNlà 0: 0: 1 (cái này được tìm thấy trong tiêu đề của trang) và của chúng tôi PrevPageLSNlà 210388: 122007: 1 (cái này được tìm thấy trong dữ liệu trên bản ghi nhật ký đang cố gắng làm lại). Đây rõ ràng là không bằng nhau, do đó err3456.

Vì vậy, để tìm hiểu lý do tại sao của sự kiện này, sẽ là tìm hiểu tại sao có sự chênh lệch ở đây. Chúng tôi thực sự cần theo dõi vòng đời của trang 4: 8088 và xem nơi ngắt kết nối. Thật không may, không có thêm thông tin, hoặc xử lý sự cố thực tế, tôi không thể làm gì khác ngoài việc cung cấp cho bạn nền tảng của hoạt động khôi phục này và nguyên nhân gây ra lỗi.