offene Datenpfade

[Robi]

Der Job läuft beim Kunden seit 3 oder 4 Monaten. (durchgehend!)
Nun hat er sich gemeldet, und über die Anzahl der offenen Dateipfade 'beklagt'.

Ich sag ihm also nun, das er sich darum nicht kümmern braucht und das das egal ist?
(auch aus performance Gründen?)

[BenderD]

... das hört sich wieder mal nach so einem HKGP Job, der alle x Minuten nachsieht, ob was auf dem Haufen liegt, da sollte man schonmal einen Blick darauf haben, ob der sukzessive zuwächst...

[Fuerchau]

Die Anzahl der ODP's im Job ist auch beschränkt (irgendwo zwischen 32K und 64K).
Mir stellt sich da eher die Frage, warum die ODP's nicht wiederverwendet werden können.

Normales Vorgehen:
1. OPEN CURSOR => OPEN ODP
1. CLOSE CUROR => CLOSE ODP
2. OPEN CURSOR => OPEN ODP
2. CLOSE => wenn 2. Open dem 1. Open entspricht, dann kein CLOSE ODP, ansonsten CLOSE ODP

Dies gilt besonders bei dynamischen SQL's mit variablen Statements, die sich eben von Aufruf zu Aufruf ändern.
Irgendwann wird wohl der Open fehlschlagen da die Ressourcen erschöpft sind und das Programm je nach Fehlerabfrage dann eher "Keine Daten" melden an Stelle eines Programmabbruchs.

Ein 2. Open Cursor ist nicht möglich, wenn der Cursor vorher nicht geschlossen ist.
Cursor lassen sich nun mal vom Namen nicht dynamisieren (außer bei CLI).

Hier gilt es eben zu prüfen:
Wird jedes Mal die selbe Openart verwendet?
Wenn ja kann es sich um einen Fehler im OS handeln.
Wenn nein, warum wird der selbe Open aber mindestens 2 Mal gemacht so dass der ODP erhalten bleibt?

Ansonsten:
Alle SQL-Einstellungen betreffen ausschließlich die Cursor und nicht die ODP's.
ODP's können nur explizit mit einem Beenden der ACTGRP oder RCLACTGRP geschlossen werden.

[andreaspr@aon.at]

Ich sag ihm also nun, das er sich darum nicht kümmern braucht und das das egal ist?
(auch aus performance Gründen?)

Du kannst Probieren die Einstellungen in der QAQQINI setzen die ich zuvor geposted habe.

[Fuerchau]

OPEN_CURSOR_CLOSE_COUNT
OPEN_CURSOR_THRESHOLD

Ein CURSOR ist kein ODP. Dies wird unabhängig verwaltet.
Normalerweise sollte der Cursor ja immer wieder geschlossen werden, da ja sonst kein neuer Open erfolgen kann. Obige Einstellungen bringen daher nichts.

[andreaspr@aon.at]

1. Natürlich ist ein CURSOR kein ODP, aber sie stehen in Verbindung!
2. Lies die Beschreibung, darin wirst du sehen dass diese Optionen jedoch sehr wohl einen Einfluss auf die ODPs haben können!
3. Es geht dabei auch nicht um ein "Exec Sql CLOSE C1;" sondern um Hard/Pseudo Close!

[BenderD]

... wobei sich die Doku über Risiken und Nebenwirkungen ausschweigt! Falls das die Anzahl der verfügbaren Cursor limitiert, kann das zu von Oracle bekannten Effekten führen!

D*B

[Fuerchau]

In der Doku wird auch nicht auf die ODP's eingegangen.
Ob ein Forced-CLose auf einen Cursor auch den ODP schließt bleibt abzuwarten.

Andererseits weist die Doku hier auf den Wert 65536 hin, was auf die maximale Anzahl an Cursor deutet.
Wenn obiges Programm schon Monate läuft, kann dieses Limit ja durchaus schon erreicht sein.

