-
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
-
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
Das Notwendige steht über dem technisch machbaren.
(klingt komisch, funktioniert aber!)
-
 Zitat von 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.
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.
 Zitat von Fuerchau
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.
-
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.
Similar Threads
-
By Tonazzo in forum NEWSboard Programmierung
Antworten: 5
Letzter Beitrag: 16-06-14, 10:30
-
By kriss in forum IBM i Hauptforum
Antworten: 2
Letzter Beitrag: 07-02-03, 10:15
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks