oradebug requires the SYSDBA privilege to execute (connect internal on older Oracle versions). The list of oradebug options can be viewed by typing oradebug help at the SQL*Plus prompt:
SQL> oradebug help
HELP [command] Describe one or all commands
SETMYPID Debug current process
DUMPSGA [bytes] Dump fixed SGA
DUMPLIST Print a list of available dumps
SUSPEND Suspend execution
RESUME Resume execution
FLUSH Flush pending writes to trace file
CLOSE_TRACE Close trace file
TRACEFILE_NAME Get name of trace file
LKDEBUG Invoke global enqueue service debugger
NSDBX Invoke CGS name-service debugger
HANGanalyze [level] Analyze system hang
FFBEGIN Flash Freeze the Instance
FFDEREGISTER FF deregister instance from cluster
FFTERMINST Call exit and terminate instance
FFRESUMEINST Resume the flash frozen instance
FFSTATUS Flash freeze status of instance
CORE Dump core without crashing process
UNLIMIT Unlimit the size of the trace file
PROCSTAT Dump process statistics
Identical to tkprof, oradebug depends on trace files to store its output. These files are in the same location as specified by the user_dump_dest initialization parameter. The trace files are named according to the SPID of the process where the oradebug command is executed – the same naming scheme as described earlier.
Some of the oradebug options apply to a particular session and therefore require a system process id (SPID) as obtained from v$process. Other options are more global in nature and can be executed without attaching to any session.
ORADEBUG Session Trace
The oradebug utility provides the ability to trace a particular user session. In addition, oradebug provides additional details that are not available through other tracing mechanisms.
The following steps are required to trace a user session with oradebug:
1. Obtain the SPID from v$process.
SQL> select username, spid from v$process;
2. Start the debug session with the SPID of the process that needs traced.
SQL> oradebug setospid 2280
3. Select the appropriate trace level. There are four different options when specifying a tracing level:
Level 1 provides “base set” tracing information. Bind variables are displayed as variables
Level 4 – provides Level 1 data and the actual data values of bind variables.
Level 8 – provides Level 1 data and information on wait events when the elapsed time is greater than the CPU time.
Level 12 – combines levels 1, 4 and 8 tracing information. A Level 12 trace contains base set, bind variable values and wait events.
The oradebug command below will enable the maximum tracing possible:
SQL> oradebug event 10046 trace name context forever, level 12
1.Turn tracing off.
SQL> oradebug event 10046 trace name context off
2.Obtain the trace file name. The oradebug facility provides an easy way to obtain the file name:
SQL> oradebug tracefile_name
3.Format the trace file with tkprof (as described in the earlier section on tkprof).
The result will be a trace file that contains more trace file information. Viewing wait events and bind variable values can be critical to diagnosing performance issues.
The oradebug utility provides many options for dumping database information to trace files. In order to know what data can be dumped, the dumplist command will return the available options.
One scenario in which a dump may aid in diagnosing the problem is when dealing with a system hang. If no errors exist in the alert log and the database appears to be hung, connect as SYSDBA and execute the following:
SQL> oradebug setmypid
SQL> oradebug unlimit
SQL> oradebug dump systemstate 10
This creates a very large trace file from the system dump. For this reason, the oradebug unlimit option should be used to override the maximum trace file size as specified in init.ora.
oradebug also has the capability to only produce trace output if a particular error is encountered. This command is especially useful when certain errors are encountered inconsistently. Rather than generate enormous trace files, the trace data will only be generated when the particular error occurs. The following command will monitor a particular session and only generate trace data when the ORA-00942 error is hit:
SQL> oradebug event 942 trace name errorstack level 3
oradebug can also be used to suspend and resume any user database connection. When suspended, the user session will simply hang until the resume command is processed. During the suspension period, v$session_wait will indicate that the session is waiting on the debugger.
Only a few of the oradebug options were discussed. oradebug is a powerful utility to be used only by expert DBAs when diagnosing serious database issues. oradebug can be used in tandem with tkprof to get more detailed information in trace files. In addition, the tool can be used to generate system or process state dumps which can be vital when diagnosing system hang scenarios.