-
 Zitat von B.Hauser
Wir müssen zwischen impliziten und expliziten Schließen eines Cursors unterscheiden.
Das SQL Statement CLOSE schließt einen Cursor, lässt jedoch die ODPs (nach dem 2. Durchlauf) stehen, sofern diese wiederverwendbar sind.
Jedes SQL Statement erhält seinen eigenen ODP, auch dann, wenn das gleiche SQL Statement mehrfach in unterschiedlichen Subroutinen, Prozeduren oder Programmen codiert wurde.
Wann ein Cursor explizit geschlossen wird hängt von der Compile Option CLOSQLCSR ab. Der Default-Wert ist *ENDACTGRP, d.h. die ODPs werden erst dann gelöscht wenn die Aktivierungsgruppe beendet wird. Wird die Option *ENDMOD verwendet, wird der ODP gelöscht sobald das Modul, in dem das SQL-Statement hinterlegt wurde beendet wird. (Da eine volle Optimierung bzw. das Aufbauen der ODPs zeitaufwendig ist, ist aus Performance-Geschichtspunkten die erste Möglichkeit die bessere).
So wie es aussieht werden alle Programme in der Default-Activation-Group ausgeführt. Und die Default-Activation-Group kann nur durch das Beenden des Jobs beendet werden.
Die Anzahl der geöffneten bzw. offengehaltenen ODPs ist auch nicht unendlich, sondern soweit ich weiß per Default 512 pro Job. Ist dieses Maximum erreicht, so wird der älteste bzw. der am längsten nicht verwendete ODP gelöscht und durch den neuen ersetzt. In der QAQQINI (Abfrage Optionsdatei) gibt es Optionen, über die auf die Anzahl der ODPs pro Job Einfluss genommen werden kann.
Trotzallem bei "SQL-System Fehler" würde ich IBM einen Fehler melden.
Birgitta
Erstmal Danke an alle.
Da habe ich ja wieder eine interessante Diskussion losgetreten.
Zum Thema:
Die Programme werden mit CLOSQLCSR *ENDACTGRP kompiliert.
(Wird von mir verwendet, weil bei *ENDMOD und häufigen Calls auf SQLRPGLE eine Verschlechterung der Performance eintritt. )
Es gibt nur statische SQL. d.H. Declare/open/fetch/close,
keine dynam. (Prepare,declare,fetch...)
Und wenn der älteste bzw. der am längsten nicht verwendete ODP bei Maximum gelöscht wird, bleibt nur die Empfehlung von Birgitta: "SQL-System Fehler" an IBM melden ?
Gruß Joe
-
Ein CLOSQLCSR *ENDMOD dürfte keine Performance-Nachteile mit sich bringen, da es sich nur um einen logischen Close handelt.
Außerdem erfolgt der ja nur, wenn du den Cursor tatsächlich offen läßt, dein Close also nicht ausgeführt wird.
Wichtiger ist da schon eher:
Wird das Programm mit *INLR = *ON oder *OFF verlassen ?
Ist es das erste SQL-Programm in der Aufrufhierarchie überhaupt ?
Wenn ja, dann erfolgt beim 1. Aufruf ein impliziter Connect zur Datenbank, bei *INLR = *ON ein Disconnect.
SQL-Programme, die ich wahlweise aus anderen Programmen oder auch als SQL-Prozedur aufrufe, verlasse ich immer mit *INLR = *OFF!
Bisher konnte ich keine Performance-Einbußen feststellen und die Anzahl der ODP's bleib auch konstant.
Es könnte sich also tatsächlich um einen Fehler in SQL (ggf. beim Aufräumen) handeln.
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