Uwe, Run: select u_dump.value || '/' || db_name.value || '_ora_' || v$process.spid || nvl2(v$process.traceid, '_' || v$process.traceid, null ) || '.trc' "Trace File" from v$parameter u_dump cross join v$parameter db_name cross join v$process join v$session on v$process.addr = v$session.paddr where u_dump.name = 'user_dump_dest' and db_name.name = 'db_name' and v$session.audsid=sys_context('userenv','sessionid'); and let us know what it says. You should find your trace files in that general area. On 5/2/07, Uwe Küchler <uwe@xxxxxxxxxxxx> wrote:
Oracle 9.2.0.6, HP-UX 11.11 Hello world, today I was trying to track down the SQL causing a full TEMP tablespace by tracing the 1652 event. I tried the following commands: - ALTER SYSTEM SET EVENTS '1652 trace name errorstack'; - ALTER SYSTEM SET EVENTS = '1652 trace name errorstack'; - ALTER SYSTEM SET EVENTS = '1652 trace name context forever, level 12'; - oradebug event 1652 trace name errorstack on a running system, but no trace files have been generated, although the alert log was flooded with this event after enabling trace. I had the same effect with the 10046 event a while ago and supposed that it only comes in effect when a new session is started, but then "oradebug" would be usesless in this case. This cannot be. Unfortunately (as so often) I didn't have the time to research, but now i need some input from you folks! So, why is there no tracefile after enabling trace and clearly seeing the traced event happen? Regards, Uwe -- //www.freelists.org/webpage/oracle-l
-- Rumpi Gravenstein