Valore corretto per il fattore di riempimento per gli indici cluster con chiavi di identità surrogate

Ho una grande tabella che ha un indice cluster con una chiave primaria di identità. Sto decidendo il valore corretto per il fattore di riempimento per questa tabella per ridurre al minimo le divisioni di pagina. Manteniamo gli indici utilizzando uno script eseguito quotidianamente che misura la frammentazione e intraprende le azioni appropriate. La tabella contiene colonne di lunghezza variabile.

Il mio primo pensiero è stato quello di impostarlo su 100 (poiché i record dovrebbero essere scritti solo alla fine della tabella) ma presumo che le modifiche alle colonne a lunghezza variabile potrebbero anche causare suddivisioni di pagina, quindi ora sto andando verso 90.

Qualche consiglio apprezzato.

Dipende

È un atto di bilanciamento. Se la tua tabella è ad alta intensità di lettura, con non molti aggiornamenti o eliminazioni, l'impostazione predefinita (che è 100) dovrebbe essere ok.

Se la tua tabella è molto intensa in scrittura, con molti aggiornamenti, un valore inferiore a 80 potrebbe essere più appropriato.

Non esiste una formula magica per questa roba. (AFAIK, se c'è, per favore, fammi sapere) La cosa migliore da fare è avere un ambiente di test, avere un carico di lavoro da testare. Apportare le modifiche e vedere le prestazioni del database con il carico di lavoro.

Nick ha praticamente ragione.

Se esegui aggiornamenti che aumentano le dimensioni di un record su pagine impaccate, causerai divisioni di pagina, ma a parte questo, con una chiave primaria di identità nulla causerà divisioni di pagina nell'indice cluster.

(Anche se lo dico, ci sono 5 tipi di suddivisioni di pagina che il motore di archiviazione può fare e non tutte causano frammentazione e spostamento dei dati - quello che si ottiene inserendo valori di identità monatonicamente crescenti è una divisione di fine pagina. Io divago...)

Ho aiutato molti clienti in questo e ho scritto tutto su BOL: se vuoi semplicemente scegliere un valore come stake-in-the-ground, il 70% ha riscontrato il maggior successo. Come dice Nick, controlla e modifica come appropriato.

Scegliere un fattore di riempimento per qualsiasi indice è un atto di bilanciamento di quanta attività si verifica che spinge la pienezza della pagina verso il 100% e con quale frequenza è possibile intraprendere azioni correttive per ripristinare il fattore di riempimento. Devi pensare a quanto spazio inizialmente verrà "sprecato" sulle pagine se imposti un fattore di riempimento molto basso, come il 50%, ma in alcuni casi ho visto che questo è appropriato.

Dovresti anche considerare come verrà utilizzato l'indice. Se è solo per le ricerche singleton, potresti cavartela con un fattore di riempimento inferiore e più tempo tra ricostruzione / deframmentazione poiché non sprecherai troppi IO / memoria per avere un sacco dell'indice cluster scarsamente popolato in memoria. Per eseguire scansioni a ampio raggio, è necessario aumentare il fattore di riempimento un po 'più in alto, per aumentare l'IO e l'efficienza della memoria.

C'è anche la domanda OLTP vs DW: di solito un DW è immutabile, quindi gli indici avrebbero un fattore di riempimento del 100%. OLTP è la parte difficile.

Dopo aver risolto l'indice cluster, ricorda che anche i non cluster avranno bisogno di attenzione poiché molto probabilmente verranno frammentati.

Quando si reimposta il fattore di riempimento, tenere presente che è possibile scegliere tra ricostruzione e deframmentazione. DBCC INDEXDEFRAG / ALTER INDEX ... REORGANIZE può ripristinare il fattore di riempimento in alcuni casi per gli indici che non sono frammentati.

Spero che sia di aiuto!

(Ci scusiamo per la "risposta eccessiva" - uno dei miei tasti di scelta rapida, dopo aver scritto il codice :-)