Ein Datenbank-Snapshot bietet eine schreibgeschützte Ansicht einer SQL Server-Datenbank, die transaktionskonsistent mit dem Zustand der Quelldatenbank zum Zeitpunkt der Erstellung des Datenbank-Snapshots ist. Es gibt eine Reihe von Gründen für die Verwendung von Datenbank-Snapshots, z. B. Berichte für eine gespiegelte Datenbank, und DBCC CHECKDB verwendet ab SQL Server 2005 auch interne Datenbank-Snapshots.
Datenbank-Snapshots bieten auch die Möglichkeit, alle Änderungen rückgängig zu machen, die an einer Datenbank vorgenommen wurden, seit der Datenbank-Snapshot erstellt wurde, aber mit einem unangenehmen Nebeneffekt auf das Transaktionsprotokoll der Datenbank, über den Paul hier gebloggt hat.
Eines der Dinge, die im Zusammenhang mit Datenbank-Snapshots normalerweise nicht berücksichtigt oder gezeigt werden, ist die Leistungsauswirkung, die der Snapshot auf die Datenbank-Schreibarbeitslast hat. Das SQLCAT-Team veröffentlichte ein Whitepaper für SQL Server 2005, Database Snapshot Performance Considerations under I/O-Intensive Workloads, das die Leistungsauswirkungen von Datenbank-Snapshots untersuchte, und nachdem ich kürzlich mit einem Kunden zusammengearbeitet hatte, bei dem Datenbank-Snapshots zu Leistungsproblemen führten, wollte ich das tun Testen Sie SQL Server 2012 und stellen Sie fest, ob sieben Jahre und drei SQL Server-Releases später Änderungen am Overhead von Datenbank-Snapshots vorgenommen wurden.
Konfiguration testen
Um die Auswirkung von Datenbank-Snapshots auf die Schreib-Workload-Leistung zu testen, habe ich unseren Dell R720 verwendet, der eine Einfügung von 1.000.000 Zeilen in eine neue Tabelle in einer erweiterten Version der AdventureWorks2012-Datenbank durchführte. Die AdventureWorks2012-Datenbank wurde mit 8 Datendateien erstellt, die auf zwei Fusion-io ioDrive Duo 640-GB-SSDs verteilt waren, die jeweils als zwei einzelne 320-GB-Festplatten in Windows eingerichtet wurden, was insgesamt 4 Festplatten darstellt. Um die Erläuterung der Konfiguration zu vereinfachen, wird das für diese Tests verwendete Speicherlayout in der folgenden Tabelle gezeigt:
| Datenträger | Konfiguration | Nutzung |
|---|---|---|
| K | 15K RAID 5 – 6 Festplatte | Schnappschuss |
| L | Fusion-io Card2 – Seite B | Protokolldatei |
| M | Fusion-io Card2 – Seite A | 4 Datendateien |
| N | Fusion-io Card1 – Seite A | 4 Datendateien |
| Q | Fusion-io Card1 – Seite B | Tempdb |
| R | LSI Nytro BLP4-1600 | Schnappschuss |
Tabelle 1 – Layout und Nutzung der Serverfestplatte
Der Speicher für den Datenbank-Snapshot war entweder ein RAID-5-Array aus sechs SAS-Laufwerken mit 15.000 U/min, die über iSCSI verbunden waren, oder eine LSI Nytro BLP4-1600 PCI-E-Karte.
Die Test-Workload verwendete die folgende SELECT INTO-Anweisung, um eine Tabelle mit 1.000.000 Zeilen zu generieren, die zwischen den einzelnen Tests gelöscht wurde.
SELECT TOP 1000000 * INTO tmp_SalesOrderHeader FROM Sales.SalesOrderHeaderEnlarged;
Die Tests wurden so terminiert, dass die Dauer ohne Datenbank-Snapshot gemessen wurde, und dann die Dauer mit einem Datenbank-Snapshot, der auf jedem der Speichergeräte erstellt wurde, um den Leistungsabfall zu messen, der durch das Schreiben von Seitenänderungen in die Sparse-Datei des Datenbank-Snapshots verursacht wurde. Die Tests wurden auch mit zwei Datenbank-Snapshots auf demselben Speichergerät durchgeführt, um festzustellen, wie hoch der Overhead zusätzlicher Datenbank-Snapshots für die möglicherweise auszuführenden duplizierten Schreibvorgänge sein könnte.
Ergebnisse
Jede Testkonfiguration wurde zehnmal ausgeführt, und die durchschnittliche Dauer, zur einfacheren Anzeige von Millisekunden in Sekunden umgerechnet, ist in Abbildung 1 für 0, 1 oder 2 Datenbank-Snapshots dargestellt.
Abbildung 1 – Snapshot-Dauer
Die Baseline-Tests ohne Datenbank-Snapshots wurden im Durchschnitt in 1,8 Sekunden ausgeführt, und selbst wenn der Speicher für die Datenbank-Snapshot-Dateien leistungsmäßig gleichwertig war, führte das Vorhandensein eines einzelnen Datenbank-Snapshots zu einem Mehraufwand für die Schreibleistung der Datenbank. Der Overhead des zweiten Datenbank-Snapshots ist geringer als der des ersten Datenbank-Snapshots in jedem der Tests, obwohl es für die Festplatten mit 15.000 U/min viel schwieriger war, mit der zusätzlichen Schreibarbeitslast des zweiten Datenbank-Snapshots für die Datenbank Schritt zu halten. P>
Die Leistung auf der LSI-Nytro-Karte hat mich zunächst überrascht, da es sich auch um eine PCI-X-SSD handelte. Nachdem er die Ergebnisse mit Glenn besprochen hatte, erwähnte er jedoch, dass die Sandforce-Controller-Komprimierung und langsamere Schreibleistung für zufällige, niedrig komprimierte Daten aus seinen früheren Tests auf dem Laufwerk. Es übertraf jedoch immer noch leicht die sich drehenden Medien.
Vor dem Ausführen der Tests wollte ich wissen, welche Wartetypen während der Tests auftreten würden, also habe ich als Teil der Testkonfiguration sys.dm_os_wait_stats mit DBCC SQLPERF gelöscht und die Ausgabe von DMV für jeden Testlauf in einer Tabelle erfasst. Die häufigsten Wartezeiten für die einzelnen Snapshot-Konfigurationen waren PREEMPTIVE_OS_WRITEFILE und WRITE_COMPLETION, wie in Abbildung 2 gezeigt, für 1 oder 2 Datenbank-Snapshots.
Abbildung 2 – Snapshot Top Waits
Eines der interessanten Elemente war das Hinzufügen von FCB_REPLICA_WRITE-Wartezeiten, wenn ein zweiter Snapshot erstellt wurde. Nach Überprüfung der Warteergebnisse einzelner Datenbank-Snapshots und erneuter Ausführung einiger Testrunden tritt dieses Warten nie für einen einzelnen Snapshot auf und tritt nur auf, wenn mehr als ein Snapshot vorhanden ist und mit dem Kopieren der Seiten in die Datenbank-Snapshot-Dateien verbunden ist. Die Wartezeiten für die PREEMPTIVE_OS_WRITEFILE-Wartezeiten verlaufen eng mit der Zunahme der Ausführungsdauer für jede der Konfigurationen.
In Anbetracht dieser Ergebnisse kann es sich bei der Überprüfung eines Systems mit der Waits- und Queues-Methodik lohnen, diesen Wartetyp mit höheren Werten zu sehen, um zu untersuchen, ob Datenbank-Snapshots für eine der Datenbanken auf dem Server vorhanden sind oder nicht.
Schlussfolgerung
Bei der Verwendung von Datenbank-Snapshots entsteht selbst in SQL Server 2012 ein Overhead im Zusammenhang mit den zusätzlichen Schreibvorgängen, die zum Kopieren von Datenseiten in die Dateien mit geringer Dichte für die Snapshots erforderlich sind. Wenn die Verwendung von Datenbank-Snapshots Teil Ihrer allgemeinen Konfiguration ist, würde ich bei der Planung des E/A-Subsystems wirklich vorsichtig sein, um die Workload-Anforderungen für gleichzeitige E/A-Aktivitäten zu den Sparse-Dateien der Datenbank-Snapshots zu erfüllen.
Aufgrund der Ergebnisse dieser Tests würde ich sogar in Betracht ziehen, Datenbank-Snapshots auf SSDs vor tempdb zu platzieren, um die Schreibleistung zu verbessern und auch um die Leistungseinbußen durch die Snapshot-Wartung zu verringern.
Wie immer kann Ihre Laufleistung variieren, und Sie werden sicherlich die Leistung jeder Konfiguration testen wollen, bevor Sie sie in den Produktionseinsatz bringen.
