Using SQL Developer to Debug your Anonymous PL/SQL Blocks

Tell Others About This Story:

Everyone knows that SQL Developer has a PL/SQL debugger – check!

Everyone also knows that it’s only setup for debugging standalone PL/SQL objects like Functions, Procedures, and Packages, right? – NO! SQL Developer can also debug your Stored Java Procedures AND it can debug your standalone PLSQL blocks. These bits of PLSQL which do not live in the database are also known as ‘Anonymous Blocks.’

Anonymous PL/SQL blocks can be submitted to interactive tools such as SQL*Plus and Enterprise Manager, or embedded in an Oracle Precompiler or OCI program. At run time, the program sends these blocks to the Oracle database, where they are compiled and executed.

Here’s an example of something you might want help debugging:

 x NUMBER := 0;
 FOR Stuff IN 1..100
  DBMS_OUTPUT.Put_Line('Stuff is equal to ' || Stuff || '.');
  x := Stuff;

With the power of remote debugging and unshared worksheets, we are going to be able to debug this ANON block!

The trick – we need to create a dummy stored procedure and call it in our ANON block. Then we’re going to create an unshared worksheet and execute the script from there while the SQL Developer session is listening for remote debug connections.

We step through the dummy procedure, and this takes OUT to our calling ANON block. Then we can use watches, breakpoints, and all that fancy debugger stuff!

First things first, create this dummy procedure –

PROCEDURE do_nothing IS

Then mouse-right-click on your Connection and select ‘Remote Debug.’ For an in-depth post on how to use the remote debugger, check out Barry’s excellent post on the subject.

Open an unshared worksheet using Ctrl+Shift+N. This gives us a dedicated connection for our worksheet and any scripts or commands executed in it.

Paste in your ANON block you want to debug.

Add in a call to the dummy procedure above to the first line of your BEGIN block like so


Then we need to setup the machine for remote debug for the session we have listening – basically we connect to SQL Developer. You can do that via a Environment Variable, or you can just add this line to your script –

CALL DBMS_DEBUG_JDWP.CONNECT_TCP( 'localhost', '4000' );

Where ‘localhost’ is the machine where SQL Developer is running and ‘4000’ is the port you started the debug listener on.

Or, Using the Environment Variable
ORA_DEBUG_JDWP=host=mypc;port= 1234

The obvious advantage here is that none of your source code needs altered.

Ok, with that all set, now just RUN the script.

Once the PL/SQL call is made, the debugger will be invoked. You’ll end up in the DO_NOTHING() object.

Debugging an ANON block from SQL Developer is possible!

If you step out to the ANON block, we’ll end up in the script that’s used to call the procedure – which is the script you want to debug.

The Anonymous Block is opened in a new SQL Dev page

You can now step through the block, using watches and breakpoints as expected.

I’m guessing your scripts are going to be a bit more complicated than mine, but this serves as a decent example to get you started.

Here’s a screenshot of a watch and breakpoint defined in the anon block being debugged:

Breakpoints, watches, and callstacks - oh my!

For giggles, I created a breakpoint with a passcount of 90 for the FOR LOOP to see if it works. And of course it does 🙂

Related Posts Plugin for WordPress, Blogger...
Tell Others About This Story:

Similar Posts by Content Area: , , ,