Re: How to trace what is happening inside the stored procedure

Tim Gorman apparently said,on my timestamp of 7/02/2005 4:40 AM:

>
> The session info (i.e. V$SESSION) is not the only place where MODULE and
> ACTION are used. If you notice, they are also used in the Library Cache, in
> the Shared SQL Area, as exposed by the V$SQL view. Thus, the same SQL
> statement executed while either MODULE or ACTION have different values will
> result in a new entry in V$SQL.

Are you saying that application_info data is duplicated all over the place? Last time I looked, the V$* views are based on the X$* views, which are direct "windows" to shared memory. I'd say that application_info data will be in one place only, and visible in various V$* views. Any savings are quite frankly moot.

> So, MODULE and ACTION are also taking up space in the Shared Pool, as well
> as the session global areas. Not only are they taking up space, but they
> are being used as part of a "primary key" value. Like any other "primary
> key" then, there are a lot of good reasons to keep the values concise.

What good reasons? There are no good reasons that I can see to make a primary key concise, even if application_info was such.

> Besides, what's wrong with 32 bytes and 48 bytes? If you can't say
> something unique in 32-48 characters, it's probably not worth saying.

I don't think so. It doesn't take long for a simple message to exceed 32 characters. If I want to note the name of the procedure that is executing in a package plus a running counter, I'm already over the limit: a name of a procedure is already by itself 30 characters long max.

> Reference "The Elements of Style" by Strunk and White... :-)

I'm not sure style of prose has anything to do with monitoring a PL/SQL package.

> So, I wouldn't call it "short-sightedness", but I would call it poor
> documentation...

I call it short-sightedness.

-- 
Cheers
Nuno Souto
in sunny Sydney, Australia
dbvision_at_iinet.net.au
--
http://www.freelists.org/webpage/oracle-l