SQL Locks

[B.Hauser]

Hallo Leute,

wir haben folgendes Problem:

In einem SQLRPG-Programm wird vom Query-Optimizer eine Join-File als Zugriffsweg ausgewählt.
Für die SQL-Abfrage ist keine Join-File notwendig.
Das SQL-Statement ist mit "FOR READ ONLY" definiert.

Ein anderes paralell laufendes SQLRPG-Programm wählt ebenfalls eine Join-File über die gleichen physischen Dateien aus.
Auch in diesem Fall ist keine Join-File für die SQL-Abfrage notwendig.
Auch dieses SQL-Statement ist mit "FOR READ ONLY" definiert.

Trotzdem erhält nur ein Programm den Zugriff auf die benötigte Datei.
In dem anderen wird SQLCOD -913 (Row or object &1 in &2 tpye *&3in use) ausgegeben.

Tritt dieses Problem auch bei anderen auf?
Wie kann ich dies vermeiden?
Oder handelt es sich um einen Bug?

Sorry ich habe diesen Punkt auch noch unter Anwendungs-Entwicklung erfasst, ich war mir nicht ganz sicher welches der richtige ist.

Danke im voraus

B.Hauser

[Fuerchau]

Die Auswahl der Joinfile hat nur etwas damit zu tun, den Zugriffsweg zu optimieren. Es wird nur der Schlüssel des Joins verwendet.

Zur Lock-Situation:

Prüfen Sie, welche Commit-Option sie verwenden, prüfen sie, ob sie "FOR READ ONLY" auch tatsächlich angegeben haben, ansonsten wir nämlich eine Update-Möglichkeit erwartet und die Tabelle gesperrt (siehe Commit-Option).

[BenderD]

Hallo,

Table Locks gibt es bei SQL lediglich bei Verwendung des Sperrlevels Serializable und das ist mir bisher noch nicht über den Weg gelaufen, obwohl es eigentlich vom SQL Standard gefordert wird.

Es geht kein Weg daran vorbei den Code rauszurücken und dann kann es immer noch sein, dass irgendein RLA Schinken der Verursacher ist.

mfg

Dieter Bender
<BLOCKQUOTE><font size="1" face="Verdana, Arial">Zitat:</font><HR>Original erstellt von Fuerchau:
Die Auswahl der Joinfile hat nur etwas damit zu tun, den Zugriffsweg zu optimieren. Es wird nur der Schlüssel des Joins verwendet.

Zur Lock-Situation:

Prüfen Sie, welche Commit-Option sie verwenden, prüfen sie, ob sie "FOR READ ONLY" auch tatsächlich angegeben haben, ansonsten wir nämlich eine Update-Möglichkeit erwartet und die Tabelle gesperrt (siehe Commit-Option).[/quote]

[B.Hauser]

Hallo,

es kann eigentlich nicht am SQL-Code liegen, da beide Programm seit ca. 3 Jahren laufen.
Das Problem tritt erst auf, seit wir von Release V4R4M0 auf Release V5R1M0 umgestiegen sind.

Das gleiche Lock-Problem tritt auch im interaktiven SQL auf, wenn eine Join-File als Zugriffsweg ausgewählt wurde und Sätze in einer der physischen Dateien gelockt sind.
Auch dann wenn bei dem Select-Statement "FOR READ ONLY" angegeben wird.

STRSQL läuft mit Commit *NONE.

Die SQL-Programme sind mit Commit *CHG umgewandelt, da auch Updates erfolgen müssen.
Pro Programm werden u.U. mehrere SQL-Abfragen verwendet.

mfg

B.Hauser

<BLOCKQUOTE><font size="1" face="Verdana, Arial">Zitat:</font><HR>Original erstellt von BenderD:
Hallo,

Table Locks gibt es bei SQL lediglich bei Verwendung des Sperrlevels Serializable und das ist mir bisher noch nicht über den Weg gelaufen, obwohl es eigentlich vom SQL Standard gefordert wird.

Es geht kein Weg daran vorbei den Code rauszurücken und dann kann es immer noch sein, dass irgendein RLA Schinken der Verursacher ist.

mfg

Dieter Bender
[/quote]

[BenderD]

Hallo,

diese Infos sind natürlich die wichtigsten, das deutet eindeutig auf einen Bug. Habt ihr eigentlich die Gruppen ptfs für die Database drin (DSPDTARA QSYS/SF99501 meine ich so aus dem Ärmel). Im übrigen kann das sogar an dem read only liegen, das erlaubt lokale Kopien, für die dann alle Sätze gebraucht werden.

Aber wie auch immer: keine Work arounds, springt IBM auf die Füsse, das Betriebssystem und die Datenbank haben Geld gekostet.

Dieter

[holli]

