Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Using Unix debuggers to attach to Oracle processes

RE: Using Unix debuggers to attach to Oracle processes

From: Schultz, Charles <>
Date: Mon, 8 May 2006 08:39:09 -0500
Message-ID: <>

Egor, you mentioned:

"There might be a catch here. Such program will not work without some values (like address of fixed table). These values may change after db startup and are obtained using ordinary SQL (via sqlplus, for example). So if we want to use program that directly read data from SGA of hanged database, we need to preliminary read some values sometimes before database hangs (for example, immediately after startup)."

That is helpful to know. I am still stuck on the debugger, and my sysadmins are not up to date with the latest debuggers we have, which are (Solaris 8): dbx 6.2 (/opterp/ban7/SUNWspro/bin/dbx)
/bin/adb (unknown version)
/bin/mdb (unknown version)

The referenced metalink note (#121779.1) shows how to use dbx, but either I am stupid and typing something wrong, or the instructions are not compatible with our version. As mentioned previously, I tried adb and mdb; the commands fail or I get a 16gb dump. =) I am still struggling my way through the man page that Tanel linked. Has anyone used any of these specific debuggers to good affect?

-----Original Message-----
From: Tanel Põder [] Sent: Saturday, May 06, 2006 5:59 AM
To:; Schultz, Charles
Cc: oracle-l
Subject: Re: Using Unix debuggers to attach to Oracle processes

ksudps() prints processtate, it might be worth to start with this one if your system is hung and proceed from there.

Those three functions are the only three which ever should be called directly and only in very extreme circumstances when even connect as sysdba doesn't work. And before resorting to that, a direct attach sga program, dumping v$session_wait should be done before (if not using 10gR2's EM direct attach mode). Several versions of such program are available from internet.


>> Update: Actually, calling ksudss from adb did produce a trace file.
>> Unfortunately, adb never returned control to the shadow process and
>> consequently generated a 16gb trace file (only completed because I
>> bounced the database). That was interesting. I was positive hanganalyze
>> dumps were not that big. =)
> You are right, hanganalyze dumps are not that big. Actually, when you
> call ksudss(), it produces systemstate dump. If you want hanganalyze
> trace, you need to call ksdhng() instead.
> --
> Egor
> --

Received on Mon May 08 2006 - 08:39:09 CDT

Original text of this message