Abfrage läuft nicht durch, Debugger beendet sich nicht

[CLL]

Ich habe ein Problem mit 11g, das vermutlich mit einem einstellbaren Parameter in der Datenbank zu tun hat. Ich habe nur überhaupt keine Ahnung in welche Richtung ich suchen muss.
Ich habe eine FUNKTIONIERENDE Prozedur, die einen Cursor abruft (keine Updates oä, somit auch keine Sperren).
Führe ich sie über ein Worksheet aus, wird sie in ca 2 Sekunden ausgeführt und gibt das Ergebnis aus. Passt.
Führe ich sie aus dem Package heraus aus (mit dem grünen Startknopf oben), läuft die Session ewig und beendet sich nicht. Ich muss die Session dann über "Extras->Sessions überwachen" beenden.
Führe ich sie (für Debug kompiliert) mit dem Debugger aus, läuft dieser komplett durch, beendet sogar den "Anonymous_Block", der für den Aufruf automatisch erstellt wird und dann bleibt die Session aber offen, der Debugger beendet sich nicht. In der Ausgabe erscheint:

PL/SQL wird ausgeführt: ALTER SESSION SET PLSQL_DEBUG=TRUE
PL/SQL wird ausgeführt: CALL DBMS_DEBUG_JDWP.CONNECT_TCP( '10.200.8.16', '53843' )
Debugger hat Verbindung von Datenbank auf Port 53843 akzeptiert.
Source Breakpoint: MYTEST.pls:15
PL/SQL wird ausgeführt: CALL DBMS_DEBUG_JDWP.DISCONNECT()

Was kann dieses merkwürdige Verhalten auslösen? Ich habe die selbe Prozedur auf einem 12g-System ausprobiert, da lief sie problemlos.
Ich freue mich über jede Vermutung!

[defo]

Führe ich sie über ein Worksheet aus, wird sie in ca 2 Sekunden ausgeführt und gibt das Ergebnis aus. Passt.
Führe ich sie aus dem Package heraus aus (mit dem grünen Startknopf oben), läuft die Session ewig und beendet sich nicht. Ich muss die Session dann über "Extras->Sessions überwachen" beenden.

Wie sieht denn der Package Aufbau bzw. die Packagefunction /-procedure aus?
Mit welchen Rechten wird das Package aufgerufen?

[CLL]

Der Nutzer, mit dem ich mich im SQL Developer mit dem Schema verbinde, hat DBA-Rechte. Da der Debugger über die Selects drüber läuft, kann es doch auch eigentlich nicht an fehlenden Rechten auf die Tabellen (aus einem anderen Schema) liegen. In das "EXCEPTION WHEN OTHERS" springt der Debugger nicht.
Die Prozedur ruft zwei Werte mit SELECT INTO ab, berechnet damit eine Ausgabevariable und füllt danach noch einen SYS_REFCURSOR für die Rückgabe. Die einzelnen Selects sind im Worksheet ausprobiert mit den selben Werten wie den Aufrufvariablen und sogar die gesamte Prozedur lässt sich im Worksheet ausführen.

[Wernfried]

Probiere mal ein 'DROP PROCEDURE ...' und erzeuge sie neu (kein 'CREATE OR REPLACE ...')

Gruss

[FlexGer]

Ich hatte so ein Problem schon mit dem PL SQL Developer. Nutzt du diesen ebenfalls?

http://stackoverflow.com/questions/2...n-certain-code

[defo]

Der Nutzer, mit dem ich mich im SQL Developer mit dem Schema verbinde, hat DBA-Rechte. ..

Ich meinte, ob Du irgendwo mit Invoker Rights arbeitest. Falls die Zugriffsrechte nicht passen, sollte wohl eine Fehlermeldung kommen.
@Flexger: Die Ausgaben in #1 wird offenbar schon das neue debug package verwendet.

[CLL]

