Monitoraggio del registro delle transazioni

Nell'ultimo anno ho bloggato diverse volte su SQLPerformance.com sui problemi di prestazioni del registro delle transazioni (vedi qui) e ho promesso di discutere il monitoraggio del registro delle transazioni, cosa che farò in questo post. Presenterò alcune delle metriche che puoi monitorare, perché dovresti preoccuparti e qualsiasi consiglio per affrontare il problema indicato.

DMV

Il modo più semplice per monitorare le latenze I/O del registro delle transazioni è utilizzare sys.dm_io_virtual_file_stats DMV. Avrai bisogno di eseguire alcuni calcoli per ottenere risultati utili e puoi ottenere del codice di esempio nello script VirtualFileStats.sql in questo file zip demo. Vuoi davvero vedere latenze di scrittura inferiori a 5 ms per il registro delle transazioni.

All'inizio di novembre ho pubblicato sul blog i risultati di un sondaggio che mostrava le latenze del registro delle transazioni e dei file di dati tempdb per oltre 25.000 database in tutto il mondo (vedi qui), con l'80% dei database che ha raggiunto il limite di 5 ms o meno per la latenza di scrittura del registro delle transazioni.

Se la tua latenza di scrittura è superiore a 5 ms, puoi:

• Lavora per ridurre la quantità di log generata e/o la quantità di svuotamenti dei log che si verificano da piccole transazioni, come ho descritto nei post precedenti.
• Segui alcuni dei passaggi per la risoluzione dei problemi che descrivo nel post del blog del sondaggio sopra.
• Passa a un sottosistema I/O più veloce, ricordando che se decidi di utilizzare un SSD, devi usarne due in una configurazione RAID-1.

Un'altra cosa che puoi è guardare per assicurarti di non raggiungere il limite massimo di 32 I/O di scrittura in sospeso per il registro delle transazioni di ciascun database nel 2008 R2 e precedenti (portato al 2012 da SQL Server 2012 in poi). Puoi provare a farlo guardando Physical Disk/Avg. Disk Write Queue Length, ma è per un intero volume, non per file, quindi se c'è qualcos'altro sul volume oltre al file di registro che ti interessa, questo non ti darà un numero valido. Un modo migliore è aggregare i risultati di sys.dm_io_pending_io_requests DMV, che elenca tutti gli I/O in sospeso. Ecco del codice per farlo:

SELECT
	COUNT (*) AS [PendingIOs],
	DB_NAME ([vfs].[database_id]) AS [DBName],
	[mf].[name] AS [FileName],
	[mf].[type_desc] AS [FileType],
	SUM ([pior].[io_pending_ms_ticks]) AS [TotalStall]
FROM sys.dm_io_pending_io_requests AS [pior]
JOIN sys.dm_io_virtual_file_stats (NULL, NULL) AS [vfs]
	ON [vfs].[file_handle] = [pior].[io_handle]
JOIN sys.master_files AS [mf]
	ON [mf].[database_id] = [vfs].[database_id]
	AND [mf].[file_id] = [vfs].[file_id]
WHERE
   [pior].[io_pending] = 1
GROUP BY [vfs].[database_id], [mf].[name], [mf].[type_desc]
ORDER BY [vfs].[database_id], [mf].[name];

Puoi facilmente modificarlo per visualizzare solo i risultati per i file di registro (filtro su type_desc ='LOG' ) e solo per l'ID database che ti interessa.

Se scopri che stai raggiungendo il limite di 32 per un determinato database, puoi:

• Riduci la quantità di svuotamenti di log che si verificano riducendo il numero di piccole transazioni e facendo attenzione a cose come le divisioni di pagina e gli indici inutilizzati/duplicati che vengono modificati durante le operazioni di modifica dei dati. Puoi leggere di più sull'ottimizzazione degli svuotamenti dei log in questo post del blog
• Prova a utilizzare un sottosistema di I/O più veloce
• Aggiorna a SQL Server 2012 o versioni successive, dove il limite è 112
• Prova la delayed durability feature DMV aggiunto in SQL Server 2014
• Come ultima risorsa, suddividi il carico di lavoro su più database o server

Se sei interessato a vedere quanto log delle transazioni viene generato dalle tue transazioni, puoi utilizzare il sys.dm_tran_database_transactions DMV, in codice simile a quello qui sotto:

BEGIN TRAN;
GO
 
-- Do something you want to evaluate
GO 
 
SELECT [database_transaction_log_bytes_used]
FROM sys.dm_tran_database_transactions
WHERE [database_id] = DB_ID (N'YourTestDB');
GO

