SQL Server đã phát hiện lỗi I / O dựa trên tính nhất quán logic: pageid không chính xác trên RESTORE


7

Việc khôi phục cơ sở dữ liệu của chúng tôi sang phần cứng máy chủ mới không thành công với lỗi trang.

Message
SQL Server detected a logical consistency-based I/O error: 
incorrect pageid (expected 49:8125916; actual 49:29097436).
It occurred during a read of page (49:8125916) in database ID 7 at
offset 0x00000f7fbb8000 in file x:\Databases\Data07\DataWarehouse_OperationalData_15.ndf'.
Additional messages in the SQL Server error log or system event
log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately.
Complete a full database consistency check (DBCC CHECKDB). 
This error can be caused by many factors; 
for more information, see SQL Server Books Online.

Một DBCC CheckDB sẽ đưa chúng ta khoảng một tuần trên cơ sở dữ liệu 70 TB này và máy chủ 6 năm tuổi.
Có bất kỳ cơ hội nào đó là bản sao lưu của tôi bị hỏng không?
Hoặc máy chủ mới có lỗi?
Hay là cơ sở dữ liệu sản xuất trên máy chủ cũ là vấn đề?

Đây là SQL Server 2016 SP1 CU1 và page_verify_option_desc là CHECKSUM.

Đây là những gì tôi có thể thấy từ nhật ký lỗi trên máy chủ mới:

Starting up database 'DataWarehouse'.
The database 'DataWarehouse' is marked RESTORING and is in a state that does not allow recovery to be run.
Error: 824, Severity: 16, State: 2.
SQL Server detected a logical consistency-based I/O error: incorrect pageid (expected 49:8125916; actual 49:29097436). It occurred during a read of page (49:8125916) in database ID 7 at offset 0x00000f7fbb8000 in file 'S:\MSSQL\DSA\Databases\DataWarehouse\Data07\DataWarehouse_OperationalData_15.ndf'.  Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.
Error: 18456, Severity: 14, State: 38.

Khi tôi chạy cái này trên máy chủ cũ:

DBCC TRACEON (3604);
DBCC PAGE ('datawarehouse', 49, 8125916, 0);

Tôi hiểu rồi

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

PAGE: (49:8125916)


BUFFER:


BUF @0x000000802C5E9300

bpage = 0x0000004DF03E8000          bhash = 0x0000000000000000          bpageno = (49:8125916)
bdbid = 5                           breferences = 1                     bcputicks = 0
bsampleCount = 0                    bUse1 = 5844                        bstat = 0x9
blog = 0x15ab215a                   bnext = 0x0000000000000000          bDirtyContext = 0x0000000000000000
bstat2 = 0x0                        

PAGE HEADER:


Page @0x0000004DF03E8000

m_pageId = (49:8125916)             m_headerVersion = 1                 m_type = 3
m_typeFlagBits = 0x0                m_level = 0                         m_flagBits = 0xa200
m_objId (AllocUnitId.idObj) = 10814647                                   m_indexId (AllocUnitId.idInd) = 256
Metadata: AllocUnitId = 72058302786633728                                
Metadata: PartitionId = 72058370492596224                                Metadata: IndexId = 1
Metadata: ObjectId = 1916450641     m_prevPage = (0:0)                  m_nextPage = (0:0)
pminlen = 0                         m_slotCnt = 2                       m_freeCnt = 2452
m_freeData = 5764                   m_reservedCnt = 0                   m_lsn = (2455108:11140830:20)
m_xactReserved = 0                  m_xdesId = (28:447547798)           m_ghostRecCnt = 0
m_tornBits = 31453216               DB Frag ID = 1                      

Allocation Status

GAM (49:7668480) = ALLOCATED        SGAM (49:7668481) = NOT ALLOCATED   
PFS (49:8120352) = 0x42 ALLOCATED  80_PCT_FULL                           DIFF (49:7668486) = CHANGED
ML (49:7668487) = NOT MIN_LOGGED    


DBCC execution completed. If DBCC printed error messages, contact your system administrator.

DBCC CHECKFILEGROUP hiện đang chạy. Kết thúc với lỗi ra.

SeanGallardy bình luận về các số nhị phân. Phải mất một thời gian dài tôi mới hiểu ý anh ta, nhưng cuối cùng tôi đã nhập hai số trong Máy tính Windows ở chế độ Lập trình viên, và đây là những gì nó hiển thị: màu đỏ cho thấy sự khác biệt

Cập nhật: Chúng tôi đã thực hiện sao lưu và khôi phục từ máy chủ cũ sang máy chủ mới. Lần này chúng tôi nhận được tin nhắn này:

