Quando crei un nuovo database in SQL Server, l'opzione Statistiche di aggiornamento automatico è abilitata per impostazione predefinita. In genere si consiglia di lasciare questa opzione abilitata. Idealmente, le statistiche sono gestite da un lavoro pianificato e l'opzione automatica viene utilizzata come rete di sicurezza, disponibile per aggiornare le statistiche nel caso in cui non si verifichi un aggiornamento pianificato o non includa accidentalmente tutte le statistiche esistenti.
Alcuni DBA si basano esclusivamente su aggiornamenti automatici per gestire le statistiche e, purché non esistano problemi di prestazioni relativi a statistiche non aggiornate o campionate in modo insufficiente, ciò è accettabile. Se ti affidi a questa opzione per gestire le tue statistiche e hai alcune tabelle molto grandi, potrebbe valere la pena implementare il flag di traccia 2371. Come con qualsiasi flag di traccia, assicurati di testare con un carico di lavoro rappresentativo prima di implementarlo in produzione. Potresti già essere consapevole del fatto che a volte un aggiornamento automatico può influire sulle prestazioni del sistema. Ad esempio, l'aggiornamento di una statistica può introdurre un picco nella CPU o nell'I/O durante la lettura dei dati della tabella o dell'indice, nonché ritardare l'esecuzione della query durante l'aggiornamento. C'è un'altra opzione del database che puoi abilitare per risolvere il ritardo della query e ne parlerò più avanti in questo post.
La domanda che mi viene spesso posta è:"Come fai a sapere se gli aggiornamenti automatici delle statistiche provocano problemi di prestazioni?" Un'opzione è tenerne traccia e collegare gli aggiornamenti a una modifica delle prestazioni. Esistono molte opzioni per tenere traccia degli aggiornamenti e in questo post esamineremo alcuni dei metodi disponibili in modo da poter scegliere e quindi implementare il opzione che si adatta meglio al tuo attuale metodo di monitoraggio dei problemi di prestazioni.
Traccia SQL
Se si esegue SQL Server 2008 R2 o versioni precedenti nel proprio ambiente, SQL Trace è un metodo che è possibile utilizzare per acquisire gli aggiornamenti automatici. Lo script di definizione della traccia utilizzato di seguito acquisisce solo l'evento Auto Stats, che rileva quando una statistica si aggiorna automaticamente e quando una statistica viene creata automaticamente. Dopo che questa traccia è stata eseguita per un po' nel tuo ambiente, puoi caricarla in una tabella e quindi interrogare l'output per vedere quali aggiornamenti si sono verificati. Lo script incluso di seguito illustra un esempio utilizzando il database di esempio delle statistiche sul baseball.
Eventi estesi
Se esegui SQL Server 2012 o versioni successive, ti consiglio di utilizzare gli eventi estesi per acquisire gli aggiornamenti automatici. Come lo script SQL Trace, lo script di definizione della sessione incluso acquisisce solo gli eventi Auto Stats, ancora una volta, sia gli aggiornamenti automatici che la creazione automatica. Dopo che la sessione XE è stata eseguita per un po', puoi caricare l'output in una tabella tramite l'interfaccia utente e quindi interrogarlo per vedere quali aggiornamenti si sono verificati. Lo script incluso illustra lo stesso esempio di prima, ma questa volta utilizzando gli eventi estesi per raccogliere i dati.
sys.dm_db_stats_properties
Una terza opzione che potresti prendere in considerazione per monitorare gli aggiornamenti delle statistiche è sys.dm_db_stats_properties DMF, disponibile solo in SQL Server 2008 R2 SP2 e versioni successive e SQL Server 2012 SP1 e versioni successive. Per quanto io ami questo DMF, questa soluzione è più complicata in termini di acquisizione di tutti i dati e la revisione dell'output richiede più lavoro. Con il DMF, ogni aggiornamento automatico non viene tracciato, ci limitiamo ad aggiornare le informazioni sulle statistiche di tendenza per vedere quando si verificano gli aggiornamenti.
È un compito semplice:crei una tabella per contenere le informazioni sulle statistiche, quindi istantanee delle informazioni dal DMF alla tabella su base regolare. La chiave qui è capire con quale frequenza acquisire i dati. Ogni ora è probabilmente eccessiva, una volta al giorno potrebbe non essere abbastanza frequente. Consiglio di iniziare con un processo di SQL Agent che esegue lo snapshot dei dati DMF ogni quattro ore. Lascia che funzioni per alcuni giorni, quindi controlla i tuoi dati. Se le statistiche si aggiornano al massimo una volta al giorno, puoi aumentare l'intervallo a ogni otto o dodici ore. Se le statistiche si aggiornano facilmente ogni quattro ore, riduci l'intervallo a ogni due ore:vuoi assicurarti di acquisire ogni aggiornamento. Per questo motivo, per alcuni sistemi, sys.dm_db_stats_properties potrebbe non valere la pena; una sessione XE o Trace potrebbe essere più semplice.
Uno script di esempio finale illustra un esempio di come utilizzare sys.dm_db_stats_properties per aggiornare le tendenze alle statistiche. Tieni presente che questo script acquisisce solo informazioni statistiche per una tabella. Se modifichi lo script per acquisire ogni tabella nel database, ci saranno molti più dati da analizzare.
Passaggi successivi
Scarica gli script di esempio e decidi quale metodo utilizzare per tenere traccia degli aggiornamenti delle statistiche.
Una volta che hai i dati che mostrano quando si verificano gli aggiornamenti automatici, è necessario collegarli a problemi di prestazioni noti. Pertanto, se non stai monitorando alcuna metrica delle prestazioni, i dati di aggiornamento delle statistiche automatiche non aiuteranno con alcun tipo di correlazione. Supponendo che tu disponga di timestamp per qualsiasi problema di prestazioni, puoi confrontarlo con StartTime e EndTime da Trace, il timestamp da XE o last_updated dal sys.dm_db_stats_properties DMF, per determinare se l'aggiornamento automatico ha influito sulle prestazioni del sistema.
Se non riesci a stabilire alcuna correlazione tra gli aggiornamenti e i problemi di prestazioni, puoi escludere gli aggiornamenti come causa del problema e concentrarti su un'altra area. Se gli aggiornamenti sono la causa principale, sono disponibili due opzioni:disabilitare l'opzione Statistiche di aggiornamento automatico o abilitare l'opzione Statistiche di aggiornamento automatico in modo asincrono. Entrambi hanno pro e contro che tu, come DBA, devi considerare.
Disattivazione dell'aggiornamento automatico delle statistiche
Se scegli di disabilitare l'opzione di aggiornamento automatico delle statistiche, le due cose più importanti da sapere sono:
- Devi assolutamente gestire le tue statistiche tramite un'attività di manutenzione o un lavoro personalizzato.
- Le query non verranno ricompilate quando aggiorni le statistiche in SQL Server 2008 R2 e versioni precedenti.
Considero il secondo elemento una sfida più grande:sono un grande sostenitore della gestione delle statistiche e mi aspetto che sia comunque qualcosa che i DBA stanno facendo. Il problema più grande è che, anche se aggiorna le statistiche normalmente provoca la ricompilazione delle query (per sfruttare le statistiche aggiornate), questo non si verifica quando l'opzione di aggiornamento automatico delle statistiche è disabilitata. Ne ho già scritto in precedenza e consiglio di rivedere queste informazioni se non si ha familiarità con questo comportamento. Vedi anche un post di follow-up per le opzioni per affrontarlo.
In generale, questo non è il percorso che consiglio. Esistono casi limite molto specifici in cui ciò potrebbe essere appropriato, ma preferirei vedere un DBA eseguire aggiornamenti manuali (tramite processi pianificati) per evitare gli aggiornamenti automatici e lasciare l'opzione abilitata come misura di sicurezza.
Abilitazione dell'aggiornamento automatico delle statistiche in modo asincrono
Quando si abilita l'opzione Aggiorna automaticamente le statistiche in modo asincrono, se una statistica è stata invalidata e viene eseguita una query che utilizza tale statistica, la statistica non verrà aggiornata fino al completamento della query:l'aggiornamento è asincrono. Il vantaggio qui è che l'aggiornamento non influirà sulla query eseguita; lo svantaggio è che la query utilizzerà il piano esistente, che potrebbe non essere più il piano ottimale. Il fatto che il piano sia ancora ottimale dipenderà dal tuo carico di lavoro (ad es. un carico di lavoro di reporting con query di lunga durata). In qualità di DBA, devi valutare i pro ei contro dell'abilitazione di questa opzione e determinare cosa è meglio per il tuo database. Si noti che se si esegue SQL Server 2008 tramite 2012, è presente una perdita di memoria associata a questa impostazione. Microsoft ha aggiornamenti cumulativi disponibili che forniscono una correzione, ma se non li hai già applicati, devi affrontare un'altra decisione:applicare la CU in modo da poter abilitare l'opzione, oppure non applicare la CU e non abilitare il opzione.
Riepilogo
L'unico modo per sapere se gli aggiornamenti automatici delle statistiche influiscono sulle prestazioni delle query è vedere un aggiornamento che si verifica contemporaneamente a un problema o acquisire quando si verificano aggiornamenti e correlare i dati alle informazioni aggiuntive che stai acquisendo sui problemi di prestazioni. Quest'ultima opzione ti consente di essere proattivo, anche se non si verificano problemi di prestazioni, potrebbe essere una buona idea sapere con quale frequenza si verificano gli aggiornamenti automatici. Aggiornamenti frequenti possono significare che è necessario rivisitare il lavoro dell'agente che gestisce manualmente le statistiche. In generale, lascia abilitata l'opzione per aggiornare automaticamente le statistiche, ma hai un metodo per gestire le statistiche e utilizzare l'opzione come rete di sicurezza.
