Perché impostare Statistiche aggiornamento automatico su False?


10

Ho appena ereditato circa 20 istanze di SQL Server, nell'ambito di un progetto di acquisizione più ampio. Sto valutando le prestazioni e non mi piace il modo in cui i piani di manutenzione sono stati implementati.

Vedo ricostruzioni giornaliere dell'indice generale (posso occuparmene) e anche un aggiornamento manuale giornaliero delle statistiche.

Circa la metà dei database è stata impostata su Statistiche aggiornamento automatico = Falso, per motivi non chiari a parte quello che mi è stato detto è di ridurre i "Problemi di prestazioni" ...

Ho sempre pensato e lavorato sulle migliori pratiche per impostare questo su True e ho ritenuto che l'aggiornamento manuale non fosse necessario se questa impostazione era True. Ho sbagliato?

Qualcuno può spiegare quale sarebbe il vantaggio di avere questo set come False, ma facendo invece un aggiornamento manuale giornaliero?

Devo dire che alcuni database sono altamente transazionali (milioni di inserti, eliminazioni, aggiornamenti al giorno), altri sono bassi in termini di tassi di transazione e alcuni sono quasi di sola lettura. Non esiste alcuna rima o motivo per cui l'impostazione di aggiornamento automatico sia impostata su False. Sembra essere una lotteria.

Risposte:


6

Hai ragione, credo anche che nella maggior parte dei casi Auto Update statisticsdovrebbe essere impostato su true dovremmo consentire a SQL Server di decidere quando aggiornare le statistiche e credermi che faccia un buon lavoro. Quando è impostato su true, assicurarsi che le statistiche siano aggiornate sulla distribuzione dei dati sul campo, che alla fine aiuterebbe l'ottimizzatore a preparare un piano migliore. La cosa importante da notare qui è l'attivazione automatica delle statistiche di aggiornamento quando il 20% dei dati cambia nella tabella. Quindi non dovresti pensare che su una tabella con 100.000 righe se vengono aggiornate 10 righe, verrà attivato l'aggiornamento dello stato.

Un'analisi più approfondita viene eseguita da Paul Randal nel blog Capire quando le statistiche si aggiorneranno automaticamente . Non ho riscontrato alcun inconveniente se questa opzione è impostata su true. Sì, puoi vedere alcune attività di I / O quando questa opzione è impostata su true.

Conclusione importante che si può trarre dal blog è

Anche se una statistica diventa obsoleta a seguito di una modifica, non si aggiornerà automaticamente al termine della modifica. La statistica si aggiornerà automaticamente al successivo utilizzo di un piano di query.

Per i casi in cui hai appena letto solo database o database in cui devi solo selezionare l'operazione e non vi è alcuna operazione DML, in quel caso puoi mantenere l'opzione su false ma, di nuovo, non verrebbe alcun danno se la mantieni vera. Vediamo principalmente database con una certa quantità di attività.


10

È troppo lungo per un commento, quindi parlerò di un altro caso in cui si potrebbe voler disattivare le statistiche di aggiornamento automatico. Ho lavorato con database che supportano carichi di lavoro OLTP ad alto volume e un rigoroso SLA sulle prestazioni delle query in millisecondi. Quasi tutte le query erano banali con molta attenzione ai dettagli di ottimizzazione delle query e degli indici e alcune tabelle erano piuttosto grandi. Non è stato molto utile aggiornare le statistiche durante i periodi di punta in questa situazione e le statistiche di aggiornamento automatico violerebbero lo SLA. Di conseguenza, la manutenzione è stata eseguita durante periodi non di punta tramite un lavoro programmato.

Un'altra opzione è attivare entrambe AUTO_UPDATE_STATISTICSe le AUTO_UPDATE_STATISTICS_ASYNCopzioni del database. Ciò consentirà alle query di procedere con piani di esecuzione basati su statistiche non aggiornate anziché sostenere il sovraccarico di aggiornamento delle statistiche in modo sincrono. Ciò è particolarmente appropriato per un carico di lavoro OLTP, purché il server sia dimensionato per adattarsi al carico di lavoro della query e all'aggiornamento delle statistiche in background.


Stavo cercando di pensare a un esempio in cui auto_update_stats avrebbe effettivamente causato problemi e questo è fantastico - lo avrei votato due volte (se potessi) anche per l'ottimo work-around, evitando il normale ritardo delle statistiche che accompagnerebbe un query
SqlRyan

1
Ho avuto situazioni con database più grandi (VLDB), in cui l'opzione di statistiche auto_update è attiva e SQL si avviava in momenti inopportuni della giornata lavorativa. L'ho spento e ho dovuto essere più strategico sugli aggiornamenti manuali di tabelle e statistiche specifiche, invece di lasciare che il server determinasse le tabelle e quando. Ciò ha reso il mio sistema più prevedibile, ma a un costo di gestione più elevato (senza dubbio), ma doveva accadere per evitare intrusioni nelle attività di aggiornamento. Se "sopprimere" il sistema con la tipica gestione di indici / statistiche fa per te, lascialo acceso. Altrimenti, alcune situazioni potrebbero richiedere una strategia dettagliata.
SnapJag

6

In generale, direi che avere statistiche di aggiornamento automatico attive è vantaggioso. Ma come ogni impostazione, ci sono ragioni per cui puoi attivarla o disattivarla.

Uno è che alcune tabelle hanno un sacco di churn, e forse le query non sono molto sensibili alle statistiche accurate. Pensa a ETL o ad altri scenari di massa in cui stai modificando molti dati, ma o non li leggi da lì o non li leggi molto. Non ha molto senso avviare aggiornamenti automatici delle statistiche e causare un sacco di I / O per fornire statistiche più accurate che non verranno mai utilizzate.

Potresti anche avere scenari in cui aggiorni i dati più volte durante il giorno, ma non vuoi necessariamente aggiornare le statistiche dopo ogni aggiornamento. (Supponiamo che i dati vengano interrogati solo in determinate ore del giorno - non è necessario aggiornare le statistiche più volte quando i dati non verranno comunque interrogati nel frattempo.)

O forse hai solo un carico di lavoro pesante in scrittura. Oppure le letture sono generalmente scansioni complete, in cui le statistiche non sono estremamente importanti.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.