it-swarm.com.de

Wie kann verhindert werden, dass das Transaktionsprotokoll während der Indexreorganisation voll wird?

Wir haben mehrere Computer, auf denen wir die Größe des Transaktionsprotokolls zuvor auf 50 GB festgelegt haben. Die Größe der Tabelle, die ich neu organisieren möchte, beträgt 55 - 60 GB, wird aber kontinuierlich zunehmen. Der Hauptgrund, warum ich mich neu organisieren möchte, besteht darin, Speicherplatz zurückzugewinnen, und jeder Leistungsvorteil ist ein zusätzlicher Bonus.

Der Fragmentierungsgrad der Tabelle beträgt 30 - 35%. Auf einigen dieser Computer wird der Fehler "Transaktionsprotokoll voll" angezeigt und die Reorganisation schlägt fehl. Die Transaktionsprotokollgröße erreicht bis zu 48 GB. Was ist ein guter Weg, um dem entgegenzuwirken? Wir haben kein automatisches Inkrement aktiviert und ich zögere es, dies zu tun.

Ich kann die Protokollgröße auf einen größeren Wert erhöhen, aber wenn die Tabellengröße in Zukunft zunimmt, reicht der Wert möglicherweise nicht aus. Außerdem wird der Zweck der Reorganisation, um Speicherplatz zurückzugewinnen, zunichte gemacht, wenn die Protokollgröße gleichermaßen erhöht wird. Irgendwelche Ideen, wie ich dem effektiv entgegenwirken kann? Die Verwendung des Bulk-Modus ist keine Option, da Datenverlust nicht akzeptabel ist.

19

REORGANIZE (wie in ALTER INDEX ... REORGANIZE) ist eine sehr schnelle Operation (meistens ...), die eine geringe Menge an Protokoll erfordert, jederzeit unterbrochen und später fortgesetzt werden kann und intern in Kleinseriengeschäfte :

die Defragmentierung wird als eine Reihe von kurzen Transaktionen ausgeführt. Daher ist ein großes Protokoll nicht erforderlich, wenn häufig Protokollsicherungen durchgeführt werden oder wenn die Einstellung für das Wiederherstellungsmodell EINFACH ist.

Sind Sie sicher, dass Sie nicht über einen Wiederaufbau sprechen? Ein Index REBUILD ist langsam, teuer, verbraucht eine enorme Menge an Protokoll (wenn es nicht offline ist und nicht minimal protokolliert , Online-Neuerstellung kann nicht minimal protokolliert werden), ist eine einzelne riesige Transaktion und kann nicht ohne unterbrochen werden die ganze Arbeit verlieren.

Es scheint mir, dass Sie einen Umbau durchführen, was eine wirklich außergewöhnliche Operation ist, die Sie nur durchführen sollten, wenn Sie einen sehr gut durchdachten Grund haben. Für welche Art von Platzrückgewinnung hüpfen Sie? Alles was DBCC CLEANTABLE geht nicht? Haben Sie die physische Struktur der Tabelle überprüft, ist sie von der logischen Struktur abgewichen (siehe SQL Server-Tabellenspalten unter der Haube für Details)?

Wenn Sie wirklich die Tabelle neu erstellen müssen, haben Sie leider keine andere Wahl, als in die Kugel zu beißen und das erforderliche Protokoll zuzuweisen. Lassen Sie es nicht automatisch wachsen, es verlangsamt nur den Prozess. Wachsen Sie es auf das 2,5-fache der Tischgröße vor.

Wenn die Tabelle partitioniert ist, können Sie jeweils eine Partition offline neu erstellen (und neu organisieren). Die Online-Neuerstellung kann nur auf der gesamten Tabellenebene durchgeführt werden.

7
Remus Rusanu

Best Practice ist REORGANIZE unter etwa 30% Fragmentierung und REBUILD darüber. Einfach, REBUILD macht eine saubere Kopie, REORGANIZE macht es in-situ.

Überprüfen Sie, was Sie tatsächlich tun: Sie haben keinen Wartungsplan, der beides erledigt, oder?

Bei größeren Tabellen (50 GB Tabelle werden dort angezeigt) habe ich gesehen, dass REORGANIZE den gesamten Transaktionsprotokollspeicher belegt, wenn Sie diese Regel befolgen. Nicht oft: nur ein System mit einem bestimmten Lastmuster. Das REORGANIZE wurde nur ausgeführt, bis das Protokoll erweitert und der gesamte Speicherplatz belegt wurde.

Wir haben stattdessen ohne weitere Probleme zu REBUILD gewechselt, aber die Fragmentierung unter 25% ignoriert. Das hat bei uns besser funktioniert: Sie müssen sehen, ob es bei Ihnen funktioniert.

