For update skip locked

[FlexGer]

Hallo zusammen,

ich habe vor eine Abarbeitung von unabhängigen SQL Statements zu parallelisieren.

Heißt also eine Tabelle beinhaltet eine CLOB Spalte mit jeweils einem SQL Statement.

Aktuell wird also eine Prozedur gestartet, die geht mit einer Schleife die Tabelle durch und führt die SQL's aus.
Zukünftig war meine Idee, dass die Prozedur sich immer nur 1 SQL holt, bis kein To-Do mehr da ist.
Hier wollte ich SELECT FOR UPDATE SKIP LOCKED WHERE ROWNUM <= 1 verwenden.
Dann kann man einfach in mehreren Sessions die Prozedur aufrufen und hat damit eine parallele Abarbeitung.

Ist das eine gute oder schlechte Idee?
Reicht meine Beschreibung aus oder soll ich genauer werden?

Vielen Dank und schöne Grüße

[defo]

Naja, Du benutzt den Datenbank Transaktionsmechanismus, um dir etwas Verwaltungsarbeit zu sparen.
Ich weiß nicht, ob man da nicht am falschen Ende spart. Ein kleines Statusflag tut doch nicht weh oder?

Das pute Select Statement das Du zeigst, sagt ja auch nichts über den Rest des Verfahrens.
Wie gehst Du mit Commit, Roleback um, wie erfolgt eine Wiederaufnahme, ..
Kann sein, dass man sich damit die Karten legt, ohne es für einige Zeit zu merken.

Oder anders, ich kann mir vorstellen, dass skip locked ganz gut flutscht, wenn Nutzdaten intelligent bearbeitet werden soll.
Solch einen Mechanismus für die "Kontrolle" (Anführungsstriche, denn die gibst Du ja ab) meiner DV Prozesse zu nutzen, halte ich für risikobehaftet. Aber vielleicht bin ich auch ein Angsthase.

[FlexGer]

Bin auch etwas ängstlich, deswegen frage ich euch
Ich denke das Problem beim Statusflag wäre, dass sich die Sessions in die Quere kommen?

Session 1: Nächsten Datensatz verarbeiten mit Status "unbearbeitet"
Session 2: Nächsten Datensatz verarbeiten mit Status "unbearbeitet"
Session 1: Datensatz 111 "in Bearbeitung" setzen

[defo]

Das tuen sie ja nicht mehr oder weniger als bei jeder anderen Transaktionslogik.
Ich würde:
Ses1: s1 = nächste SesID mit state 'new' holen und die als state "uncommited" setzen, commit
Sed2: s2 = nächste SesID mit state 'new' holen und als state "uncommited" setzen, commit
Ses1: doWorkAndCommitSesLogikasDone(s1)
Ses2: doWorkAndCommitSesLogikasDone(s2)
Ses1: steigtMitError xy Wert ist keine Zahl aus, implicit roleback, s1 verbleibt als 'uncommited'
Ses2: endet normal, setzt state als "done"
Sed2: s3 = nächste SesID mit state 'new' holen und als state "uncommited" setzen, commit
Ses1 bleibt zur Prüfung liegen
Datenkorrektur
Ses1: manuelles Flag reset auf 'new'
Ses1: sx = nächste SesID mit state 'new' holen und die als state "uncommited" setzen, commit (das Statement liegt erneut zur Bearbeitung vor)


Ob man die states innerhalb der Datentransaktion setzt oder separat oder innerhalb aber mit autonomer Transaktion muss man sehen, entscheiden. Zumindest muss es so gemacht werden, dass im Fehlerfall das Flag den Fehlschlag kennzeichnet, ohne zurückgerollt zu werden. Damit erkennbar bleibt, welche Transaktionen auch erfolgreich bearbeitet wurden. (Ggf. ist zur Unterscheidung 'uncomitted' nicht ausreichend und es muss noch ein 'failed' eingetragen werden.

Jetzt wo ich das schreibe fällt mir dbms_jobs oder neu dbms_scheduler(?) ein. Hab das schon länger nicht genutzt, aber das könnte alles bieten, was man braucht.