offene Datenpfade

[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.

[Fuerchau]

Wenn das Programm immer schön seinen Close Cursor durchführt und trotzdem ständig neue ODP's generiert werden, sollte das ggf. als Fehler an die IBM gemeldet werden.
Zumal anscheinend obige Einstellung nicht hilft, da die Cursor wohl geschlossen sind, die ODP's aber offen bleiben.
Normal ist das nicht, auch wenn man ständig per Prepare neue Abfragen erzeugt. Der "Cursor" bleibt ja doch immer der Selbe.

Ggf. hilft auch ein Drop Statement, wobei eigentlich die Ressource "Statementname" auch statisch ist und ein neuer Prepare ohne Drop auch abgelehnt wird.