@Wernfried: Ich habe die Prozedur schon in mehreren Varianten in verschiedenen Testpackages neu erstellt. zB ohne Cursor, nur mit einem Output-Wert. Immer das selbe.
@FlexGer: Ich nutze den Oracle SQL Developer Version 4.1.0.19
@defo: Nein, gar nichts kompliziertes.
SELECT ... INTO ... FROM SCHEMA.TABELLE;
pOutput := ...
(OPEN curOut FOR ...)
Selbst wenn ich diese Abfragen in dem Schema ausführe, in dem die Tabellen liegen passiert das selbe. Dabei ist mir aber nebenbei auch noch aufgefallen, dass die DBMS-Ausgabe nicht funktioniert (evtl auch ein Bedienungsfehler. Aber ich bekomme weder beim Debugging noch beim normalen Ausführen die Ausgabe zu dem Befehl "dbms_output.put_line('Abfrage 1 komplett');". Aktiviert habe ich den Output für die Verbindung über das grüne +)

Verrückterweise läuft die selbe Abfrage durch, wenn ich die Daten auf den aktuellen Tag eingrenze. Sobald ich die Daten des ganzen Jahres abrufe, klappt es nicht mehr - aber der Debugger hängt NICHT bei der Ausführung der Selects! Die werden in 0.1-2 Sekunden ausgeführt. Das Problem ist irgendwo beim Beenden der Session.
Grenze ich auf 2 Wochen ein, kann ich im Debugger über "rollback" und "END" am Ende des anonymen Blocks drüber springen und der Debugger bleibt dann noch eine halbe Minute aktiv, bevor er "Prozess beendet" in die Ausgabe schreibt. Bei längeren Zeiträumen habe ich die Session teilweise nach über einer Stunde abgebrochen. Was passiert hier nach der Ausführung noch? Warum kann die Session nicht beendet werden wie bei allen anderen Prozeduren?

[defo]

SELECT ... INTO ... FROM SCHEMA.TABELLE;
pOutput := ...
(OPEN curOut FOR ...)
Dabei ist mir aber nebenbei auch noch aufgefallen, dass die DBMS-Ausgabe nicht funktioniert (evtl auch ein Bedienungsfehler. Aber ich bekomme weder beim Debugging noch beim normalen Ausführen die Ausgabe zu dem Befehl "dbms_output.put_line('Abfrage 1 komplett');". Aktiviert habe ich den Output für die Verbindung über das grüne +)

Verrückterweise läuft die selbe Abfrage durch, wenn ich die Daten auf den aktuellen Tag eingrenze. Sobald ich die Daten des ganzen Jahres abrufe, klappt es nicht mehr - aber der Debugger hängt NICHT bei der Ausführung der Selects! Die werden in 0.1-2 Sekunden ausgeführt. Das Problem ist irgendwo beim Beenden der Session.
Grenze ich auf 2 Wochen ein, kann ich im Debugger über "rollback" und "END" am Ende des anonymen Blocks drüber springen und der Debugger bleibt dann noch eine halbe Minute aktiv, bevor er "Prozess beendet" in die Ausgabe schreibt. Bei längeren Zeiträumen habe ich die Session teilweise nach über einer Stunde abgebrochen. Was passiert hier nach der Ausführung noch? Warum kann die Session nicht beendet werden wie bei allen anderen Prozeduren?

Also 2 Anmerkugen:
1. Sollte die Frage nicht einfach lauten: Warum läuft meine Abfrage so lange, wenn ich ein ganzes Jahr abfrage?
(da Du ein select .. into.. from .. schreibst, wird hier vermutlich kräftig abgefragt und aggregiert und irgendeine Kennzahl weggeschrieben)
2. dbms_ouput ... hat so ein Laufzeitverhalten, dass es erst am Ende der session alles ausspuckt. Das fällt bei flotten Einzelanweisungen nicht auf, aber je mehr man outputted, am besten in einer Loop oder vlt sogar in einem Select das eine Funktion enthält, die dbms_output verwendet, desto schlimmer wirds und irgendwann ist halt Kirmes. Vlt ist wegen Functionsverwendung nicht mal klar, dass da ein output läuft. In einer Standardumgebung ist ja eh sofort der Puffer voll, wie das bei Oracle Develper gehandhabt wird (Puffergröße) weiß ich nicht. Jedenfalls ist mir noch nie aufgefallen, dass der Mechanismus elegant ist oder effizient, daher nutze ich ihn kaum noch, nur vlt bei irgendwelchem adhoc Kram.
Im Grunde müsstest Du bei entsprechend kurzen Abfragezeiträumen aber vielleicht irgendwie ins Grübeln kommen, wenn Du den Output anschaust. Steht da viel oder wenig? Und wie wärs hochgerechnet auf ein Jahr?

