Giảm thiểu tác động của DBCC CHECKDB:DO và DONTs

Trách nhiệm của bạn với tư cách là một DBA (hoặc ) có thể bao gồm những thứ như điều chỉnh hiệu suất, lập kế hoạch năng lực và khôi phục sau thảm họa. Điều mà nhiều người có xu hướng quên hoặc trì hoãn là đảm bảo tính toàn vẹn của cấu trúc cơ sở dữ liệu của họ (cả logic và vật lý); bước quan trọng nhất là DBCC CHECKDB . Bạn có thể bắt đầu làm việc ở đó bằng cách tạo một kế hoạch bảo trì đơn giản với "Kiểm tra tính toàn vẹn của cơ sở dữ liệu" - tuy nhiên, theo tôi, đây chỉ là đánh dấu một hộp kiểm.

Nếu bạn nhìn kỹ hơn, bạn có thể làm rất ít điều để kiểm soát cách thức hoạt động của nhiệm vụ. Ngay cả bảng Thuộc tính khá rộng cũng hiển thị rất nhiều cài đặt cho kế hoạch phụ bảo trì, nhưng hầu như không có gì về DBCC lệnh nó sẽ chạy. Cá nhân tôi nghĩ rằng bạn nên thực hiện một cách tiếp cận chủ động và có kiểm soát hơn nhiều đối với cách bạn thực hiện CHECKDB của mình hoạt động trong môi trường sản xuất, bằng cách tạo công việc của riêng bạn và tạo thủ công DBCC của bạn các lệnh. Bạn có thể điều chỉnh lịch biểu của mình hoặc bản thân các lệnh cho phù hợp với các cơ sở dữ liệu khác nhau - ví dụ:cơ sở dữ liệu thành viên ASP.NET có thể không quan trọng như cơ sở dữ liệu bán hàng của bạn và có thể chịu được việc kiểm tra thường xuyên hơn và / hoặc ít kỹ lưỡng hơn.

Nhưng đối với cơ sở dữ liệu quan trọng của bạn, tôi nghĩ tôi sẽ tổng hợp một bài đăng để trình bày chi tiết một số điều tôi sẽ điều tra để giảm thiểu sự gián đoạn DBCC các lệnh có thể gây ra - và bạn nên cảnh giác với những huyền thoại và sự huyên náo tiếp thị nào. Và tôi muốn cảm ơn Paul "Mr. DBCC" Randal (@PaulRandal) vì đã cung cấp thông tin đóng góp có giá trị - không chỉ cho bài đăng cụ thể này mà còn cả những lời khuyên vô tận mà anh ấy cung cấp trên blog của mình, #sqlhelp và trong khóa đào tạo SQLskills Immersion.

Vui lòng bỏ qua tất cả các ý tưởng này và cố gắng hết sức để thực hiện thử nghiệm đầy đủ trong môi trường của bạn - không phải tất cả các đề xuất này sẽ mang lại hiệu suất tốt hơn trong mọi môi trường. Nhưng bạn nợ chính mình, người dùng và các bên liên quan của bạn ít nhất phải xem xét tác động mà CHECKDB của bạn các hoạt động có thể có và thực hiện các bước để giảm thiểu những ảnh hưởng đó nếu khả thi - mà không gây ra rủi ro không cần thiết do không kiểm tra những thứ phù hợp.

Giảm tiếng ồn và loại bỏ tất cả các lỗi

Cho dù bạn đang chạy ở đâu CHECKDB , luôn sử dụng WITH NO_INFOMSGS lựa chọn. Điều này chỉ đơn giản là loại bỏ tất cả đầu ra không liên quan chỉ cho bạn biết có bao nhiêu hàng trong mỗi bảng; nếu bạn quan tâm đến thông tin đó, bạn có thể lấy nó từ các truy vấn đơn giản đối với DMV chứ không phải trong khi DBCC đang chạy. Việc loại bỏ đầu ra giúp bạn ít có khả năng bỏ lỡ một thông điệp quan trọng bị chôn vùi trong tất cả đầu ra vui vẻ đó.

