If you have ever seen the BACKUPTHREAD wait type in the sysprocesses table or sp_who2 output and wondered what it is, I have found the answer.
The basic explanation is “Used when waiting for a backup thread to complete. Wait time may be very long (minutes, hours).” Basically what this means is that there is a backup running and something is waiting for it to complete.
When i saw this show up I was running a restore. That restore had three entries in the sysprocesses table. The first was the main kpid, with two child kpids. The parent kpid was the wait type of BACKUPTHREAD while it was waiting for the child kpid to finish processing. In my case the wait time was short, and it seamed to switch from this wait type to an IO wait type.
Service Broker is a transaction message queueing system build into Microsoft SQL Server. It provides you with in order, guaranteed single read, message processing that is handled and managed with T/SQL code. This makes it extremely easy to send and process messages either within a single database, or send those messages to a remote database on another server for processing. Messages are sent as XML documents so a message payload can contain a single field of data or a multiple row record set as a single message.
For those familiar with Microsoft Message Queue you will find that Service Broker is very similar to MSMQ but is native to the Microsoft SQL Server.
Server Broker can route messages from database to database, or server to server. Messages can be processed or routed to another server for processing there. Queues can be setup to hold messages for processing by an application or job, or have the messages processed as soon as they arrive by an activation procedure which is simply a procedure which is fired as messages arrive. Activation procedures can be run as a single thread or several threads pulling from the same queue at once.
Look for a future blog posting on configuring and using the service broker to send and process messages.
Take your XML execution plan and save it to a file with a file extension of sqlplan (such as MyQuery.sqlplan) and double click on it. It will open in the SQL Server Management Studio and show you the plan in the GUI plan viewer making it much easier to read than the XML version.
My next tip on SQL Server Statistics has been published on SearchSQLServer.com entitled Update SQL Server table statistics for performance kick.
I’ve published this before over on tek-tips.com, but I figured that I’d republish it here as well. I’ve written an update for sp_who2 which I call sp_who3. It can be most useful when trying to diagnose slow running queries as it can provide a wealth of information in a single screen.
exec sp_who3 active
exec sp_who3 blocked
exec sp_who3 72 /*Any active spid*/
Download: SQL 7 / SQL 2000 / SQL 2005
When using no parameter the output will match the output of sp_who2.
When using the “active” keyword the output will match the output of sp_who2 active.
When using the “blocked” keyword the output will have the same columns as sp_who3 active but show only the blocking and blocked processes.
There are two main types of cache which SQL Server deals with, the buffer cache and the procedure cache. The procedure cache is where the execution plans for procedures and queries are stored. The buffer cache is where the actual data is cached so that SQL Server doesn’t have to go to disk to get often accessed data.
The version of SQL Server that you are running will determine how SQL calculates the maximum size of the procedure cache.
SQL 2000 – 50% of the memory or 1 Gig which ever is lower
SQL 2005 RTM to SP1 – 75% of the first 8 Gigs of RAM + 50% of the next 56 Gigs of RAM + 25% of the ram over 64 Gigs.
SQL 2005 SP2 and up – 75% of the first 4 Gigs of RAM + 10% of the ram over 4 Gigs
As I understand the reason for the change the original settings were causing SQL Server to lockup for some customers as not enough RAM was left over for the buffer cache.
If you are using SQL 2005 in a Win32 platform these calculations change again as the procedure cache must remain within the first 2 Gigs of memory giving you a max of 2 Gigs of procedure cache no matter how much memory you install.
Bob Ward of Microsoft has written an excellent blog about the lock pages is memory right over on the PSS blog.
I know that there is some confusion about what exactly the minimum server memory setting in sp_configure actually does. When I was at PASS I was able to ask the Microsoft guys this very question and here is what they told me.
The setting does not control how much memory SQL takes when it starts up. What it controls is a low watermark as to how much memory SQL will keep.
For example if you have 2 Gigs of memory installed, and a min memory setting on 1024 MB and a max memory setting of 1536 MB and Windows starts telling SQL that it needs more memory SQL will give the memory back until it hits the 1024 MB lower limit. Once it hits that limit it will no longer give memory back to Windows.
I’ve submitted a request to Microsoft (via the Connect site) to have them improve the error reporting which the Service Broker does to the error log. If everyone could vote for that submission (https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=304785) it would go a long way towards getting it included in a future build of SQL Server.
While waiting for an index to be created I ran across this little beauty over at http://xkcd.com. I just had to share it.