Being pro-active, and using one of the various tracing capabilities of SQL Server, is one of the best ways to keep track of what is going on in your SQL Server and what might be causing performance problems. But does that mean if you haven’t set up any tracing, there is nothing you can do to find out what problematic queries might be running? The answer is no.
In this session, we’ll explore SQL Server’s plan cache, from the way it is managed in memory, to the tools and techniques for discovering what plans are in cache, how long they’ve been there, and how often they’ve been run. Knowing what’s happened is the first step in knowing what needs to be fixed.