Ser på Database Snapshot Performance

Et database-øjebliksbillede giver en skrivebeskyttet visning af en SQL Server-database, som er transaktionsmæssigt konsistent med kildedatabasens tilstand på det tidspunkt, da database-øjebliksbilledet blev oprettet. Der er en række grunde til at bruge database-snapshots, for eksempel rapportering mod en spejlet database, og DBCC CHECKDB bruger også interne database-snapshots fra SQL Server 2005 og fremefter.

Database-øjebliksbilleder giver også mulighed for at rulle tilbage alle de ændringer, der er sket i en database, siden database-øjebliksbilledet blev oprettet, men med en ubehagelig bivirkning på databasens transaktionslog, som Paul bloggede om her.

En af de ting, der ikke almindeligvis betragtes eller vises omkring databasesnapshots, er den præstationspåvirkning, som snapshottet har for databaseskrivearbejdsbelastningen. SQLCAT-teamet udgav et whitepaper til SQL Server 2005, Database Snapshot Performance Considerations under I/O-intensive Workloads, der undersøgte virkningerne af databasesnapshots på ydeevnen, og efter at have arbejdet med en klient for nylig, hvor databasesnapshots resulterede i ydeevneproblemer, ønskede jeg at test SQL Server 2012 og afgør, om der var ændringer i overheaden af ​​database-øjebliksbilleder syv år og tre SQL Server-udgivelser senere.

Test konfiguration

For at udføre testen af ​​effekten af ​​database-øjebliksbilleder på skrive-arbejdsbelastningens ydeevne brugte jeg vores Dell R720 til at udføre en 1.000.000 række-indsættelse i en ny tabel i en forstørret version af AdventureWorks2012-databasen. AdventureWorks2012-databasen blev oprettet med 8 datafiler fordelt på to Fusion-io ioDrive Duo 640 GB SSD'er, der hver blev sat op som to individuelle 320 GB-diske i Windows, og præsenterede i alt 4 diske. For at forenkle forklaringen af ​​konfigurationen er lagerlayoutet brugt til disse test vist i tabellen nedenfor:

Tabel 1 – Serverdisklayout og -brug

Lageret til database-øjebliksbilledet var enten et RAID-5-array af seks 15k RPM SAS-drev forbundet via iSCSI, eller et LSI Nytro BLP4-1600 PCI-E-kort.

Testens arbejdsbelastning brugte følgende SELECT INTO-sætning til at generere en tabel med 1.000.000 rækker, som blev slettet mellem hver af testene.

SELECT TOP 1000000 *
INTO tmp_SalesOrderHeader
FROM Sales.SalesOrderHeaderEnlarged;

Testene blev timet til at måle varigheden uden et database-snapshot, og derefter varigheden med et database-snapshot oprettet på hver af lagerenhederne for at måle ydeevneforringelsen forårsaget af at skrive sideændringer til databasens snapshot sparse-fil. Testene blev også kørt ved hjælp af to database-snapshots på den samme lagerenhed for at fastslå, hvad overheaden ved at have yderligere database-snapshots kan være for de duplikerede skriveoperationer, der potentielt skal udføres.

Resultater

Hver testkonfiguration blev udført ti gange, og den gennemsnitlige varighed, konverteret fra millisekunder til sekunder for lettere visning, er vist i figur 1, for 0, 1 eller 2 database-øjebliksbilleder.

Figur 1 – Snapshot-varighed

Baseline-testene uden database-snapshots udført i gennemsnit på 1,8 sekunder, og selv når lagringen for database-snapshot-filerne var tilsvarende i ydeevne, påførte eksistensen af ​​et enkelt database-snapshot overhead til skriveydeevnen for databasen. Overheaden for det andet database-snapshot er lavere end at have det første database-snapshot i hver af testene, selvom 15K RPM-diskene havde meget sværere ved at holde trit med den tilføjede skrive-arbejdsbelastning fra det andet database-snapshot for databasen.

Ydeevnen på LSI Nytro-kortet overraskede mig oprindeligt, da det også var en PCI-X SSD. Efter at have diskuteret resultaterne med Glenn nævnte han dog, at Sandforce-controllerens komprimering og langsommere skriveydeevne for tilfældige, lavkomprimerede data fra hans tidligere test på drevet. Det udklassede dog stadig nemt de snurrende medier.

Før jeg kørte testene, var jeg interesseret i at vide, hvilke ventetyper der ville forekomme under testene, så som en del af testkonfigurationen ryddede jeg sys.dm_os_wait_stats med DBCC SQLPERF og fangede outputtet fra DMV'en for hver testkørsel i en tabel. De øverste ventetider på de enkelte snapshot-konfigurationer var PREEMPTIVE_OS_WRITEFILE og WRITE_COMPLETION som vist i figur 2, for 1 eller 2 database-snapshots.

Figur 2 – Snapshot Top Waits

Et af de interessante elementer var tilføjelsen af ​​FCB_REPLICA_WRITE-venter, når et andet snapshot blev oprettet. Efter at have gennemgået resultaterne af venteresultaterne for enkelt databasesnapshot og genkørt et par testrunder, forekommer denne ventetid aldrig for et enkelt snapshot og forekommer kun, når der findes mere end ét snapshot og er forbundet med kopiering af siderne til databasens snapshotfiler. Ventetiderne for PREEMPTIVE_OS_WRITEFILE venter tæt på stigningerne i udførelsesvarigheden for hver af konfigurationerne.

Med disse resultater i tankerne, når du gennemgår et system, der bruger Waits and Queue-metoden, kan det være værd at se denne ventetype med højere værdier at undersøge, om der findes database-øjebliksbilleder for nogen af ​​databaserne på serveren.

Konklusion

Når du bruger database-snapshots, selv i SQL Server 2012, er der en overhead forbundet med de yderligere skrivninger, der kræves for at kopiere datasider til de sparsomme filer til snapshots. Hvis brug af database-snapshots er en del af din generelle konfiguration, ville jeg virkelig være forsigtig med at planlægge I/O-undersystemet, så det opfylder arbejdsbelastningskravene for samtidig I/O-aktivitet til databasens snapshot sparsomme filer.

Ud fra resultaterne af disse test ville jeg endda overveje at placere database-snapshots på SSD'er foran tempdb for skriveydeevnen, og også for lavere ydeevnepåvirkning fra snapshotvedligeholdelsen.

Som altid kan dit kilometertal variere, og du vil helt sikkert gerne teste ydeevnen af ​​enhver konfiguration, før du sætter den i produktionsbrug.