SQL-Statement "TRUNCATE TABLE"

[Proggi]

Guten Morgen,

wie ich sehe, habt ihr wohl das ganze Wochenende am PC gesessen und fleißig diskutiert. Leider ist meine Frage damit nicht beantwortet. Fuerchau hat da vollkommen Recht, beim Befehl "TRUNCATE TABLE" kann die Datei ruhig geöffnet sein, ich benötige keine Exklusivrechte am Objekt, um diese zu löschen (was bei CLRPFM der Fall ist).

Weiterhin wird beim TRUNCATE TABLE kein Journaleintrag erstellt, und genau deshalb würde ich gerne diesen Befehl (oder einen alternativen) verwenden.

Gruß
proggi

[BenderD]

Hallo,

beim delete ohne where Klausel kann die Datei ebenfalls geöffnet sein, wo sit das Problem? eventuelle Journal Einträge sind jedenfalls keines.
Ganz am Rande ist TRUNCATE meines Wissens auch nicht Bestandteil von ANSI SQL und damit würde ich es auch nicht für andere Datenbanken empfehlen.

mfg

Dieter Bender

Guten Morgen,

wie ich sehe, habt ihr wohl das ganze Wochenende am PC gesessen und fleißig diskutiert. Leider ist meine Frage damit nicht beantwortet. Fuerchau hat da vollkommen Recht, beim Befehl "TRUNCATE TABLE" kann die Datei ruhig geöffnet sein, ich benötige keine Exklusivrechte am Objekt, um diese zu löschen (was bei CLRPFM der Fall ist).

Weiterhin wird beim TRUNCATE TABLE kein Journaleintrag erstellt, und genau deshalb würde ich gerne diesen Befehl (oder einen alternativen) verwenden.

Gruß
proggi

[Fuerchau]

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.

[BenderD]

@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.

[Proggi]

@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

[Fuerchau]

Da hilft halt nichts, als auch diese Programme mal kurzfristig zu beenden.

[BenderD]

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

[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