Erweiterung der Einsatzmöglichkeiten von DBCC CLONEDATABASE

Service Pack 2 für SQL Server 2014 wurde letzten Monat veröffentlicht (lesen Sie die Versionshinweise hier) und enthält eine neue DBCC-Anweisung:DBCC CLONEDATABASE . Ich war ziemlich aufgeregt, als dieser Befehl eingeführt wurde, da er eine sehr einfache Funktion bietet Möglichkeit, ein Datenbankschema zu kopieren, einschließlich Statistiken , die zum Testen der Abfrageleistung verwendet werden kann, ohne den gesamten Speicherplatz zu beanspruchen, der für die Daten in der Datenbank benötigt wird. Endlich habe ich mir die Zeit genommen, DBCC CLONEDATABASE zu testen und verstehe die Einschränkungen, und ich muss sagen, es hat ziemlich viel Spaß gemacht.

Die Grundlagen

Ich habe damit begonnen, einen Klon der AdventureWorks2014-Datenbank zu erstellen und eine Abfrage für die Quelldatenbank und dann für die Klondatenbank auszuführen:

DBCC CLONEDATABASE (N'AdventureWorks2014', N'AdventureWorks2014_CLONE');
GO
 
SET STATISTICS IO ON;
GO
SET STATISTICS TIME ON;
GO
SET STATISTICS XML ON;
GO
 
USE [AdventureWorks2014];
GO
 
SELECT *
FROM [Sales].[SalesOrderHeader] [h]
JOIN [Sales].[SalesOrderDetail] [d] ON [h].[SalesOrderID] = [d].[SalesOrderID]
ORDER BY [SalesOrderDetailID];
GO
 
USE [AdventureWorks2014_CLONE];
GO
 
SELECT *
FROM [Sales].[SalesOrderHeader] [h]
JOIN [Sales].[SalesOrderDetail] [d] ON [h].[SalesOrderID] = [d].[SalesOrderID]
ORDER BY [SalesOrderDetailID];
GO
 
SET STATISTICS IO OFF;
GO
SET STATISTICS TIME OFF;
GO
SET STATISTICS XML OFF;
GO

Wenn ich mir die E/A- und TIME-Ausgabe ansehe, kann ich sehen, dass die Abfrage der Quelldatenbank länger gedauert und viel mehr E/A generiert hat, was beides erwartet wird, da die Klondatenbank keine Daten enthält:

/* SOURCE-Datenbank */

SQL Server-Ausführungszeiten:
CPU-Zeit =0 ms, verstrichene Zeit =0 ms.

SQL Server Analyse- und Kompilierungszeit:
CPU-Zeit =0 ms, verstrichene Zeit =4 ms.

(121317 Zeile(n) betroffen)

Tabelle 'SalesOrderHeader'. Anzahl der Scans 0, logische Lesevorgänge 371567, physische Lesevorgänge 0, Read-Ahead-Lesevorgänge 0, logische Lob-Reads 0, physische Lob-Reads 0, Lob-Read-Ahead-Reads 0.

Tabelle 'Arbeitstisch'. Scan-Anzahl 0, logische Lesevorgänge 0, physische Lesevorgänge 0, Read-Ahead-Lesevorgänge 0, Lob-Logik-Reads 0, Lob-Physical-Reads 0, Lob-Read-Ahead-Reads 0.

Tabelle 'SalesOrderDetail'. Anzahl der Scans 5, logische Lesevorgänge 1361, physische Lesevorgänge 0, Read-Ahead-Lesevorgänge 0, logische Lob-Reads 0, physische Lob-Reads 0, Lob-Read-Ahead-Reads 0.

Tabelle 'Arbeitstisch'. Scan-Anzahl 0, logische Lesevorgänge 0, physische Lesevorgänge 0, Read-Ahead-Lesevorgänge 0, Lob-Logik-Reads 0, Lob-Physical-Reads 0, Lob-Read-Ahead-Reads 0.

