January 22, 2013 at 1:03 pm
LAW1143 (1/22/2013)
might this have anything to do with the datatypes of the index columns?
No. Nothing strange about bigint columns.
Just checking... You are rebuilding the same index that you're checking (same table, same database, same server)? Not trying to be insulting, but I've seen many times people working on different servers without realising.
Can you post the table and index definitions?
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
January 22, 2013 at 1:48 pm
The highlighted index is the one we're dealing with...
and I'm not above making stupid mistakes... in fact, I usually dont recognize them as such untill I post here or ask someone else to explain something that doesnt make sense...
I just double (er, triple) checked, and im looking at the right server, db, table, index statistics as the one im rebuilding...
thanks again for your time and help! 🙂
January 22, 2013 at 2:39 pm
Final update of the day from me... my brain hurts and im going home...
I just did a Alter Index ALL on this table to see what came of it...
Index_id 11 is my problem child:
index_idavg_fragmentation_in_percent
10.179520838203473
20.532145960034752
40.518418036320809
1193.7920077651411
160.89879248101581
:crazy:
January 23, 2013 at 7:34 am
I did a quick comparison against a few other databases (of varying sizes) with the same table/index definitions and found similar results..
short term, I'll just exclude this from the automated indexing routine i am working up, but I'd still like to understand why this index is so fragmented, even immediately after a rebuild.
thanks again for everyone's help and time!: )
Viewing 4 posts - 16 through 18 (of 18 total)
You must be logged in to reply to this topic. Login to reply