Once the breakpoint is hit, the debug facility pauses execution of the
program. The power of any debugger is in its ability to inspect and change
variable values at runtime. The code below will get the value of the “ctr”
variable and display it in SQL*Plus:

So far, everything looks correct. A value of 500 was passed to the
function, and the value returned by the get_value procedure was the same.
Next, the set_value procedure will be executed in order to change the
value to 700:

The developer can then choose to continue execution (dbms_debug.continue),
add more breakpoints, delete breakpoints, or whatever is needed to analyze
the issues with the code.

The ability to inspect and modify variable values at runtime is a
prerequisite for any development environment. It allows developers to test
code during the actual execution without writing additional code for the
sole purpose of testing.

Many procedures exist within the dbms_debug package. A developer can
utilize these to create a complete debug environment, set break points,
inspect variable values, pause program execution, etc. When errors occur
during debugging, one way to map the error numbers to messages is to view
the source for dbms_debug located in $ORACLE_HOME/rdbms/admin/dbmspb.sql.

dbms_debug is a powerful, yet somewhat difficult to use, utility for
Oracle developers. It is easy to see why third party tools (Figure 8.2)
are successful with products that serve as an API to dbms_debug, with a
robust user interface and insulation from the details of the utility.

Figure 8.2 – SQL Programmer (Third Party Product)
Developers should leverage this utility for inspecting and changing
runtime variables instead of inserting code that writes values to tables.
Once mastered, dbms_debug is impossible to live without.