Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 1234»»»

Fill factors, index fragmentation and indexing strategy Expand / Collapse
Author
Message
Posted Wednesday, October 15, 2008 11:39 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Thursday, July 10, 2014 4:13 AM
Points: 1,860, Visits: 3,597
I need to confirm whether my understanding with regards to fill factors and index fragmentation is correct in the following scenario.

I have a table of about 300,000 rows that looks like this:

Column
---------
AID (INT - Identity column, monotonically increasing - also the PK)
FKID (INT - foreign-key column)
Dt (DATETIME)

The PK is clustered.

The table is truncated and re-populated from scratch according to a daily schedule.

I want to create non-clustered indexes on the FKID and DT columns.

My question is:
do I need to worry about specifying a fill factor for the non-clustered indexes? My feeling is that I don't need a fill factor, since the data is entered one row at a time in the table, so there should be no random inserts into the pages of the non-clustered indexes.

Can someone pls confirm?


__________________________________________________________________________________

Turbocharge Your Database Maintenance With Service Broker: Part 2
Turbocharge Your Database Maintenance With Service Broker: Part 1
Real-Time Tracking of Tempdb Utilization Through Reporting Services
Monitoring Database Blocking Through SCOM 2007 Custom Rules and Alerts
Preparing for the Unthinkable - a Disaster/Recovery Implementation
Post #586408
Posted Wednesday, October 15, 2008 12:15 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 7:32 AM
Points: 7,115, Visits: 14,985
You might worry about it if the columns making up the key change a lot. in a similar way to why you worry about fill factor for clustered indexes, data movement in those columns would cause the index to fragment if there isn't enough room to accomodate the change.

Of course - it's not as "bad" as a page split in the clustered index, but still - might be worth considering some amount of slack.

Specify it exactly like you would on a clustered index.

create index ix_jr09 on job20080930(rowID) include (msg) WITH FILLFACTOR=80



----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
Post #586440
Posted Wednesday, October 15, 2008 12:19 PM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Thursday, July 10, 2014 4:13 AM
Points: 1,860, Visits: 3,597
Matt Miller (10/15/2008)
You might worry about it if the columns making up the key change a lot. in a similar way to why you worry about fill factor for clustered indexes, data movement in those columns would cause the index to fragment if there isn't enough room to accomodate the change.

Of course - it's not as "bad" as a page split in the clustered index, but still - might be worth considering some amount of slack.

Specify it exactly like you would on a clustered index.

create index ix_jr09 on job20080930(rowID) include (msg) WITH FILLFACTOR=80



Thanks for responding.

In this case we are not doing any updates, just a straight TRUNCATE of the table and INSERT of new data. Also, the clustered index is set on the identity column, so there should be no random inserts.


__________________________________________________________________________________

Turbocharge Your Database Maintenance With Service Broker: Part 2
Turbocharge Your Database Maintenance With Service Broker: Part 1
Real-Time Tracking of Tempdb Utilization Through Reporting Services
Monitoring Database Blocking Through SCOM 2007 Custom Rules and Alerts
Preparing for the Unthinkable - a Disaster/Recovery Implementation
Post #586444
Posted Wednesday, October 15, 2008 7:20 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Yesterday @ 11:19 PM
Points: 36,724, Visits: 31,173
In that case, I'd use a FILL Factor of 100 for that tiny bit more speed on any SELECTS you may do on the table.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #586674
Posted Wednesday, October 15, 2008 9:25 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 7:32 AM
Points: 7,115, Visits: 14,985
Jeff Moden (10/15/2008)
In that case, I'd use a FILL Factor of 100 for that tiny bit more speed on any SELECTS you may do on the table.


True - but that assumes a "single load" scenario, where the table is essentially recreated "from scratch" and then left alone afterwards. That also entails dropping the non-clustered's before the truncate and recreating the indexes once the insert has happened. That may well fit your scenario.

If you plan on leaving the indexes in place (or if the indexes happen over a prolonged stretch of time), you'd still need a fill factor <100.


