none
Shrink einer 2 TB großen Datenbank RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo,

    aufgrund von Änderungen habe ich nun eine Datenbank von ca. 2 TB, welche aber nur noch mit 300 GB an Daten gefüllt ist.

    99% davon macht eine Tabelle aus, welche wiederum einen PK beinhaltet, dieser natürlich clustered.

    Nun die Frage, wie bekomme ich die Datenbank auf ein normales Maß verkleinert.

    Alle meine Versuche brachten nichts, ich habe es über die GUI versucht, und über das passend Script. Der Job lief jedesmal Stunden, ohne zum Ergebnis zu kommen.

    Ich habe auch einen Neustart des Dienstes versucht, und auch einen Reorg des Clustered Index, also des PK in der entsprechenden Tabelle. Auch hier lief der Job stundenlang, ohne zum Ergebnis zu kommen.

    Hat noch jemand eine Idee, oder muss man bei der Verkleinerung einfach Geduld beweisen, und das Ganze aussitzen. An diesem Server wäre das kein Problem, das ist eine Kopie des produktiven Systems. Aber in der echten produktiven Umgebung bekomme ich niemals eine Downtime von 12h genehmigt.

    Ich danke euch,

    Grüße

    Andreas

    Montag, 10. Februar 2020 08:23
    |

Antworten

  • Question
    Anmelden
    1
    Anmelden

    muss man bei der Verkleinerung einfach Geduld beweisen, und das Ganze aussitzen.

    Hallo Andreas,

    eigentlich genau das oder noch besser, nicht verkleinern, das fragmentiert nur die Indizes.
    Wie lange es dauert hängt davon ab, wie die Date/Indize Seiten verteilt sind und wie schnell das Storage ist

    Am besten macht man es Batch-weise in dem man die Zielgröße immer auch sagen wir mal 500 MB kleiner als die aktuelle Größe setzt mit

    DBCC SHRINKFILE (N'LogischerDateiname' , 1999500) -- in MB
    Eine Downzeit benötigt man nicht, Shrink ist eine Online Operation und arbeitet Seitenweise, es wird immer nur eine Seite verschoben, wenn es parallel läuft, dann mehrer. Es erzeugt aber eben viel I/O Last, was das System langsamer macht. Man kann den Vorgang jederzeit gefahrlos abbrechen, wenn man z.B. merkt, das sonst viel Last herscht.

    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Montag, 10. Februar 2020 11:10
    |

Alle Antworten

  • Question
    Anmelden
    1
    Anmelden

    muss man bei der Verkleinerung einfach Geduld beweisen, und das Ganze aussitzen.

    Hallo Andreas,

    eigentlich genau das oder noch besser, nicht verkleinern, das fragmentiert nur die Indizes.
    Wie lange es dauert hängt davon ab, wie die Date/Indize Seiten verteilt sind und wie schnell das Storage ist

    Am besten macht man es Batch-weise in dem man die Zielgröße immer auch sagen wir mal 500 MB kleiner als die aktuelle Größe setzt mit

    DBCC SHRINKFILE (N'LogischerDateiname' , 1999500) -- in MB
    Eine Downzeit benötigt man nicht, Shrink ist eine Online Operation und arbeitet Seitenweise, es wird immer nur eine Seite verschoben, wenn es parallel läuft, dann mehrer. Es erzeugt aber eben viel I/O Last, was das System langsamer macht. Man kann den Vorgang jederzeit gefahrlos abbrechen, wenn man z.B. merkt, das sonst viel Last herscht.

    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Montag, 10. Februar 2020 11:10
    |
  • Question
    Anmelden
    3
    Anmelden

    Hi Andreas,

    der von Olaf beschriebene Weg klappt auf jeden Fall. Der Shrinkfile Operation ist leider single threaded, deswegen muss man etwas Geduld beweisen.

    Ich hatte eine ähnliche Situation, wo eigentlich auch nur eine Tabelle der "Kostentreiber" gewesen ist. Daher hab ich einfach eine neue Datendateigruppe angelegt mit einer Datendatei. Die Gruppe hab ich auch einfach "interim" genannt.  ann hab ich den clustered index neu erstellen lassen mit der Option DROP_EXISTING = ON  als Ziel die interim Dateigruppe angegeben.

    Dann die ursprüngliche Datendatei verkleinert, was auch nicht mehr so lange gedauert hatte, da nur noch einige wenige Datenseiten vorhanden waren. Die Datei aber nicht zu klein werden lassen, da ja unsere "verschobene" Tabelle wieder zurück sollte.

    Also über den gleichen Weg clustered index wieder umgezogen und zum Schluss die Interim Dateigruppe wieder weggeworfen.

    Vorteil: der SQL Server parallelisierte bei mir den Neuafubau des Index, was deutlich schneller war.

    Zudem hab ich auch keinen fragmentierten Index gehabt, was bei der reinen Shrinkfile Operation der Fall gewesen wäre.

    Gruß

    Dirk

    May you never suffer the sentiment of spending a day without any purpose

    Montag, 10. Februar 2020 13:43
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo ihr beiden,

    vielen Dank für eure Antworten. Warum auch immer lief der Prozess jetzt nach ca. 2h ohne Probleme durch.

    Aber interessant, dass es ein Single Thread ist, dann kann man nicht viel optimieren.

    Beste Grüße

    Andreas

    PS: sorry für die späte Antwort, aber ich habe vom Forum keine E-Mail erhalten, dass Antworten eingegangen sind. Ich prüfe mal meinen SPAM-Filter.

    Montag, 17. Februar 2020 06:53
    |