delete von 100 Mill. Datensätze

[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