Because when looking for the MIN of a value, Oracle can generally use the index via the index full scan min/max access method to find the first leaf block and hence find the minimum value. However, if this block contains nothing but empty index entries, it has to keep looking and so hops across to the second leaf block and so on and so on until it finds the first non-deleted value. If you delete 90% of index entries and they’re all on the “left hand” of the index, you might need to access 90% of the entire index, a single block read at a time to find the min value (maybe 1000s of LIOs) when previously it found it straight away. Hence, it’s an example of performance being much worse than previously.

BETTER:
If the retrieved data required the use of index blocks that have been affected by the delete, the performance will be better because you do not have access to the corresponding blocks of the table.

Note that the index blocks will be taken to buffer cache anyway, even if empty.

WORSE:
After the cancellation of 90% of the data(and recalculation of the statistics), if the clustering factor is high (for high, I mean a number very close to the number of rows in the table), the optimizer might choose a table scan and then read up to HWM, which means reading all blocks, even those subjected to delete (if you’re not taking Reorg).

Regards,

Donatello Settembrino

thanks
kc

SAME: If the table is small, then would the delete not have put the modified blocks into the buffer cache? Plus the index would have been read during the DELETE and would also reside in the buffer cache. Therefore not performing any other modifications to the table or the index, the performance difference would be so dramatically small as to be un-noticeable (is this how we are measuring the performance?).

WORSE: If the table or index is large (maybe too large to fit in the buffer cache or gets aged out almost immediately), then we start talking about physical reads on the table or index and I can’t think that hard but I think the others have nailed it when they talk about traversals and differing index methods.

BETTER: The performance would be better if you have a partitioned index/table and you delete the records 90% of which happen to be in one partition. The range scan will have significantly less work to do as the other partition(s) would have been dropped (??).

If I delete 90% of my rows, then performance of the queries is based on following scenarios –

1. If query is doing range scan, then there will not be any impact. Only thing here is if after rebuild, blevel of the index reduces then I have to do one less IO.
2. If query is doing Index Full/Fast Full scan, then there will be huge impact on the query.
3. My full Table scan will impact. This is not related to index rebuild but I have to do table reorg as well.

Thanks

Nilesh Rajapurkar

Another example of worse is the High water mark of the table. FULL table scans will be of a high cost if nothing is done on the table and the deleted space keep empty and not inserted again.

But if we shrink the table to set its High Water Mark, we might damage the Clustering Factor of the indexes and hence decrease their desirability by the CBO.

Finally it’s all about the delete pattern and how the rows are scattered through the table indexes and the effect this delete will have on this data scattering

Best regards

Mohamed Houri

1. does the result set of the range scan changed so much or almost no change.
2. does the range scan followed by a index filter or table filter.
3. does the range scan followed by a stop key by count.

a. If the predicates is nearly unique, the range scan performance will remain unchanged or will have a minor improvement(by eliminate the leaf block or table block scan).
b. If the result set is based on a stop key by count, and there are so many rows map this predicates, the scan performance may be will degrade.
c. If the result set will be significantly decreased, then the scan performance will be improved significantly.