Analisi delle prestazioni degli snapshot del database

Uno snapshot del database fornisce una visualizzazione di sola lettura di un database di SQL Server che è coerente a livello transazionale con lo stato del database di origine al momento della creazione dello snapshot del database. Esistono diversi motivi per l'utilizzo di snapshot di database, ad esempio report su un database con mirroring, e DBCC CHECKDB utilizza anche snapshot di database interni da SQL Server 2005 in poi.

Gli snapshot del database offrono anche la possibilità di annullare tutte le modifiche apportate a un database da quando è stato creato lo snapshot del database, ma con un brutto effetto collaterale sul registro delle transazioni del database di cui Paul ha scritto sul blog qui.

Una delle cose che non viene comunemente considerata o mostrata sugli snapshot del database è l'impatto sulle prestazioni che lo snapshot ha per il carico di lavoro di scrittura del database. Il team SQLCAT ha pubblicato un whitepaper per SQL Server 2005, Considerazioni sulle prestazioni degli snapshot del database in carichi di lavoro intensivi di I/O, che ha esaminato l'impatto sulle prestazioni degli snapshot del database e, dopo aver lavorato di recente con un client in cui gli snapshot del database causavano problemi di prestazioni, volevo testare SQL Server 2012 e determinare se sono state apportate modifiche al sovraccarico degli snapshot del database sette anni e tre versioni di SQL Server successive.

Configurazione di prova

Per eseguire il test dell'effetto degli snapshot del database sulle prestazioni del carico di lavoro in scrittura, ho utilizzato il nostro Dell R720 eseguendo un inserimento di 1.000.000 di righe in una nuova tabella in una versione ingrandita del database AdventureWorks2012. Il database AdventureWorks2012 è stato creato con 8 file di dati distribuiti su due SSD Fusion-io ioDrive Duo da 640 GB, ciascuno configurato come due singoli dischi da 320 GB in Windows, per un totale di 4 dischi. Per semplificare la spiegazione della configurazione, il layout di archiviazione utilizzato per questi test è mostrato nella tabella seguente:

Tabella 1 – Layout e utilizzo del disco del server

L'archiviazione per lo snapshot del database era un array RAID-5 di sei unità SAS da 15k RPM collegate tramite iSCSI o una scheda PCI-E LSI Nytro BLP4-1600.

Il carico di lavoro del test ha utilizzato la seguente istruzione SELECT INTO per generare una tabella di 1.000.000 di righe che è stata eliminata tra ciascuno dei test.

SELECT TOP 1000000 *
INTO tmp_SalesOrderHeader
FROM Sales.SalesOrderHeaderEnlarged;

I test sono stati programmati per misurare la durata senza uno snapshot del database, quindi la durata con uno snapshot del database creato su ciascuno dei dispositivi di archiviazione per misurare il degrado delle prestazioni causato dalla scrittura delle modifiche di pagina nel file sparse dello snapshot del database. I test sono stati eseguiti anche utilizzando due snapshot di database sullo stesso dispositivo di archiviazione per accertare quale potrebbe essere il sovraccarico di avere snapshot di database aggiuntivi per le operazioni di scrittura duplicate che potenzialmente devono essere eseguite.

Risultati

Ciascuna configurazione di test è stata eseguita dieci volte e la durata media, convertita da millisecondi a secondi per una visualizzazione più semplice, è mostrata nella Figura 1, per 0, 1 o 2 snapshot del database.

Figura 1 – Durata dell'istantanea

I test di base senza snapshot del database eseguiti in media in 1,8 secondi e anche quando lo spazio di archiviazione per i file di snapshot del database era equivalente in termini di prestazioni, l'esistenza di un singolo snapshot del database imponeva un sovraccarico alle prestazioni di scrittura del database. L'overhead del secondo snapshot del database è inferiore rispetto al primo snapshot del database in ciascuno dei test, sebbene i dischi da 15.000 RPM abbiano avuto molte più difficoltà a tenere il passo con il carico di lavoro di scrittura aggiunto dal secondo snapshot del database per il database.

Le prestazioni sulla scheda LSI Nytro inizialmente mi hanno sorpreso poiché era anche un SSD PCI-X. Tuttavia, dopo aver discusso i risultati con Glenn, ha menzionato che la compressione del controller Sandforce e prestazioni di scrittura più lente per dati casuali a bassa compressione dei suoi test precedenti sull'unità. Tuttavia, ha comunque surclassato facilmente i mezzi di rotazione.

Prima di eseguire i test ero interessato a sapere quali tipi di attesa si sarebbero verificati durante i test, quindi come parte della configurazione del test, ho cancellato sys.dm_os_wait_stats con DBCC SQLPERF e catturato l'output dal DMV per ogni test eseguito in una tabella. Le attese principali per le configurazioni di istantanee singole erano PREEMPTIVE_OS_WRITEFILE e WRITE_COMPLETION come mostrato nella Figura 2, per 1 o 2 istantanee del database.

Figura 2 – Attese principali dell'istantanea

Uno degli elementi interessanti è stata l'aggiunta di attese FCB_REPLICA_WRITE quando è stata creata una seconda istantanea. Dopo aver esaminato i risultati dell'attesa di un singolo snapshot del database e aver eseguito nuovamente un paio di cicli di test, questa attesa non si verifica mai per un singolo snapshot e si verifica solo quando esiste più di uno snapshot ed è associato alla copia delle pagine nei file di snapshot del database. I tempi di attesa per PREEMPTIVE_OS_WRITEFILE sono un trend di attesa vicino all'aumento della durata di esecuzione per ciascuna delle configurazioni.

Tenendo presente questi risultati, durante la revisione di un sistema utilizzando la metodologia Waits and Queues, potrebbe valere la pena vedere questo tipo di attesa con valori più elevati per verificare se esistono o meno snapshot del database per uno qualsiasi dei database sul server.

Conclusione

Quando si usano gli snapshot del database, anche in SQL Server 2012, c'è un sovraccarico associato alle scritture aggiuntive necessarie per copiare le pagine di dati nei file sparsi per gli snapshot. Se l'utilizzo degli snapshot del database fa parte della configurazione generale, farei davvero attenzione a pianificare il sottosistema di I/O per soddisfare i requisiti del carico di lavoro per l'attività di I/O simultanea sui file sparsi degli snapshot del database.

Dai risultati di questi test, prenderei in considerazione anche di posizionare gli snapshot del database sugli SSD prima del tempdb per le prestazioni di scrittura e anche per ridurre l'impatto sulle prestazioni della manutenzione degli snapshot.

Come sempre, il tuo chilometraggio può variare e vorrai sicuramente testare le prestazioni di qualsiasi configurazione prima di metterla in produzione.