Sửa chữa các trang không nhất quán trong cơ sở dữ liệu

Chúng tôi có SQL 2000 DB. Máy chủ bị sập do lỗi mảng Raid. Bây giờ khi chúng tôi chạy DBCC CHECKDB, chúng tôi nhận được một lỗi rằng có 27 lỗi nhất quán trong 9 trang.

Khi chúng tôi chạy TRANG DBCC trên các trang này, chúng tôi nhận được điều này:

Msg 8939, Level 16, State 106, Line 1
Table error: Object ID 1397580017, index ID 2, page (1:8404521). Test (m_freeCnt == freeCnt) failed. Values are 2 and 19.
Msg 8939, Level 16, State 108, Line 1
Table error: Object ID 1397580017, index ID 2, page (1:8404521). Test (emptySlotCnt == 0) failed. Values are 1 and 0.

Vì chỉ mục được chỉ định là không được phân cụm và được tạo bởi một hằng số duy nhất bao gồm 2 cột, chúng tôi đã thử thả và tạo lại chỉ mục. Điều này dẫn đến lỗi sau:

CREATE UNIQUE INDEX terminated because a duplicate key was found for index ID 2. Most significant primary key is '3280'. 
The statement has been terminated.

Tuy nhiên đang chạy

Select var_id,result_on
from tests
group by var_id,result_on
having count(*)>1

trả về 0 hàng.

Đây là những gì chúng tôi dự định làm:

Khôi phục bản sao sự cố máy chủ trước DB và chạy DBCC CHECKDB
Nếu điều đó trở lại sạch sẽ, sau đó khôi phục lại mà không cần phục hồi
Áp dụng tất cả các bản sao lưu TLOG không đầy đủ
Dừng ứng dụng sản xuất, sao lưu nhật ký đuôi và cũng áp dụng điều đó
Bỏ prod DB và đổi tên DB mới được khôi phục để biến nó thành prod
Bắt đầu ứng dụng prod

Ai đó có thể xin vui lòng đục lỗ trong phương pháp này? Có lẽ, đề nghị một cách tiếp cận khác nhau? Những gì chúng ta cần là thời gian chết tối thiểu.

SQL 2000 DB Kích thước 94 GB Bảng có các trang bị hỏng có 460 triệu + hàng dữ liệu

Cảm ơn đã giúp đỡ.

Raj

sql-server dbcc

Tôi thích cách tiếp cận của bạn. Có nghĩa với tôi. Có lẽ giữ cơ sở dữ liệu bị hỏng bên cạnh, vì bảo hiểm ...

— user24161

Ngoài ra, khi mọi thứ ổn định, hãy lên kế hoạch nâng cấp 2008 hoặc 2008 :-)

— user24161

(nghĩa là nâng cấp năm 2005 hoặc 2008)

— user24161

+1 để có kế hoạch khôi phục hợp lệ và rất phù hợp

— Andrew

Câu trả lời:

Giải pháp phục hồi của bạn là cách sách giáo khoa để tiến hành. Giả sử bạn có các bản sao lưu phù hợp và miễn là bạn có thể sao lưu nhật ký giao dịch cho cơ sở dữ liệu bị hỏng, thì chiến lược của bạn là cuốn sách văn bản cần thực hiện.

Tuy nhiên, trước khi tiếp tục, bạn đã xem xét khả năng chỉ tạo lại bảng bị ảnh hưởng chưa?

Đôi khi bạn có thể thoát khỏi việc tạo một bản sao chính xác của bảng bị ảnh hưởng bằng cách thực hiện

select *
into NewTableFromOld
from DamagedTable

Sau đó, chỉ cần thả / trao đổi bảng bị hỏng với bảng mới, ghi nhớ để thêm các ràng buộc và chỉ mục thích hợp.

— John Sansom
nguồn

Cảm ơn vì sự trả lời. Cách tiếp cận của bạn có vẻ tốt, nhưng mối quan tâm là, xem xét rằng bảng có 461 triệu hàng dữ liệu, điều gì sẽ tác động đến sản xuất khi tôi chọn *? Điều đó sẽ không có một khóa và đạt hiệu suất?

Không, nếu bạn sử dụng gợi ý truy vấn với (nolock) không. Tuy nhiên, bạn có thể xác thực rằng không có gì thay đổi giữa bảng nguồn và bảng đích trong khi bạn lấy bản sao. Điều này có thể sẽ được yêu cầu trong quá trình xây dựng bảng dù thế nào đi nữa nếu bạn không ngăn ứng dụng thực hiện thay đổi. Sẽ có hiệu suất đĩa trên đầu trong một hoạt động như vậy.

— John Sansom

Cá nhân tôi sẽ thử phương pháp này trước, bạn có thể thực hiện với tùy chọn nolock để thử nghiệm, bạn cũng có thể kiểm tra thời gian cần thiết. Nếu nó hoạt động như bình thường, thì tôi sẽ đặt db ở chế độ người dùng đơn trong khi thực hiện lại, để đảm bảo rằng không có thay đổi nào xảy ra trong khi quá trình đang chạy. Thời gian chết sẽ ngắn hơn nhiều trong cách tiếp cận này, nếu nó hoạt động.

— trọc

Nếu bạn định làm điều này, tôi khuyên bạn nên tạo bảng trước (bằng cách viết ra bảng gốc). Sau đó sử dụng "CHERTN VÀO newTable CHỌN" so với "CHỌN VÀO". Bạn có thể gặp vấn đề về hiệu suất với "CHỌN VÀO".

— SQL3D

Trước tiên, tôi nên thử lấy dữ liệu ra để gửi dữ liệu và sau đó gửi dữ liệu lại vào một bảng mới. CHỌN VÀO không phù hợp (IMO) cho số lượng hồ sơ đó ...

— m4rty
nguồn