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?
HoggZillaConnect With a Mentor Commented:
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
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."
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.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.