Tương tự, bạn phải luôn sử dụng WITH ALL_ERRORMSGS , nhưng đặc biệt nếu bạn đang chạy SQL Server 2008 RTM hoặc SQL Server 2005 (trong những trường hợp đó, bạn có thể thấy danh sách lỗi cho mỗi đối tượng được cắt ngắn thành 200). Đối với bất kỳ CHECKDB nào các hoạt động khác ngoài việc kiểm tra đặc biệt nhanh chóng, bạn nên xem xét chuyển hướng đầu ra vào một tệp. Management Studio được giới hạn ở 1000 dòng đầu ra từ DBCC CHECKDB , vì vậy bạn có thể bỏ sót một số lỗi nếu vượt quá con số này.

Mặc dù không hoàn toàn là một vấn đề về hiệu suất, nhưng việc sử dụng các tùy chọn này sẽ giúp bạn không phải chạy lại quy trình. Điều này đặc biệt quan trọng nếu bạn đang trong quá trình khắc phục thảm họa.

Giảm tải kiểm tra lôgic nếu có thể

Trong hầu hết các trường hợp, CHECKDB dành phần lớn thời gian để thực hiện kiểm tra logic dữ liệu. Nếu bạn có khả năng thực hiện các kiểm tra này trên bản sao y bản chính của dữ liệu, bạn có thể tập trung nỗ lực vào cấu trúc vật lý của hệ thống sản xuất của mình và sử dụng máy chủ phụ để xử lý tất cả các kiểm tra logic và giảm bớt tải từ máy chủ chính. Bởi máy chủ phụ , Ý tôi chỉ là những điều sau:

• Nơi bạn kiểm tra các khôi phục hoàn toàn của mình - vì bạn kiểm tra các khôi phục của mình, phải không?

Những người khác (đáng chú ý nhất là lực lượng tiếp thị khổng lồ là Microsoft) có thể đã thuyết phục bạn rằng các dạng máy chủ phụ khác phù hợp với DBCC Séc. Ví dụ:

• một Nhóm Luôn sẵn sàng có thể đọc được thứ cấp;
• ảnh chụp nhanh của cơ sở dữ liệu được sao chép;
• một nhật ký được vận chuyển thứ cấp;
• Phản chiếu SAN;
• hoặc các biến thể khác…

Thật không may, đây không phải là trường hợp, và không có bản thứ hai nào là nơi hợp lệ, đáng tin cậy để thực hiện kiểm tra của bạn như một sự thay thế cho kiểm tra chính. Chỉ một bản sao lưu một cho một có thể dùng như một bản sao y thực; bất kỳ thứ gì khác dựa vào những thứ như ứng dụng sao lưu nhật ký để đạt được trạng thái nhất quán sẽ không phản ánh một cách đáng tin cậy các vấn đề về tính toàn vẹn trên chính.

Vì vậy, thay vì cố gắng giảm tải các kiểm tra logic của bạn xuống thứ yếu và không bao giờ thực hiện chúng trên kiểm tra chính, đây là những gì tôi đề xuất:

