IndexOptimize'dan sonra sorgular ve güncellemeler son derece yavaş

Veritabanı SQL Server 2017 Enterprise CU16 14.0.3076.1

Kısa bir süre önce varsayılan İndeks Yenileme bakım işlerinden Ola Hallengren'e geçmeyi denedik IndexOptimize. Varsayılan Dizin Yeniden Oluşturma işleri birkaç ay boyunca sorunsuz bir şekilde çalışıyordu ve sorgular ve güncellemeler kabul edilebilir yürütme süreleriyle çalışıyordu. IndexOptimizeVeritabanında çalıştırdıktan sonra :

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'

performans çok düştü. Daha önce 100 ms süren bir güncelleme ifadesi IndexOptimizedaha sonra 78.000 ms sürdü (özdeş bir plan kullanarak) ve sorgular aynı zamanda birkaç büyüklük daha da kötüye gitti.

Bu hala bir test veritabanı olduğundan (Oracle'dan bir üretim sistemi geçiriyoruz) bir yedeklemeye geri döndük ve devre dışı bıraktık IndexOptimizeve her şey normale döndü.

Ancak üretime geçtikten sonra bundan kaçındığımızdan emin olmak için bu aşırı performans bozulmasına neden olabilecek IndexOptimize"normal" den farklı olanı anlamak Index Rebuildistiyoruz. Ne aramak için herhangi bir öneri büyük mutluluk duyacağız.

Güncelleme deyimi yavaş olduğunda yürütme planı. ie
IndexOptimize Gerçek yürütme planından sonra (en kısa sürede
geliyor)

Bir fark bulamadım.
Hızlı olduğunda aynı sorguyu planlayın
Gerçek yürütme planı

İki bakım yaklaşımınız arasında tanımlanmış farklı bir örnekleme oranınız olduğundan şüpheleniyorum . Şu anda yaptığınız gibi görünmeyen @StatisticsSampleparametreyi belirtmedikçe Ola'nın komut dosyalarının varsayılan örneklemeyi kullandığına inanıyorum .

Bu noktada, bu bir spekülasyon, ancak veritabanınızda aşağıdaki sorguyu çalıştırarak istatistiklerinizde şu anda hangi örnekleme oranının kullanıldığını kontrol edebilirsiniz:

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

Bunun 1'lerden (örneğin% 100) geldiğini görüyorsanız, bu sizin sorununuzdur. Belki Ola'nın komut dosyalarını @StatisticsSample, bu sorgu tarafından döndürülen yüzdeyle birlikte parametre de dahil olmak üzere tekrar deneyin ve bunun sorununuzu çözüp çözmediğine bakın?

Bu teori için ek destekleyici kanıt olarak, yürütme planı XML'si yavaş sorgu için oldukça farklı örnekleme oranları gösterir (% 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]" />

Hızlı sorguya (% 100) karşı:

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

John'un cevabı doğru çözümdür, bu sadece yürütme planının hangi bölümlerinin değiştiğine ve Sentry One Plan explorer ile farkların nasıl kolayca tespit edileceğine bir eklentidir.

IndexOptimize'dan 100ms önce geçen bir güncelleme bildirimi daha sonra 78.000ms aldı (aynı planı kullanarak)

Performansınızın düştüğü tüm sorgu planlarına bakarken, farkları kolayca tespit edebilirsiniz.

Düşük performans

İşlemci süresi ve geçen sürenin 35 saniyesinin üzerinde iki sayım

Beklenen performans

Çok daha iyi

Ana bozulma bu güncelleştirme sorgusunda iki kez olur:

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

düşük performans gösteren bu sorgu için yürütme planı

Bu güncelleştirme sorgusunun tahmini sorgu planı performans düştüğünde çok yüksek tahminlere sahiptir:

Gerçekte (gerçek yürütme planı), tahminlerin gösterdiği çılgın miktar değil, yine de iş yapmak zorundadır.

Performans üzerindeki en büyük etki, aşağıdaki iki tarama ve karma eşleştirme birleşimidir:

Düşük performansta gerçek tarama # 1

Düşük performansta gerçek tarama # 2

Beklenen performansa sahip bu sorgu için yürütme planı

Bunu, normal beklenen performansa sahip sorgu planının tahminleri (veya gerçek değerleri) ile karşılaştırdığınızda, farkların fark edilmesi kolaydır.

Ayrıca, önceki iki tablo erişimi bile gerçekleşmedi:

İlk olarak build (top) girişi karma tablosuna eklendiğinden, karma birleştirmesinde bu elemeyi göremezsiniz. Daha sonra sıfır değerlerini döndüren bu karma tabloda sıfır değerleri incelenir.

Daha fazla bilgi olmadan, karanlıkta sadece hafifçe bilgilendirilmiş bıçaklar alabiliriz, bu yüzden biraz daha fazla sağlamak için soruyu düzenlemeniz gerekir. Örneğin, dizin bakım işlemlerinden önce ve sonra zamanlamaları verdiğiniz söz konusu güncelleme deyiminin sorgu planları, planların güncellendiği dizin istatistikleri nedeniyle farklılık gösterebileceğinden ( https://www.brentozar.com/pastetheplan) / soruyu büyük bir XML parçası ile doldurmak veya planın metninin içerdiği ilgili bilgilerin bir kısmını içermeyen bir ekran görüntüsü vermek yerine bunun için yararlıdır).

Ama yarasadan iki çok basit nokta:

1. Optimizasyon çalışması kesinlikle tamamlandı mı? Testleriniz, zamanlamaları etkileyecek uzun süredir devam eden endeks yeniden oluşturmalarının ES'si ile rekabet ediyorsa.
2. Birden fazla kez test yaptınız mı? Güncelleme, çok fazla veri dikkate alan bir sorgudan elde edilen verilere dayanıyorsa (basit bir `` UPDATE TheTable SET ThisColumn = 'A Static Value' yerine), bu verilerin normalde bellekte olduğu, ancak ilgili sorguların ilk çalıştırmaları, bellekte arabellek havuzunda gerekli olan sayfaları bulmak yerine diske vurma nedeniyle normalden daha yavaş olacaktır .