DBCC CHECKDB rất quan trọng đối với cơ sở dữ liệu SQL Server để chắc chắn 100% rằng không có tham nhũng. Tuy nhiên, do cơ sở dữ liệu phát triển kích thước khổng lồ, rất khó để tìm thấy một cửa sổ bảo trì khi bạn tuyên bố là 24x7 trở lên. Trong những năm qua, nhóm SQL Server đã triển khai các cơ chế khác nhau sẽ phát hiện hầu hết các dạng tham nhũng phổ biến, đặc biệt liên quan đến tham nhũng vật lý do phần cứng gây ra.
SQL Server 2005 trở lên có PAGE_VERIFY = CHECKSUM có thể giúp bạn chủ động phát hiện tham nhũng vật lý trong các trang cơ sở dữ liệu, do đó thêm một tổng kiểm tra vào mỗi trang khi nó được ghi vào hệ thống I / O và xác nhận tổng kiểm tra khi nó được đọc từ đĩa.
Ngoài ra, sao lưu (đầy đủ hoặc khác biệt) với CHECKSUM sẽ đảm bảo phát hiện bất kỳ tham nhũng I / O nào do phần cứng gây ra.
Do đó, từ khía cạnh phần cứng của tham nhũng, SQL Server thực hiện tốt việc phát hiện và báo cáo nó. (Đảm bảo đặt cả Cảnh báo tham nhũng quan trọng ).
Điều đó đang được nói, vẫn còn lỗi logic , lỗi do scribbler gây ra - trong đó các trang trong bộ nhớ bị hỏng bởi mã của bên thứ ba chạy bên trong quy trình SQL Server hoặc bởi trình điều khiển hoặc phần mềm khác có đủ đặc quyền thực thi trong chế độ nhân Windows và / hoặc SQL Server Lỗi , v.v. không thể phát hiện được bằng các phương thức trên và do đó CHECKDB xuất hiện.
DBCC CHECKDB thực hiện kiểm tra kỹ lưỡng hơn bao gồm kiểm tra các tiêu đề trang về khả năng tham nhũng có thể không phát hiện được bằng bất kỳ phương tiện nào khác.
Bất kỳ kịch bản hiện có ngoài đó?
Thay vì phát minh lại bánh xe, tôi thực sự khuyên bạn nên xem qua giải pháp Kiểm tra tính toàn vẹn máy chủ SQL của Ola
Chạy DBCC CHECKDB một cách hiệu quả:
Bạn chỉ cần sáng tạo khi bạn chặt chẽ trong cửa sổ bảo trì có cơ sở dữ liệu lớn hoặc số lượng cơ sở dữ liệu cao để chạy CHECKDB.
Sau khi tham gia khóa đào tạo SQLSkills, những gì tôi đã triển khai trong môi trường của mình là:
- ưu tiên những bảng nào là quan trọng để kiểm tra.
- tách các bảng thành các nhóm với các ưu tiên khác nhau và sau đó chạy
DBCC CHECKTABLE
cùng với chạy DBCC CHECKALLOC
vàDBCC CHECKCATALOG
- Tạo một bảng worker sẽ lưu trữ các tên bảng với mức độ ưu tiên. Chỉ cần đảm bảo rằng tất cả các bảng có mức độ ưu tiên cao (rất lớn) không nằm trong một nhóm nào khác, CHECKDB của bạn sẽ không hoàn thành.
- Bạn thậm chí có thể có một cột thời gian chờ trong bảng worker của mình sẽ được sắp xếp khi CHECKDB của bạn sẽ bị giết khi nó đã qua cửa sổ bảo trì
- Thêm mất bao lâu cho mỗi bảng để chạy
DBCC CHECKTABLE
, DBCC CHECKALLOC
và DBCC CHECKCATALOG
. Vì vậy mà bạn có thể nhận được một cảm giác về bao lâu nó được thường dùng để kiểm tra của bạn để chạy.
- Bạn thậm chí có thể chạy với
NOINDEX
tùy chọn vì nó sẽ tăng tốc hoạt động vì nó không kiểm tra các Chỉ mục không được nhóm trên bảng người dùng. Điều này có một số lợi thế vì nó không quá quan trọng vì Dữ liệu bị hỏng do không có dữ liệu nào bị mất và bạn có thể bỏ và tạo lại Chỉ mục nếu cần.
Rõ ràng, phiên bản Enterprise có thể tận dụng việc thực thi song song các câu lệnh DBCC, nhưng hãy chú ý đến cài đặt MAXDOP vì cuối cùng có thể lấy hết CPU của bạn. Điều này có thể bị giới hạn bởi Thống đốc tài nguyên.
Lưu ý: Nếu bạn đang có cột SPARSE, thì CHECKDB của bạn sẽ bị chết chậm như được mô tả ở đây .
Cuối cùng, đó là cách ngăn chặn tham nhũng cơ sở dữ liệu bằng cách sử dụng tất cả các bộ công cụ có sẵn + niềm tin của bạn vào hệ thống phần cứng máy chủ cơ sở dữ liệu của bạn và quan trọng nhất là giá trị của dữ liệu của bạn.
Một số tài liệu tham khảo tuyệt vời: