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.Contact the Author | Contact DCAC
|Published On: 2007-10-29||By: Denny Cherry|
|Published On: 2007-10-25||By: Denny Cherry|
My next tip on SQL Server Statistics has been published on SearchSQLServer.com entitled Update SQL Server table statistics for performance kick.Contact the Author | Contact DCAC
|Published On: 2007-10-24||By: Denny Cherry|
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*/
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.Contact the Author | Contact DCAC
|Published On: 2007-10-22||By: Denny Cherry|
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.
DennyContact the Author | Contact DCAC