Chia DBCC CHECKDB qua nhiều ngày


10

Tôi đang làm việc để triển khai phương pháp lan truyền thủ công DBCC CHECKDB của Paul Randal trong nhiều ngày cho các cơ sở dữ liệu rất lớn, về cơ bản bao gồm:

  • Chia các bảng trong cơ sở dữ liệu gần bằng nhau giữa 7 nhóm
  • Chạy DBCC CHECKALLOC hai lần một tuần
  • Chạy một DBCC CHECKCATALOG mỗi tuần một lần
  • Chạy KIỂM TRA DBCC trên một thùng mỗi ngày trong tuần

Có ai đã sử dụng kỹ thuật này? Bất kỳ kịch bản hiện có ngoài đó?

Tôi lo ngại điều này có thể không thực sự bao gồm mọi thứ mà CHECKDB làm; tài liệu Sách trực tuyến cho CHECKDB nói rằng ngoài CHECKALLOC, CHECKCATALOG và KIỂM TRA, nó cũng:

  • Xác thực nội dung của mọi chế độ xem được lập chỉ mục trong cơ sở dữ liệu.
  • Xác thực tính nhất quán ở cấp độ liên kết giữa siêu dữ liệu bảng và các thư mục và tệp hệ thống tệp khi lưu trữ dữ liệu varbinary (max) trong hệ thống tệp bằng cách sử dụng FILESTREAM. (Chỉ SQL 2008)
  • Xác thực dữ liệu Nhà môi giới dịch vụ trong cơ sở dữ liệu.

Vì vậy, đây là những câu hỏi của tôi:

  1. Là những kiểm tra bổ sung cần thiết / quan trọng? (Lượt xem được lập chỉ mục có thể liên quan nhiều hơn đến tôi một chút, tôi không nghĩ chúng ta đang sử dụng Nhà môi giới dịch vụ hoặc FILESTREAM.)

  2. Nếu vậy, có cách nào để thực hiện các kiểm tra bổ sung này một cách riêng biệt?

  3. CHECKALLOC và CHECKCATALOG dường như chạy rất nhanh, ngay cả trên các dbs lớn. Bất kỳ lý do để không chạy những thứ này mỗi ngày?

.


Paul đã trả lời một phiên bản của câu hỏi này trong các bình luận trên blog của mình. Anh ấy nói "Đừng lo lắng về việc xác thực chế độ xem được lập chỉ mục. Nó bị tắt theo mặc định từ năm 2008 trở đi vì nó không tìm thấy vấn đề."
BradC

Tôi đang làm việc để làm điều tương tự - bất kỳ lời khuyên / gotcha nào mà bạn tìm thấy, vì bạn có thể đã thực hiện điều này?
scsimon

1
@scsimon Tôi đã làm cho nó hoạt động tốt, xem câu hỏi liên quan này cho chiến lược cụ thể mà tôi đã sử dụng để phân chia các bảng. Tôi nghĩ rằng cuối cùng tôi đã lập một danh sách tổng thể của tất cả các bảng trong tất cả các cơ sở dữ liệu (lớn) trên toàn bộ máy chủ để chia thành các "nhóm" hàng ngày, điều này mang lại cho tôi sự phân chia đồng đều hơn nhiều so với việc chia riêng từng danh sách của cơ sở dữ liệu. Cơ sở dữ liệu nhỏ hơn Tôi vừa thực hiện một DBCC đầy đủ mỗi ngày và không phải là một phần của sự phân chia.
BradC

Câu trả lời:


6

Là những kiểm tra bổ sung cần thiết / quan trọng? (Lượt xem được lập chỉ mục có thể liên quan nhiều hơn đến tôi một chút, tôi không nghĩ chúng ta đang sử dụng Nhà môi giới dịch vụ hoặc FILESTREAM.)

Bạn có thể chạy DBCC CHECKTABLE WITH EXTENDED_LOGICAL_CHECKS trực tiếp trên các khung nhìn được lập chỉ mục . Kiểm tra các khung nhìn được lập chỉ mục có thể có vấn đề trong một số trường hợp nhất định , vì vậy hãy chuẩn bị để điều tra bất kỳ kết quả dương tính giả nào. (Paul Randal cũng đề cập trong các bình luận cho bài viết được tham chiếu rằng cũng có thể phủ định sai, nhưng tôi không có kinh nghiệm trực tiếp về điều đó.)

Nếu vậy, có cách nào để thực hiện các kiểm tra bổ sung này một cách riêng biệt?

Không có hỗ trợ để chạy Nhà môi giới dịch vụ hoặc FILESTREAMkiểm tra riêng, không.

CHECKALLOCCHECKCATALOGdường như chạy rất nhanh, ngay cả trên các dbs lớn. Bất kỳ lý do để không chạy những thứ này mỗi ngày?

Không phải là tôi biết.


Bạn cũng có thể xem xét việc chạy DBCC CHECKCONSTRAINTS. Kiểm tra này không được bao gồm trong DBCC CHECKDB, bất kể tùy chọn nào bạn có thể chỉ định. Bạn cũng có thể muốn nghĩ về việc thỉnh thoảng chạy CHECKDB, và khi hoàn cảnh cho phép.


6

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 CHECKTABLEcùng với chạy DBCC CHECKALLOCDBCC 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 CHECKALLOCDBCC 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 NOINDEXtù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:

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.