Per cercare quali statistiche o indici duplicati, ci bassiamo nel primo capo. Questo si deve a che le statistiche automatiche sono su un campo; b/ le statistiche d’usuario possono andare suvari campi, ma è il primo quello che ci può indicare i duplicati; e c/ nel caso degl’indici, se due iniziano con lo stesso campo, dobbiamo analizzare se uno copre l’altro o se sono necessari tutti e due. Quindi no cerchiamo coincidenze esatte, ma segni che possono esistere statistiche o indici duplicati, quindi, migliora il rendimento se gli eliminiamo.
Per quello, per ogni base di dati cerchiamo in tutte le tabelle (sys.tables e sys.schemas) tutte le statistiche (sys.stats) e il primo campo secondo l’ordine della statistica (sys.stats_columns), inoltre al nome e largo di quella colonna (sys.columns).
Il largo è informativo, un’altra cosa che possiamo fare è eliminare statistiche dei campi troppo larghi, in generale non si usano nelle indagini. Cioè, in un campo grande spesso si usa LIKE per cercare in qualsiasi parte del campo, e le statistiche in generale non aiutanoin questo caso.
Se agruppiamo attraverso l’identificatore del oggetto e della colonna, andremmo ad ottenere quelle statistiche che potremmo analizzare.
Se l’istanza di SQL Server ha molte basi di dati o hanno un lungo periodo senza revisione, ci possono tornare molte statistiche duplicate. visto che di solito non influisce sulle prestazioni, siamo in grado di concentrarci sulle più importanti, sia per le sue dimensioni, sia per il numero di righe.
Ora, questo può essere affrontato in diversi modi. Nel mio caso ho voluto conoscere la dimensione della prima colonna sia in MB come in records. Cioè, come non mi interessano solo le statistiche, ma anche gli indici, non ho cercato il numero di righe controlate per fare la statistica, ma la colonna. Pertanto, una volta ottenuto quelle statistiche che sembravano duplicate, le ho aggiunte questi dati per poi filtrare le più importanti.
In genere è quando si inizia a lavorare con una tabella, e su questa era abilitata la creazione automatica di statistiche, SQL Server crea statistiche automatiche di colonna per analizzare consulte, e poi si creanno indici. È facile trovare tabelle che hanno statistiche in tutte le sue colonne anche se negli aplicativi no si usino queste colonne in ricerche. È l’effetto delle prove in produzione dove si analizzano le colonne e SQL Server crea statistiche per consulte che si eseguono una sola volta.
Vediamo un esempio. Queste sono le statistiche automatiche e di indice:
Se guardiamo bene, una volta aggiornate insieme, sono identiche. Per quello, potremmo togliere le automatiche ed avere un percorso in meno da fare durante la manutenzione. Un’analisi di questo tipo può evitare di fare la scansione di milioni di linee nella manutenzione della bese di dati.
Quelle precedenti le guardiamo nel Object Explorer:
Vediamo che la consulta ci da sia il nome, come l’identificatore nel campo decimale e esadecimale. Per le statistiche automatiche, quel identificatore esadecimale si trova nel nome della statistica e così lo possiamo trovare rapidamente. Nel esempio, il campo IDTASK è il secondo e troviamo il duplicato subito.
In altre occasioni bisogna analizzare ogni statistica per trovare il duplicato. Per esempio nel caso degli indici <<duplicati>>:
In questo caso abbiamo che ci sono tre statistiche che iniziano per il campo ATTRIBUTE_ID, quindi ci offre un aiuto aggiuntivo per questo tipo di analisi: C’è qualche indice superfluo? Per quello ricorreremo all’analisi standar del uso degl’indici e elimineremo quei indici (quello che fa sparire la statistica) che si aggiornano troppo e si usano poco. In oltre ocasioni vedremo che, anche se ce una posibilitè superflua, incluso che un indici copra un’altro, tutti si stanno usando per accelerare le consulte specifiche e quindi sono necessarie. In questo caso è meglio lasciarli.
Se guardiamo bene, l’ordine delle colonne nella vista della statistica (stats_column_id) è molto diverso a quello reale che ci indica la vista dell’indice (key_ordina). Quindi, questa consulta dovrebbe essere migliorata affinchè, se una statistica d’indice, trovasse il primo campo dell’indice invece di quello della statistica. Ma questa implicazione la lasciamo come compito.
Anche se non è necessario l’analisi delle statistiche duplicate, se usiamo i filtri adeguati ci possono indicare quelle che migliorano la manutenzione come quei indici que possiamo eliminare.
Lascia un Commento
Vuoi partecipare alla discussione?Sentitevi liberi di contribuire!