Een databasemomentopname biedt een alleen-lezen weergave van een SQL Server-database die transactioneel consistent is met de status van de brondatabase op het moment dat de databasemomentopname is gemaakt. Er zijn een aantal redenen om database-snapshots te gebruiken, bijvoorbeeld rapportage tegen een gespiegelde database, en DBCC CHECKDB gebruikt ook interne database-snapshots vanaf SQL Server 2005.
Database-snapshots bieden ook de mogelijkheid om alle wijzigingen die in een database zijn opgetreden sinds het maken van de database-snapshot terug te draaien, maar met een vervelende bijwerking op het transactielogboek van de database waarover Paul hier blogde.
Een van de dingen die niet vaak worden overwogen of getoond bij momentopnamen van databases, is de prestatie-impact die de momentopname heeft voor de schrijfwerkbelasting van de database. Het SQLCAT-team publiceerde een whitepaper voor SQL Server 2005, Database Snapshot Performance Considerations under I/O-Intensive Workloads, waarin de prestatie-impact van databasesnapshots werd onderzocht. test SQL Server 2012 en bepaal of er zeven jaar later en drie SQL Server-releases wijzigingen zijn aangebracht in de overhead van database-snapshots.
Testconfiguratie
Om het effect van database-snapshots op de schrijfwerkbelasting te testen, heb ik onze Dell R720 gebruikt voor het invoegen van 1.000.000 rijen in een nieuwe tabel in een vergrote versie van de AdventureWorks2012-database. De AdventureWorks2012-database is gemaakt met 8 gegevensbestanden verspreid over twee Fusion-io ioDrive Duo SSD's van 640 GB die elk waren ingesteld als twee afzonderlijke schijven van 320 GB in Windows, met in totaal 4 schijven. Om het uitleggen van de configuratie te vereenvoudigen, wordt de opslaglay-out die voor deze tests wordt gebruikt, weergegeven in de onderstaande tabel:
| Schijf | Configuratie | Gebruik |
|---|---|---|
| K | 15K RAID 5 – 6 Schijf | Momentopname |
| L | Fusion-io Card2 – Zijde B | Logbestand |
| M | Fusion-io Card2 – Kant A | 4 gegevensbestanden |
| N | Fusion-io Card1 – Kant A | 4 gegevensbestanden |
| Q | Fusion-io Card1 – Zijde B | Tempdb |
| R | LSI Nytro BLP4-1600 | Momentopname |
Tabel 1 – Indeling en gebruik van serverschijven
De opslag voor de database-snapshot was ofwel een RAID-5-array van zes 15k RPM SAS-schijven aangesloten via iSCSI, of een LSI Nytro BLP4-1600 PCI-E-kaart.
De testworkload gebruikte de volgende SELECT INTO-instructie om een tabel met 1.000.000 rijen te genereren die tussen elk van de tests werd verwijderd.
SELECT TOP 1000000 * INTO tmp_SalesOrderHeader FROM Sales.SalesOrderHeaderEnlarged;
De tests werden getimed om de duur te meten zonder een database-snapshot, en vervolgens de duur met een database-snapshot gemaakt op elk van de opslagapparaten om de prestatievermindering te meten die werd veroorzaakt door het schrijven van paginawijzigingen naar het schaarse database-snapshot-bestand. De tests werden ook uitgevoerd met behulp van twee database-snapshots op hetzelfde opslagapparaat om vast te stellen wat de overhead zou kunnen zijn van het hebben van extra database-snapshots voor de dubbele schrijfbewerkingen die mogelijk moeten worden uitgevoerd.
Resultaten
Elke testconfiguratie werd tien keer uitgevoerd en de gemiddelde duur, geconverteerd van milliseconden naar seconden voor een betere weergave, wordt weergegeven in Afbeelding 1, voor 0, 1 of 2 database-snapshots.
Figuur 1 – Momentopnameduur
De basislijntests zonder database-snapshots werden gemiddeld in 1,8 seconden uitgevoerd, en zelfs wanneer de opslag voor de database-snapshotbestanden gelijkwaardig was in prestaties, zorgde het bestaan van een enkele database-snapshot voor overhead voor de schrijfprestaties voor de database. De overhead van de tweede database-snapshot is lager dan bij de eerste database-snapshot in elk van de tests, hoewel de 15K RPM-schijven het veel moeilijker hadden om de toegevoegde schrijfwerkbelasting van de tweede database-snapshot voor de database bij te houden.
De prestaties op de LSI Nytro-kaart verrasten me aanvankelijk omdat het ook een PCI-X SSD was. Na de resultaten met Glenn te hebben besproken, zei hij echter dat de Sandforce-controller compressie en tragere schrijfprestaties had voor willekeurige, lage compressiegegevens van zijn eerdere tests op de schijf. Het overklast echter nog steeds gemakkelijk de draaiende media.
Voordat ik de tests uitvoerde, was ik geïnteresseerd om te weten welke typen wachten tijdens de tests zouden optreden, dus als onderdeel van de testconfiguratie heb ik sys.dm_os_wait_stats gewist met DBCC SQLPERF en de uitvoer van de DMV vastgelegd voor elke testrun in een tabel. De hoogste wachttijden voor de enkelvoudige snapshotconfiguraties waren PREEMPTIVE_OS_WRITEFILE en WRITE_COMPLETION zoals weergegeven in afbeelding 2, voor 1 of 2 databasesnapshots.
Figuur 2 – Snapshot Top Waits
Een van de interessante items was de toevoeging van FCB_REPLICA_WRITE waits wanneer een tweede snapshot werd gemaakt. Na het bekijken van de wachtresultaten van de enkele database-snapshot en het opnieuw uitvoeren van een aantal testrondes, vindt deze wachttijd nooit plaats voor een enkele snapshot en vindt deze alleen plaats wanneer er meer dan één snapshot bestaat en wordt geassocieerd met het kopiëren van de pagina's naar de snapshot-bestanden van de database. De wachttijden voor de PREEMPTIVE_OS_WRITEFILE-wachttrend sluiten nauw aan bij de toename van de uitvoeringsduur voor elk van de configuraties.
Met deze resultaten in gedachten, kan het bij het beoordelen van een systeem met behulp van de Waits and Queues-methodologie de moeite waard zijn om te onderzoeken of er database-snapshots bestaan voor een van de databases op de server.
Conclusie
Bij het gebruik van database-snapshots, zelfs in SQL Server 2012, is er een overhead in verband met de extra schrijfbewerkingen die nodig zijn voor het kopiëren van gegevenspagina's naar de schaarse bestanden voor de snapshots. Als het gebruik van database-snapshots een onderdeel is van uw algemene configuratie, zou ik echt voorzichtig zijn met het plannen van het I/O-subsysteem om te voldoen aan de werkbelastingsvereisten voor gelijktijdige I/O-activiteit voor de schaarse bestanden met snapshots van de database.
Op basis van de resultaten van deze tests zou ik zelfs overwegen om database-snapshots op SSD's te plaatsen vóór tempdb voor de schrijfprestaties, en ook voor een lagere prestatie-impact van het snapshot-onderhoud.
Zoals altijd kan uw kilometerstand variëren, en u zult zeker de prestaties van elke configuratie willen testen voordat u deze in productie gaat nemen.