Comments on: How to make Microsoft SQL Server cry like a baby http://programmerjoe.com/2007/11/24/how-to-make-microsoft-sql-server-cry-like-a-baby/ Whats with all the screaming? Fri, 05 Sep 2008 18:47:56 +0000 http://wordpress.org/?v=2.2.3 By: Joe http://programmerjoe.com/2007/11/24/how-to-make-microsoft-sql-server-cry-like-a-baby/#comment-71549 Joe Tue, 11 Dec 2007 23:19:12 +0000 http://programmerjoe.com/2007/11/24/how-to-make-microsoft-sql-server-cry-like-a-baby/#comment-71549 We're running regular backups and truncating the transaction logs when they run. We just had a problem with the backups that was preventing the truncation. They're working fine now, though. We’re running regular backups and truncating the transaction logs when they run. We just had a problem with the backups that was preventing the truncation. They’re working fine now, though.

]]> By: BigRed http://programmerjoe.com/2007/11/24/how-to-make-microsoft-sql-server-cry-like-a-baby/#comment-71075 BigRed Mon, 10 Dec 2007 17:43:15 +0000 http://programmerjoe.com/2007/11/24/how-to-make-microsoft-sql-server-cry-like-a-baby/#comment-71075 You have got your recovery model set to simple or are running regular log backups aren't you? 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. You have got your recovery model set to simple or are running regular log backups aren’t you?

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.

]]> By: sidereal http://programmerjoe.com/2007/11/24/how-to-make-microsoft-sql-server-cry-like-a-baby/#comment-69950 sidereal Fri, 07 Dec 2007 02:00:08 +0000 http://programmerjoe.com/2007/11/24/how-to-make-microsoft-sql-server-cry-like-a-baby/#comment-69950 Also, as general SQL Server advice, perfmon your Current Disk Queue Length (Logical Disk), % Processor Time (Processor), Transactions/sec (SQLServer:Databases), User Connections (SQLServer:General Statistics), and Average Wait Time (SQLServer:Locks) all the time. Generally, when something starts crapping the bed you'll be able to narrow down what to look for by checking which counters go to hell. 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). Also, as general SQL Server advice, perfmon your Current Disk Queue Length (Logical Disk), % Processor Time (Processor), Transactions/sec (SQLServer:Databases), User Connections (SQLServer:General Statistics), and Average Wait Time (SQLServer:Locks) all the time. Generally, when something starts crapping the bed you’ll be able to narrow down what to look for by checking which counters go to hell.

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).

]]> By: Joe http://programmerjoe.com/2007/11/24/how-to-make-microsoft-sql-server-cry-like-a-baby/#comment-67754 Joe Sat, 01 Dec 2007 19:33:33 +0000 http://programmerjoe.com/2007/11/24/how-to-make-microsoft-sql-server-cry-like-a-baby/#comment-67754 We still aren't sure exactly what was going on with problem #1. 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. We still aren’t sure exactly what was going on with problem #1.

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.

]]> By: Steve http://programmerjoe.com/2007/11/24/how-to-make-microsoft-sql-server-cry-like-a-baby/#comment-66102 Steve Mon, 26 Nov 2007 21:31:32 +0000 http://programmerjoe.com/2007/11/24/how-to-make-microsoft-sql-server-cry-like-a-baby/#comment-66102 My friend Jeff Ward pointed me at your blog, and you should be able to get substantially better performance on that hardware then what you've described with SQL Server 2005. 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. My friend Jeff Ward pointed me at your blog, and you should be able to get substantially better performance on that hardware then what you’ve described with SQL Server 2005.

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.

]]> By: Joe http://programmerjoe.com/2007/11/24/how-to-make-microsoft-sql-server-cry-like-a-baby/#comment-66101 Joe Mon, 26 Nov 2007 21:31:23 +0000 http://programmerjoe.com/2007/11/24/how-to-make-microsoft-sql-server-cry-like-a-baby/#comment-66101 We're definitely keeping the connections open and re-using them. Each server process makes its connections at startup, queries on them a bunch of times, and closes the connection at shutdown. That's still a fair number of new connections because most zones only last 15 minutes. When there are 1500 of them that's 100 new zones per minute or 1.6 per second. Still not nearly as many as there would be if we didn't persist connections though. :) We’re definitely keeping the connections open and re-using them. Each server process makes its connections at startup, queries on them a bunch of times, and closes the connection at shutdown. That’s still a fair number of new connections because most zones only last 15 minutes. When there are 1500 of them that’s 100 new zones per minute or 1.6 per second. Still not nearly as many as there would be if we didn’t persist connections though. :)

]]> By: Jeff Ward http://programmerjoe.com/2007/11/24/how-to-make-microsoft-sql-server-cry-like-a-baby/#comment-66098 Jeff Ward Mon, 26 Nov 2007 21:26:16 +0000 http://programmerjoe.com/2007/11/24/how-to-make-microsoft-sql-server-cry-like-a-baby/#comment-66098 Hey Joe! 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. Hey Joe!

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.

]]>