SQL-Statement "TRUNCATE TABLE"

[RobertPic]

...
Die Eigenschaften des CLRPFM-Befehl werden in Release V5R3M0 für SQL DELETEs ohne Where-Angaben automatisch übernommen.

DELETE ohne WHERE CLRPFM in V5R3? Skepsis! (ohne es besser zu wissen)

Ich habe zwar noch kein V5R3, aber das würde mich sehr überraschen. Es kann maximal das Leeren der Datei beschleunigt werden, für das Journal muss er ja dann doch alle Sätze "abarbeiten" - wie sollte sonst ein RMVJRNCHG / ROLLBACK funktionieren?

Wir stellen unsere Tagesendeverarbeitung auch "Transaktionssicher" um und ersetzen dabei die CLRPFM durch SQL-DELETE's. Das käme dann aber ungelegen....

LG
Robert P.

[BenderD]

Hallo,

da steht was im Memo to user für V5R3 drin, soweit ich mich erinnere (dumpf) kann man das über die QAQQINI steuern, was der default ist, weiss ich nicht; jedenfalls ist commit/rollback nicht tangiert und funktioniert weiter, sobald genügend Group PTFs verfügbar sind, dass das überhaupt funktioniert.

mfg

Dieter Bender

DELETE ohne WHERE CLRPFM in V5R3? Skepsis! (ohne es besser zu wissen)

Ich habe zwar noch kein V5R3, aber das würde mich sehr überraschen. Es kann maximal das Leeren der Datei beschleunigt werden, für das Journal muss er ja dann doch alle Sätze "abarbeiten" - wie sollte sonst ein RMVJRNCHG / ROLLBACK funktionieren?

Wir stellen unsere Tagesendeverarbeitung auch "Transaktionssicher" um und ersetzen dabei die CLRPFM durch SQL-DELETE's. Das käme dann aber ungelegen....

LG
Robert P.

[B.Hauser]

Hallo Leute,

meine Behauptung von vorhin war wohl etwas unvollständig.
SQL-Delete macht zwar einen CLRPFM aber unter folgenden Bedingungen.

Hier ein Auszug aus der SQL-Reference:
DELETE Performance: An SQL DELETE statement that does not contain a WHERE clause will delete all rows of a table. In this case, the rows may be deleted using either a clear operation (if not running under commitment control) or a change file operation (if running under commitment control). If running under commitment control, the deletes can still be committed or rolled back. This implementation will be much faster than individually deleting each row, but individual journal entries for each row will not be recorded in the journal. This technique will only be used if all the following are true:

The target table is not a view.
A significant number of rows are being deleted.
The job issuing the DELETE statement does not have an open cursor on the file (not including pseudo-closed SQL cursors).
No other job has a lock on the table.
The table does not have an active delete trigger.
The table is not the parent in a referential constraint with a CASCADE, SET NULL, or SET DEFAULT delete rule.
The user issuing the DELETE statement has *OBJMGT or *OBJALTER system authority on the table in addition to the DELETE privilege.

Birgitta

[RobertPic]

@bender
Danke für den Hinweis

@Brigitta:
schnell wie immer, ich wollte gerade auch die Memo reinkopieren....

Bleibt mir nur noch der Link für das vollständige Memo,

@bender:
ich habe mich mit V5R3 noch nicht beschäftigt, wir lassen die Versionen auch immer etwas "reifen".

Also so wie das da steht, dürfte es in den meisten Fällen kein Problem geben. Ich hoffe, dass der Befehl APYJRNCHG die neuen Journaleinträge auch richtig deutet - aber das fällt wohl unter "reifen lassen".

LG
Robert P.

[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