Query e aggiornamenti estremamente lenti dopo IndexOptimize

Database SQL Server 2017 Enterprise CU16 14.0.3076.1

Di recente abbiamo provato a passare dai lavori di manutenzione predefiniti di ricostruzione degli indici a Ola Hallengren IndexOptimize. I lavori predefiniti di ricostruzione degli indici erano in esecuzione da un paio di mesi senza problemi e le query e gli aggiornamenti funzionavano con tempi di esecuzione accettabili. Dopo l'esecuzione IndexOptimizesul 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'

le prestazioni sono state estremamente degradate. Una dichiarazione di aggiornamento che ha richiesto 100 ms prima IndexOptimizeha richiesto 78.000 ms in seguito (utilizzando un piano identico), e le query hanno anche peggiorato diversi ordini di grandezza.

Dato che questo è ancora un database di test (stiamo migrando un sistema di produzione da Oracle) siamo tornati a un backup e disabilitato IndexOptimizee tutto è tornato alla normalità.

Tuttavia, vorremmo capire cosa IndexOptimizefa diversamente dal "normale" Index Rebuildche potrebbe aver causato questo degrado estremo delle prestazioni al fine di assicurarci di evitarlo una volta che andremo in produzione. Qualsiasi suggerimento su cosa cercare sarebbe molto apprezzato.

Piano di esecuzione dell'istruzione di aggiornamento quando è lento. cioè
dopo IndexOptimize
Piano di esecuzione effettivo (disponibile al più presto)

Non sono stato in grado di individuare una differenza.
Pianificare la stessa query quando è veloce
Piano di esecuzione effettivo

Ho il sospetto che tu abbia una diversa frequenza di campionamento definita tra i tuoi due approcci di manutenzione. Credo che gli script di Ola utilizzino il campionamento predefinito a meno che non specifichi il @StatisticsSampleparametro , che non sembra che stia facendo attualmente.

A questo punto, questa è una speculazione, ma puoi verificare per vedere quale frequenza di campionamento è attualmente utilizzata nelle tue statistiche eseguendo la seguente query nel tuo database:

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

Se vedi che questo sta attraversando un 1s (es. 100%), è questo il tuo problema. Magari prova di nuovo gli script di Ola includendo il @StatisticsSampleparametro con la percentuale che viene restituita da questa query e vedi se questo risolve il tuo problema?

Come ulteriore prova a sostegno di questa teoria, l'XML del piano di esecuzione mostra frequenze di campionamento molto diverse per la query lenta (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]" />

Contro la query veloce (100%):

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

La risposta di John è la soluzione corretta, questa è solo un'aggiunta a quali parti del piano di esecuzione sono cambiate e ad esempio su come individuare facilmente le differenze con Sentry One Plan explorer

Una dichiarazione di aggiornamento che ha richiesto 100 ms prima che IndexOptimize impiegasse 78.000 ms in seguito (utilizzando un piano identico)

Quando si esaminano tutti i piani di query quando le prestazioni sono state ridotte, è possibile individuare facilmente le differenze.

Prestazione degradata

Due conteggi di oltre 35 secondi di tempo cpu e tempo trascorso

Prestazioni attese

Molto meglio

Il degrado principale è due volte in questa query di aggiornamento:

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

il piano di esecuzione per questa query con prestazioni degradate

Il piano di query stimato di questa query di aggiornamento ha stime molto elevate in caso di degrado delle prestazioni:

Mentre in realtà (l'attuale piano di esecuzione) deve ancora fare un lavoro, non solo la quantità folle che mostrano le stime.

Il maggiore impatto sulle prestazioni sono le due scansioni e le partite hash che seguono:

Scansione effettiva su prestazioni degradate n. 1

Scansione effettiva su prestazioni degradate n. 2

Il piano di esecuzione per questa query con prestazioni previste

Quando lo si confronta con le stime (o gli effettivi) del piano di query con le prestazioni previste normali, le differenze sono facili da individuare.

Inoltre, i precedenti accessi alle due tabelle non sono nemmeno avvenuti:

Questa eliminazione non viene visualizzata nel join hash perché l'input build (in alto) viene inserito per primo nella tabella hash. Successivamente vengono analizzati valori zero in questa tabella hash, restituendo valori zero.

Senza ulteriori informazioni possiamo prendere solo pugnalate leggermente informate al buio, quindi dovresti modificare la domanda per fornire un po 'di più. Ad esempio, i piani di query per quella dichiarazione di aggiornamento per cui sono stati indicati i tempi, sia prima che dopo le operazioni di manutenzione dell'indice poiché i piani possono differire a causa dell'aggiornamento delle statistiche dell'indice ( https://www.brentozar.com/pastetheplan / è utile per questo, piuttosto che riempire la domanda con quello che potrebbe essere un grosso pezzo di XML o dare una schermata che non include alcune delle informazioni pertinenti contenute nel testo del piano).

Due punti molto semplici fuori dal pipistrello però:

1. La corsa di ottimizzazione è stata definitivamente completata? Se i tuoi test sono in competizione con l'IO delle ricostruzioni degli indici di lunga durata che influiranno sui tempi.
2. Hai provato più volte? Se l'aggiornamento si basa sui dati di una query che considera molti dati (piuttosto che un semplice `UPDATE TheTable SET ThisColumn = 'A Static Value'), è possibile che questi dati siano normalmente in memoria ma sono stati cancellati in che le prime esecuzioni delle query correlate saranno più lente del solito a causa del colpire il disco anziché trovare le pagine necessarie già nel pool di buffer in memoria.