Potresti essere molto sorpreso dalla quantità di registro generata, specialmente in tempdb per il codice che utilizza oggetti temporanei. E, naturalmente, il registro delle transazioni di tempdb può essere un collo di bottiglia proprio come per un database utente.

Contatori di monitoraggio delle prestazioni

I contatori delle prestazioni relativi al registro si trovano tutti nell'oggetto prestazioni Database. Ecco alcuni dei principali da guardare (con Performance Monitor stesso o utilizzando gli avvisi di SQL Agent o utilizzando il DMV sys.dm_os_performance_counters o nel tuo strumento di monitoraggio di terze parti preferito):

Crescite log

Non vuoi vedere questo contatore aumentare in quanto ciò dice che sta accadendo qualcosa nel database che sta causando la generazione di più log delle transazioni rispetto allo spazio corrente. Implica che il registro delle transazioni non è in grado di cancellare, quindi è necessario indagare sulla causa eseguendo una query nel campo log_reuse_wait_desc di sys.databases e intraprendere l'azione necessaria (per ulteriori dettagli, vedere l'argomento della documentazione in linea Fattori che possono ritardare il troncamento del registro). Un esempio di codice potrebbe essere:

SELECT [log_reuse_wait_desc]
	FROM sys.databases
	WHERE [name] = N'YourDB';
GO

Ogni volta che si verifica una crescita del registro, la parte appena allocata del registro delle transazioni deve essere azzerata, inoltre vengono aggiunti altri file di registro virtuali, entrambi i quali possono causare problemi come ho scritto in precedenza.

Il registro si restringe

A meno che tu non sia la persona che esegue l'operazione di restringimento per riportare sotto controllo un registro delle transazioni fuori controllo, non vuoi che questo contatore aumenti. Se qualcuno rimpicciolisce il registro delle transazioni senza una buona ragione, è probabile che aumenterà di nuovo, causando problemi come ho scritto in precedenza.

Registro percentuale utilizzato

Dovresti monitorare questo contatore ed essere preoccupato se il valore supera il 90%, poiché ciò indica che una crescita del registro potrebbe essere imminente e il registro delle transazioni non è in grado di cancellarsi correttamente, come ho discusso sopra.

Attese di risciacquo registro/sec

Si desidera che questo valore rimanga lo stesso o diminuisca. Se aumenta, significa che hai un collo di bottiglia del sottosistema di I/O o un collo di bottiglia all'interno del meccanismo di svuotamento del registro perché stai scaricando molte piccole porzioni di registro. Un aumento qui può anche essere correlato al raggiungimento dei 32 I/O in sospeso per il registro. Vedi la discussione su sys.dm_io_pending_io_requests sopra per maggiori dettagli.

Log Byte scaricati/sec e Log scaricati/sec

Questi due contatori ti permettono di calcolare la dimensione media del filo di log, dividendo il primo contatore per il secondo. Il risultato sarà un valore compreso tra 512 e 61440 (rispettivamente le dimensioni minima e massima di un log flush). È più probabile che un valore più basso sia correlato all'aumento delle attese di lavaggio del registro/sec. Di nuovo, guarda la discussione su sys.dm_io_pending_io_requests sopra per maggiori dettagli.

Eventi estesi

Per i più avanzati, ci sono alcuni eventi estesi che puoi utilizzare per guardare cosa sta succedendo con il registro. Ti consiglio di iniziare usando il modello di tracciamento I/O del file di registro del database in SQL Server 2012 SSMS. Puoi arrivarci andando su Esplora oggetti e quindi sulla tua istanza -> Gestione -> Eventi estesi e facendo clic con il pulsante destro del mouse su Sessioni per selezionare Nuova sessione guidata. Nella finestra che si apre, digita un nome di sessione e seleziona il modello di monitoraggio dal menu a discesa. Quindi premi Ctrl + Maiusc + N e la sessione verrà inserita in una finestra di query. I dettagli di tutto ciò che contiene vanno oltre lo scopo di questo post, sfortunatamente, ma la descrizione del modello è piuttosto esplicativa:

C'è anche un nuovo evento esteso in SQL Server 2012 chiamato transaction_log che può essere utilizzato per eseguire tutti i tipi di analisi interessanti di quali record di registro vengono generati. Questo è sicuramente un argomento che tratterò in un prossimo post.

Riepilogo

Date tutte le informazioni di cui sopra, dovresti essere in grado di trovare un buon sistema di monitoraggio del registro delle transazioni. L'integrità del registro delle transazioni è di fondamentale importanza per garantire che il carico di lavoro funzioni come dovrebbe essere e spero che i quattro post di questa serie (più tutti gli altri collegamenti) ti abbiano aiutato a migliorare le prestazioni complessive del tuo ambiente SQL Server.