Database
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> Database

Tổng quan về chức năng CheckDB của DBCC

Giới thiệu

Bảo trì cơ sở dữ liệu thường xuyên là một phần quan trọng trong công việc của Quản trị viên cơ sở dữ liệu giúp đảm bảo rằng các hệ thống cực kỳ quan trọng đang chạy bình thường. Một trong những cách dễ nhất để thực hiện điều này là tự động hóa các tác vụ liên quan đến DBCC CheckDB. Bất kể bạn đang chạy phiên bản SQL Server nào, sẽ không bao giờ có cơ sở dữ liệu yêu cầu bảo trì. Bạn sẽ phải lập kế hoạch bảo trì diễn ra thường xuyên để có thể trang trải cho mình, đặc biệt là vào thời điểm xảy ra tình huống thảm họa thực sự.

DBA luôn là thủ phạm

Bất cứ khi nào có vấn đề về cơ sở dữ liệu, mọi con mắt đều đổ dồn vào DBA. Cho dù vấn đề là do mưa hay do một số nhà phát triển viết mã khó chịu dẫn đến cơ sở dữ liệu chậm đi, thì DBA luôn được kỳ vọng sẽ khắc phục được tình trạng lộn xộn. Và bạn có thể tưởng tượng loại áp lực bạn cần đối phó nếu bạn được yêu cầu nhanh chóng khôi phục cơ sở dữ liệu bằng cách sử dụng bản sao lưu cuối cùng có sẵn, như bạn phát hiện ra trong quá trình này, không hợp lệ và tính toàn vẹn của cơ sở dữ liệu đã bị xâm phạm vài tháng. trước kia. Đây là sự khác biệt giữa DBA chủ động và DBA phản ứng. Trên thực tế, chiến lược khôi phục của bạn quan trọng hơn nhiều so với chiến lược sao lưu. Các bản sao lưu cơ sở dữ liệu hàng ngày có thể phục vụ cho mục đích gì nếu chúng không được sử dụng tại thời điểm khôi phục?

Tại sao Bảo trì lại quan trọng?

Với sự phát triển chưa từng có của công nghệ cơ sở dữ liệu và với các tính năng mới xuất hiện với mọi bản phát hành, bạn với tư cách là DBA bắt buộc phải đi trước phần còn lại và đảm bảo rằng bạn đang tuân theo các phương pháp hay nhất trong ngành bảo trì cơ sở dữ liệu.

DBCC CheckDB và cách chúng ta có thể chạy nó

DBCC CheckDB - tên này khá mô tả về chức năng. Nói một cách dễ hiểu, nó kiểm tra cơ sở dữ liệu. Điều này rất quan trọng để đảm bảo rằng cơ sở dữ liệu đang hoạt động như mong đợi. Về cơ bản, DBCC CheckDB kiểm tra tính toàn vẹn logic và vật lý của tất cả các đối tượng trong cơ sở dữ liệu. Đây là những gì DBCC CheckDB thực hiện theo chính thức Tài liệu của Microsoft:

  • Chạy DBCC CHECKALLOC trên cơ sở dữ liệu - tính nhất quán của phân bổ dung lượng đĩa

  • Chạy DBCC CHECKTABLE trên mọi bảng và dạng xem trong cơ sở dữ liệu - đây là tính toàn vẹn của tất cả các trang và cấu trúc tạo nên bảng hoặc dạng xem được lập chỉ mục.

  • Chạy DBCC CHECKCATALOG trên cơ sở dữ liệu - điều này kiểm tra tính nhất quán của danh mục trong cơ sở dữ liệu được chỉ định.

  • Xác thực nội dung của mọi dạng 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 / tệp hệ thống tệp khi lưu trữ dữ liệu varbinary (max) trong hệ thống tệp bằng FILESTREAM.

  • Xác thực dữ liệu Người môi giới dịch vụ trong cơ sở dữ liệu.

Khi bạn chạy lệnh DBCC CheckDB một cách rõ ràng hoặc thông qua một công việc, về cơ bản nó sẽ thực hiện tất cả những điều trên.

Chạy DBCC CheckDB Trực tiếp trên Cơ sở dữ liệu

Bạn có thể chạy lệnh DBCC CheckDB trực tiếp trên cơ sở dữ liệu và kiểm tra kết quả. Kiểm tra đầu ra của lệnh như được hiển thị trên ảnh chụp màn hình bên dưới. Kết quả hiển thị chi tiết về các hàng trong bảng và số trang được sử dụng bởi các hàng này.

Nếu quan sát kỹ hơn, bạn sẽ thấy thêm chi tiết cụ thể cho các đối tượng cơ sở dữ liệu. Ví dụ:trên cơ sở dữ liệu “VLDB”, tôi có thể thấy kết quả sau:

“Object ID 1179151246 (object 'Warehouse.ColdRoomTemperatures'): The operation is not supported with memory optimized tables. This object has been skipped and will not be processed.”

Như kết quả này hiển thị, DBCC CheckDB không được hỗ trợ với các bảng được tối ưu hóa bộ nhớ. Bảng được tối ưu hóa bộ nhớ lần đầu tiên được giới thiệu trong SQL Server 2014 như một tính năng chỉ dành cho Doanh nghiệp. Tuy nhiên, trong những năm qua, chúng đã trở thành một chức năng phổ biến và rộng rãi trong SQL Server.

Bạn cũng sẽ nhận thấy rằng Kiểm tra DBCC đã xác thực dữ liệu người môi giới dịch vụ trong cơ sở dữ liệu như được hiển thị bên dưới.

“DBCC results for 'VLDB'.

Service Broker Msg 9675, State 1: Message Types analyzed: 14.

Service Broker Msg 9676, State 1: Service Contracts analyzed: 6.

Service Broker Msg 9667, State 1: Services analyzed: 3.

Service Broker Msg 9668, State 1: Service Queues analyzed: 3.

Service Broker Msg 9669, State 1: Conversation Endpoints analyzed: 0.

Service Broker Msg 9674, State 1: Conversation Groups analyzed: 0.

Service Broker Msg 9670, State 1: Remote Service Bindings analyzed: 0.

Service Broker Msg 9605, State 1: Conversation Priorities analyzed: 0.”

Cuối cùng, khi lệnh DBCC CheckDB được hoàn tất thành công, bạn sẽ thấy kết quả sau:

Điều gì xảy ra nếu Lỗi được báo cáo sau khi chạy DBCC CheckDB?

Trong ví dụ trên, bạn có thể thấy rằng DBCC CheckDB đã được hoàn thành mà không có bất kỳ lỗi nào. Tuy nhiên, nếu không may mắn như vậy, bạn có thể gặp phải lỗi nhất quán - và đó sẽ là lúc bạn cần đưa ra một số quyết định quan trọng. Nếu bạn gặp sự cố trên cơ sở dữ liệu sản xuất, tốt nhất là thông báo cho chủ doanh nghiệp hoặc Người quản lý hoạt động của bạn để đặt thẻ của bạn trên bàn. Bạn có thể cung cấp cho họ tùy chọn khôi phục cơ sở dữ liệu từ bản sao lưu cuối cùng có sẵn hoặc bạn có thể thử nghiệm với việc chạy các lệnh DBCC CheckDB với các tùy chọn bổ sung.

Thông báo lỗi DBCC có thể trông giống như thông báo bên dưới:

Table error: Object ID 36, index ID 1, partition ID, alloc unit ID (type In-row data).

Keys out of order on page (1:107), slots 6 and 9.
CHECKDB found 0 allocation errors and 1 consistency errors in table 'sys.syk' (object ID 36).
CHECKDB found 0 allocation errors and 1 consistency errors in database 'VLDB'.
repair_rebuild is the minimum repair level for the errors found by DBCC CHECKDB (VLDB).

Trong thông báo lỗi, bạn có thể thấy thông báo lỗi được viết cẩn thận - “ repair_rebuild là tối thiểu mức sửa chữa cho các lỗi được tìm thấy bởi DBCC CHECKDB ”- đề xuất bạn chạy DBCC CheckDB với tùy chọn Repair_rebuild. Chỉ cần nhìn vào từ được tô sáng - ‘tối thiểu’. Điều này có nghĩa là, với tùy chọn Repair_rebuild, không có khả năng mất dữ liệu thực sự và SQL Server thực hiện một số bản sửa lỗi nhanh. Vui lòng tham khảo lệnh dưới đây để chạy DBCC CheckDB với tùy chọn Repair_rebuild. Đảm bảo đặt cơ sở dữ liệu ở chế độ người dùng duy nhất.

Theo tài liệu của Microsoft, tùy chọn REPAIR_REBUILD là phiên bản vô hại nhất vì không thể mất dữ liệu. Tuy nhiên, nếu REPAIR_REBUILD vẫn không sửa được lỗi nhất quán, thì có một tùy chọn khác - bật REPAIR_ALLOW_DATA_LOSS. Nhìn vào tên, chúng ta biết rằng sẽ có thể xảy ra một số mất mát dữ liệu nếu chúng ta bật tùy chọn này. Do đó, Microsoft cảnh báo chúng tôi sử dụng tính năng này hết sức thận trọng vì có thể có những hậu quả không mong muốn khi chạy DBCC CheckDB với REPAIR_ALLOW_DATA_LOSS. Lệnh DBCC CheckDB trong trường hợp này sẽ có dạng như sau:

Các điểm cần cân nhắc trước khi sử dụng tùy chọn Sửa chữa với DBCC CheckDB

  • Cơ sở dữ liệu được đề cập quan trọng như thế nào?

  • Cơ sở dữ liệu trên sản xuất hay môi trường thử nghiệm?

  • Cơ sở dữ liệu lớn đến mức nào?

  • Bạn có chiến lược khôi phục tốt trong trường hợp sự cố xuất hiện không?

  • Bạn đã xác thực các bản sao lưu cơ sở dữ liệu của mình chưa?

Dựa trên tình huống và câu trả lời cho các câu hỏi trên, hãy cố gắng đưa ra quyết định lưu ý đến lợi ích tốt nhất của khách hàng.

Tự động hóa các Nhiệm vụ Kiểm tra DBCC trên Máy chủ SQL bằng Kế hoạch Bảo trì Cơ sở dữ liệu

Chà, bạn không phải chạy tất cả các lệnh này theo cách thủ công trên máy chủ của mình. Đó là lý do tại sao chúng tôi có kế hoạch bảo trì. Đảm bảo lên lịch một chu kỳ bảo trì thường xuyên cho tất cả các cơ sở dữ liệu của bạn bằng cách sử dụng các kế hoạch bảo trì cơ sở dữ liệu. Đó là một nhiệm vụ khá đơn giản và dễ hiểu. Trong “Nhiệm vụ kế hoạch bảo trì”, hãy chọn “Kiểm tra nhiệm vụ toàn vẹn cơ sở dữ liệu”.

Việc này sẽ thêm một nhiệm vụ phụ vào kế hoạch bảo trì của bạn để lên lịch kiểm tra tính toàn vẹn cho cơ sở dữ liệu của bạn. Đảm bảo chọn cơ sở dữ liệu cần thiết như được hiển thị.

Hãy đảm bảo chạy tất cả các kiểm tra cơ sở dữ liệu trong thời gian thấp điểm trong tuần. Thông thường, các cửa sổ bảo trì vào cuối tuần khi máy chủ ít bận hơn so với các ngày khác trong tuần. Tuy nhiên, điều này sẽ khác nhau giữa các máy chủ và tùy thuộc vào ứng dụng. Trên các hệ thống cơ sở dữ liệu quan trọng, cảnh báo thường được hiển thị bất cứ khi nào có việc bỏ sót DBCC CheckDB hoặc kiểm tra tính toàn vẹn. Bằng cách này, các DBA có thể chủ động kiểm tra và đảm bảo rằng họ đã hoàn thành việc kiểm tra tính toàn vẹn để tránh bất ngờ về sau.

Tự động hóa các tác vụ DBCC CheckDB trên SQL Server bằng cách sử dụng các tập lệnh tùy chỉnh hoặc các tập lệnh phổ biến khác

Kế hoạch bảo trì Máy chủ SQL không cần được sử dụng mọi lúc để thực hiện các tác vụ bảo trì trên phiên bản Máy chủ SQL của bạn. Có các tập lệnh tùy chỉnh có sẵn khác mà bạn có thể sử dụng. Một trong những công cụ bảo trì miễn phí phổ biến là giải pháp bảo trì Ola Hallengren’s. Bạn có thể cài đặt toàn bộ giải pháp bảo trì bao gồm các tác vụ sao lưu, tối ưu hóa, v.v. hoặc bạn chỉ có thể tải xuống các tập lệnh có liên quan liên quan đến kiểm tra tính toàn vẹn. Trong bản trình diễn này, chúng tôi sẽ cố gắng cài đặt các tập lệnh dành riêng cho việc kiểm tra tính toàn vẹn của cơ sở dữ liệu.

Nhấp vào tùy chọn DatabaseIntegrityCheck.sql như được hiển thị để tải xuống các thủ tục được lưu trữ để kiểm tra tính toàn vẹn của cơ sở dữ liệu. Sau khi chạy các thủ tục được lưu trữ này trên cơ sở dữ liệu chính, tôi đã gặp các thông báo cảnh báo sau:

“The module 'DatabaseIntegrityCheck' depends on the missing object 'dbo.CommandExecute'. The module will still be created; however, it cannot run successfully until the object exists.”

Nếu bạn chạy quy trình đã lưu trữ để thực hiện kiểm tra tính toàn vẹn, bạn sẽ gặp lỗi sau:

Khi lỗi xuất hiện, bạn có thể tải xuống mã bị thiếu tại đây. Sau khi hoàn tất, bạn có thể bắt đầu thử kiểm tra tính toàn vẹn của cơ sở dữ liệu.

Bạn có thể điều chỉnh các tùy chọn khác nhau bằng cách sử dụng các tham số lệnh DBCC bổ sung. Bạn có thể tìm thêm thông tin chi tiết và ví dụ về những điều đó tại đây.

Tuy nhiên, trong bản trình diễn này, chúng tôi sẽ kiểm tra một vài ví dụ để xem những tập lệnh này thực sự dễ dàng và thân thiện với người dùng như thế nào.

Để chạy DBCC CheckDB trên tất cả cơ sở dữ liệu người dùng , bạn sẽ cần thực hiện những điều sau:

EXECUTE dbo.DatabaseIntegrityCheck

@Databases = 'USER_DATABASES',

@CheckCommands = 'CHECKDB'

Bạn có thể thấy lệnh đã được chạy và trạng thái kết quả xác nhận rằng DBCC CheckDB đã hoàn tất thành công.

Để chạy DBCC Chỉ kiểm tra cơ sở dữ liệu hệ thống, thực hiện lệnh này:

EXECUTE dbo.DatabaseIntegrityCheck

@Databases = 'SYSTEM_DATABASES',

@CheckCommands = 'CHECKDB'

Trên ảnh chụp màn hình, bạn có thể thấy rằng Kiểm tra DBCC đã được hoàn tất thành công cho cơ sở dữ liệu hệ thống.

Để chạy DBCC CheckDB chỉ cho một cơ sở dữ liệu cụ thể, thực hiện như sau:

EXECUTE dbo.DatabaseIntegrityCheck

@Databases = 'VLDB', -- your specific DB Name

@CheckCommands = 'CHECKDB'

Trong ví dụ trên, bạn đã thấy một số cách chúng ta có thể sử dụng các tham số. Tuy nhiên, có một số bộ lọc khác mà bạn có thể chọn dựa trên sở thích của mình. Ngoài ra, như đã đề cập, bạn có thể tham khảo liên kết này để hiểu thêm về các kịch bản của Ola Hallengren. Chỉ cần nhắc lại, tôi đang sử dụng các tập lệnh của Ola Hallengren trên các máy chủ mà tôi quản lý và nó rất được khuyến khích và công nhận trong cộng đồng SQL Server. Bạn có thể lập lịch các thủ tục được lưu trữ dựa trên các tham số ưa thích của mình và chạy nó là một công việc SQL trong giờ thấp điểm. Bằng cách này, bạn không thực sự cần phải chạy bất kỳ tập lệnh nào trong số này theo cách thủ công, vì vậy bạn có thể tập trung vào các nhiệm vụ quan trọng khác.

Kết luận

  • Từ bài viết này, bạn đã biết về DBCC CheckDB và cách sử dụng nó
  • Bạn cũng hiểu tầm quan trọng của việc chạy DBCC CheckDB thường xuyên trên tất cả các cơ sở dữ liệu quan trọng của mình
  • Bạn cũng đã học về tầm quan trọng của việc có một chiến lược sao lưu đã thử nghiệm - bạn nên khôi phục cơ sở dữ liệu của mình bằng cách sử dụng một bản sao lưu tốt thay vì giải quyết bất kỳ lỗi nhất quán nào bằng cách sử dụng các tùy chọn Sửa chữa DBCC
  • Bạn cũng đã thấy việc định cấu hình và tự động hóa các tập lệnh dễ dàng như thế nào bằng cách sử dụng kế hoạch bảo trì của SQL Server hoặc các tập lệnh tùy chỉnh, ví dụ:tập lệnh từ Ola Hallengren
  • Bạn cũng đã biết được những rủi ro khi không lên lịch DBCC CheckDB trên cơ sở hạ tầng được hỗ trợ của mình
  • Bạn cũng biết được rằng, bất kể bạn đang sử dụng máy chủ nào hoặc bạn chạy cơ sở hạ tầng nào, không thể có cơ sở dữ liệu nào yêu cầu bảo trì
  • Cuối cùng, hãy đảm bảo giữ cho cơ sở dữ liệu của bạn hoạt động tốt và trong mọi trường hợp, hãy sẵn sàng cho những ngày TẮT mà có thể không nằm trong tầm kiểm soát của bạn

  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Zombie PerfMon đếm không bao giờ chết!

  2. Cách tạo dữ liệu thử nghiệm DB

  3. Hiểu sự khác biệt giữa toán tử EXCEPT và NOT IN

  4. Chuẩn hóa:Khi nào, Tại sao và Làm thế nào

  5. Cách kết nối cơ sở dữ liệu với Amazon VPC