Could not redo log record (2456609:4261461:64), for transaction ID (28:972770238), on page (48:211577379), allocation unit 72058359886184448, database 'DataWarehouse' (database ID 7). 
Page: LSN = (2456609:3279166:236), allocation unit = 72058351460417536, type = 20. Log: OpCode = 2, context 5, PrevPageLSN: (2456609:4250688:2). 
Restore from a backup of the database, or repair the database.

Tôi đã cố gắng gửi cho Google thông báo này, nhưng lời khuyên duy nhất tôi có thể tìm thấy là khôi phục cơ sở dữ liệu (đó là những gì tôi đang cố gắng).

Câu hỏi thực sự là; tôi nên làm gì tiếp theo?


3
Vì bạn có số trang, bạn có thể thấy nếu bạn có thể đọc trang đó khi sản xuất mặc dù tôi chắc chắn sẽ rất cố gắng để đảm bảo bạn có bản sao lưu đáng tin cậy mà bạn có thể khôi phục ở đâu đó trước.
Max Vernon

1
Phiên bản nào của SQL Server này? Bạn có thể thực hiện khôi phục trang nếu bạn đang sử dụng ít nhất năm 2008
Tara Kizer

1
Máy chủ sản xuất có bật xác minh trang tổng kiểm tra không?
Max Vernon

3
Có một sự khác biệt hai byte giữa hai giá trị trong các byte quan trọng nhất. Đây có thể là một vấn đề với bộ đệm của bộ điều khiển, vấn đề IO được đệm trên bản sao tệp, v.v. Tôi cũng sẽ kiểm tra kỹ phần cứng và trình điều khiển. Ngoài ra, bạn không cần thực hiện toàn bộ checkdb, chỉ cần nhắm mục tiêu tệp, bảng và phân bổ mà có các lệnh checkdb.
Sean Gallardy - Người dùng đã nghỉ hưu

1
@MaxVernon; chúng tôi đang cố gắng khôi phục bản sao lưu lên một máy chủ mới. Phải mất 3 ngày để di chuyển các tệp sao lưu 25TB đến Copenhagen. Sau đó RESTORE thất bại. Bummer. Tôi sẽ cố gắng để CheckAlloc và / hoặc CheckFilegroup chạy vào sáng mai. Cập nhật câu hỏi.
Henrik Staun Poulsen

Câu trả lời:


1

Bạn không có bản sao lưu cho đến khi bạn thực hiện khôi phục .

Câu hỏi thực sự là; tôi nên làm gì tiếp theo?

Điều này nghe có vẻ không phải là 'câu trả lời' cho câu hỏi DBA.SE, nhưng thật lòng mà nói, lựa chọn hợp lý duy nhất của bạn ở đây là mở một trường hợp hỗ trợ với Microsoft và yêu cầu hỗ trợ, hoặc thuê một chuyên gia (công ty tư vấn hoặc công ty có uy tín) có chứng minh hồ sơ sửa chữa các vấn đề tham nhũng SQL Server. Nếu bạn không đủ khả năng cho các tùy chọn này, điều đó có nghĩa là dữ liệu không có giá trị.


Xin chào Remus; Trường hợp được tạo với trạng thái B, vì vậy bây giờ Microsoft phải đến 10 giờ sáng ngày mai để phản ứng. Cảm ơn sự giúp đỡ của bạn.
Henrik Staun Poulsen

chào Remus; Nó đã giúp đỡ. Microsoft đã đề xuất một RESTORE với CONTINUE_AFTER_ERROR. Điều đó đã cho chúng tôi một số trang, cho chúng tôi một tên bảng. Mà tôi đánh rơi. Họ cũng đề nghị chúng tôi xóa nhật ký hoàn toàn, và sau đó sao lưu lên 2TB. Sau khi làm cả hai, sao lưu và khôi phục làm việc mà không có vấn đề. Cảm ơn tất cả sự giúp đỡ của bạn.
Henrik Staun Poulsen

1
Cảm ơn bạn đã đăng đề xuất để những người khác có thể xem và thử
Remus Rusanu

1

Henrik,

Cố gắng cung cấp đầu ra của DBCC CHECKDB. Bạn nên đọc chủ đề này: Lỗi I / O dựa trên tính nhất quán của DBCC CHECKDB

Tôi hy vọng nó sẽ giúp bạn.

Chúc may mắn!


như tôi đã viết; Một DBCC CheckDB sẽ đưa chúng tôi khoảng một tuần và ngay cả khi chúng tôi có nhật ký giao dịch 4 TB, điều đó sẽ không đủ lớn.
Henrik Staun Poulsen

DDBC CheckDB chỉ mất 3 ngày rưỡi trên máy chủ mới, với MaxDOP = 40. Nó "tìm thấy 0 lỗi và sửa chữa 0 lỗi."
Henrik Staun Poulsen
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.