Mà tin tưởng?

Chúng tôi đang khắc phục sự cố lâu dài với một nhà cung cấp. Phần mềm của họ có xu hướng đóng băng và ngừng hoạt động một hoặc hai lần một tuần gây ra sự gián đoạn lớn cho hoạt động của chúng tôi. Họ đã không thể xác định nguyên nhân mặc dù chúng tôi đã gửi cho họ nhiều GB nhật ký và bản sao lưu của DB. Gần đây, họ đã bắt đầu đề xuất các vấn đề liên quan đến bảo trì của chúng tôi và có lẽ không phải với phần mềm của họ (mặc dù không có truy vấn chạy lâu, áp suất CPU / RAM / IO hoặc thậm chí là bế tắc khi xảy ra sự cố). Cụ thể họ đang nói rằng các chỉ số của chúng tôi là một vấn đề.

Công cụ yêu thích của họ để sử dụng là DBCC showcontig mặc dù tôi cho rằng điều đó không được MS phản đối. Họ ám ảnh về mật độ quét và phân mảnh mức độ đặc biệt. Để loại bỏ lý do, tôi đã thiết lập một số bảo trì hàng đêm tích cực để xây dựng lại các chỉ mục với mật độ quét <90% hoặc phân mảnh> 10%. Điều này đã phần nào ném chúng ra khỏi tàu mật độ quét nhưng chúng vẫn cố định ở mức độ phân mảnh. DBCC showcontig cho thấy sự phân mảnh ở mức độ cao ngay cả trên một chỉ mục đã được xây dựng lại nhiều giờ trước đó. Dưới đây là kết quả của dbcc_showcontig và sys.dm_db_index_physical_stats cho một bảng mà họ đã chỉ ra là "vấn đề có thể xảy ra".

DBCC SHOWCONTIG

• Các trang được quét ................................: 1222108
• Mức độ quét ..............................: 152964
• Công tắc mở rộng ..............................: 180904
• Trung bình Số trang trên mỗi mức độ ........................: 8.0
• Mật độ quét [Đếm tốt nhất: Đếm thực tế] .......: 84,44% [152764: 180905]
• Phân mảnh quét logic ..................: 3,24%
• Phân mảnh quét mở rộng ...................: 35,97%
• Trung bình Byte miễn phí trên mỗi trang .....................: 692,5
• Trung bình Mật độ trang (đầy đủ) .....................: 91,44%

sys.dm_db_index_physical_stats

index_type_desc      alloc_unit_type_desc     Avg_fragmentation_in_percent  page_count

CLUSTERED INDEX       IN_ROW_DATA          3.236803129  1222070

NONCLUSTERED INDEX    IN_ROW_DATA          0.680074642  48230

NONCLUSTERED INDEX    IN_ROW_DATA          0.093237195  48264

NONCLUSTERED INDEX    IN_ROW_DATA          0.03315856   48253

NONCLUSTERED INDEX    IN_ROW_DATA          0.194653248  48291

NONCLUSTERED INDEX    IN_ROW_DATA          0.393480436  58961

NONCLUSTERED INDEX    IN_ROW_DATA          0.23622292   64346

NONCLUSTERED INDEX    IN_ROW_DATA          0.041445623  48256

NONCLUSTERED INDEX    IN_ROW_DATA          0.701172007  59044

NONCLUSTERED INDEX    IN_ROW_DATA          0.216397724  53605

Tôi có nên quan tâm đến các chỉ số của tôi? Một ở trên không phải là không điển hình. MS DMV ưa thích sẽ xuất hiện cho thấy nó vẫn ổn, nhưng nhà cung cấp bị mắc kẹt trên mức phân mảnh 35,97% đó. Tôi nghi ngờ đây chỉ là họ đang cố gắng tìm kiếm thứ gì đó để đổ lỗi cho vấn đề phần mềm của họ, nhưng nếu tôi gặp vấn đề thực sự, tôi muốn thử và sửa nó.

Phần mềm của họ có xu hướng đóng băng và ngừng hoạt động một hoặc hai lần một tuần gây ra sự gián đoạn lớn cho hoạt động của chúng tôi. Họ đã không thể xác định nguyên nhân mặc dù chúng tôi đã gửi cho họ nhiều GB nhật ký và bản sao lưu của DB. ... Đặc biệt họ đang nói rằng các chỉ số của chúng tôi là một vấn đề.

Ồ, phải rồi, tôi nghĩ tôi đã nghe trò đùa này trước đây. Nó không đi giống như:

Một con vịt đi vào quán bar và nói, "Ouch!" (đùa thôi ;-) và nhân viên pha chế nói, "Bạn sẽ có gì?"

Con vịt nói, "Gimme 3 ngón tay của vodka mạnh nhất của bạn."

Người pha chế nói, gần như thể anh ta đang nói đùa, "Không phải bạn có nghĩa là 3 'lông'?"

Con vịt nói: "Hãy nhìn xem, tôi xin lỗi vì bạn không còn là nhà văn chính cho Mọi người yêu Raymond , nhưng đó là một ngày khó khăn vì vậy bạn có thể là một người bạn thân và làm với vodka không?"

Người pha chế nói, "Chắc chắn rồi, anh bạn. Giữ lấy."

Anh ta quay lại một lúc sau, rõ ràng hơi kém hạnh phúc so với khi anh ta rời đi và nói với con vịt, "Có vẻ như tất cả chúng ta đều thoát khỏi những thứ tốt. Tất cả những gì chúng ta còn lại là Skyy. Công việc đó có ổn không?"

