SQL-Statement "TRUNCATE TABLE"

[Proggi]

Hallo,

unter MS-SQL (Windows) gibt es die Anweisung "TRUNCATE TABLE MyTable". Hier die genaue Beschreibung aus der Onlinedokumentation:
__________________________________________________ __________________________
TRUNCATE TABLE funktioniert wie eine DELETE-Anweisung ohne WHERE-Klausel: Beide entfernen alle Zeilen aus der Tabelle. TRUNCATE TABLE ist jedoch schneller und verwendet weniger Systemressourcen und Ressourcen für die Transaktionsprotokollierung als DELETE.

Die DELETE-Anweisung entfernt jede Zeile einzeln und protokolliert jede Löschung einzeln im Transaktionsprotokoll. Beim Entfernen der Daten mit TRUNCATE TABLE wird die Reservierung der zur Speicherung der Tabellendaten verwendeten Datenseiten aufgehoben, und nur die Reservierungsaufhebungen der Datenseiten werden im Transaktionsprotokoll aufgezeichnet.

TRUNCATE TABLE entfernt alle Zeilen aus einer Tabelle, die Tabellenstruktur (Spalten, Einschränkungen, Indizes usw.) dagegen bleibt erhalten. Der für die Identität neuer Zeilen verwendete Zähler wird auf den Ausgangswert der Spalte zurückgesetzt. Falls Sie den Wert des Identitätszählers erhalten möchten, verwenden Sie stattdessen DELETE. Falls Sie die Tabellendefinition und die Tabellendaten entfernen möchten, verwenden Sie die DROP TABLE-Anweisung.

Es ist nicht möglich, TRUNCATE TABLE für eine Tabelle zu verwenden, auf die eine FOREIGN KEY-Einschränkung verweist; verwenden Sie stattdessen eine DELETE-Anweisung ohne WHERE-Klausel. Da TRUNCATE TABLE nicht protokolliert wird, kann es keinen Trigger aktivieren.

TRUNCATE TABLE kann nicht für Tabellen verwendet werden, die an einer indizierten Sicht beteiligt sind.
__________________________________________________ __________________________

Meine Frage: Gibt es einen ähnlichen Befehl unter SQL auf der iSeries?

Auf der iSeries gibt es den Befehl auch, leider macht der hier etwas anderes:

TRUNCATE or TRUNC
The TRUNCATE function returns numeric-expression–1 truncated to some number of places to the right or left of the decimal point.



Danke und ein schönen Wochenende
proggi

[B.Hauser]

Hallo proggi,

was hälst Du vom CL-Befehl CLRPFM?

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

Birgitta

[Fuerchau]

Oh weia !
Beim CLRPFM benötige ich Exclusiv-Rechte an der Datei. Hat irgend jemand die Datei offen (oder auch eine LF/Join), geht kein CLRPFM !
Der Delete ohen where geht immer (ausser für Satzsperren).

Ich hoffe, dass dann unter V5R3 der Delete ohne Where nicht abgelehnt wird, nur weil irgendwo die Datei noch auf ist, sondern dann halt Satzweise gelöscht wird.

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