DELETE Performance

Question

We are running Oracle 9i on Solaris 9.
I have a delete statement that's taking too long. Can somebody please advice what to do reduce the run time? Here is that:
delete materal_table where material_id = (select material_id from materials where name = 'abcd');
Result: About 1 million rows deleted in 4 hours!
Thanks.
Here is some more information:
Number of Records:
MATERIAL_TABLE = 280680800
MATERIALS = 8000
EXPLAIN PLAN:
Operation     Object Name     Rows     Bytes     Cost     Object Node     In/Out     PStart     PStop
DELETE STATEMENT Optimizer Mode=FIRST_ROWS          55 K          50402                     
DELETE     MATERIAL_TABLE                                   
INDEX RANGE SCAN     MATERIALTABLE_INDX     55 K     4 M     378           
TABLE ACCESS BY INDEX ROWID     MATERIALS     1      66      2           
INDEX UNIQUE SCAN     MATERIALS_INDX     1           1
MATERIALTABLE_INDX & MATERIALS_INDX are not PRIMARY KEYs.
Edited by: user578671 on Nov 13, 2008 3:38 PM

Answer 1

The optimizer has got two choices for this plan (once it has fetched the material_id): access by index, or full table scan. Your plan shows it is using the index, which for 1M rows from 280M (0.36%) is probably the right choice.
However to ensure it is the right choice you should make sure the optimizer has as much information as possible. Have you collected system stats recently? Have you collected table stats recently? The optimiser thinks it will find 55K rows via the index, whereas you say there are 1M to delete. That estimate is therefore out by a factor of 20 which could be significant. You might try collecting a histogram on the material_table.material_id column to help the optimizer. If that doesn't give the correct cardinality estimate, you may also want to try splitting the "SELECT material_id FROM materials..." into a separate statement to capture the material_id into a variable, then use that variable in the DELETE so that the optimizer can do bind peeking for an accurate cardinality estimate.
If after all this the plan is the same, then (as Justin says) you need to find out what it's waiting on. For example an unindexed FK might be doing a full table scan of a child table for each of the 1M rows. To do this, perform an extended trace, e.g.
ALTER SESSION SET timed_statistics=true;
ALTER SESSION SET max_dump_file_size=unlimited;
ALTER SESSION SET tracefile_identifier='DELETE';
ALTER SESSION SET EVENTS '10046 trace name context forever, level 8';
<run DELETE here>
ALTER SESSION SET EVENTS '10046 trace name context off';
<terminate session>Then use a tool like OraSRP to process the results and find out the biggest waits (and whether any other SQL statements are being run in the background - as a result of FKs, triggers, etc).