1. Đảm bảo rằng bạn thường xuyên kiểm tra việc khôi phục các bản sao lưu đầy đủ của mình. Và không, điều này không bao gồm COPY_ONLY sao lưu từ AG thứ cấp, vì những lý do tương tự như trên - điều đó sẽ chỉ hợp lệ trong trường hợp bạn vừa bắt đầu thứ cấp với khôi phục đầy đủ.
2. Chạy DBCC CHECKDB thường chống lại sự đầy đủ khôi phục, trước khi làm bất cứ điều gì khác. Một lần nữa, việc phát lại các bản ghi nhật ký tại thời điểm này sẽ làm mất hiệu lực cơ sở dữ liệu này dưới dạng bản sao đúng của nguồn.
3. Chạy DBCC CHECKDB chống lại chính của bạn, có lẽ được chia nhỏ theo những cách mà Paul Randal gợi ý, và / hoặc theo một lịch trình ít thường xuyên hơn và / hoặc sử dụng PHYSICAL_ONLY thường xuyên hơn không. Điều này có thể phụ thuộc vào mức độ thường xuyên và đáng tin cậy của bạn (2).
4. Đừng bao giờ cho rằng kiểm tra đối với phụ là đủ. Ngay cả với một bản sao chính xác của cơ sở dữ liệu chính của bạn, vẫn có những sự cố vật lý có thể xảy ra trên hệ thống con I / O của hệ thống chính của bạn sẽ không bao giờ lây lan sang hệ thống thứ cấp.
5. Luôn phân tích DBCC đầu ra. Chỉ chạy nó và bỏ qua nó, để đánh dấu nó ra khỏi danh sách nào đó, cũng hữu ích như chạy các bản sao lưu và tuyên bố thành công mà không cần kiểm tra để bạn thực sự có thể khôi phục bản sao lưu đó khi cần.

Thử nghiệm với cờ theo dõi 2549, 2562 và 2566

Tôi đã thực hiện một số thử nghiệm kỹ lưỡng đối với hai cờ theo dõi (2549 và 2562) và nhận thấy rằng chúng có thể mang lại những cải tiến hiệu suất đáng kể, tuy nhiên Lonny báo cáo rằng chúng không còn cần thiết hoặc hữu ích nữa. Nếu bạn đang sử dụng phiên bản 2016 trở lên, hãy bỏ qua toàn bộ phần này . Nếu bạn đang sử dụng phiên bản cũ hơn, hai cờ theo dõi này được mô tả chi tiết hơn trong KB # 2634571, nhưng về cơ bản:

• Cờ theo dõi 2549
  • Điều này tối ưu hóa quy trình checkdb bằng cách coi từng tệp cơ sở dữ liệu riêng lẻ như nằm trên một đĩa cơ bản duy nhất. Điều này có thể sử dụng nếu cơ sở dữ liệu của bạn có một tệp dữ liệu duy nhất hoặc nếu bạn biết rằng trên thực tế, mỗi tệp cơ sở dữ liệu nằm trên một ổ đĩa riêng biệt. Nếu cơ sở dữ liệu của bạn có nhiều tệp và chúng dùng chung một trục quay gắn trực tiếp, bạn nên cảnh giác với cờ theo dõi này, vì nó có thể gây hại nhiều hơn lợi.

    QUAN TRỌNG :sql.sasquatch báo cáo hồi quy trong hành vi cờ theo dõi này trong SQL Server 2014.
    

• Cờ theo dõi 2562
  • Cờ này coi toàn bộ quy trình checkdb là một đợt duy nhất, với chi phí sử dụng tempdb cao hơn (lên đến 5% kích thước cơ sở dữ liệu).
  • Sử dụng thuật toán tốt hơn để xác định cách đọc các trang từ cơ sở dữ liệu, giảm sự tranh chấp chốt (cụ thể cho DBCC_MULTIOBJECT_SCANNER ). Lưu ý rằng cải tiến cụ thể này nằm trong đường dẫn mã SQL Server 2012, vì vậy bạn sẽ được hưởng lợi từ nó ngay cả khi không có cờ theo dõi. Điều này có thể tránh được các lỗi như:Đã xảy ra
    hết thời gian chờ khi chờ chốt:class 'DBCC_MULTIOBJECT_SCANNER'.
• Hai cờ theo dõi trên có sẵn trong các phiên bản sau:

  Bản cập nhật tích lũy SQL Server 2008 Service Pack 2 9+
  (10.00.4330 -> 10.00.5499)

  SQL Server 2008 gói dịch vụ 3 Cập nhật tích lũy 4+
  (10.00.5775+)

  Bản cập nhật tích lũy SQL Server 2008 R2 RTM 11+
  (10.50.1809 -> 10.50.2424)

  SQL Server 2008 R2 Gói dịch vụ 1 Cập nhật tích lũy 4+
  (10.50.2796 -> 10.50.3999)

  SQL Server 2008 R2 Gói dịch vụ 2
  (10.50.4000+)

  SQL Server 2012, tất cả các phiên bản
  (11.00.2100+)

