PL/SQL-Debugging mit dem Oracle SQL Developer

Ein hartnäckiger Fehler in einer PL/SQL-Prozedur hat mich in den letzten Tagen dazu gebracht, mich nicht nur intensiver mit dieser Prozedur zu beschäftigen, sondern auch dazu, die Debugging-Möglichkeiten des SQL-Developer kennenzulernen

Gehen wir mal davon aus, dass wir im SQL Developer bereits eine entsprechende DB-Connection konfiguriert haben. In unserem Beispiel ist es der altbekannte User SCOTT der mit einer Oracle 11.2-Datenbank arbeitet.

01

Damit wir PL/SQL-Code debuggen können, braucht der User Scott die Privilegien

DEBUG CONNECT SESSION und DEBUG ANY PROCEDURE, die der User von einem DBA gegranted bekommen muß:

SQL> show user

USER is "SYSTEM"

SQL> grant DEBUG CONNECT SESSION to SCOTT;

Grant succeeded.

SQL> grant DEBUG ANY PROCEDURE TO SCOTT;

Grant succeeded.

Als Beispielprozedur für das Debugging nehmen wir eine kleine Prozedur, die das Gehalt aller Mitarbeiter einer Abteilung satzweise um einen angegebenen Prozentsatz erhöht. Natürlich wissen wir alle, dass man sowas nicht mit PL/SQL macht sondern mit einem einfachen UPDATE, aber darum geht es in diesem Beispiel nicht (und das ist natürlich auch nicht die Prozedur, die mich in einem Kundenprojekt Zeit für das Debugging gekostet hat).

02

Mittels Rechtsklick auf „Prozeduren“ können wir dann eine neue Prozedur anlegen:

 

Die Prozedur heißt DEBUG_DEMO und bekommt die zwei Parameter IN_DEPTNO und IN_INCT_PCT.

03

Nach „OK“ zeigt der SQL-Developer das Grundgerüst der Prozedur:

04

 

Und das komplettieren wir jetzt mit unserem Demo-Code:

CREATE OR REPLACE PROCEDURE DEBUG_DEMO
(
IN_DEPTNO IN NUMBER
, IN_INC_PCT IN NUMBER DEFAULT 0
) AS
BEGIN
FOR c_rec in
(select empno from emp where deptno = in_deptno)
LOOP
update emo set sal=sal*1.1 where empno=c_rec.empno;
END LOOP;
COMMIT;
END DEBUG_DEMO;

 

Das Kompilieren dieser Prozedur ist der erste Schritt wo sich das Debugging mit dem SQL-Developer von der Arbeit „ohne Debugging“ unterscheidet: Die Prozedur muss für das Debugging speziell kompiliert werden.

05

Das Debuggen startet man durch einen Klick auf den kleinen roten Bug oder über das Kontext-Menü der Prozedur:

06

Als nächstes erscheint ein Fenster mit einer kleinen „Wrapper-Prozedur“, in der die Parameter definiert werden können, mit der unsere kleine Prozedur aufgerufen wird:

07

Hier kann man dann die Werte angeben, z.B.  IN_DEPTNO=10 und IN_INC_PCT=1:

08

Über „OK“ wird die Ausführung gestartet und anschließend wird das Debug-Protokoll angezeigt.

09

Das ist in diesem Fall nicht besonders spannend. Allerdings zeigt der Output eine Besonderheit: der DB-Server verbindet sich mit dem Client. D.h. wenn man eine Personal Firewall installiert hat, muss diese Kommunikation in diese Richtung zulassen. Ansonsten bekommt man die Meldung:

10

oder eine ähnliche Meldung, die auf Kommunikationsprobleme zwischen Client und DB-Server hinweist.

Der Session-Parameter PLSQL_DEBUG, den der SQL-Developer hier setzt, ist übrigens in 11.2 „deprecated“.

Interessanter wird das Debugging, wenn man Breakpunkte setzt. Das macht man, in dem man in der jeweiligen Code-Zeile in der Spalte ganz links 1 x klickt.

11

Bei der nächsten Ausführung wird der Debugger dann deutlich gesprächiger

12

Im Debugging-Protokoll steht, dass der Breakpoint erreicht wurde
14

Unter „Smart Data“ (siehe oben) sieht man die aktuellen Werte der Cursor-Variablen, unter „Daten“ alle Variablen. Über einen „Rechtsklick“ auf die jeweilige Zeile kann man die Werte auch ändern.

Über „Wiederaufnahme“ – im Debugging-Protokoll rechts kann man die Ausführung fortsetzen – bis die Prozedur den Breakpoint erneut erreicht.

Insgesamt bieten die Reiter im unteren Bereich u.a. folgende Funktionen:

Debugging-Protokoll

–       Beenden der Prozedur

–       „Springen“ in der Prozedur

–       Fortsetzung nach einem Breakpoint

Breakpoint:

–       Löschen von Breakpoints

Smart Data

–       Übersicht über Cursor-Variablen, Möglichkeit Watches zu definieren

Daten

–       Übersicht über alle Variablen

–       Werte ändern

–       Watches definieren

Wenn die Prozedur zum Ende gekommen ist (bei der Abteilung 10 wurden 3 Datensätze aktualisiert), sieht das Debugging-Protokoll wie folgt aus:

15

Das ist natürlich nur ein Einstieg in das Debugging mittels SQL-Developer, aber mir hat es bei meinem Problem sehr geholfen.

Insgesamt entwickelt sich der SQL Developer mehr und mehr zu meinem bevorzugten Tool. Dazu trägt nicht nur die wachsende Funktionalität, die mehr und mehr Unterstützung für den DBA bietet, und das unschlagbare Preis-Leistungsverhältnis (SQL Developer ist kostenlos) bei, sondern auch die Erweiterungsmöglichkeiten wie eigene Reports und interessante Plugins.

Weitere Informationen

Dieser Post ist natürlich nicht der erste und einzige Beitrag zum Thema „PL/SQL-Debugging mit dem SQL-Developer“. Informationen zu dem Thema gibt es auch unter:

Dieser Beitrag wurde unter Allgemein veröffentlicht. Setze ein Lesezeichen auf den Permalink.