Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> c.d.o.misc -> Re: Never rebuild Indexes?

Re: Never rebuild Indexes?

From: DA Morgan <>
Date: Mon, 05 Feb 2007 09:24:36 -0800
Message-ID: <>

Oradba Linux wrote:

> DA Morgan wrote:

>> Oradba Linux wrote:
>>> DA Morgan wrote:
>>>> Oradba Linux wrote:
>>>>> We are running a 4 node RAC on RHEL 3.0. We have a table with
>>>>> 300mil rows that has an pk index upto 12Gb and we rebuilt it it
>>>>> came down to 6g. The data into this table was loaded with
>>>>> concurrent inserts from different sessions. This table is on ASSM
>>>>> tablespace. Same thing with many other indexes.
>>>> Given it is a RAC cluster I must ask ...
>>>> What type of index?
>>> B*Tree
>>>> Does the primary key include the instance identifier?
>>> No
>>>> What performance metric indicates the rebuild is accomplishing
>>>> anything?
>>> None.
>> Then I would recommend a couple of things.
>> 1. Learn about indexing strategies for RAC. There are white papers
>> written on the subject and low on my list of index types for a RAC
>> cluster would be a normal B*Tree. Doesn't mean I wouldn't use them
>> but not my first choice due to contention.
>> 2. Same comment as above. Look for papers written by Kirk McGowan
>> who is Technical Director of Oracle's RAC Pack.
>> 3. Then my recommendation would be to push yourself back away from
>> the keyboard. Making changes without metrics generally produces changes:
>> Little else.
>> You might want to bookmark this website:
> Is there a specific paper that you have in mind. I went through the 
> website and there are only 2 papers by Kirk McGowan.
> One is about best practices and other one is RAC/ASM.

I read everything from Kirk and Eric Peterson I can get my hands on. Also look for anything written by Julian Dyke (not with Oracle) and Nitin Vengurlekar.

Daniel A. Morgan
University of Washington
(replace x with u to respond)
Puget Sound Oracle Users Group
Received on Mon Feb 05 2007 - 11:24:36 CST

Original text of this message