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