REBUILD kann die Leistung in der Produktion stärker beeinträchtigen als REORGANIZE, dies kann jedoch manchmal mit der Option ONLINE (Enterprise Edition erforderlich) verringert werden.

7
gbn

Ich hatte dieses Problem schon einmal.

  • Sie haben eine große Datenbank und ein kleines Protokolllaufwerk. Sie möchten sich neu organisieren (aus verschiedenen Gründen).
  • Wenn Sie dies in einer großen fragmentierten Tabelle versuchen, wird das Protokoll gefüllt, bis das Protokolllaufwerk voll ist, und der Befehl wird abgebrochen.
  • Wenn es sich im einfachen Modus befindet, schlagen andere Transaktionen möglicherweise fehl, bis das Protokoll am nächsten Prüfpunkt gelöscht wird, und wenn es sich im vollständigen Modus befindet, schlagen andere Transaktionen möglicherweise bis zur nächsten Protokollsicherung fehl. Ausfall!
  • Wenn Sie sich im Vollmodus befinden, erhöhen Sie die Häufigkeit der Protokollsicherung. Dies hilft jedoch nicht, das Problem zu vermeiden, da die Reorganisation in einer impliziten Transaktion erfolgt. Das Protokoll wird erst gelöscht, wenn diese Transaktion abgeschlossen oder abgebrochen oder gestoppt wurde.
  • Und Sie möchten WIRKLICH, dass diese Reorganisation vollständig ausgeführt wird.

Das ist ein wenig kontraintuitiv, da Sie wissen, dass wenn Sie die Reorganisation abbrechen, sie dort fortgesetzt werden kann, wo sie aufgehört hat. Es ist nur so, dass ein Abbruch die Transaktion festschreibt, anstatt sie zurückzusetzen.

Hier ist was du tust. Es ist etwas lang, aber unkompliziert.

  • Erweitern Sie Ihre Protokolldatei vorab auf eine relativ große Größe, jedoch nicht auf das Maximum. Grundsätzlich möchten Sie genügend Platz lassen, um nützliche Arbeit zu leisten, sowie für einige kleine Wucherungen, falls diese auftreten, damit der normale Betrieb nicht aufhört.
  • Erstellen Sie einen Job, um Ihre Indexreorganisation auszuführen ('Reorganisieren').
  • Erstellen Sie eine Agenten-WMI-Warnung ('Überdruckventil neu organisieren') für eine Leistungsbedingung.

    • Objekt: SQLServer: Datenbanken
    • Zähler: Verwendetes Prozentprotokoll
    • Instanz: (Ihr großer Datenbankname)
    • Alarm, wenn der Zähler über 80 steigt
    • Antwort: Job ausführen ('Check neu organisieren')
  • Erstellen Sie einen Job ('Scheck neu organisieren')

    • Überprüfen Sie im Job msdb.dbo.sysjobactivity, um festzustellen, ob der Job 'Reorganize' ausgeführt wird. Und wenn es so ist ...
    • Beenden Sie den Job und rufen Sie ab, bis er beendet ist. Dies kann einige Sekunden dauern.
    • (Wenn Sie sich im Vollmodus befinden) Lösen Sie Ihren Protokollsicherungsjob aus und bestätigen Sie, wann er abgeschlossen ist.
    • Überprüfen Sie die sys.dm_os_performance_counters, dass Ihr Zähler für freien Protokollspeicherplatz unter Ihren Schwellenwert gesunken ist.
    • Starten Sie den Job "Reorganisieren".
  • Testen Sie dies alles irgendwo, sogar in einer Entwicklungssandbox, um sicherzustellen, dass es ordnungsgemäß funktioniert, bevor Sie es auf Ihren Produktionsserver kleben.

Was Sie sehen werden, ist, dass der Job 'Reorganisieren' beginnt und das Protokoll ausfüllt. Wenn das Protokoll einen Prozentsatz voll erreicht, wird die WMI-Warnung (innerhalb von ca. 30 Sekunden) ausgelöst, mit der Ihr anderer Job ausgeführt wird. Dabei wird festgestellt, dass der Job "Reorganisieren" ausgeführt wird und daher wahrscheinlich ein Fehler vorliegt. Anschließend wird "Reorganize" gestoppt, eine Sicherung durchgeführt, bestätigt, dass der protokollfreie Speicherplatz wieder einen angemessenen Wert aufweist, und der Job "Reorganize" wird erneut gestartet, der dort fortgesetzt wird, wo er aufgehört hat.

