SQLServer v2005, rebuild or re-organise index is not lowering fragmentation


I've made up a new SQLServer db with about 95% of our production data as a test. I then dropped all the records and then filled the tables again with 100% of our data. The db seems fine.

I thought I'd look at the index frag because of the record drop and re-add and it was high in a few tables, >70%. I tried to do a rebuild and a re-organise but the frag level is same. These are primary keys, non-clustered.

I noticed the fragmentation is high only on the tables with not many records, < ~1000, and the frag on table with many records, > 50000, is fine, like about 0.2%. So are tables with not many records likely to have high frag?

I've tried rebuild and reorder in the SMSS (right click on index, rebuild) and also in code:
     ALTER INDEX ALL ON [dbo].[log_GRSPN]
        REBUILD WITH (
               PAD_INDEX  = OFF,
              ALLOW_ROW_LOCKS  = ON,
              ALLOW_PAGE_LOCKS  = ON,
              SORT_IN_TEMPDB = OFF,
              ONLINE = OFF )

Ideas ?
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Steve HoggITCommented:
I reccomend you drop and recreate the indexes in question.
LukeBAuthor Commented:
Hi Hogg

see SSIS help:


it specifically recommends against doing that ...
"You can also rebuild an index by first dropping the index with the DROP INDEX statement and re-creating it with a separate CREATE INDEX statement. Performing these operations as separate statements has several disadvantages, and we do not recommend this."
Steve HoggITCommented:
I do realize it is not the first choice, but if the rebuild is not accomplishing your task? How about this, your options are limited to just a few.
Pros: Rebuilds index in one step which is good for clustered indexes, as it means that non-clustered indexes do not need to be rebuilt. Can be used to recreate (and thereby defragment) indexes created by constraints, if the index definition matches the requirements of the constraint.
Cons: Potential blocking problems with other processes in the same way as for drop and recreate index above

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
LukeBAuthor Commented:
ok, I tried that, the frag level has gone from 80% to 55% ...
This table has a 2 field PK index, nonclusted, unique. The table has 5300 records. The 2 fields are HoleID (varchar(7)) and RunNumber(tinyint) which are unique when in combination. There are also many other fields in the table, non of which are indexed and do not need to be (v rarely searched on)
The code I used, per Hogg suggestion is :

     CREATE UNIQUE INDEX aa_tblGeophyx
     ON [dbo].[log_GRSPN]  (HoleID, RunNumber)
which got it down to 55%. So better but still high.
This is a parent table with a related table, log_GRSPN]_data , which has 26.9 mil records. Referential integrity is setup per SQLServer v2005, i.,e. not using triggers. This related table has 0.2% frag.

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft SQL Server 2005

From novice to tech pro — start learning today.