Truy vấn và cập nhật cực kỳ chậm sau khi IndexOptizing

Cơ sở dữ liệu SQL Server 2017 Enterprise CU16 14.0.3076.1

Gần đây chúng tôi đã thử chuyển từ các công việc bảo trì Index Rebuild mặc định sang Ola Hallengren IndexOptimize. Các công việc Index Rebuild mặc định đã chạy trong một vài tháng mà không có vấn đề gì, và các truy vấn và cập nhật đang hoạt động với thời gian thực hiện chấp nhận được. Sau khi chạy IndexOptimizetrên cơ sở dữ liệu:

EXECUTE dbo.IndexOptimize
@Databases = 'USER_DATABASES',
@FragmentationLow = NULL,
@FragmentationMedium = 'INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationHigh = 'INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationLevel1 = 5,
@FragmentationLevel2 = 30,
@UpdateStatistics = 'ALL',
@OnlyModifiedStatistics = 'Y'

hiệu suất đã vô cùng xuống cấp. Một tuyên bố cập nhật mất 100ms trước đó IndexOptimizemất 78.000ms sau đó (sử dụng một kế hoạch giống hệt nhau) và các truy vấn cũng đang thực hiện một số đơn đặt hàng có cường độ tồi tệ hơn.

Vì đây vẫn là một cơ sở dữ liệu thử nghiệm (chúng tôi đang di chuyển một hệ thống sản xuất từ ​​Oracle), chúng tôi đã trở lại bản sao lưu và bị vô hiệu hóa IndexOptimizevà mọi thứ trở lại bình thường.

Tuy nhiên, chúng tôi muốn hiểu điều gì IndexOptimizekhác với "bình thường" Index Rebuildcó thể gây ra sự suy giảm hiệu suất cực đoan này để đảm bảo chúng tôi tránh được điều đó một khi chúng tôi đi vào sản xuất. Bất kỳ đề xuất về những gì cần tìm sẽ được đánh giá rất cao.

Kế hoạch thực hiện cho tuyên bố cập nhật khi nó chậm. tức là
sau khi IndexOptizing tối đa
kế hoạch thực hiện (sắp tới)

Tôi đã không thể nhận ra một sự khác biệt.
Lập kế hoạch cho cùng một truy vấn khi đó là kế hoạch thực hiện nhanh

Tôi nghi ngờ bạn đã có một tỷ lệ mẫu khác nhau được xác định giữa hai phương pháp bảo trì của bạn. Tôi tin rằng các tập lệnh của Ola sử dụng lấy mẫu mặc định trừ khi bạn chỉ định @StatisticsSampletham số , nó không giống như bạn đang làm.

Tại thời điểm này, đây là suy đoán, nhưng bạn có thể kiểm tra xem tốc độ lấy mẫu nào hiện đang được sử dụng trên số liệu thống kê của mình bằng cách chạy truy vấn sau trong cơ sở dữ liệu của bạn:

SELECT  OBJECT_SCHEMA_NAME(st.object_id) + '.' + OBJECT_NAME(st.object_id) AS TableName
    ,   col.name AS ColumnName
    ,   st.name AS StatsName
    ,   sp.last_updated
    ,   sp.rows_sampled
    ,   sp.rows
    ,   (1.0*sp.rows_sampled)/(1.0*sp.rows) AS sample_pct
FROM sys.stats st 
    INNER JOIN sys.stats_columns st_col
        ON st.object_id = st_col.object_id
        AND st.stats_id = st_col.stats_id
    INNER JOIN sys.columns col
        ON st_col.object_id = col.object_id
        AND st_col.column_id = col.column_id
    CROSS APPLY sys.dm_db_stats_properties (st.object_id, st.stats_id) sp
ORDER BY 1, 2

Nếu bạn thấy điều này xảy ra trong 1 giây (ví dụ 100%) thì đây có thể là vấn đề của bạn. Có thể thử lại các tập lệnh của Ola bao gồm @StatisticsSampletham số với tỷ lệ phần trăm được trả về bởi truy vấn này và xem điều đó có khắc phục được sự cố của bạn không?

Là bằng chứng hỗ trợ bổ sung cho lý thuyết này, XML của kế hoạch thực hiện cho thấy tỷ lệ lấy mẫu rất khác nhau đối với truy vấn chậm (2,18233%):

<StatisticsInfo LastUpdate="2019-09-01T01:07:46.04" ModificationCount="0" 
    SamplingPercent="2.18233" Statistics="[INDX_UPP_4]" Table="[UPPDRAG]" 
    Schema="[SVALA]" Database="[ulek-sva]" />

So với truy vấn nhanh (100%):

<StatisticsInfo LastUpdate="2019-08-25T23:01:05.52" ModificationCount="555" 
    SamplingPercent="100" Statistics="[INDX_UPP_4]" Table="[UPPDRAG]" 
    Schema="[SVALA]" Database="[ulek-sva]" />

