SQL Server 2005 : intermittently slow Inserts

Question

I have a client app that is submitting the following command to SQL Server 2005. At a specific time of day we are having performance issues where some of the requests are taking between 2 - 8 seconds to run when the norm is below 300ms. We are researching SQL Server options as well as all external variables that can impact the server.

My question here is how/why can a request take 8 seconds and during this time many other identical requests start and finish during this 8 second window? What can be preventing the 8 second call from finishing, but not prevent or slow down the other calls?

Running server profiler during this time the number of reads are around 20 and the writes less than 5 for all (long and short durations) the calls.

The table being inserted into has around 22M records. We are keeping about 30 days worth of data. We will probably change the approach to archive this data daily and keep the daily insert table small and index free, but really want to understand what is happening here.

• There are no triggers on this table.
• There are 3 indexes for GUID, Time and WebServerName (none are clustered)

Here's the command being submitted:

exec sp_executesql N'Insert Into WebSvcLog_Duration (guid,time,webservername,systemidentity,useridentity,metricname,details,duration,eventtype)values(@guid,@time,@webservername,@systemidentity,@useridentity,@metricname,@details,@duration,@eventtype)',N'@guid nvarchar(36),@time datetime,@webservername nvarchar(10),@systemidentity nvarchar(10),@useridentity nvarchar(8),@metricname nvarchar(5),@details nvarchar(101),@duration float,@eventtype int',@guid=N'...',@time='...',@webservername=N'...',@systemidentity=N'...',@useridentity=N'...',@metricname=N'...',@details=N'...',@duration=0.0,@eventtype=1

Answer 1

The probable reason why is heap fragmentation; you didn't mention if you had some sort of index maintenance going on, so I'm assuming that it's non-existent. The best way to minimize fragmentation is to build a clustered index on a monotonic value (a column with a naturally increasing order). I'm not sure what the time column is supposed to represent, but if it's the time of insertion, then it might be a good candidate for a clustered index; if not, then I'd add a column that captures the time inserted into the table and build a clustered index on that.