Und wie Dieter schon sagt, ein weiterer Open per SQL (ggf. auch Native IO?) ist dann nicht mehr möglich.

(Wobei die DB-Limits da angeben "storage").

[B.Hauser]

M.E. sollte der Tip von Andreas angenommen werden, und die Optionen OPEN_CURSOR_CLOSE_ COUNT und OPEN_CURSOR_ THRESHOLD gesetzt werden.
Eine Dokumentation findet sich hier:
QAQQINI query options

Die QAQQINI kann ja mit CRTDUPOBJ in jede Bibliothek kopiert und dort modifiziert werden, und anschließend mit CHGQRYA auf Job-Ebene aktiviert werden.

Wird das Limit der geöffneten Cursor/(SQL)ODPs erreicht, werden die am längsten nicht benutzten (SQL) ODPs gelöscht (Hard Close)

Zu prüfen wäre auch, ob zufällig in der Bibliotheksliste der Datenbereich QSQPSCLS1 irgendwo in der Bibliotheksliste gefunden wird. In diesem Fall werden nämlich ODPs nämlich nach der ersten Ausführung nicht gelöscht.

Vielleicht ist auch der folgende Link hilfreich:
Reducing the number of open operations

Kann es vielleicht auch sein, dass das gleiche dynamische SQL-Statement immer und immer wieder erstellt (PREPARE) und anschließend ausgeführt wird (EXECUTE)?

Birgitta

[Robi]

Moin,
Danke Euch!
@Birgitta
Prepare ja, dann wird in Schleife gefetcht.
@QAQQINI
Habe den zuständigen EDV Leiter diese Infos gegeben
Die haben den Job gestern irgendwann beenden lassen und neu aufgesetzt.
Habe leider keinen Einfluß ob QAQQINI dort (versuchsweise) geändert wird.
Bei uns hat es NICHT geholfen, wobei wir nach 8-10 Test aufrufen aufgehört haben.
Vielleicht muß ja erst eine Anzahl x oder ein Speicher y belegt sein damit das greift.

Gruß
Robi

[BenderD]

Prepare ja, dann wird in Schleife gefetcht.
Robi

... oft lässt sich das mit Parameter Markers in einen prepare und close/open using auflösen, was die genauere Lösung ist - und dann ist der Effekt weg.
Wenn das nicht so sein sollte, dann muss man sich hier überlegen, wie man einen hard close forcieren kann.
QAQQINI würde ich eher vermeiden wollen, da sich der Effekt schlecht eingrenzen lässt, der minimale Scope ist hier der Job und es muss vor dem ersten SQL Programm erfolgen, das wäre allenfalls in einem Batch, der sonst nix macht tolerabel. Ein klassischer Kunstfehler wäre, das Systemweit zu machen.
Wenn das so ein Job vom Muster HKGP (mach was leg dich schlafen, machs wieder bis dich jemand canceled), dann wäre das wirkungsvollste, nach jedem Durchlauf disconnect und als erste Aktion nach dem aufwachen connect.
Ganz egal ist das nicht mit den ODPs, wenn die Anzahl proportional zur Laufzeit des JObs wächst, die brauchen zumindest Hauptspeicher und die open Operationen werden sukzessive teurer, statt billiger, was ja eigentlich Sinn des cachens der ODPs ist.

D*B

[andreaspr@aon.at]

In der Doku wird auch nicht auf die ODP's eingegangen.
Ob ein Forced-CLose auf einen Cursor auch den ODP schließt bleibt abzuwarten.

Der Link von Birgitta zeigts sehr schön:

The ODPs opened by DB2 for i are closed when any of the following occurs:
* the threshold for open cursors specified by the query options file (QAQQINI) parameter OPEN_CURSOR_THRESHOLD is reached.
* a hard close was forced.

Ein CURSOR ist kein ODP. Dies wird unabhängig verwaltet.

Oben kann man eben auch nochmal nachlesen, dass diese eben NICHT unabhängig voneinander sind.