Il tempo di ricostruzione dell'indice dipende dal livello di frammentazione?

Il tempo richiesto per la ricostruzione dell'indice dipende dal livello di frammentazione?

La ricostruzione di un indice frammentato all'80% richiede circa 2 minuti se la ricostruzione dello stesso indice frammentato al 40% richiede 1 minuto?

Sto chiedendo il RUNTIME (ad esempio in secondi) che potrebbe essere necessario per eseguire l'azione richiesta, non su quale azione è richiesta in quale particolare situazione. Sono a conoscenza delle migliori pratiche di base quando è necessario eseguire il reorg dell'indice o gli aggiornamenti di ricostruzione / statistica.

Questa domanda NON pone su REORG e la differenza tra REORG e REBUILD.

Sullo sfondo: a causa della configurazione di diversi lavori di manutenzione degli indici (ogni notte, lavoro più pesante durante i fine settimana ...) Mi chiedevo se un lavoro di manutenzione dell'indice OFFLINE "leggero intenso" giornaliero dovrebbe essere eseguito meglio su indici frammentati medio-bassi per mantenere il tempi di inattività piccoli - o non importa nemmeno e la ricostruzione su un indice frammentato dell'80% potrebbe richiedere lo stesso tempo di inattività della stessa operazione sullo stesso indice frammentato al 40%.

Ho seguito i suggerimenti e ho cercato di scoprire cosa stesse succedendo. La mia configurazione sperimentale: su un server di prova che non fa NIENTE e non viene utilizzato da nessuno o altro, ho creato una tabella con un indice cluster su una colonna chiave primaria dell'identificatore univoco con alcune colonne aggiuntive e diversi tipi di dati [2 numeri, 9 datetime e 2 varchar (1000)] e righe semplicemente aggiunte. Per il test presentato ho aggiunto circa 305.000 righe.

Quindi ho usato un comando di aggiornamento e ho aggiornato casualmente un intervallo di filtri di righe su un valore intero e ho modificato una delle colonne VarChar con un valore stringa variabile per creare la frammentazione. Dopo di che ho controllato il avg_fragmentation_in_percentlivello attuale in sys.dm_db_index_physical_stats. Ogni volta che ho creato una "nuova" frammentazione per il mio benchmark, ho aggiunto questo valore incluso il physical_page_countvalore alle mie registrazioni di cui è composto il diagramma seguente.

Poi ho corso: Alter index ... Rebuild with (online=on); e l' ho afferrato CPU timeusando STATISTICS TIME ONnelle mie registrazioni.

Le mie aspettative: mi aspettavo di vedere almeno l'indicazione di una sorta di curva lineare che mostra una dipendenza tra livello di frammentazione e tempo della CPU.

Questo non è il caso. Non sono sicuro che questa procedura sia davvero appropriata per un buon risultato. Forse il numero di righe / pagine è troppo basso?

Tuttavia, i risultati indicano che la risposta alla mia domanda originale sarebbe sicuramente NO . Sembra che il tempo richiesto per la CPU sia necessario a SQL Server per ricostruire l'indice non dipende né dal livello di frammentazione né dal conteggio delle pagine dell'indice sottostante.

Il primo grafico mostra il tempo della CPU richiesto per RICOSTRUIRE l'indice rispetto al livello di frammentazione precedente. Come puoi vedere, la linea media è una costante relativa e non è affatto osservabile una relazione tra frammentazione e tempo richiesto della cpu.

Per rispettare la possibile influenza del numero variabile di pagine nell'indice dopo i miei aggiornamenti che potrebbero richiedere più o meno tempo per la ricostruzione, ho calcolato LIVELLO DI FRAGMENTAZIONE * CONTEGGIO PAGINE e ho usato questo valore nel secondo grafico che mostra la relazione del tempo cpu richiesto vs. frammentazione e conteggio delle pagine.

Come puoi vedere, anche questo non indica che il tempo richiesto per la ricostruzione è influenzato dalla frammentazione anche se il numero di pagine varia.