Fazit: (Beschleunige Dein SQL) und wirf die Outputanweisungen erstmal alle raus bzw. schalte es ab, vlt kommt der Debugger dann sofort nach Sessionende zurück.

[CLL]

"dbms_ouput ... hat so ein Laufzeitverhalten, dass es erst am Ende der session alles ausspuckt"
Das erklärt zumindest, warum ich keine Ausgabe erhalte, wenn ich die Session nach 1 Stunde abbreche. Nicht aber warum ich nichts erhalte, wenn ich nur einen Tag abfrage und die Prozedur fehlerfrei durchläuft. So oder so wäre nur eine einzelne Ausgabe drin: "Abfrage komplett". Keine Mengen.
Wenn das Problem an meiner Abfrage liegt:
a) Warum kann ich sie im Worksheet in unter 2 Sekunden ausführen und das Ergebnis anzeigen lassen?
b) Warum springt der Debugger innerhalb derselben 2 Sekunden in die nächste Zeile? Müsste der dann nicht an dieser Stelle hängen anstatt NACH der "END"-Zeile?

Bei Eingrenzung auf Daten von 14 Tagen läuft die Abfrage im Worksheet 0,2 Sekunden und gibt mir dann 3 Zeilen mit 2 Spalten aus. Im Package läuft dieselbe Abfrage ca 30 Sekunden.

Durch Zufall habe ich die Ursache gerade gefunden - bin aber weiterhin verwirrt. Es lag daran, dass ich den Cursor mit einem "WITH myCursor AS" abgerufen habe und in diesem with-select nach einem Parameter gefiltert wurde. Aber wie passt das zusammen? Ich hätte erwartet, dass der Debugger dann bei diesem Select hängen bleibt!

[defo]

..
a) Warum kann ich sie im Worksheet in unter 2 Sekunden ausführen und das Ergebnis anzeigen lassen?
b) Warum springt der Debugger innerhalb derselben 2 Sekunden in die nächste Zeile? Müsste der dann nicht an dieser Stelle hängen anstatt NACH der "END"-Zeile?
..
Im Package läuft dieselbe Abfrage ca 30 Sekunden.
..

Wie ein Debugger Deine Codezeilen interpretiert oder interpretieren sollte, ist nun echt schwer zu klären.
Also ..worksheet.. zeile..nächste zeile.. end..package..
Das sind eine Menge geistige Trockenübungen, die sich vielleicht ganz einfach klären ließen, wenn man wüsste, wie Deine Zeilen denn aussehen und wie Dein Package aussieht. "Durch Zufall " wäre ich nie darauf gekommen, dass Du da ein "with mycursor as mit Filter" einsetzt. Das ist etwas unerfreulich für diejenigen, die sich das Problem vorknöpfen. So kann Dir keiner helfen.
Ich habe schon weiter oben geschrieben, dass es auch am Package liegen kann. Ein Package stellt eine eigenständige, andere Laufzeit-Umgebung, Transaktionskontext, .. her, als Dein Worksheet, was immer das auch ist, hab ich noch nie mit gearbeitet. Also alles Kaffeesatzleserei.
Wenn Du nicht weiterkommst, vereinfache Dein Problem solange, bis es nicht mehr weiter geht, ohne dass der Fehler auftritt und veröffentliche den Code hier. (Das müsstest Du auch machen, wenn Du bei einem professionellen Support landest und es ist sowieso vom Vorgehen her sinnvoll)
Oder probier ein anderes Debug Tool (PLSQL Developer wurde schon erwähnt, gibt's als Trial), eine anderen Datenstand, eine andere DB Version, anderen Patchlevel ...

[CLL]

Ich habe den Code nicht veröffentlicht, weil ich davon ausging, dass es an dem nicht liegen kann. Eben aus dem Grund, dass der Debugger sich da so merkwürdig verhalten hat und das Worksheet nicht das selbe Problem hatte.
Ich ging eher von einem Problem mich Caching, Execution Plan, Blocking Sessions oä aus und habe mich deshalb für die Unterschiede zwischen Package und Worksheet interessiert.
Dass deine Vermutung mit dem Code stimmt hat mich sehr überrascht. Danke für die Hilfe!