(1 Zeile(n) betroffen)

SQL Server-Ausführungszeiten:
CPU-Zeit =686 ms, verstrichene Zeit =2548 ms.

/* KLON-Datenbank */

SQL Server-Ausführungszeiten:
CPU-Zeit =0 ms, verstrichene Zeit =0 ms.

SQL Server Analyse- und Kompilierzeit:
CPU-Zeit =12 ms, verstrichene Zeit =12 ms.

(0 Zeile(n) betroffen)

Tabelle 'Arbeitstisch'. Scan-Anzahl 0, logische Lesevorgänge 0, physische Lesevorgänge 0, Read-Ahead-Lesevorgänge 0, Lob-Logik-Reads 0, Lob-Physical-Reads 0, Lob-Read-Ahead-Reads 0.

Tabelle 'SalesOrderHeader'. Scan-Anzahl 0, logische Lesevorgänge 0, physische Lesevorgänge 0, Read-Ahead-Lesevorgänge 0, Lob-Logik-Reads 0, Lob-Physical-Reads 0, Lob-Read-Ahead-Reads 0.

Tabelle 'SalesOrderDetail'. Scan-Anzahl 5, logische Lesevorgänge 0, physische Lesevorgänge 0, Read-Ahead-Lesevorgänge 0, Lob-Logik-Reads 0, Lob-Physical-Reads 0, Lob-Read-Ahead-Reads 0.

(1 Zeile(n) betroffen)

SQL Server-Ausführungszeiten:
CPU-Zeit =0 ms, verstrichene Zeit =83 ms.

Wenn ich mir die Ausführungspläne ansehe, sind sie für beide Datenbanken gleich, mit Ausnahme der tatsächlichen Werte (der Datenmenge, die tatsächlich durch den Plan gelaufen ist):

Abfrageplan für die AdventureWorks2014-Datenbank

Abfrageplan für AdventureWorks2014_CLONE-Datenbank

Hier steht der Wert von DBCC CLONEDATABASE ist offensichtlich – ich kann jedem (Microsoft Product Support, mein Kollege DBA usw.) eine leere Kopie einer Datenbank geben und sie neu erstellen und ein Problem untersuchen lassen, und sie benötigen dafür möglicherweise nicht Hunderte von GB Speicherplatz es. Melissas T-SQL Tuesday Post vom Juli enthält detaillierte Informationen darüber, was während des Klonvorgangs passiert, daher empfehle ich, diesen für weitere Informationen zu lesen.

Ist es das?

Aber… kann ich mit DBCC CLONEDATABASE mehr machen ? Ich meine, das ist großartig, aber ich denke, es gibt viele andere Dinge, die ich mit einer leeren Kopie der Datenbank machen kann. Wenn Sie die Dokumentation für DBCC CLONEDATABASE lesen , sehen Sie diese Zeile:

Mein erster Gedanke war:„Abfrageoptimierer – hmm … kann ich diesen als Option zum Testen von Upgrades verwenden ?“

Nun, die geklonte Datenbank ist schreibgeschützt, aber ich dachte, ich würde trotzdem versuchen, einige Optionen zu ändern. Wenn ich beispielsweise den Kompatibilitätsmodus ändern könnte, wäre das wirklich cool, da ich dann CE-Änderungen sowohl in SQL Server 2014 als auch in SQL Server 2016 testen könnte.

USE [master];
GO
 
ALTER DATABASE [AdventureWorks2014_CLONE] SET COMPATIBILITY_LEVEL = 110;

Ich erhalte eine Fehlermeldung:

Hm. Kann ich das Wiederherstellungsmodell ändern?

ALTER DATABASE [AdventureWorks2014_CLONE] SET RECOVERY SIMPLE WITH NO_WAIT;

Ich kann. Das erscheint nicht fair. Nun, es ist schreibgeschützt, kann ich das ändern?

