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:
Declare
x number := 0;
Begin
Dbms_Output.Put(Sysdate || ' ' || Systimestamp);
For Stuff In 1..100
Loop
Dbms_Output.Put_Line('Stuff is equal to ' || Stuff || '.');
x := Stuff;
End Loop;
End;
/
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 -
create or replace procedure do_nothing is begin null; end;
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
Begin do_nothing(); ...
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.
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.
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:
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




Twitter
RSS
GooglePlus
Facebook
Jun 08, 2012 @ 11:40:56
Jeff, your article seems a little unclear.
- I pasted your anon script,
- created the dummy proc
- right clicked on the db connection, clicked remote debug…no window for pops up
- and obviously the DBMS_DEBUG_JDWP.CONNECT_TCP fails afterwards.
My sandbox environment is a Win7 host running oracle 11g on a windows server 2008 guest VM via VirtualBox. SQL Developer is v3.1.07 which I am running from the host. I don’t understand why the window does not appear for remote debug though.
Maybe I should try running SQL Developer on the VM to see if that is causing the issue.
Jun 08, 2012 @ 11:48:46
So we need to figure out why the ‘remote debug’ click isn’t working. That’s a ‘do not pass go’ type of problem. Can you follow my directions here for capturing logging info and email that to me? jeff.d.smith@oracle.com
Thanks for trying this technique and taking the time to respond with your feedback – we’ll get it working!
Jun 08, 2012 @ 14:25:20
Hey Jeff,
Well the good news is a restart of SQL Developer seemed to fix the problem with the popup. I executed the anon script in an unshared worksheet with the dbms_debug call. I tried to make the dbms_debug call in another unshared worksheet as well but kept getting errors. I was most interested in running anon scripts the most from this article, as of right now I start a debug on a procedure and replace the autogenerated script with my anonymous script.
I guess a picture might help:
http://i18.photobucket.com/albums/b116/dtdono0/Oracle/oracle_debug001.png
Jun 08, 2012 @ 15:31:24
You only use localhost if you’re database is on the same machine as SQL Developer. Replace localhost with the IP or network name of the machine where you have SQL Developer installed.
Jul 02, 2012 @ 21:09:11
There is “debug” context menu item in SQL worksheet. However, there is no way to set breakpoints in SQLWorksheet. If you have Preferences->Debug->”Step Into” then the debuggin process would open PL/SQL editor for anonymous block with execution stopped at the very first line, where you can set breakpoints and do normal debugging.
Jul 03, 2012 @ 10:11:12
Thanks Tegiri! I totally overlooked that Context menu item!
Nov 29, 2012 @ 14:38:25
Great article. Just like to add a small information. Before starting the first debugging run, add a breakpoint into the procedure “do_nothing”. On my system (SQL-Developer 3.2.2) this seemed to be another way to get the anonymous_block window. And from there adding further breakpoints was obvious.