• Cờ theo dõi 2566
  • Nếu bạn vẫn đang sử dụng SQL Server 2005, cờ theo dõi này, được giới thiệu trong 2005 SP2 CU # 9 (9.00.3282) (mặc dù không được ghi lại trong bài viết Cơ sở Kiến thức của Bản Cập Nhật Tích lũy, KB # 953752), sẽ cố gắng sửa hiệu suất kém trong tổng số DATA_PURITY kiểm tra trên các hệ thống dựa trên x64. Tại một thời điểm, bạn có thể xem thêm chi tiết trong KB # 945770, nhưng có vẻ như bài viết đó đã bị loại bỏ khỏi cả trang web hỗ trợ của Microsoft và máy WayBack. Cờ theo dõi này không cần thiết trong các phiên bản SQL Server hiện đại hơn, vì sự cố trong bộ xử lý truy vấn đã được khắc phục.

Nếu bạn định sử dụng bất kỳ cờ theo dõi nào trong số này, tôi thực sự khuyên bạn nên đặt chúng ở cấp phiên bằng cách sử dụng DBCC TRACEON chứ không phải như một cờ theo dõi khởi động. Nó không chỉ cho phép bạn tắt chúng mà không cần phải chạy SQL Server, mà còn cho phép bạn triển khai chúng chỉ khi thực hiện một số CHECKDB các lệnh, trái ngược với các hoạt động sử dụng bất kỳ loại sửa chữa nào.

Giảm tác động I / O:tối ưu hóa tempdb

DBCC CHECKDB có thể sử dụng nhiều tempdb, vì vậy hãy đảm bảo rằng bạn có kế hoạch sử dụng tài nguyên ở đó. Đây thường là điều tốt nên làm trong mọi trường hợp. Đối với CHECKDB bạn sẽ muốn phân bổ đúng không gian cho tempdb; điều cuối cùng bạn muốn là cho CHECKDB tiến độ (và bất kỳ hoạt động đồng thời nào khác) phải đợi tự động duyệt. Bạn có thể lấy ý tưởng cho các yêu cầu bằng cách sử dụng WITH ESTIMATEONLY , như Paul giải thích ở đây. Chỉ cần lưu ý rằng ước tính có thể khá thấp do lỗi trong SQL Server 2008 R2. Ngoài ra, nếu bạn đang sử dụng cờ theo dõi 2562, hãy đảm bảo đáp ứng các yêu cầu về không gian bổ sung.

Và tất nhiên, tất cả các lời khuyên điển hình để tối ưu hóa tempdb trên bất kỳ hệ thống nào cũng phù hợp ở đây:hãy đảm bảo tempdb ở trên bộ nhanh của riêng nó. trục xoay, hãy đảm bảo rằng nó có kích thước phù hợp với tất cả các hoạt động đồng thời khác mà không cần phải phát triển, đảm bảo rằng bạn đang sử dụng số lượng tệp dữ liệu tối ưu, v.v. Một số tài nguyên khác mà bạn có thể xem xét:

• Tối ưu hóa Hiệu suất tempdb (MSDN)
• Lập kế hoạch năng lực cho tempdb (MSDN)
• Chuyện hoang đường về DBA SQL Server mỗi ngày:(30/12) tempdb phải luôn có một tệp dữ liệu cho mỗi lõi bộ xử lý

Giảm tác động I / O:kiểm soát ảnh chụp nhanh

