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

Indexes on tables with a high churn rate Expand / Collapse
Author
Message
Posted Monday, September 16, 2013 7:53 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, July 7, 2014 2:16 AM
Points: 3, Visits: 55
Are there any recommendations for indexing a table with a very high churn rate?

I have a table (in an inherited DB) that is basically used for processing temporary data.

There is a service constantly running that populates this table (200,000-400,000 inserts per day).
There are a number of services running that retrieve and use the data. They flag the data as processed. (200,000-400,000 updates per day).
There is also an additional service that deletes old processed data from the table. (200,000-400,000 deletes per day).

There are indexes on the table but because of the high data churn rate, they are always completely fragmented. They are probably causing more harm than good.

So are there any recommendations for indexing on tables with such high insert, update, delete and read activity?
Post #1495090
Posted Monday, September 16, 2013 8:58 AM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Yesterday @ 6:30 PM
Points: 15,518, Visits: 27,900
The most important thing I would suggest is monitoring how the statistics are maintained. Likely it's just the automatic update. Depending on the type of data, how it's stored in the indexes, etc., this may be grossly inadequate. You may need to do a full scan on your own on a regular basis.

As to the fragmentation of the indexes, unless you're running enterprise and can do an online rebuild of the indexes, I don't think you have much choice around that. Even a fragmented index can be helpful and fragmentation isn't always a big deal. Measure performance before and after a defrag to see exactly how much impact you might be suffering from.


----------------------------------------------------
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood..." Theodore Roosevelt
The Scary DBA
Author of: SQL Server 2012 Query Performance Tuning
SQL Server 2008 Query Performance Tuning Distilled
and
SQL Server Execution Plans

Product Evangelist for Red Gate Software
Post #1495139
Posted Tuesday, September 17, 2013 1:53 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, July 7, 2014 2:16 AM
Points: 3, Visits: 55
thanks for the feedback. I will try that.
Post #1495393
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse