Tiếp tục loạt bài viết về chốt, lần này tôi sẽ thảo luận về chốt DBCC_OBJECT_METADATA và chỉ ra cách nó có thể là một nút thắt cổ chai chính đối với việc kiểm tra tính nhất quán trước SQL Server 2016 trong một số trường hợp nhất định. Sự cố ảnh hưởng đến DBCC CHECKDB, DBCC CHECKTABLE và DBCC CHECKFILEGROUP, nhưng để rõ ràng hơn, tôi sẽ chỉ tham khảo DBCC CHECKDB cho phần còn lại của bài đăng này.
Bạn có thể thắc mắc tại sao tôi lại viết về một vấn đề ảnh hưởng đến các phiên bản cũ hơn, nhưng vẫn còn một số lượng lớn SQL Server 2014 và các phiên bản cũ hơn, vì vậy đây là một chủ đề hợp lệ cho loạt bài của tôi.
Tôi thực sự khuyên bạn nên đọc bài đầu tiên trong loạt bài trước bài này, để bạn có tất cả kiến thức nền tảng chung về chốt.
Chốt DBCC_OBJECT_METADATA là gì?
Để giải thích chốt này, tôi cần giải thích một chút về cách hoạt động của DBCC CHECKDB.
Trong số rất nhiều kiểm tra tính nhất quán mà DBCC CHECKDB thực hiện là kiểm tra tính đúng đắn của các chỉ mục không phân biệt. Cụ thể, DBCC CHECKDB đảm bảo:
- Đối với mọi bản ghi chỉ mục không hợp nhất trong mọi chỉ mục không hợp nhất, có chính xác một bản ghi dữ liệu "phù hợp" trong bảng cơ sở (chỉ mục một đống hoặc một nhóm)
- Đối với mọi bản ghi dữ liệu trong bảng, có chính xác một bản ghi chỉ mục không phân biệt "phù hợp" trong mỗi chỉ mục không phân biệt được xác định cho bảng, có tính đến các chỉ mục đã lọc
Không đi sâu quá chi tiết về cách thực hiện điều này, đối với mỗi bản ghi dữ liệu trong một bảng, DBCC CHECKDB xây dựng mỗi bản ghi chỉ mục không phân biệt sẽ tồn tại cho mỗi chỉ mục không hợp nhất và đảm bảo bản ghi chỉ mục không hợp nhất đã xây dựng khớp chính xác với thực tế bản ghi chỉ mục không phân tán. Nếu chỉ mục không phân bổ có một cột được tính toán trong đó (như một phần của khóa chỉ mục không phân bổ hoặc dưới dạng cột BAO GỒM), DBCC CHECKDB phải tìm ra giá trị cột được tính toán để sử dụng khi tạo các bản ghi chỉ mục.
Cũng như kiểm tra tính đúng đắn của chỉ mục không phân bổ, nếu có vẫn tồn tại cột được tính toán trong định nghĩa của một bảng, sau đó đối với mỗi bản ghi dữ liệu trong bảng, DBCC CHECKDB phải kiểm tra xem giá trị duy trì có chính xác hay không, bất kể cột đó có phải là một phần của chỉ mục không hợp nhất hay không.
Vậy làm cách nào để nó tìm ra các giá trị cột được tính toán?
Bộ xử lý truy vấn cung cấp một cơ chế để tính toán các giá trị cột được tính toán, được gọi là "trình đánh giá biểu thức". DBCC CHECKDB gọi hàm đó, cung cấp thông tin siêu dữ liệu thích hợp và bản ghi dữ liệu, đồng thời trình đánh giá biểu thức sử dụng định nghĩa được lưu trữ của cột được tính toán trong siêu dữ liệu và các giá trị từ bản ghi dữ liệu và trả về giá trị của cột được tính toán để DBCC CHECKDB sử dụng . Các hoạt động bên trong của bộ đánh giá biểu thức nằm ngoài sự kiểm soát của mã DBCC, nhưng để có thể sử dụng bộ đánh giá biểu thức, trước tiên phải có chốt; chốt DBCC_OBJECT_METADATA.
Làm thế nào để chốt trở thành nút cổ chai?
Đây là vấn đề:chỉ có một chế độ được chấp nhận trong đó chốt DBCC_OBJECT_METADATA có thể được lấy trước khi sử dụng bộ đánh giá biểu thức và đó là chế độ EX (độc quyền). Và như bạn sẽ biết khi đọc bài đăng giới thiệu cho loạt bài này, mỗi lần chỉ có một chủ đề có thể giữ chốt ở chế độ EX.
Kết hợp tất cả thông tin này lại với nhau:khi cơ sở dữ liệu có các cột được tính toán liên tục hoặc các chỉ mục không phân biệt có các cột được tính toán trong chúng, thì bộ đánh giá biểu thức phải được sử dụng. Nếu phiên bản SQL Server là Enterprise, DBCC CHECKDB có thể sử dụng song song và do đó có nhiều luồng thực hiện các kiểm tra khác nhau. Và ngay sau khi bạn có nhiều luồng đang cố gắng lấy chốt ở chế độ EX, chốt đó sẽ trở thành nút cổ chai. Mức độ lớn của nút cổ chai mà nó trở nên phụ thuộc vào lượng trình đánh giá biểu thức cần được sử dụng, vì vậy, càng có nhiều cột được tính liên tục hoặc chỉ mục không phân tán sử dụng các cột được tính toán, và số lượng hàng của bảng trong các bảng đó càng lớn, thì nút cổ chai càng lớn thì chốt DBCC _OBJECT_METADATA trở nên lớn hơn.
Nhưng hãy nhớ rằng, nút cổ chai này chỉ xảy ra đối với các phiên bản SQL Server sớm hơn SQL Server 2016. Trong SQL Server 2016, Microsoft đã quyết định "sửa chữa" nút cổ chai bằng cách tắt tính năng kiểm tra các chỉ mục không phân biệt bằng cách sử dụng các cột được tính toán theo mặc định và chỉ thực hiện chúng khi VỚI Tùy chọn EXTENDED_LOGICAL_CHECKS được sử dụng.
Hiển thị nút cổ chai
Bạn có thể dễ dàng tái tạo nút cổ chai cho mình bằng cách chạy DBCC CHECKDB trên cơ sở dữ liệu có các cột được tính toán liên tục hoặc các chỉ mục không phân biệt với các cột được tính toán trong và cơ sở dữ liệu AdventureWorks do Microsoft cung cấp là một ví dụ tuyệt vời. Bạn có thể tải xuống các bản sao lưu của AdventureWorks cho phiên bản SQL Server của mình từ đây. Tôi đã chạy một số bài kiểm tra bằng cách sử dụng cơ sở dữ liệu AdventureWorks2014 trên phiên bản SQL Server 2014 (trên Dell R720 32 lõi) và tôi đã phóng to cơ sở dữ liệu lên vài trăm GB bằng cách sử dụng các tập lệnh của Jonathan.
Khi tôi chạy DBCC CHECKDB, với máy chủ MAXDOP được đặt thành 0, mất hơn 5 giờ để chạy. Loại chờ LATCH_EX chiếm khoảng 30% số lần chờ, với mỗi lần chờ chỉ là 1 phần nghìn giây và 99% số lần chờ LATCH_EX dành cho chốt DBCC_OBJECT_METADATA.
Tôi đã tìm kiếm các chỉ mục không phân biệt có chứa các cột được tính bằng mã sau:
SELECT
[s].[name] AS [Schema],
[o].[name] AS [Object],
[i].[name] AS [Index],
[c].[name] AS [Column],
[ic].*
FROM sys.columns [c]
JOIN sys.index_columns [ic]
ON [ic].[object_id] = [c].[object_id]
AND [ic].[column_id] = [c].[column_id]
JOIN sys.indexes [i]
ON [i].[object_id] = [ic].[object_id]
AND [i].[index_id] = [ic].[index_id]
JOIN sys.objects [o]
ON [i].[object_id] = [o].[object_id]
JOIN sys.schemas [s]
ON [o].[schema_id] = [s].[schema_id]
WHERE [c].[is_computed] = 1; Mã đó tìm thấy sáu chỉ mục không hợp nhất trong cơ sở dữ liệu AdventureWorks2014. Tôi đã vô hiệu hóa tất cả sáu chỉ mục (sử dụng ALTER INDEX… DISABLE) và chạy lại DBCC CHECKDB và nó hoàn thành trong khoảng 18 phút. Vì vậy, nút cổ chai chốt DBCC_OBJECT_METADATA là một yếu tố chính khiến DBCC CHECKDB chạy chậm hơn 16 lần!
Tóm tắt
Thật không may, việc vô hiệu hóa các chỉ mục không phân tán bằng cách sử dụng các cột được tính toán (và sau đó bật lại chúng bằng ALTER INDEX… REBUILD) là cách * duy nhất * để loại bỏ nút cổ chai chốt DBCC_OBJECT_METADATA trong các phiên bản trước SQL Server 2016 trong khi vẫn giữ tất cả các chức năng khác của DBCC CHECKDB. Vô hiệu hóa các chỉ mục không phân tán có thể không phải là điều bạn muốn làm trong môi trường sản xuất trừ khi bạn có thời hạn duy trì hoạt động bằng không. Điều này có nghĩa là bạn có thể sẽ chỉ vô hiệu hóa các chỉ mục không hợp nhất đó để loại bỏ nút thắt cổ chai nếu quá trình kiểm tra tính nhất quán của bạn được tải xuống một máy chủ khác bằng phương pháp backup-copy-restore-CHECKDB.
Một cách khác để làm điều đó là sử dụng tùy chọn WITH PHYSICAL_ONLY khi chạy DBCC CHECKDB nhưng sau đó bạn bỏ lỡ tất cả các kiểm tra logic chuyên sâu, vì vậy tôi không phải là người thích đề xuất giải pháp đó.