Để chạy CHECKDB , các phiên bản SQL Server hiện đại sẽ cố gắng tạo một ảnh chụp nhanh ẩn cơ sở dữ liệu của bạn trên cùng một ổ đĩa (hoặc trên tất cả các ổ đĩa nếu tệp dữ liệu của bạn trải dài trên nhiều ổ đĩa). Bạn không thể kiểm soát cơ chế này, nhưng nếu bạn muốn kiểm soát CHECKDB ở đâu hoạt động, tạo ảnh chụp nhanh của riêng bạn trước (bắt buộc phải có Phiên bản doanh nghiệp) trên bất kỳ ổ đĩa nào bạn thích và chạy DBCC lệnh chống lại ảnh chụp nhanh. Trong cả hai trường hợp, bạn sẽ muốn chạy thao tác này trong thời gian chết tương đối, để giảm thiểu hoạt động sao chép-ghi sẽ diễn ra trong ảnh chụp nhanh. Và bạn sẽ không muốn lịch biểu này xung đột với bất kỳ thao tác ghi nặng nào, như duy trì chỉ mục hoặc ETL.

Bạn có thể đã thấy các đề xuất buộc CHECKDB để chạy ở chế độ ngoại tuyến bằng cách sử dụng WITH TABLOCK lựa chọn. Tôi thực sự khuyên bạn không nên tiếp cận này. Nếu cơ sở dữ liệu của bạn đang được sử dụng, việc chọn tùy chọn này sẽ chỉ khiến người dùng bực bội. Và nếu cơ sở dữ liệu không được sử dụng tích cực, bạn sẽ không tiết kiệm bất kỳ dung lượng ổ đĩa nào bằng cách tránh một ảnh chụp nhanh, vì sẽ không có hoạt động sao chép-ghi để lưu trữ.

Giảm tác động I / O:tránh 665/1450/1452 lỗi

Trong một số trường hợp, bạn có thể thấy một trong các lỗi sau:

Hệ điều hành đã trả lại lỗi 665 (Không thể hoàn thành thao tác được yêu cầu do giới hạn hệ thống tệp) cho SQL Server trong khi ghi ở offset 0x […] trong tệp '[tệp]'

Có một số mẹo ở đây để giảm nguy cơ mắc các lỗi này trong CHECKDB và giảm tác động của chúng nói chung - với một số bản sửa lỗi có sẵn, tùy thuộc vào hệ điều hành và phiên bản SQL Server của bạn:

• Lỗi tệp thưa thớt:1450 hoặc 665 do phân mảnh tệp:Các bản sửa lỗi và cách giải quyết
• SQL Server báo cáo lỗi hệ điều hành 1450 hoặc 1452 hoặc 665 (thử lại)

Giảm tác động của CPU

DBCC CHECKDB là đa luồng theo mặc định (nhưng chỉ trong Phiên bản Doanh nghiệp). Nếu hệ thống của bạn bị ràng buộc bởi CPU hoặc bạn chỉ muốn CHECKDB để sử dụng ít CPU hơn với chi phí chạy lâu hơn, bạn có thể xem xét giảm tính song song theo một số cách khác nhau:

1. Sử dụng Resource Governor trên 2008 trở lên, miễn là bạn đang chạy Enterprise Edition. Để chỉ nhắm mục tiêu các lệnh DBCC cho một nhóm tài nguyên hoặc nhóm khối lượng công việc cụ thể, bạn sẽ phải viết một hàm phân loại có thể xác định các phiên sẽ thực hiện công việc này (ví dụ:đăng nhập cụ thể hoặc job_id).
2. Sử dụng cờ theo dõi 2528 để tắt chế độ song song cho DBCC CHECKDB (cũng như CHECKFILEGROUP và CHECKTABLE ). Cờ theo dõi 2528 được mô tả ở đây. Tất nhiên điều này chỉ hợp lệ trong Phiên bản Doanh nghiệp, vì bất chấp những gì Sách Trực tuyến hiện nói, sự thật là CHECKDB không song song trong Standard Edition.
3. Trong khi DBCC bản thân lệnh không hỗ trợ MAXDOP (ít nhất là trước SQL Server 2014 SP2), nó tôn trọng cài đặt chung max degree of parallelism . Có thể không phải là điều tôi sẽ làm trong quá trình sản xuất trừ khi tôi không có lựa chọn nào khác, nhưng đây là một cách tổng thể để kiểm soát một số DBCC nhất định nếu bạn không thể nhắm mục tiêu chúng một cách rõ ràng hơn.