Wie Sie können, besteht der Grund dafür, dass Sie Ihr Protokoll in diesem Szenario auf einen vernünftigen Wert einstellen, darin, die Anzahl der Zuwächse/Auslöser/Jobs/Stopps/Neustarts zu verringern, damit es effizienter wird und auch genügend Speicherplatz für das Protokoll vorhanden ist gelegentliche Wucherungen, die nicht rechtzeitig erfasst werden.

Dies ist eine Art seltsames Szenario. Ich bin mir ziemlich sicher, dass ich mich vor ein paar Jahren damit abgefunden hätte, und offensichtlich gibt es hier grundlegende zugrunde liegende Probleme. Wenn Sie jedoch mit Hunderten von Servern arbeiten, werden einige Edge-Fälle wie dieser auftauchen, die aus geschäftlichen Gründen in keiner Weise behandelt werden können, außer durch MacGyvering, eine temporäre Lösung, die die Aufgabe erledigt.

Solange es sicher, logisch, getestet und gut dokumentiert ist, sollte es kein Problem geben.

6
Cody Konior

Dies ist, was ich normalerweise für die Index-Neuorganisation getan habe (ich habe auch einige Tabellen mit jeweils über 80 GB) (da die Index-Neuorganisation jederzeit gestoppt werden kann, ohne die vorherige Neuorganisation zu verlieren).

  1. Während der Index-Neuordnung werde ich die tlog-Sicherung von meiner regulären 30-Minuten-Frequenz auf alle 10-Minuten-Frequenz erhöhen
  2. Ich habe eine weitere Sitzung, in der alle 1 Minute die Überprüfung des freien Speicherplatzes durchgeführt wird. Wenn der freie Speicherplatz des Protokolls unter einem Schwellenwert liegt, stoppe ich die Index-Reorg-Sitzung und starte (oder warte) die tlog-Sicherung. Starten Sie dann den Index-Reorg neu.

In meinem Indexpflege-Framework kategorisiere ich die Indizes in zwei Gruppen, eine für die Indexwiederherstellung und eine für die Indexreorganisation. Für die Indexwiederherstellung werde ich einen etwas anderen Ansatz verwenden, da ich eine Indexwiederherstellungssitzung nicht stoppen möchte (was zu einem Rollback führt und alle vorherigen Arbeiten verliert). Wenn meine Überwachungssitzung während der Indexwiederherstellung ein Szenario mit freiem Speicherplatz für Tlog-Dateien feststellt, erhöht die Überwachungssitzung die Tlog-Datei automatisch vorab, und im schlimmsten Fall (dh die Festplatte ist voll) erstellt meine Überwachungssitzung eine weitere Protokolldatei ( aber später werde ich es ablegen) auf einem anderen Laufwerk (dem Backup-Laufwerk)

1
jyao

Ich hatte das gleiche Problem wie der Fragesteller, und wenn ich mir seine Kommentare ansehe, kann ich sagen, dass ich das gleiche Setup hatte. Während ich versuchte, ein REORGANIZE zu erstellen, wird das Protokoll unabhängig von der Größe zu voll, sogar um ein Vielfaches der Größe der gesamten Tabelle.

Das Problem wurde durch Transaktionsreplikation verursacht. Anscheinend kann das Protokoll erst gesichert werden, wenn der Vorgang REORGANIZE abgeschlossen ist. Ich habe irgendwo gelesen, dass es sich um ein bekanntes Problem von Microsoft handelt, bin mir aber nicht sicher, wo.

Nachdem ich die Transaktionsreplikation deaktiviert hatte, funktionierten die Protokollsicherungen wieder normal, und die Durchführung von Protokollsicherungen alle 30 Sekunden während der Reorganisation funktionierte für mich gut.

1
IUmpierrez

Ich gehe davon aus, dass Sie etwas in der Art von:

ALTER INDEX ON REORGANIZE

Leider gibt es keine Möglichkeit, eine teilweise Organisation auszuführen (wie Sie beispielsweise eine Protokolldatei teilweise verkleinern können). Ich kann diese Probleme wie folgt umgehen:

1) Stellen Sie die Datenbank auf den einfachen Wiederherstellungsmodus ein, während Sie die Reorganisation ausführen. Sie sagten jedoch, dass dies nicht akzeptabel ist

2) Partitionieren des Index - Wenn Sie sich eine Möglichkeit vorstellen können, den Index zu partitionieren, um ungefähr gleich große Partitionen zu erhalten, können Sie jede Partition unabhängig neu organisieren (oder mit Online-Option neu erstellen) und so das Wachstum von Protokolldateien begrenzen

Ich bin mir sicher, dass Sie dies tun, aber wenn Sie dies nicht tun, möchten Sie möglicherweise vor und nach der Durchführung von Indexoptimierungen eine Protokolldateisicherung starten, um den verwendeten Speicherplatz zurückzugewinnen.

0
voutmaster