----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
Post #586689
Posted Wednesday, October 15, 2008 9:48 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Yesterday @ 11:19 PM
Points: 36,724, Visits: 31,173
Matt Miller (10/15/2008)
Jeff Moden (10/15/2008)
In that case, I'd use a FILL Factor of 100 for that tiny bit more speed on any SELECTS you may do on the table.


True - but that assumes a "single load" scenario, where the table is essentially recreated "from scratch" and then left alone afterwards. That also entails dropping the non-clustered's before the truncate and recreating the indexes once the insert has happened. That may well fit your scenario.

If you plan on leaving the indexes in place (or if the indexes happen over a prolonged stretch of time), you'd still need a fill factor <100.


No... :) it assumes a clustered PK on the IDENTITY column (like the OP said) which will keep things just as tidy as a single load.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #586698
Posted Wednesday, October 15, 2008 9:51 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 7:32 AM
Points: 7,115, Visits: 14,985
Jeff Moden (10/15/2008)
Matt Miller (10/15/2008)
Jeff Moden (10/15/2008)
In that case, I'd use a FILL Factor of 100 for that tiny bit more speed on any SELECTS you may do on the table.


True - but that assumes a "single load" scenario, where the table is essentially recreated "from scratch" and then left alone afterwards. That also entails dropping the non-clustered's before the truncate and recreating the indexes once the insert has happened. That may well fit your scenario.

If you plan on leaving the indexes in place (or if the indexes happen over a prolonged stretch of time), you'd still need a fill factor <100.


No... it assumes a clustered PK on the IDENTITY column (like the OP said) which will keep things just as tidy as a single load.


I understand that keeps the CLUSTERED index tidy - but how does that help the NON-Clustered indexes (and their fill factors). OP was asking about the fill factor of the NCI's (which would fragment if present on load of the data)


----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
Post #586700
Posted Wednesday, October 15, 2008 9:58 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Yesterday @ 11:19 PM
Points: 36,724, Visits: 31,173
Sorry... the day's coffee is wearing off. :) I didn't read all of your last...

You're correct. Since the rows are going to be added on a onesy basis, there could be some pretty nasty fragmentation at FILL FACTOR 100 on the non-clustered indexes. I don't believe even an 80 FILL FACTOR would help there. Might want to go as low as, say, 60 as a guess. Best thing to do would be to find out what an average day of inserts looks like and calculate a FILL FACTOR to support the inserts.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #586702
Posted Thursday, October 16, 2008 4:10 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Thursday, July 10, 2014 4:13 AM
Points: 1,860, Visits: 3,597
Thank you both for your replies.

I'm not sure I follow though. How would the non-clustered indexes get fragmented? The table population is done all at once, in a sequential fashion by the clustered PK. Wouldn't the non-clustered-index pages be also filled sequentially in a "from-top-to-bottom" fashion?

There should be no page splits in this scenario.


__________________________________________________________________________________

Turbocharge Your Database Maintenance With Service Broker: Part 2
Turbocharge Your Database Maintenance With Service Broker: Part 1
Real-Time Tracking of Tempdb Utilization Through Reporting Services
Monitoring Database Blocking Through SCOM 2007 Custom Rules and Alerts
Preparing for the Unthinkable - a Disaster/Recovery Implementation
Post #586820
Posted Thursday, October 16, 2008 7:53 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 7:32 AM
Points: 7,115, Visits: 14,985
Marios Philippopoulos (10/16/2008)
Thank you both for your replies.

I'm not sure I follow though. How would the non-clustered indexes get fragmented? The table population is done all at once, in a sequential fashion by the clustered PK. Wouldn't the non-clustered-index pages be also filled sequentially in a "from-top-to-bottom" fashion?

There should be no page splits in this scenario.


The page inserts are sequential for the clustered index only. Since you're using other columns in the non-clustered indexes, it would be a "random insert" scenario on those indexes, unless the key column in the non-clustered index also happen to follow EXACTLY the same ordering as the ID (which would be rather unusual).

Since you're doing a single load, your best bet is to actually then drop all non-clustered indexes before the load, and rebuild them from scratch when the load is done. In which case - load them as Jeff was recommending (100% fill factor, since there will be NO fragmentation).


----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
Post #586982
« Prev Topic | Next Topic »

Add to briefcase 1234»»»

Permissions Expand / Collapse