Permintaan dan pembaruan sangat lambat setelah IndexOptimize

Database SQL Server 2017 Enterprise CU16 14.0.3076.1

Kami baru-baru ini mencoba beralih dari pekerjaan pemeliharaan Index Rebuild default ke Ola Hallengren IndexOptimize. Pekerjaan Rebuild Index default telah berjalan selama beberapa bulan tanpa masalah, dan pertanyaan dan pembaruan bekerja dengan waktu eksekusi yang dapat diterima. Setelah berjalan IndexOptimizedi database:

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'

kinerja sangat menurun. Pernyataan pembaruan yang mengambil 100 IndexOptimizems sebelum mengambil 78.000 ms sesudahnya (menggunakan rencana yang identik), dan kueri juga melakukan beberapa pesanan yang jauh lebih buruk.

Karena ini masih merupakan basis data pengujian (kami memigrasikan sistem produksi dari Oracle), kami kembali ke cadangan dan dinonaktifkan IndexOptimizedan semuanya kembali normal.

Namun, kami ingin memahami apa yang IndexOptimizeberbeda dari "normal" Index Rebuildyang dapat menyebabkan penurunan kinerja yang ekstrem ini untuk memastikan kami menghindarinya begitu kami mulai berproduksi. Setiap saran tentang apa yang harus dicari akan sangat dihargai.

Rencana eksekusi untuk pernyataan pembaruan saat lambat. yaitu
Setelah IndexOptimasi
rencana eksekusi Aktual (segera hadir)

Saya belum dapat menemukan perbedaan.
Rencanakan untuk permintaan yang sama ketika itu adalah rencana eksekusi yang cepat

Saya menduga Anda memiliki tingkat sampel berbeda yang ditentukan antara dua pendekatan pemeliharaan Anda. Saya percaya skrip Ola menggunakan pengambilan sampel default kecuali jika Anda menentukan @StatisticsSampleparameternya , yang sepertinya tidak sedang Anda lakukan.

Pada titik ini, ini adalah spekulasi, tetapi Anda dapat memeriksa untuk melihat tingkat pengambilan sampel apa yang saat ini digunakan pada statistik Anda dengan menjalankan kueri berikut dalam database Anda:

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

Jika Anda melihat ini datang melalui 1s (misalnya 100%) kemungkinan ini adalah masalah Anda. Mungkin coba skrip Ola lagi termasuk @StatisticsSampleparameter dengan persentase yang dikembalikan oleh permintaan ini dan lihat apakah itu memperbaiki masalah Anda?

Sebagai bukti pendukung tambahan untuk teori ini, rencana eksekusi XML menunjukkan laju pengambilan sampel yang sangat berbeda untuk kueri lambat (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]" />

Lawan kueri cepat (100%):

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

Jawaban John adalah solusi yang tepat, ini hanya merupakan tambahan untuk bagian mana dari rencana eksekusi yang diubah dan contoh tentang cara mudah menemukan perbedaan dengan Penjelajah Sentry One Plan

Pernyataan pembaruan yang mengambil 100 ms sebelum IndexOptimize mengambil 78.000 ms sesudahnya (menggunakan paket yang identik)

Saat melihat semua paket kueri saat kinerja Anda menurun, Anda dapat dengan mudah menemukan perbedaannya.

Performa yang menurun

Dua hitungan lebih dari 35 detik waktu cpu & waktu berlalu

Performa yang diharapkan

Jauh lebih baik

Degradasi utama adalah dua kali pada permintaan pembaruan ini:

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)
                      )

rencana eksekusi untuk permintaan ini dengan kinerja yang menurun

Perkiraan rencana kueri dari kueri pembaruan ini memiliki perkiraan yang sangat tinggi ketika kinerja terdegradasi:

Sementara dalam kenyataannya (rencana eksekusi aktual) masih harus melakukan pekerjaan, hanya saja bukan jumlah gila yang ditampilkan perkiraan.

Dampak terbesar pada kinerja adalah dua pemindaian & hash match yang tergabung di bawah:

Pemindaian aktual pada kinerja terdegradasi # 1

Pemindaian aktual pada kinerja terdegradasi # 2

Paket eksekusi untuk permintaan ini dengan kinerja yang diharapkan

Saat Anda membandingkannya dengan perkiraan (atau aktual) dari rencana kueri dengan kinerja normal yang diharapkan, perbedaannya mudah dikenali.

Juga, dua akses tabel sebelumnya bahkan tidak terjadi:

Anda tidak melihat penghapusan ini pada gabungan hash karena input build (atas) dimasukkan ke tabel hash terlebih dahulu. Setelah itu nilai nol diperiksa dalam tabel hash ini, mengembalikan nilai nol.

Tanpa informasi lebih lanjut, kami hanya dapat menerima bacokan informasi ringan dalam gelap, jadi Anda harus mengedit pertanyaan untuk memberikan sedikit lebih banyak. Misalnya, kueri merencanakan untuk pernyataan pembaruan yang telah Anda berikan waktunya, baik sebelum dan sesudah operasi pemeliharaan indeks karena rencana mungkin berbeda karena statistik indeks telah diperbarui ( https://www.brentozar.com/pastetheplan Saya berguna untuk ini, daripada mengisi pertanyaan dengan apa yang mungkin merupakan sebagian besar dari XML atau memberikan screen-grab yang tidak termasuk beberapa informasi terkait yang berisi teks dari paket tersebut).

Dua poin yang sangat sederhana dari kelelawar:

1. Sudahkah proses optimalisasi selesai? Jika tes Anda bersaing dengan IO pembangunan kembali indeks berjalan lama yang akan mempengaruhi timing.
2. Apakah Anda menguji beberapa kali? Jika pembaruan didasarkan pada data dari kueri yang mempertimbangkan banyak data (daripada `UPDATE TheTable SET yang sederhana, ThisColumn = 'Nilai Statis') maka mungkin data ini biasanya dalam memori tetapi telah dihapus dalam yang menjalankan kueri terkait yang pertama akan lebih lambat dari biasanya karena memukul disk daripada menemukan halaman yang diperlukan sudah ada di buffer pool dalam memori.