Fragmentation effect

Question

10g R2
Table has about 0.5 billion records at this time
There is a process deleting records (5-6 millions per day)
At the beginning of process there is a select getting min date (indexed column) to start from.
I see this select taking more time - plus about 1 min each day (surprise).
I tried shrink but canceled execution in a couple of hours. Based on previous discussions looks like it never completed on large tables.
What other people really do in such cases besides full table reorganization?
Thanks.

Answer 1

Bolev wrote:
10g R2
Table has about 0.5 billion records at this time
There is a process deleting records (5-6 millions per day)
At the beginning of process there is a select getting min date (indexed column) to start from.
I see this select taking more time - plus about 1 min each day (surprise). This looks as if your query for min(adate) is having to walk through increasing numbers of empty blocks each day. I'm going to guess that you then delete data for a given date range above that date - leaving even more empty blocks at the low end of the index. If this is the case, a "coalesce" might be more appropriate than a shrink. This may take some time on the first run, but it operates as a large number of small transactions so won't have to unwind itself if the process crashes.
Since you are inserting 0.5 M rows per day and deleting 5-6M rows per day for a net loss of 4.5 - 5.5 M rows per day, at some stage it will probably make sense to rebuild most of the indexes, and at some stage it will probably make sense to "move" the table (and rebulid the indexes again).
Regards
Jonathan Lewis