delete von 100 Mill. Datensätze

[B.Hauser]

Sukzessive gesperrt heißt, dass der Datensatz erst in dem Moment gesprerrt wird, wenn er gelesen/gelöscht wird. So könnte der 100 Millionste Datensatz noch gelesen und geändert werden, wenn die Delete-Orgie bereits gestartet ist.
Wenn Du Commit(*ALL) einstellst geht bei Deiner Aktion überhaupt nichts mehr, da selbst die Datensätze, die nur gelesen und nicht gelöscht werden gelockt werden.
Je nach dem mit welchem Tool Du arbeitest ist entweder kein Commit oder Commit *CHG per Default eingestellt. Change heißt, solange die Änderung noch nicht mit COMMIT bestätigt wurde, kann der geänderte Datensatz durch keine andere Aktion erneut geändert werden. Wird der geänderte Datensatz nur gelesen, so ist die Änderung sichtbar.
Höhere Commit Level sind schwierig zu handeln und benötigen eine exakte Planung.

Birgitta

Birgitta

[BenderD]

Je nach dem mit welchem Tool Du arbeitest ist entweder kein Commit
Birgitta

commit *none bei Bulk Statements mit Fortschreibung sind ein ernsthafter Kunstfehler, beim Abbruch bleiben dann undefinierte Zustände übrig!!!

D*B

[tt0ny]

In einem konkretes Problem. Alle Gast-User sollen gelöscht werden die noch nie bestellt haben. Jeder Gast-user hat eine member_id. Wie gesagt dauert das delete mehrere Tagen. Der Gast-user kommt in dieser Zeit wieder und bekommt die gleicher member_id zugewiesen und bestellt. Ergebniss der Gast-user wird gelöscht obwohl er nicht mehr zur Auswahlkriterien gehört (schon einmal bestellt). Kannt es so vorkommen ?

[BenderD]

Unter Commit level *all ist das Transaktionssicher, vorausgesetzt der Bestellprozess macht nicht nur einen dirty read, benutzt also ebenfalls Transaktions Steuerung mit minimalem Sperrlevel read committed. Der Preis wäre dann, dass die Transaktion mit der Bestellung mit timeout abbricht.
Verwendet der Löschprozess ein niedrigeres Sperrlevel, ist das nicht transaktionssicher, das selbe gilt, wenn der Bestellprozess mit commit *none arbeitet, letzteres selbst dann wenn man den Löschprozess transaktionssicher macht.
Wie macht man das transaktions sicher:
- Der Bestellprozess arbeitet mit read committed.
- Der Löschprozess (hier braucht es ein Programm!!!) arbeitet am einfachsten ebenfalls unter commit und liest über einen dynamic scroll cursor (der wird automatisch aktualisiert, wenn das resultset von updates tangiert ist), prüft und löscht einen Satz und beendet die Transaktion mit commit, wenn das erfolgreich war, ansonsten rollback. Das ganze in einer Schleife, bis der Cursor durch ist.

Zur Dauer ist noch zu sagen, dass die Tage mir zu lange vorkommen. Ich habe für die Löschung von 30 Millionen von 900 Millionen Sätzen etliche Stunden in Erinnerung (die wir dann letztlich in den Bereich unter einer Stunde gedampft haben, dafür musste man allerdings schon in die Trickkiste greifen, was im concurrent mode nicht alles möglich gewesen wäre).

D*B

[holgerscherer]

mit einem SQL-Zweizeiler wird es kritisch, wie schon beschrieben. Kannst Du nicht ein Statusfeld verwenden, das erst mal programmatisch gesetzt wird, z.B. von 1=Active auf 0=Inactive - das sollte in der Auftragserfassung natürlich berücksichtigt werden. Dann Löschen nach Auswahl auf diesem Statusfeld.

-h

[BenderD]

mit einem SQL-Zweizeiler wird es kritisch, wie schon beschrieben. Kannst Du nicht ein Statusfeld verwenden, das erst mal programmatisch gesetzt wird, z.B. von 1=Active auf 0=Inactive - das sollte in der Auftragserfassung natürlich berücksichtigt werden. Dann Löschen nach Auswahl auf diesem Statusfeld.

-h

... das ändert die Transaktionsproblematik in keiner Weise, sondern verschiebt sie bestenfalls in das setzen des Statusfeldes.

D*B

[Fuerchau]

FRCRATIO(1) ist der absolute Tod von schnellen SQL-Lösungen.
Mit *NONE erreicht man durchaus Faktor 100 oder mehr.
Durch RAID, Cachebatterie, Notstromversorgung und sonstige Maßnahmen kann man auf FRCRATIO(1) verzichten.
Bei mir dauerte ein CHGPF mit Quelle (ein neues Feld wurde benötigt) bei FRCRATIO(1) schon 30 Minuten und hatte mal gerade 7 Mio-Sätze kopiert. Für 100Mio war also 1 Tag zu erwarten.
Das habe ich abgebrochen, einen CHGPF FRCRATIO(*NONE) und anschließend die Feldänderung. Das dauerte dann noch knapp 15 Minuten.

[tt0ny]

Denke habe jetzt verstanden. Vielen Dank für die Antworten und Tips. Tolles Forum!

[holgerscherer]

... das ändert die Transaktionsproblematik in keiner Weise, sondern verschiebt sie bestenfalls in das setzen des Statusfeldes.

Das Setzen des Statusfeldes kann "gemütlich" nebenher laufen, zur Not in RPG ohne Commit-Steuerung. Warum? Das Statusfeld basiert ja auf einer anderen Information. Das Lösen des Performance-Problems einer sehr großen Transaktion im laufenden Update-Betrieb wird sonst schwer, wie man hier liest.

-h

[BenderD]

Das Setzen des Statusfeldes kann "gemütlich" nebenher laufen, zur Not in RPG ohne Commit-Steuerung. Warum? Das Statusfeld basiert ja auf einer anderen Information. Das Lösen des Performance-Problems einer sehr großen Transaktion im laufenden Update-Betrieb wird sonst schwer, wie man hier liest.

-h

Diese "andere Information" muss zwischen lesen und schreiben unverändert bleiben, mit anderen Worten: in derselben Transaktion erfolgen und ob isch einen Satz fortschreibe oder lösche, das macht in einem Programm mit Einzelsatzverarbeitung keinen signifikanten Unterschied.

D*B