Capturing the SQL that caused the sort-extents breach in TEMP

Question

We occasionally get ad-hoc queries in our production database
which cause "ORA-1630: max # extents reached in temp segment for tablespace TEMP" alert-log entries.
(The user is chewing 750Mb of sort-space).
No user is "owning-up" to these queries, so I wish to track them down myself.
I originally created a system-trigger as follows:-
begin
if (is_servererror (1630))
then
insert sort_breach
select iv.sid,
iv.serial#,
iv.username,
iv.osuser,
iv.extents,
sq.sql_text
from
(select
ss.sid,
ss.serial#,
ss.username,
ss.osuser,
su.extents,
su.sqladdr
from v$sort_usage su,
v$session ss
where ss.serial# = su.session_num) iv,
v$sqlarea sq
where iv.sqladdr = sq.address;
end if;
end;
However, this has proved ineffective, because v$sort_usage is EMPTY by the time the trigger is fired (duoh..)(it may also be that I need to use v$session.prev_sql_addr, not v$session.sql_address - please comment !).
As there are generally upwards of 250 concurrent users, I suspect that I am condemned to the following in order to narrow down my search:-
begin
if (is_servererror (1630))
then
insert into cfm.sort_breach (SID, SERIAL#, USERNAME, OSUSER, SQL_TEXT, sorts)
select ss.sid,
ss.serial#,
ss.username,
ss.osuser,
sq.sql_text,
sq.sorts
from
v$session ss,
v$sqlarea sq
where ss.sql_address = sq.address
and sq.sorts > 0
and ss.status = 'ACTIVE'
end if;
end;
Question(1) : By the time the trigger is fired, is my sorting session actually ACTIVE ?
Question(2) : Have any of you come up with a better route to this particular grail ?
Regards.

Answer 1

Have you discounted the possiblility that the DBA is responsible? For instance, creating unique indexes generates sorts; so adding a primary key to a large table or inserting millions of rows into a table without dropping the primary key could blow the temp tablespace.
Anyway, why don't you use something like the following query to establish which users are generating excessive disk sorts. That will give you a much smaller pool of suspects to investigate in greater depth.
cheers, APC
This comes from Gurry & Corrigan (I think), anyway I half-inched it from somewhere: it's very useful.
select u.username
, u.sid
, sum(decode(n.name, 'sorts (memory)', s.value, 0)) memory_sorts
, sum(decode(n.name, 'sorts (disk)', s.value, 0)) disk_sorts
, (round(1 - (sum(decode(n.name, 'sorts (disk)', decode(s.value,0,1,s.value), 0
(sum(decode(n.name, 'sorts (memory)', decode(s.value,0,1,s.value), 0
)+sum(decode(n.name, 'sorts (disk)', decode(s.value,0,1,s.value), 0
,6)
) dmsr
from v$statname n, v$sesstat s, v$session u
where u.type = 'USER'
and lower(n.name) in ( 'sorts (disk)', 'sorts (memory)' )
and s.sid = u.sid
and n.statistic# = s.statistic#
and nvl(s.value,0) > 0
group by u.username, u.sid
order by 5 desc