Con vịt nhảy lên quầy, túm lấy cổ áo bằng một cánh (bằng cách nào đó), rút ​​con dao ra, tốt, ở đâu đó với cánh kia, và nói, khá chậm rãi, nhẹ nhàng, nhưng rõ ràng, "Tôi sẽ . Cắt bạn."

Người pha chế, hoảng loạn, nói, "Này anh bạn, đó là cơ sở dữ liệu. Nó chậm. Nó không phản hồi."

Con vịt, hơi bối rối không biết liệu anh ta có nên kết thúc người pha chế hay không - ngay tại đây, ngay bây giờ - sủa anh ta một cách giận dữ, "Cơ sở dữ liệu? Anh đang nói cái quái gì vậy?"

Người pha chế, bây giờ khóc nức nở, thốt lên, "Tôi không biết ... Có bất kỳ sự ngăn chặn nào đang diễn ra không? .. Đó chỉ là những gì chúng ta nói .... Bạn có thể thử xây dựng lại các chỉ mục hoặc một cái gì đó không? chúng ta không biết nói gì nữa .... có lẽ chúng ta nên thêm bộ nhớ vào máy chủ ... bạn nghĩ điều đó có giúp ích gì không? ... mọi người đều biết rằng mã ứng dụng nhanh và cơ sở dữ liệu là cổ chai .. ..Hey, tôi đã được nghe về các cơ sở dữ liệu NoQuery này là <air-trích dẫn> quy mô web </ air-quote> và thường là Nguồn mở để chúng miễn phí, và như, Twitter và Google và Tất cả Facebook đều sử dụng những thứ đó vì cơ sở dữ liệu quan hệ có khá nhiều trên đường ra. "

Và với điều đó, con vịt đã quyết định ............

Hừm. Chà, tin tôi đi, nó vui hơn nhiều so với tiếng Hungary gốc.

Tuy nhiên, tại sao phản ứng ban đầu của rất nhiều người, khi một hệ thống chậm lại, chỉ cho rằng đó là cơ sở dữ liệu? Như thể mã ứng dụng không thể được viết khủng khiếp, hoặc đơn giản là có một số lỗi? Mọi thứ trở nên chậm hơn chắc chắn có thể là cơ sở dữ liệu. Nhưng chỉ đơn giản là khóa / đóng băng? Đó không phải là một vấn đề cụ thể về cơ sở dữ liệu.

Những gì nó nghe có vẻ như có thể là một số mã ứng dụng không giải phóng đúng tài nguyên bên ngoài (ổ cắm mạng, xử lý hệ thống tệp, v.v.). Nếu chúng ta đang nói về một ứng dụng .NET, đôi khi các nhà phát triển quên không sử dụng đúng Dispose()các đối tượng có liên quan đến tài nguyên không được quản lý. Ví dụ: mở ra một SqlConnectionđối tượng. Bạn không nhận được một số lượng vô hạn của chúng. Vì vậy, nếu họ muốn tìm trong cơ sở dữ liệu thì tốt. Nhưng có lẽ, lần tới khi hệ thống đóng băng, hãy xem nhanh:

SELECT sdec.*, '---' AS [---], sdes.*
FROM sys.dm_exec_connections sdec
INNER JOIN sys.dm_exec_sessions sdes
        ON sdes.session_id = sdec.session_id

Nếu mã của họ không giải phóng các kết nối, thì nó sẽ khá rõ ràng nếu có quá nhiều kết nối, đặc biệt là nếu nhiều trong số chúng có thời gian nhàn rỗi dài.

Và có lẽ công cụ này đã được kiểm tra và đơn giản là không được tiết lộ trong Câu hỏi. Nhưng điều gây ấn tượng với tôi là khá kỳ lạ khi họ quá tập trung vào các chỉ số và phân mảnh. Chắc chắn, có những vấn đề đánh hơi thông số đôi khi gây ra một, hoặc có thể một vài, Thủ tục lưu trữ mất thời gian THỰC SỰ, nhưng khóa toàn bộ ứng dụng? Tôi không mua nó, đặc biệt nếu bạn không thấy một truy vấn đang chạy và chiếm nhiều tài nguyên hoặc khóa hoặc thời gian khi điều này xảy ra.

Vì vậy, "để tin tưởng?" Chắc chắn không phải nhà cung cấp này ;-).

Một điều bạn có thể xem lại để xem liệu các chỉ mục của bạn có cần sắp xếp lại hoặc xây dựng lại hay không, là sử dụng truy vấn này:

declare @strBD nvarchar(50)

set @strBD = N'Tu_BD';

select table = OBJECT_NAME(object_id, database_id)
    ,index = index_id
    ,Index_Type = index_type_desc
    ,Logic_Frag = avg_fragmentation_in_percent
    ,Action = case 
        when avg_fragmentation_in_percent < 30.0
            then 'ALTER INDEX REORGANIZE'
        else 'ALTER INDEX REBUILD WITH (ONLINE = ON)'
        end
from sys.dm_db_index_physical_stats(DB_ID(@strBD), null, null, null, 'LIMITED');

Thay thế @strBDbằng your database name.

Theo kết quả, vui lòng tiếp tục như đã nêu trong https://msdn.microsoft.com/en-us/l Library / ms189858 (v = sql.110) .aspx . Liên kết này dành cho phiên bản 2012 của SQL Server; Vui lòng chọn phiên bản thích hợp để tiến hành chính xác.

Như ai đó đã nhận xét, tốt hơn là nói với nhà cung cấp của bạn rằng xem xét và khắc phục, ngoài "vấn đề phân mảnh". Có lẽ xác định một số truy vấn và kế hoạch thực hiện với một bản ghi SQL Profiler.