Chúng tôi đã yêu cầu kiểm soát tốt hơn số lượng CPU DBCC CHECKDB nhưng chúng đã bị từ chối liên tục cho đến SQL Server 2014 SP2. Vì vậy, bây giờ bạn có thể thêm WITH MAXDOP = n vào lệnh.

Phát hiện của tôi

Tôi muốn trình diễn một vài kỹ thuật này trong môi trường mà tôi có thể kiểm soát. Tôi đã cài đặt AdventureWorks2012, sau đó mở rộng nó bằng cách sử dụng tập lệnh mở rộng AW do Jonathan Kehayias (blog | @SQLPoolBoy) viết, đã tăng cơ sở dữ liệu lên khoảng 7 GB. Sau đó, tôi chạy một loạt CHECKDB các lệnh chống lại nó và hẹn giờ chúng. Tôi đã sử dụng một loại vani đơn giản DBCC CHECKDB riêng nó, sau đó tất cả các lệnh khác được sử dụng WITH NO_INFOMSGS, ALL_ERRORMSGS . Sau đó, bốn kiểm tra với (a) không có cờ theo dõi, (b) 2549, (c) 2562 và (d) cả 2549 và 2562. Sau đó, tôi lặp lại bốn kiểm tra đó, nhưng thêm PHYSICAL_ONLY tùy chọn bỏ qua tất cả các kiểm tra logic. Kết quả (tính trung bình trên 10 lần chạy thử nghiệm) đang cho biết:

Kết quả CHECKDB dựa trên cơ sở dữ liệu 7 GB

Sau đó, tôi mở rộng cơ sở dữ liệu thêm một số nữa, tạo nhiều bản sao của hai bảng được phóng to, dẫn đến kích thước cơ sở dữ liệu chỉ ở phía bắc là 70 GB và chạy lại các bài kiểm tra. Kết quả, lại được tính trung bình trên 10 lần chạy thử nghiệm:

Kết quả CHECKDB dựa trên cơ sở dữ liệu 70 GB

Trong hai trường hợp này, tôi đã học được những điều sau (một lần nữa, hãy nhớ rằng quãng đường của bạn có thể khác nhau và bạn sẽ cần thực hiện các bài kiểm tra của riêng mình để đưa ra bất kỳ kết luận có ý nghĩa nào):

1. Khi tôi phải thực hiện kiểm tra logic:
   • Ở kích thước cơ sở dữ liệu nhỏ, NO_INFOMSGS tùy chọn có thể cắt giảm đáng kể thời gian xử lý khi việc kiểm tra được chạy trong SSMS. Tuy nhiên, trên các cơ sở dữ liệu lớn hơn, lợi ích này giảm đi, vì thời gian và công việc dành cho việc chuyển tiếp thông tin trở thành một phần không đáng kể trong thời lượng tổng thể. 21 giây trong số 2 phút là đáng kể; 88 giây trong tổng số 35 phút, không quá nhiều.
   • Hai cờ theo dõi mà tôi đã thử nghiệm có tác động đáng kể đến hiệu suất - giảm thời gian chạy từ 40-60% khi cả hai được sử dụng cùng nhau.
     
2. Khi tôi có thể đẩy các kiểm tra lôgic đến máy chủ phụ (một lần nữa, giả sử rằng tôi đang thực hiện kiểm tra lôgic ở nơi khác so với bản sao đúng ):
   • Tôi có thể giảm thời gian xử lý trên phiên bản chính của mình 70-90% so với CHECKDB tiêu chuẩn cuộc gọi mà không có tùy chọn.
   • Trong trường hợp của tôi, các cờ theo dõi có rất ít tác động đến thời lượng khi thực hiện PHYSICAL_ONLY séc.

