Presumably they are active and doing things so looks like you might need to get more info about your sessions before killing them off. I usually use a query like this to get important info about active sessions including how long they have been logged on (oldest at top), and also how long they have been running the current SQL.
SELECT USERNAME,
TERMINAL,
PROGRAM,
SQL_ID,
LOGON_TIME,
ROUND((SYSDATE-LOGON_TIME)*(24*60),1) as MINUTES_LOGGED_ON,
ROUND(LAST_CALL_ET/60,1) as Minutes_FOR_CURRENT_SQL
From v$session
WHERE STATUS='ACTIVE'
AND USERNAME IS NOT NULL
ORDER BY MINUTES_LOGGED_ON DESC;
How intermittently are you getting the error?
Do you have any logging in the trigger that is truncating a partition? You could use a simple procedure that writes (in an autonomous transaction) some information about which partition is being truncated.
Also create the on servererror trigger as suggested by Leigh Riffel, and log the query and error stack.
Finally, I would enable tracing of all occurrences of the long running query (assuming this query isn't executed all too often!):
alter session set sql_trace = true;
alter session set tracefile_identifier = wrschneider08103;
before the query and
alter session set sql_trace = false;
after.
Then, once the error has again reared its ugly head, run tkprof on the last trace file with 'wrschneider08103' in its name...
Hopefully you'll be able to correlate the information you've thus collected.
Best Answer
This should be the Oracle equivalent to the accepted answer:
I have never seen a
select a.*
before (i.e. aselect
without aFROM
clause using an alias instead of constant values) but I assume it maps to a co-related subqueryNote that onedaywhen's answer would work as well in Oracle (when replacing
except
withminus
):SQLFiddle: http://sqlfiddle.com/#!4/3f369/1
Just for completeness: in standard SQL this could be written as:
which is e.g. supported by Postgres: http://sqlfiddle.com/#!15/b431b/1