Dopo aver fatto queste affermazioni suppongo che la mia procedura debba essere sbagliata perché il tempo della CPU richiesto per ricostruire un indice enorme e altamente frammentato potrebbe essere influenzato solo dal numero di righe - e non credo davvero in questa teoria.

Quindi, dato che voglio davvero e sicuramente scoprirlo ora, ulteriori commenti e raccomandazioni sono i benvenuti .

Il tempo richiesto per la ricostruzione dell'indice dipende dal livello di frammentazione?

Credo che questo non sarà il parametro principale su cui deciderà SQL Server e richiede tempo per ricostruire \ riorganizzare l'indice:

Ci sono vari altri fattori coinvolti in base a "DATI" attraverso i quali decide per quanto tempo ci vorrà: parametri come

Fattore 1: dimensioni della tabella

Fattore 2: preoccupazioni di disponibilità

Fattore 3: partizionamento

Fattore 4: colonne indice e unicità

Se vuoi leggere di più su questi fattori puoi fare riferimento qui .

La ricostruzione di un indice frammentato all'80% richiede circa 2 minuti se la ricostruzione dello stesso indice frammentato al 40% richiede 1 minuto

Ancora una volta la risposta può essere Dipende! Per i numeri dovrai testare lo scenario e vedere gli output come va. Tieni traccia di tali dettagli come per FRAG livello 80, la ricostruzione ha richiesto X ore \ mins \ sec e per Frag livello 40, la ricostruzione ha impiegato Y ore \ mins \ sec. Calcola e conserva la cronologia per più di 15 giorni (dipende dall'attività di manutenzione programmata) e potresti giungere a una conclusione su quanto tempo impiega effettivamente a confrontare entrambi.

Inoltre:

È possibile raccogliere i dati \ calcolo sull'avanzamento della ricostruzione dell'indice:

utilizzando DMV sys.dm_exec_requests OPPURE

Se disponi dei piani di manutenzione di Ola per la reindicizzazione e la riorganizzazione, esiste un'opzione per salvare la cronologia delle azioni eseguite durante la manutenzione all'interno della tabella CommandLog, come spiegato in SQL Server Index and Statistics Maintenance . Una volta salvati i dati, è possibile eseguire una query per il tipo di comando `ALTER_INDEX - REBUILD 'e la differenza per lo stesso tra le colonne START TIME e END TIME

Per tutti gli interessati, ho creato un grafico che mostra l'indice REBUILD durata di circa 2500 ricostruzioni dell'indice entro un paio di settimane in relazione alla frammentazione dell'indice e alle sue dimensioni in pagine.

Questi dati si basano su 10 server SQL, centinaia di tabelle e sulle procedure di ottimizzazione di Ola Hallengren . La soglia generale per la ricostruzione è impostata su una frammentazione del 5%.

Ho tagliato alcune delle tabelle più grandi (10 Mi + Pagine) in queste statistiche per renderle più leggibili.

Il grafico mostra il tempo richiesto (durata) come dimensione delle bolle. I valori della bolla più grande sono circa 220 secondi. Mostra che il tempo richiesto per ricostruire un indice non è realmente correlato alla frammentazione. Invece sembra essere più dipendente dal numero di pagine dell'indice. Inoltre indica che la frammentazione di basso livello richiede più tempo rispetto alla frammentazione più elevata.

Il secondo grafico viene appena ingrandito nell'area <= 200 K pagine. Mostra lo stesso, impiega più tempo per gli indici più grandi, non per una maggiore frammentazione.

REBUILDdell'indice non dipende dalla frammentazione. Elimina completamente l'indice e lo crea da zero.

REORGANZE indice: serve per ridurre la frammentazione senza la ricostruzione dell'indice, quindi non rilasciare e creare.

MS consiglia di utilizzare Riorganizza per una frammentazione del 30% o inferiore. Per una frammentazione più elevata è preferibile la ricostruzione.

Ecco l'articolo MSDN su questo: riorganizzazione e ricostruzione degli indici

AGGIORNARE

In termini di tempo impiegato per completare l'operazione, dipende ovviamente dalla frammentazione dell'indice. La ricostruzione di un indice estremamente frammentato richiederà meno tempo della riorganizzazione; la ricostruzione di un indice leggermente frammentato richiederà molto più tempo. Suggerirei di prendere le linee guida per la SM come punto di partenza e di eseguire alcuni test sui tuoi tavoli. Il punto di pareggio in termini di frammentazione% dipenderà dalla tabella specifica, dalla dimensione dell'indice e dal tipo di dati.

La ricostruzione di un indice frammentato all'80% richiede circa 2 minuti se la ricostruzione dello stesso indice frammentato al 40% richiede 1 minuto?

L'algoritmo per REBUILD vs REORG è diverso. Un REORG NON ​​assegnerà nuove estensioni invece di un REVISIONATO. Un REORG funzionerà con le pagine attualmente allocate (alloca una pagina casuale da 8Kb in modo che possa spostare le pagine) e le sposta in giro, quindi se necessario spostare le pagine.

Dalle mie note interne di SQLSkills (precedentemente IE0) ....

Per REVISIONATO:

• Può usare più CPU - può sfruttare il parallelismo per fare il lavoro velocemente.
• Per indici fortemente frammentati (ad es. 80% come nel tuo esempio), un REVISION sarà molto più veloce di un REORG. REBUILD creerà semplicemente un'altra copia dell'indice, mentre REORG si impantanerà nel rimuovere la frammentazione e quindi sarà più lento. Questo è il motivo per cui Paul Randal ha dato la sua raccomandazione generale che sarebbe bene fare un RICOSTRUZIONE di un indice fortemente frammentato.
• Un REBUILD ti consentirà di modificare la modalità di ripristino in BULK_LOGGED per una registrazione minima lì generando meno record di registro .

Per Index REORG:

• È sempre a thread singolo. Nessun parallelismo.
• È più lento per gli indici fortemente frammentati e più veloce per gli indici leggermente frammentati. Il costo di creazione di un indice rispetto a un rimbalzo di un indice leggermente frammentato è maggiore e quindi un REORG sarà più veloce per un indice leggermente frammentato.
• Un REORG è sempre un'operazione completamente registrata.

Continua a leggere - Note - Frammentazione, tipi e soluzioni dell'indice di SQL Server

So che è una vecchia discussione, ma penso che sarà utile condividere qui il post di Paul Randal.

Velocità algoritmo

Una ricostruzione dell'indice creerà sempre un nuovo indice, anche se non c'è frammentazione. Il tempo impiegato dalla ricostruzione è correlato alla dimensione dell'indice, non alla quantità di frammentazione in esso.

https://www.sqlskills.com/blogs/paul/sqlskills-sql101-rebuild-vs-reorganize/

Sì, perché in genere una ricostruzione deve scansionare l'indice originale in ordine mentre si esegue lo streaming delle righe (in ordine) in una nuova partizione dell'indice fisico. La frammentazione danneggia scansioni non memorizzate, quindi sì, la ricostruzione richiederà più tempo.

Quanto più a lungo dipende dalla frammentazione e da come la CPU è legata all'intero processo. La serializzazione delle righe richiede molta CPU, quindi potrebbe non avere alcuna importanza. In alternativa, potresti ottenere frequenze IO casuali in genere di 1,5 MB / sec, che è facilmente 5-10 volte più lenta di una ricostruzione veloce (dipende dallo schema e dai dati). A seconda delle ipotesi che fai, puoi probabilmente inventare qualsiasi cosa tra il rallentamento 1x e 100x.

La ricostruzione di un indice frammentato all'80% richiede circa 2 minuti se la ricostruzione dello stesso indice frammentato al 40% richiede 1 minuto?

Non è una relazione lineare. La metrica di frammentazione è un proxy molto approssimativo per quanto tempo impiega a scansionare una partizione.