Tittar på Databas Snapshot Performance

En ögonblicksbild av databasen ger en skrivskyddad vy av en SQL Server-databas som är transaktionellt överensstämmande med tillståndet för källdatabasen vid den tidpunkt då ögonblicksbilden av databasen skapades. Det finns flera anledningar till att använda ögonblicksbilder av databasen, till exempel rapportering mot en speglad databas, och DBCC CHECKDB använder även interna ögonblicksbilder av databasen från SQL Server 2005 och framåt.

Databasögonblicksbilder ger också möjligheten att återställa alla ändringar som har skett i en databas sedan ögonblicksbilden av databasen skapades, men med en otäck bieffekt på databasens transaktionslogg som Paul bloggade om här.

En av de saker som vanligtvis inte betraktas eller visas kring ögonblicksbilder av databasen är den prestandapåverkan som ögonblicksbilden har för skrivarbetsbelastningen för databasen. SQLCAT-teamet publicerade ett whitepaper för SQL Server 2005, Database Snapshot Performance Considerations under I/O-Intensive Workloads, som undersökte prestandapåverkan av databasögonblicksbilder, och efter att ha arbetat med en klient nyligen där databasögonblicksbilder resulterade i prestandaproblem, ville jag testa SQL Server 2012 och avgör om det har skett några förändringar i överheaden för ögonblicksbilder av databasen sju år och tre SQL Server-utgåvor senare.

Testa konfiguration

För att testa effekten av databasögonblicksbilder på skrivprestanda använde jag vår Dell R720 och utförde en 1 000 000 radinsättning i en ny tabell i en förstorad version av AdventureWorks2012-databasen. AdventureWorks2012-databasen skapades med 8 datafiler spridda över två Fusion-io ioDrive Duo 640 GB SSD-enheter som var och en konfigurerades som två individuella 320 GB-diskar i Windows, vilket ger totalt 4 diskar. För att förenkla beskrivningen av konfigurationen visas lagringslayouten som används för dessa tester i tabellen nedan:

Tabell 1 – Serverdisklayout och användning

Lagringen för ögonblicksbilden av databasen var antingen en RAID-5-array med sex 15k RPM SAS-enheter anslutna via iSCSI, eller ett LSI Nytro BLP4-1600 PCI-E-kort.

Testarbetsbelastningen använde följande SELECT INTO-sats för att generera en tabell med 1 000 000 rader som släpptes mellan vart och ett av testerna.

SELECT TOP 1000000 *
INTO tmp_SalesOrderHeader
FROM Sales.SalesOrderHeaderEnlarged;

Testerna tidsbestämdes för att mäta varaktigheten utan en ögonblicksbild av databasen, och sedan varaktigheten med en ögonblicksbild av databasen skapad på var och en av lagringsenheterna för att mäta prestandaförsämringen som orsakas av att sidändringar skrevs till den glesa filen för ögonblicksbilden av databasen. Testerna kördes också med hjälp av två databasögonblicksbilder på samma lagringsenhet för att fastställa vad kostnaden för att ha ytterligare databasögonblicksbilder kan vara för de duplicerade skrivoperationer som eventuellt måste utföras.

Resultat

Varje testkonfiguration utfördes tio gånger och den genomsnittliga varaktigheten, omvandlad från millisekunder till sekunder för enklare visning, visas i figur 1, för 0, 1 eller 2 ögonblicksbilder av databasen.

Figur 1 – Ögonblicksbildens varaktighet

Baslinjetesterna utan några ögonblicksbilder av databasen exekveras i genomsnitt på 1,8 sekunder, och även när lagringen för ögonblicksbildsfilerna för databasen var likvärdig i prestanda, pålade förekomsten av en enda ögonblicksbild av databasen skrivprestandan för databasen. Overheaden för den andra ögonblicksbilden av databasen är lägre än att ha den första ögonblicksbilden av databasen i vart och ett av testerna, även om 15K RPM-diskarna hade mycket svårare att hålla jämna steg med den extra skrivbelastningen från den andra ögonblicksbilden av databasen för databasen.

Prestandan på LSI Nytro-kortet överraskade mig initialt eftersom det också var en PCI-X SSD. Men efter att ha diskuterat resultaten med Glenn nämnde han att Sandforce-kontrollerns komprimering och långsammare skrivprestanda för slumpmässiga, lågkomprimerade data från hans tidigare tester på enheten. Men det överklassade fortfarande lätt det snurrande mediet.

Innan jag körde testerna var jag intresserad av att veta vilka väntetyper som skulle inträffa under testerna, så som en del av testkonfigurationen rensade jag sys.dm_os_wait_stats med DBCC SQLPERF och fångade utdata från DMV för varje testkörning i en tabell. De översta väntetiderna för konfigurationerna för enstaka ögonblicksbilder var PREEMPTIVE_OS_WRITEFILE och WRITE_COMPLETION som visas i figur 2, för 1 eller 2 ögonblicksbilder av databasen.

Figur 2 – Snapshot Top Waits

En av de intressanta objekten var tillägget av FCB_REPLICA_WRITE-väntningar när en andra ögonblicksbild skapades. Efter att ha granskat resultaten för en enskild ögonblicksbild av databasen och kört ett par omgångar av tester, inträffar denna väntan aldrig för en enstaka ögonblicksbild och inträffar endast när mer än en ögonblicksbild finns och är associerad med att kopiera sidorna till databasens ögonblicksbildfiler. Väntetiderna för PREEMPTIVE_OS_WRITEFILE väntar trend nära med ökningen av körtiden för var och en av konfigurationerna.

Med dessa resultat i åtanke kan det vara värt att undersöka om det finns ögonblicksbilder av databasen för någon av databaserna på servern när man granskar ett system som använder metoden Waits and Queues att se denna väntetyp med högre värden.

Slutsats

När du använder ögonblicksbilder av databasen, även i SQL Server 2012, finns det en overhead associerad med de ytterligare skrivningar som krävs för att kopiera datasidor till de sparsamma filerna för ögonblicksbilderna. Om användning av ögonblicksbilder av databasen är en del av din allmänna konfiguration, skulle jag verkligen vara försiktig med att planera I/O-undersystemet för att uppfylla arbetsbelastningskraven för samtidig I/O-aktivitet till de glesa filerna för ögonblicksbilden av databasen.

Utifrån resultaten av dessa tester skulle jag till och med överväga att placera ögonblicksbilder av databasen på SSD:er före tempdb för skrivprestanda och även för lägre prestandapåverkan från ögonblicksbildunderhållet.

Som alltid kan din körsträcka variera, och du kommer säkert att vilja testa prestandan för alla konfigurationer innan du tar den i produktion.