Slow delete on a table with one CLOB column

Question

Hi,
I have a table which has one CLOB column and even if I delete one row from it, it takes approx. 16 seconds. Since UNDO isn't generated for CLOBs (at least not in the UNDO tablespace), I can't figure out why this is so? The CLOB has defined a RETENTION clause, so it depends upon UNDO_RETENTION which is set to 900. There wasn't any lock from another session present on this table.
The table currently contains only 6 rows but it used to be bigger in the past, so I thought that maybe a full table scan is going on when deleting. But even if I limit the DELETE statement with an ROWID (to avoid a FTS), it doesn't help:
SQL> select * from v$version;
BANNER
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
PL/SQL Release 11.1.0.6.0 - Production
CORE    11.1.0.6.0      Production
TNS for 32-bit Windows: Version 11.1.0.6.0 - Production
NLSRTL Version 11.1.0.6.0 - Production
SQL> select count(*) from scott.packet;
  COUNT(*)
         6
SQL> column segment_name format a30
SQL> select segment_name
  2    from dba_lobs
  3  where owner = 'SCOTT'
  4     and table_name = 'PACKET';
SEGMENT_NAME
SYS_LOB0000081487C00002$$
SQL>  select segment_name, bytes/1024/1024 MB
  2    from dba_segments
  3  where owner = 'SCOTT'
  4      and segment_name in ('PACKET', 'SYS_LOB0000081487C00002$$');
SEGMENT_NAME                           MB
PACKET                               ,4375
SYS_LOB0000081487C00002$$             576
SQL> -- packet_xml is the CLOB column
SQL> select sum(dbms_lob.getlength (packet_xml))/1024/1024 MB from scott.packet;
        MB
19,8279037
SQL> column rowid new_value rid
SQL> select rowid from scott.packet where rownum=1;
ROWID
AAAT5PAAEAAEEDHAAN
SQL> set timing on
SQL> delete from scott.packet where rowid = '&rid';
old   1: delete from scott.packet where rowid = '&rid'
new   1: delete from scott.packet where rowid = 'AAAT5PAAEAAEEDHAAN'
1 row deleted.
Elapsed: 00:00:15.64From another session I monitored v$session.event for the session performing the DELETE and the reported wait event was 'db file scattered read'.
Someone asked Jonathan Lewis a similar looking question (under comment #5) here: http://jonathanlewis.wordpress.com/2007/05/11/lob-sizing/ but unfortunately I couldn't find if he wrote any answer/note about that.
So if anyone has any suggestion, I'll appreciate it very much.
Regards,
Jure

Answer 1

After reviewing the tkprof as suggested by user503699, I noticed that the DELETE itself is instantaneous. The problem is another statement:
select /*+ all_rows */ count(1)
from
"SCOTT"."MESSAGES" where "PACKET_ID" = :1
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          2           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        1      1.40      16.93     125012     125128          0           1
total        3      1.40      16.93     125012     125128          2           1
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      1  SORT AGGREGATE (cr=125128 pr=125012 pw=125012 time=0 us)
      0   TABLE ACCESS FULL MESSAGES (cr=125128 pr=125012 pw=125012 time=0 us cost=32900 size=23056 card=5764)I checked if there was any "ON DELETE" trigger and since there wasn't, I suspected this might be a problem of unindexed foreign keys. As soon as I created an index on SCOTT.MESSAGES.PACKET_ID the DELETE executed immediately. The "funny" thing is that, the table SCOTT.MESSAGES is empty, but it has allocated 984MB of extents (since it wasn't truncated), so a time consuming full tablescan was occurring on it.
Thanks for pointing me to the 10046 trace which solved the problem.
Regards,
Jure