Easy ways of debugging the plsql code ??

Question

I have a dumb question, i am just curious to know what are the different ways you use to debug a thousands of lines of pl/sql code (procedure/function etc)...it is really scary sometimes going through different variables/code/sytnax/functionality with tight timelines...is it possible for debugging purpose to see the output of the execution like what we use in unix (set -x command)..is there any similar way in Oracle...appreciate your time it really helps me to speed up my learning though i know the basics of Oracle PL/SQL just want to know opinion from peers on how they do,Thank you.

Answer 1

Ariean wrote:
1. Can you please provide me an example on how to read the DBMS_OUPUT static array and mail it.You need to wrap DBMS_OUPUT into a package - so your code will call the package and not the DBMS_OUPUT directly. The package header may look as follows:
create or replace package DebugOut is
  procedure Write( line varchar2 );
... other calls such as writing the call stack, error trace and so on
  (see DBMS_UTILITY for details)
end;In the package implementation, you need to count the number of times that Write() is called via a counter. The counter needs to be a static package variable. When the counter reaches the ceiling (e.g. 10,000 lines), then you reset DBMS_OUPUT buffer calling DBMS_OUPUT..disable() and then DBMS_OUPUT.enable(). For example:
create or replace package body DebugOut is
  MAX_LINES constant number := 10000;
  lineCnt number := 0;
  procedure ResetDbmsOutput is
  begin
        DBMS_OUTPUT.disable;
        lineCount := 0;
        DBMS_OUTPUT.enable( buffer_size => NULL );
  end;
  procedure Write( line varchar2 ) is
  begin
    lineCnt := lineCnt + 1;
    if lineCnt > MAX_LINES then
     ResetDbmsOutput;
    end if;
    DBMS_OUTPUT.put_line( line );
  end;
end;
2. API - does it stand for "Application programming Interface" in this context like toad ?? can you please explain more on this.Correct API means Application Programming Interface. See Wikipedia's article on API for a basic overview.
In PL/SQL we have a bunch of APIs supplied by Oracle - these APIs are implemented as PL/SQL packages. UTL_SMTP is for example an API to communicate via Simple Mail Transfer Protocol with a mail server. DBMS_PIPE is an API for IPC (Inter Process Communication), allowing PL/SQL processes to communicate with one another and coordinate processing. DBMS_LOB is an API for dealing with Large Objects (LOBs). Etc.
Likewise, a good development team will create their own APIs for services their application code often needs. For example, creating a Debug Logging API (as the very simplistic example above shows).
3. What is instrumentation / instrumentation overhead ??? Instrumentation is explained via the link I've provided. Simplistically, it records what a code unit (e.g. procedure or function) does, what parameter it received, what assertions failed, what exceptions were raised and so on.
Also have a look at Microsoft Dev Network's Introduction to Instrumentation and Tracing for additional details.
As for the overheads - instrumentation means extra code that needs to be executed while your process is executed. This code will need to use resources like memory or disk space to store/record instrumentation data.
For example, we use the above DebugOut API to record the start of a code unit and parameters passed as part of instrumenting our code. The DebugOut API consumes memory (it used the DBMS_OUTPUT buffer).
So what we can do is add a debug boolean variable to the package header of the DebugOut package. In the Write() procedure of the package, we only write to DBMS_OUTPUT when debug is true.
This now means that when debug is false, our instrumentation code does not record any data - and thus reduce resource usage. When the need arise, we can enable debug in DebugOut prior to executing our code - and now as our code executes, the instrumentation part happens and DebugOut record trace information to the DBMS_OUTPUT buffer. And we can display that trace data when our process completes in order to troubleshoot problems and process flow.