First thing is find out if the problem is CPU, I/O, Network related, etc…

What are your average disk queue lengths sitting at?
high, you have a disk I/O bottle neck (controller, slow disk, bad filegroup layout, etc…)

What are your CPU averages? Over 70%
Bad index, etc…

What type of locking hints are you using in your queries? Is something blocking/dead locking you? Try sp_who2 stored procedure and look at the DBCC INPUTBUFFER({spid}) here.

You never mentioned anything about the disk setup. Usually a DB has issue with I/O before CPU depending upon the type of system it is. Now if I was talking about a web server… I would probalby be more concerned about CPU.

If you have chance, backup your database then shrink your transaction log as small as possible while there is no activity then resize it to a proper size to remove fragmentation of the virtual log files and set the autogrow figure to a sensible size.

And a quick sp_who active followed by slightly less quick Profiler run tend to be helpful.

Your transaction log should be getting truncated if it’s getting backed up as part of the maintenance plan. If it hasn’t happened in a while or for some other reason got really big, you need to shrink it (see dbcc shrinkfile).

Problem #2 we have a better handle on. Steve was exactly right: The transaction log was autogrowing and that process was blocking all queries for a full minute. It seems that there is some issue with the auto-truncation of that log, so it’s growing forever. It takes a while to grow a 50GB file.

Hopefully the dump-to-file solution will resolve the flogger DB problem and both these will be behind us.

Regarding your first problem, are you seeing a substantial change in your SQL Server buffer pool size during the connection lock? What connection authentication mechanism are you using? Are you using SQL Server connection pooling?

The second indicates that you’re definitely blocking on something. There are a couple of things that can cause this to happen. The first is a lock that goes way out of scope, which you should be able to track with the profiler or the lock management views. The second is if you’re not managing an autogrow tranlog file and the OS is slow at allocating new volume space. The last is a bad IO drivers, which were common on some of last year’s HP servers if that’s appropriate to you.

Was talking to DB administrator friend of mine about your problem and he had few suggestion for you.

He said to make sure you’re caching SQL connections. Managing new connections, login, authentication and security is very expensive – your SQL box has better things to do then overhead. By making a new connection per query or request, you’re treating SQL as if it were IIS, which its not – you want to take advantage of SQL connection pools

He does say that you CAN use IIS as a proxy to SQL Server, and that might help.

As for your query problems, he says he’d have to look at it, but if you want he said I can pass along his email.