Ich hatte ja auch Probleme, wie im Thread "Dateileseprobleme" beschrieben. Am besten ist es, die Programm unter V5R1M0 neu zu kompilieren, dann wird es wahrscheinlich keine Probleme mehr geben. So war es jedenfalls bei meinem Dateiproblem.

[Dieser Beitrag wurde von holli am 15. August 2002 editiert.]

[BenderD]

Hallo,

dieser Empfehlung kann ich mich nicht anschliessen. Wenn das was bringt, dann spricht das für eine ungeordnete Umgebung mit nicht reproduzierbaren Compiles. Sorry, dass mir keine mildere Beschreibung eingefallen ist.

Dieter

[Fuerchau]

Dieses Problem habe ich auch schon bei V4R5.
Bei COMMIT(*NONE) ist SQL nun mal so definiert, dass keine "schmutzigen" Read's ermöglicht werden.
Wenn also auf einem Satz ein Lock vorliegt, kann SQL diesen Satz nun leider nicht lesen.
Versuchen Sie es mit einem höheren Commit-Level, COMMIT(*CHG), so dass gelockte Daten auch gelesen werden können.

IBM hat wohl diesen "Fehler" seit V4R5 korrigiert, so dass nun einige SQL's jetzt fehlschlagen.

COMMIT(*CHG) kann auch ohne Journalisierung verwendet werden.

[BenderD]

Hallo,

es tut mir ja leid, dass ich ausgerechnet einem der Moderatoren widersprechen muss, aber ...

Commit *NONE heisst, dass SQL keine Sätze sperrt, weder gelesene, noch geschriebene, gelesen wird alles, was share read zulässt. Hierfür ist keine Journalisierung erforderlich

Commit *CHANGE heisst auch *UC für uncommited read, liest also alles, was share read zulässt und sperrt nur geschriebene Sätze bis Commit oder Rollback. hiermit kann man also nicht verhindern, dass ein Satz zwischen lesen und schreiben nicht von anderen verändert wird. Journal erforderlich!!!

*CS wird auch read committed genannt, hier gibt es keine dirty reads mehr, beim Lesen über Cursor wird der aktuelle Satz beim Lesen gesperrt und beim Schreiben oder nächstem Lesen freigegeben. Ist dem Sperren in RLA ähnlich. erfordert ebenfalls Journalisierung.

*ALL sperrt alle Sätze, egal ob gelesen oder geschrieben, bis Transaktionsende, keine dirty reads, Journal erforderlich.
*RR entspricht ANSI Serializable, das heisst es wird so geschrieben, als ob man alleine auf der DB wäre; sperrt alles gelesen und geschriebene und legt einen Write Lock auf alle Tables, auf die geschrieben wurde, Sperren werden auch hier beim Commit/Rollback freigegeben, erfordert Journal. Das ist auf einer AS/400 normalerweise nicht einsetzbar, wegen RLA (Dateien mit update geöffnet) und idiotischer defaults beim CREATE TABLE bzw. CRTPF (waitfile *immed).

Wenn wir denn bei idiotischen defaults sind; wait record 60 sec, das ist auch so einer.

Ein Blick ins SQL Handbuch, oder in die Bedienerhilfe beim STRSQL oder CRTSQLxxx, wäre hier hilfreich!!!

Dieter Bender

******************************************

<BLOCKQUOTE><font size="1" face="Verdana, Arial">Zitat:</font><HR>Original erstellt von Fuerchau:
Dieses Problem habe ich auch schon bei V4R5.
Bei COMMIT(*NONE) ist SQL nun mal so definiert, dass keine "schmutzigen" Read's ermöglicht werden.

siehe oben!!!

Wenn also auf einem Satz ein Lock vorliegt, kann SQL diesen Satz nun leider nicht lesen.

siehe oben!!!

Versuchen Sie es mit einem höheren Commit-Level, COMMIT(*CHG), so dass gelockte Daten auch gelesen werden können.

IBM hat wohl diesen "Fehler" seit V4R5 korrigiert, so dass nun einige SQL's jetzt fehlschlagen.

hier gab es keinen Fehler!!! allenfalls damages im OS (Gruppen PTFs einspielen!!!)


COMMIT(*CHG) kann auch ohne Journalisierung verwendet werden.[/quote]

siehe oben!!!

[Fuerchau]

Auch Moderatoren sind nicht allwissend.

Nach Einspielung der letzten DB-PTF's (V4R5) taucht der von mir beschriebene Fehler auch nicht mehr auf.
Ist ein Datensatz durch eine andere Anwendung gesperrt (egal ob native oder per SQL), liest SQL jetzt auch diesen Satz (ohne Satzwartezeit).
Selbst wenn ich einen "Select ... for update" kodiere, wird der Satz gelesen, aber halt ohne Sperre. Beim "update .. current of " wird dann erst ein SQL-Fehler ausgelöst.