View Full Version : SQL-Statement "TRUNCATE TABLE"
@Baldur: das mit dem Journal ist eine völlig andere Diskussion; für Transaktions Unterstützung gibt es zwei Möglichkeiten: Journal zum rückwärts Recovery beim Rollback, oder write ahead buffer und vorwärts, beim commit.
mfg
Dieter Bender
Wenn der TRUNCATE keinen Journal-Eintrag erstellt und somit ein Rollback unmöglich ist, stellt dieser Befehl eine unglaubliche Gefahr dar !
Da finde ich die IBM-Lösung (ab V5R3) insofern besser, wenn sie denn tatsächlich funktioniert, also incl. Rollback.
Und insofern gebe ich Dieter Recht: Was nicht ANSI-SQL ist, sollte man aus Kompatibilitätsgründen tunlichst unterlassen.
@Bender
Das Problem ist, dass ich kein V5R3 habe. Aber das kann wiederum nicht euer Problem sein, es hätte aber ja sein können, dass ihr eine andere Lösung parat hättet, die auch unter V5R2 läuft.
Grundsätzlich ist das Problem folgendes, dass es um verdichtete Statistikdateien geht, die ich am Wochenende neu aufbauen muss. Da diese Dateien aber immer von diversen Programmen geöffnet sind, habe ich hier Null Chance. Dem TRUNCATE TABLE macht das nicht, wenn die geöffnet sind, der haut die Sätze weg. Und genau das möchte ich. Ein einfaches DELETE dauert da zu lange, da alleine die eine Datei über 4 Millionen Datensätze hat die dann noch alle protokolliert werden.
Gruß
proggi
Gruß
Proggi
Da hilft halt nichts, als auch diese Programme mal kurzfristig zu beenden.
Hallo,
die erste Frage, die ich mir stelle ist, ob man die Programme nicht einfach rausfeuern kann, schließlich können die bei einem löschen der Daten, wie auch immer technisch durchgeführt, nix vernünftiges mehr anzeigen.
Die zweite Frage, die ich mir stelle ist, ob ein clear, wie auch immer bewerkstelligt und 4 Millionen inserts signifikant billiger ist als 4 Millionen updates.
Die dritte Frage, die ich mir stelle ist, ob man (redundante) Statistikdaten journalisieren sollte und ob das der wirkliche Engpass ist.
Die vierte Frage, die ein Kollege hier immer gestellt hat ist, konnte man das nicht anders machen!
Bei genügend CPU Ressourcen, könnte man natürlich auch mit parallelen Jobs speed gewinnen.
mfg
Dieter Bender
@Bender
Das Problem ist, dass ich kein V5R3 habe. Aber das kann wiederum nicht euer Problem sein, es hätte aber ja sein können, dass ihr eine andere Lösung parat hättet, die auch unter V5R2 läuft.
Grundsätzlich ist das Problem folgendes, dass es um verdichtete Statistikdateien geht, die ich am Wochenende neu aufbauen muss. Da diese Dateien aber immer von diversen Programmen geöffnet sind, habe ich hier Null Chance. Dem TRUNCATE TABLE macht das nicht, wenn die geöffnet sind, der haut die Sätze weg. Und genau das möchte ich. Ein einfaches DELETE dauert da zu lange, da alleine die eine Datei über 4 Millionen Datensätze hat die dann noch alle protokolliert werden.
Gruß
proggi
Gruß
Proggi
@Bender
zu Frage 1: Sicherlich ist das möglich, aber wieso sollte man nicht versuchen, mit möglichst geringen Aufwand viel zu erreichen (das habe ich mal irgendwo gelernt) und das hätte ich mit TRUNCATE TABLE
zu Frage 2: Da wir eine Standardsoftware gekauft haben und diese ein Update von bereits eingerechneten Umsätzen nicht zulässt, stellt sich die Frage nicht. Alternativ müsste ich ein eigenes Programm erstellen, nur dann verliere ich die Wartung!
zu Frage 3: siehe unter 2, sollten Differenzen auftreten beruft sich der Softwarelieferant auf die Journale um feststellen zu können, wo diese Differenzen herkommen.
zu Frage 4: Natürlich kann man alles anders machen, keine Frage.
Gruß
proggi