Câu trả lời của John là giải pháp chính xác, đây chỉ là phần bổ sung cho những phần nào trong kế hoạch thực hiện đã thay đổi và ví dụ về cách dễ dàng phát hiện sự khác biệt với nhà thám hiểm Sentry One Plan

Một tuyên bố cập nhật mất 100ms trước khi IndexOptizing mất 78.000ms sau đó (sử dụng một kế hoạch giống hệt nhau)

Khi xem xét tất cả các kế hoạch truy vấn khi hiệu suất của bạn bị suy giảm, bạn có thể dễ dàng phát hiện ra sự khác biệt.

Hiệu suất xuống cấp

Hai lần đếm trên 35 giây thời gian cpu và thời gian đã trôi qua

Hiệu suất mong đợi

Tốt hơn nhiều

Sự xuống cấp chính là hai lần trên truy vấn cập nhật này:

UPDATE SVALA.INGÅENDEANALYS
                           SET 
                              UPPDRAGAVSLUTAT = @NEW$AVSLUTAT
                        WHERE INGÅENDEANALYS.ID IN 
                           (
                              SELECT IA.ID
                              FROM 
                                 SVALA.INGÅENDEANALYS  AS IA 
                                    JOIN SVALA.INGÅENDEANALYSX  AS IAX 
                                    ON IAX.INGÅENDEANALYS = IA.ID 
                                    JOIN SVALA.ANALYSMATERIAL  AS AM 
                                    ON AM.ID = IA.ANALYSMATERIALID 
                                    JOIN SVALA.ANALYSMATERIALX  AS AMX 
                                    ON AMX.ANALYSMATERIAL = AM.ID 
                                    JOIN SVALA.INSÄNTMATERIAL  AS IM 
                                    ON IM.ID = AM.INSÄNTMATERIALID 
                                    JOIN SVALA.INSÄNTMATERIALX  AS IMX 
                                    ON IMX.INSÄNTMATERIAL = IM.ID
                              WHERE IM.UPPDRAGSID = SVALA.PKGSVALA$STRIPVERSION(@NEW$ID)
                      )

kế hoạch thực hiện cho truy vấn này với hiệu suất bị suy giảm

Kế hoạch truy vấn ước tính của truy vấn cập nhật này có ước tính rất cao khi hiệu suất bị suy giảm:

Mặc dù trong thực tế (kế hoạch thực hiện thực tế) nó vẫn phải thực hiện công việc, nhưng không phải là số tiền điên rồ mà các ước tính cho thấy.

Tác động lớn nhất đến hiệu suất là hai lần quét và kết hợp khớp băm dưới đây:

Quét thực tế về hiệu suất xuống cấp # 1

Quét thực tế trên hiệu suất xuống cấp # 2

Kế hoạch thực hiện cho truy vấn này với hiệu suất dự kiến

Khi bạn so sánh điều đó với các ước tính (hoặc thực tế) của kế hoạch truy vấn với hiệu suất dự kiến ​​bình thường, sự khác biệt rất dễ nhận ra.

Ngoài ra, hai lần truy cập bảng trước đó thậm chí không xảy ra:

Bạn không thấy sự loại bỏ này trên phép nối băm vì đầu vào bản dựng (trên cùng) được chèn vào bảng băm trước tiên. Sau đó, các giá trị 0 được thăm dò trong bảng băm này, trả về các giá trị 0.

Nếu không có thêm thông tin, chúng tôi chỉ có thể đưa những cú đâm nhẹ vào bóng tối, vì vậy bạn nên chỉnh sửa câu hỏi để cung cấp thêm một chút. Chẳng hạn, các kế hoạch truy vấn cho câu lệnh cập nhật mà bạn đã đưa ra thời gian cho cả trước và sau các hoạt động bảo trì chỉ mục vì các kế hoạch có thể khác nhau do các số liệu thống kê chỉ mục đã được cập nhật ( https://www.brentozar.com/pastetheplan / rất hữu ích cho việc này, thay vì điền vào câu hỏi với phần lớn XML hoặc đưa ra một màn hình lấy mà không bao gồm một số thông tin thích hợp mà văn bản của kế hoạch chứa).

Hai điểm rất đơn giản ngoài dơi:

1. Đã chạy tối ưu hóa chắc chắn hoàn thành? Nếu các bài kiểm tra của bạn đang cạnh tranh với IO của việc xây dựng lại chỉ mục chạy dài sẽ ảnh hưởng đến thời gian.
2. Bạn đã kiểm tra nhiều lần? Nếu bản cập nhật dựa trên dữ liệu từ một truy vấn xem xét nhiều dữ liệu (chứ không phải là một 'CẬP NHẬT TheTable SET ThisColumn =' Giá trị tĩnh ') thì có thể dữ liệu này thường nằm trong bộ nhớ nhưng đã bị xóa mà các lần chạy đầu tiên của các truy vấn có liên quan sẽ chậm hơn bình thường do nhấn vào đĩa thay vì tìm các trang cần thiết đã có trong vùng đệm trong bộ nhớ.