ALTER DATABASE [AdventureWorks2014_CLONE] SET READ_WRITE WITH NO_WAIT;

JA! Bevor Sie zu aufgeregt werden, lassen Sie mich diese Notiz aus der Dokumentation hier hinterlassen:

Ich wiederhole diese Zeile aus der Dokumentation, fette sie und setze sie rot als freundliches, aber extrem wichtiges Zeichen Erinnerung:

Nun, das ist in Ordnung für mich, ich wollte das definitiv nicht für die Produktion verwenden, aber jetzt kann ich es zum Testen verwenden! JETZT kann ich den Kompatibilitätsmodus ändern, und JETZT kann ich ihn sichern und zum Testen auf einer anderen Instanz wiederherstellen!

USE [master];
GO
 
BACKUP DATABASE [AdventureWorks2014_CLONE]
  TO  DISK = N'C:\Backups\AdventureWorks2014_CLONE.bak'
  WITH INIT, NOFORMAT, STATS = 10, NAME = N'AW2014_CLONE_full';
GO
 
/* restore on SQL Server 2016 */
 
 
RESTORE DATABASE [AdventureWorks2014_CLONE]
FROM  DISK = N'C:\Backups\AdventureWorks2014_CLONE.bak' WITH
MOVE N'AdventureWorks2014_Data' TO N'C:\Databases\AdventureWorks2014_Data_2684624044.mdf',
MOVE N'AdventureWorks2014_Log' TO N'C:\Databases\AdventureWorks2014_Log_3195542593.ldf',
NOUNLOAD,  REPLACE,  STATS = 5;
GO
 
ALTER DATABASE [AdventureWorks2014_CLONE] SET COMPATIBILITY_LEVEL = 130;
GO

DAS IST GROSS.

In meinem letzten Beitrag habe ich über das Trace-Flag 2389 und das Testen mit dem neuen Cardinality Estimator gesprochen, weil Sie, Freunde, brauchen mit dem neuen CE testen, bevor Sie ein Upgrade durchführen. Wenn Sie nicht testen und den Kompatibilitätsmodus im Rahmen Ihres Upgrades auf 120 (SQL Server 2014) oder 130 (SQL Server 2016) ändern, laufen Sie Gefahr, in einem Brandbekämpfungsmodus zu arbeiten, wenn Sie darauf stoßen Regressionen mit dem neuen CE. Jetzt könnte es Ihnen gut gehen, und die Leistung könnte nach dem Upgrade sogar noch besser sein. Aber… möchten Sie nicht sicher sein?

Sehr oft, wenn ich das Testen vor einem Upgrade erwähne, wird mir gesagt, dass es keine Umgebung gibt, in der die Tests durchgeführt werden können. Ich weiß, dass einige von Ihnen eine Testumgebung haben. Einige von Ihnen haben Test, Dev, QA, UAT und wer weiß was noch. Du hast Glück.

Für diejenigen unter Ihnen, die angeben, dass Sie überhaupt keine Testumgebung zum Testen haben, gebe ich Ihnen DBCC CLONEDATABASE . Mit diesem Befehl haben Sie keine Entschuldigung dafür, die am häufigsten ausgeführten Abfragen und die Schwergewichte nicht gegen einen Klon Ihrer Datenbank auszuführen. Auch wenn Sie keine Testumgebung haben, haben Sie Ihre eigene Maschine. Sichern Sie die Klondatenbank aus der Produktion, löschen Sie den Klon, stellen Sie die Sicherung auf Ihrer lokalen Instanz wieder her und testen Sie dann. Die Klondatenbank nimmt sehr wenig Speicherplatz auf der Festplatte ein und es entstehen keine Speicher- oder E/A-Konflikte, da keine Daten vorhanden sind. Sie werden in der Lage sein, Abfragepläne aus dem Klon mit denen aus Ihrer Produktionsdatenbank zu validieren. Wenn Sie auf SQL Server 2016 wiederherstellen, können Sie außerdem den Abfragespeicher in Ihre Tests integrieren! Aktivieren Sie den Abfragespeicher, führen Sie Ihre Tests im ursprünglichen Kompatibilitätsmodus durch, aktualisieren Sie dann den Kompatibilitätsmodus und testen Sie erneut. Sie können den Abfragespeicher verwenden, um Abfragen nebeneinander zu vergleichen! (Kannst du sagen, dass ich gerade auf meinem Stuhl tanze?)

