| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: re Rebuilding Indexes in Oracle Apps -- was RE: RE: Separate
Correction. Paragraph 4 should begin, "I agree though that index rebuilds
are often unnecessary."
Mike
-----Original Message-----
Sent: 16 October 2003 15:20
To: 'ORACLE-L_at_fatcity.com'
All of that is fair enough but the number of rows and the values you've chosen fit the point you wished to prove. The value "5" conveniently fits the range for an existing leaf block with empty space.
The facts as I understand them are this :
Index space freed by deleted entries can be reused ( by subsequent
transactions ) so long as the indexed value 'belongs' in the leaf block
which has free space.
Index leaf blocks are only placed back on the free list when they are empty
of entries.
This means that given a constantly incrementing index value no free space will be reused unless whole index blocks are emptied by deletes. This is fine for working tables which are constantly filled and (totally) emptied but it can lead to large indexes for tables which preserve small amounts os data across the range of keys. Such monotonically increasing key values are pretty common in my experience.
I agree though that index rebuilds are often necessary. For a while now we've had useful commands like coalesce that could combine logically adjacent, sparsely populated leaf blocks at far less cost than a rebuild.
Regards,
Mike Hately
-----Original Message-----
Sent: 16 October 2003 14:29
To: Multiple recipients of list ORACLE-L
Hi Rafiq,
I haven't been receiving all the mail from this list so I don't know the full thread and it doesn't appear a mail I sent a few days ago regarding all this ever made it so I could be wasting my time again. But everytime I see comments as in the above, a voice in my head says "do something, do something". So I'll try again.
Having lots of deletes and inserts of course doesn't necessarily mean fragmentation. These so-called holes are fully re-usable and in the vast majority of cases results in no substantial issues. Having lots of deletes, inserts and updates rarely requires the index to be rebuilt.
Simple little demo for any newbies or those force-fed Oracle myths since child birth ...
<demo snipped on space grounds - Mike Hately>
With few exceptions (the key is picking those rare cases), index rebuilds are redundant, wasteful and can actually be "detrimental" to performance.
Cheers
Richard
You agree that you have read and understood this disclaimer and you agree to be bound by its terms.
The information contained in this e-mail and any files transmitted with it (if any) are confidential and intended for the addressee only. If you have received this e-mail in error please notify the originator.
This e-mail and any attachments have been scanned for certain viruses prior to sending but CE Electric UK Funding Company nor any of its associated companies from whom this e-mail originates shall be liable for any losses as a result of any viruses being passed on.
No warranty of any kind is given in respect of any information contained in this e-mail and you should be aware that that it might be incomplete, out of date or incorrect. It is therefore essential that you verify all such information with us before placing any reliance upon it.
CE Electric UK Funding Company
Lloyds Court
78 Grey Street
Newcastle upon Tyne
NE1 6AF
Registered in England and Wales: Number 3476201
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Hately, Mike (LogicaCMG)
INET: mike.hately_at_nedl.co.uk
Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services ---------------------------------------------------------------------To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). Received on Thu Oct 16 2003 - 12:19:37 CDT
 |
 |