Seltsames Verhalten DBCC Shrinkfile

Ich versuche, eine dbcc-Schrumpfdatei in Blöcken von 1 GB für eine Datenbank auszuführen, in der 95% der Daten archiviert und gelöscht wurden. Ich habe eine 235-GB-Datei, in der 9 GB Daten / Indizes sind. Ich möchte dies auf 50 GB reduzieren. Ich weiß, dass das Verkleinern von Datenbankdateien schlecht ist, Fragmentierung usw. verursacht. Im Rahmen der Datenbereinigung / -verkleinerung haben wir auch ein IDnex-Skript zum erneuten Erstellen.

Wenn ich mein dbcc-Shrinkfile-Skript für die Datenbank auf meiner eigenen Workstation (Quad-Core, 12 GB RAM, 2 x SATA-Laufwerke) ausführe, dauert das Shrink etwa 8 bis 10 Minuten.

Wenn Sie den identischen Code für eine identische Kopie der Datenbank nach der Datenbereinigung ausführen, dauert es in unserer Testumgebung (über 80 Kerne, 128 GB RAM, SSD-SAN) 70 Minuten. Zu beachten ist, dass zum Zeitpunkt der Ausführung der Verkleinerungsdatei auf diesem Server nur geringe Aktivitäten ausgeführt werden. Es wurde 4 Mal mit identischen Ergebnissen ausgeführt.

Ich habe dann einen anderen Ansatz gewählt, indem ich die verbleibenden 9 GB in eine andere Dateigruppe und physische Datei verschoben habe. Das Ausführen von dbcc shrinkfile für die leere 230-GB-Datei, um sie auf 50 GB zu verkleinern, auf meiner eigenen Workstation dauert <1 Minute.

Mit demselben Ansatz dauert es in der Testumgebung erneut mehr als 70 Minuten.

Ich habe während und nach dem Skript von Brent Ozar während des 70-minütigen Laufs in der Testumgebung eine Momentaufnahme der Wartestatistiken gemacht, und die Wartetypen kehrten zurück und zeigten nichts, worüber man sich Sorgen machen müsste. Top 3 Reihen unten:

Zweite Abtastzeit Abtastdauer in Sekunden wait_type Wartezeit (Sekunden) Anzahl der Wartezeiten Durchschn. Ms pro Wartezeit
2013-05-28 11: 24: 22.893 3600 WRITELOG 160.8 143066 1.1
2013-05-28 11: 24: 22.893 3600 CXPACKET 20.9 13915 1.5
2013-05-28 11: 24: 22.893 3600 PAGELATCH_EX 11.1 443038 0.0

Das Windows-Ereignisprotokoll zeigt nichts Ungewöhnliches. Ich bin gerade dabei, mich zu kratzen, warum es auf der Ninja-Hardware im Vergleich zu meiner eigenständigen Workstation so lange dauert.

— ptreston
quelle

Überprüfen Sie die Datenbank und versuchen Sie es dann.

— Kin Shah

Löschen Sie die Verriegelungsstatistiken vor dem Schrumpfen und erfassen Sie sie nach dem Schrumpfen auf beiden Maschinen. sys.dm_os_latch_stats

— Remus Rusanu

Auch @@versionauf beiden

— Remus Rusanu

Waren die Daten, die gelöscht wurden, Blob-Daten oder normale Daten? Die Kopie auf Ihrer Workstation wurde dort gelöscht oder haben Sie das QS-System nach dem Löschen gesichert und dann auf Ihrem Computer wiederhergestellt?

— Mrdenny

Das Verkleinern einer Datendatei ist eine Single-Thread-Operation, bei der ein kleiner Speicherpuffer wiederverwendet wird.

Die Ninja-Hardware hat also keinen Vorteil mit dem zusätzlichen Speicher und den 80 Kernen.

Ihr lokaler PC hat jedoch den Vorteil einer lokalen E / A-Latenz (lokale Festplatte, dh Sie müssen nicht mehrere Fahrten zum SAN durchführen).

— John Alan
quelle