Überlegungen

Auch dies sollte nichts sein, was Sie in der Produktion verwenden würden, und ich weiß, dass Sie das nicht tun würden, aber es muss wiederholt werden, da es in seinem aktuellen Zustand DBCC CLONEDATABASE ist ist nicht vollständig . Dies wird im KB-Artikel unter unterstützte Objekte vermerkt; Objekte wie speicheroptimierte Tabellen und Dateitabellen werden nicht kopiert, Volltext wird nicht unterstützt usw.

Nun, die Klondatenbank ist nicht ohne Nachteile. Wenn Sie versehentlich einen Indexneuaufbau oder eine Aktualisierung der Statistiken in dieser Datenbank ausführen, haben Sie gerade Ihre Testdaten gelöscht. Sie werden die ursprünglichen Statistiken verlieren, was Sie wahrscheinlich ursprünglich wirklich wollten. Wenn ich zum Beispiel gerade Statistiken für den gruppierten Index auf SalesOrderHeader überprüfe, erhalte ich Folgendes:

USE [AdventureWorks2014_CLONE];
GO
DBCC SHOW_STATISTICS (N'Sales.SalesOrderHeader',PK_SalesOrderHeader_SalesOrderID);

Originalstatistik für SalesOrderHeader

Wenn ich jetzt Statistiken für diese Tabelle aktualisiere, erhalte ich Folgendes:

UPDATE STATISTICS [Sales].[SalesOrderHeader] WITH FULLSCAN;
GO
 
DBCC SHOW_STATISTICS (N'Sales.SalesOrderHeader',PK_SalesOrderHeader_SalesOrderID);

Aktualisierte (leere) Statistiken für SalesOrderHeader

Als zusätzliche Sicherheit ist es wahrscheinlich eine gute Idee, automatische Aktualisierungen der Statistiken zu deaktivieren:

USE [master];
GO
ALTER DATABASE [AdventureWorks2014_CLONE] SET AUTO_UPDATE_STATISTICS OFF WITH NO_WAIT;

Wenn Sie versehentlich Statistiken aktualisieren, führen Sie DBCC CLONEDATABASE aus und der Sicherungs- und Wiederherstellungsprozess ist nicht so schwer, und Sie werden ihn im Handumdrehen automatisieren.

Sie können der Datenbank Daten hinzufügen. Dies kann nützlich sein, wenn Sie mit Statistiken experimentieren möchten (z. B. unterschiedliche Abtastraten, gefilterte Statistiken) und Sie über genügend Speicherplatz verfügen, um eine Kopie der Daten der Tabelle zu speichern.

Ohne Daten in der Datenbank erhalten Sie offensichtlich keine zuverlässig repräsentativen Dauer- und E/A-Daten. Das ist okay. Wenn Sie Daten über die tatsächliche Ressourcennutzung benötigen, benötigen Sie eine Kopie Ihrer Datenbank mit allen darin enthaltenen Daten. DBCC CLONEDATABASE geht es wirklich darum, die Abfrageleistung zu testen; das ist es. Es ist in keiner Weise ein Ersatz für herkömmliche Upgrade-Tests – aber es ist eine neue Option, um zu überprüfen, wie SQL Server eine Abfrage mit verschiedenen Versionen und Kompatibilitätsmodi optimiert. Viel Spaß beim Testen!