Tất nhiên, và tôi không thể nhấn mạnh điều này đủ, đây là những cơ sở dữ liệu tương đối nhỏ và chỉ được sử dụng để tôi có thể thực hiện các bài kiểm tra được đo lặp lại trong một khoảng thời gian hợp lý. Máy chủ này có 80 CPU logic và RAM 128 GB và tôi là người dùng duy nhất. Thời lượng và sự tương tác với các khối lượng công việc khác trên hệ thống có thể làm sai lệch những kết quả này khá nhiều. Dưới đây là một cái nhìn sơ lược về cách sử dụng CPU điển hình, bằng cách sử dụng SQL Sentry, trong một trong các CHECKDB hoạt động (và không có tùy chọn nào thực sự thay đổi tác động tổng thể lên CPU, chỉ là thời lượng):

Tác động của CPU trong quá trình CHECKDB - chế độ mẫu

Và đây là một dạng xem khác, hiển thị các cấu hình CPU tương tự cho ba mẫu khác nhau CHECKDB hoạt động trong chế độ lịch sử (Tôi đã phủ một mô tả của ba thử nghiệm được lấy mẫu trong phạm vi này):

Tác động của CPU trong quá trình CHECKDB - chế độ lịch sử

Trên các cơ sở dữ liệu thậm chí lớn hơn, được lưu trữ trên các máy chủ bận rộn hơn, bạn có thể thấy các hiệu ứng khác nhau và quãng đường của bạn có khả năng thay đổi. Vì vậy, vui lòng thực hiện thẩm định của bạn và kiểm tra các tùy chọn này và theo dõi cờ trong một khối lượng công việc đồng thời điển hình trước khi quyết định cách bạn muốn tiếp cận CHECKDB .

Kết luận

DBCC CHECKDB là một phần rất quan trọng nhưng thường được đánh giá thấp trong trách nhiệm của bạn với tư cách là DBA hoặc kiến ​​trúc sư và rất quan trọng đối với việc bảo vệ dữ liệu của công ty bạn. Đừng coi nhẹ trách nhiệm này và cố gắng hết sức để đảm bảo rằng bạn không hy sinh bất cứ điều gì vì lợi ích giảm thiểu tác động đến các trường hợp sản xuất của bạn. Quan trọng nhất:hãy nhìn xa hơn các bảng dữ liệu tiếp thị để chắc chắn rằng bạn hoàn toàn hiểu những lời hứa đó có giá trị như thế nào và liệu bạn có sẵn sàng đặt cược dữ liệu của công ty mình vào chúng hay không. Bỏ qua một số séc hoặc tải chúng xuống các vị trí phụ không hợp lệ có thể là một thảm họa đang chực chờ xảy ra.

Bạn cũng nên cân nhắc đọc các bài viết PSS này:

• CHECKDB nhanh hơn - Phần I
• CHECKDB nhanh hơn - Phần II
• CHECKDB nhanh hơn - Phần III
• CHECKDB nhanh hơn - Phần IV (SQL CLR UDT)

Và bài đăng này từ Brent Ozar:

• 3 cách để chạy DBCC CHECKDB nhanh hơn

Cuối cùng, nếu bạn có câu hỏi chưa được giải đáp về DBCC CHECKDB , đăng nó lên thẻ băm #sqlhelp trên twitter. Paul kiểm tra thẻ đó thường xuyên và vì ảnh của anh ấy sẽ xuất hiện trong bài báo chính của Books Online, nên có khả năng là nếu ai trả lời được thì anh ấy có thể. Nếu nó quá phức tạp với 140 ký tự, bạn có thể hỏi tại đây (và tôi sẽ đảm bảo rằng Paul sẽ nhìn thấy nó vào một lúc nào đó) hoặc đăng lên một trang diễn đàn như Quản trị viên cơ sở dữ liệu Stack Exchange.