on November 5, 2009
SQLPass unfortunately can’t last forever, but happily it’s still going strong. Here’s some highlights from my Day #2.
Paul Randal Knows Exactly What’s Going on in Your Transaction Log…
A definite highlight of day 2 was attending Paul Randal’s session on Logging and Recovery in SQL Server. I’ve read Pauls' blog posts on this topic and attended his classes before, but even being familiar with the material I find I always learn something from his talks. You just can’t beat being strong on the basics!
I took a lot of notes in the session, this is my favorite excerpt from my notes:
- SQL Server must reserve space in the TLOG so that it can roll back the active transactions, if needed.
- Once a VLF no longer contains log records that are required, it can be cleared
- This is done by a log backup in full or bulk_logged recovery models, or by checkpiont in simple
- All that happens when a VLF is “cleared” is that it is marked as inactive
- Nothing is cleared at that time
- Nothing is truncated
- Nothing is overwritten
- The log file size does not change
- The only thing that happens is that whole VLFs are marked inactive if possible (no active transactions)
Ben Nevarz asks, “How You Doing, Optimizer?”
One of my favorite pieces of information on day 2 was in Ben Nevarez’s talk on how the query optimizer works. He mentioned this DMV, which I hadn’t used before yesterday:
Sys.dm_exec_query_optimizer_info ←_Check me out!_
The other useful bit of info is that the timeout flag is recorded in the xml for the sql plans, so plans which the optimizer finds so complicated that it times out on compilation can be queried from the cache!
SQLPASS homework assignment: Write and test this query, determine how to automate running it and collecting the information.
Sample Queries
This sample from BOL to find excessive compiles/recompiles:
select *
from sys.dm_exec_query_optimizer_info
where counter = 'optimizations'
or counter = 'elapsed time'
See Also…
Ben Nevarez on the Phases of Query Optimization
Conor Cunningham’s Blog on sys.dm_exec_query_optimizer_info– excerpt:
The other use of the DMV is to get a good statistical picture of a running system. Say that I’m a DBA and I want to know how many queries in my application have hints or need hints to work well. Well, this will tell you. Granted, it doesn’t separate recompiles from compiles, and if you have a system where plans are getting kicked out of the cache things may be a bit skewed, but I can tell you that this is far better than simply guessing. Often the DB application developer doesn’t realize that they’ve built an application that requires a lot of hinting or a lot of compilations, and you can see this in more detail than you get with the performance counters"