This is the 4th in a series of posts about query plans.  The first post covered what a query plan is and how to read it.  The second post described the effort required to make a query plan.  The third entry explained how the plans are stored in a cache to be reused.  This post will cover how the optimizer is able to quickly determine whether a plan in the cache exists for any given query. When a query is executed the database engine quickly creates a hash of the query code.  This hash is called a query handle.  The engine then compares this handle to a listRead More →

This is the 3rd in a series of posts about query plans.  The first post covered what a query plan is and how to read it.  The second post described the effort required to make a query plan.  This post will cover the plan cache. If your server is running SQL Server 2016+ and you have enabled query store please STOP READING this post.  Seriously.  Query store changes and supersedes much of the information in this post.  Instead, read about query store from the expert herself, Erin Stellato. The plan cache is a list of query plans that have been compiled by the optimizer andRead More →

The previous post in this series introduced the idea of query execution plans.  These plans are compiled by the SQL Server optimizer when a query is executed in an effort to decide an efficient manner in which to execute a query.  This compilation takes time and effort beyond that of actually running the query.  While most compilation effort is relatively small, at times it can be significant and be an impetus to query performance.  In this post we’ll offer methods to measure that time and effort. The demos below utilize the WideWorldImporters DB that can be downloaded for free. To follow along open SSMS, create a new queryRead More →

This post will serve as the first in a series of posts about query execution plans.  In this entry the goal is simply to understand that query execution plans exist, why they exist, and how to do basic navigation of them in SSMS. Every time a query is executed on a SQL Server instance the server must decide how best to find the necessary data to be retrieved or modified.  It’s not as simple as going to a table and returning rows.  A table may have multiple indexes and the decision must be made about which, if any, is appropriate for this query.  There mightRead More →

I was working on a project this week and stumbled across an issue I hadn’t seen before. The programmer had written stored procedures for every possible CRUD operation as well as all reporting requirements. Security was controlled by granting EXECUTE permissions only to appropriate stored procedures and by explicitly not granting permission to any tables or views within the database. One of the procedures was getting a bad query plan and timing out. This is when I was called in. The procedure was performing a search based on an unknown number of up to 10 search parameters. The code was filled with many AND/OR combinationsRead More →

Trace flag 1117 is a setting that is often misunderstood.  When enabled it forces any file growth event on a data file to include all data files in the same file group so that the files can remain the same size.  I usually hear it described as a setting that changes how TempDB files are treated as they need to grow. While true, what is interesting is that this is more of a side effect of the flag.  The trace flag is not TempDB specific and affects all databases on a SQL Server instance that have more than 1 file in any file group andRead More →

Even the most green DBAs know that indexes are a good thing.  A database won’t run well without them.  But it is important to remember that indexes aren’t free.  They have to be created, stored, backed up, consistency checked, updated, defragmented, and have their statistics updated.  That’s a lot of work!  This extra work associated with indexes is sometimes called the “write penalty”.  It is why having too many indexes can be just as bad as not having enough. The goal of the DBA should be to have as many high-value indexes — indexes that will be used often by the workload — as possibleRead More →

In this entry I am going to cover a handful of common myths and misconceptions about how SQL Server handles memory.  Each of these comes from repeated instances of confusion in my dealings with other SQL Server users.  Many of these have come up from even very seasoned DBAs so don’t feel bad if you’ve been laboring under a misconception yourself. The Myth: I logged in and found my SQL Server is running at 95% memory utilization.  I restarted the box which fixed it temporarily, but it grew and grew right back to 95% within a few hours!!  SQL Server must have a memory leak!Read More →

There are a few reasons that one might need to restore a SQL Server backup.  Perhaps it is time to refresh a test database with a copy from production. Maybe there has been a disaster and this is how the disaster recovery plan is getting the system back online.  Another common restore reason is to recover a single data element that was removed or modified in production by accident.  Whatever the reason, being able to restore a database and understanding some of the basic options thereof is an essential skill for the SQL Server DBA. For this demo I will cover the topic using theRead More →

Thank you to those of you that came to see my presentation on full text indexes at SQL Saturday #615 in Baltimore!  As promised, please find the slide deck and table builder/ sample queries script at these links.  Also, I have included a few links to useful Microsoft documentation pages below to help you continue to expand your knowledge. CONTAINS FUNCTION FREETEXT FUNCTION FULL TEXT EXAMPLE LIST A few notes: I received an explanation for the strange query plan functionality I showed at the end of the class.  It turns out I was 100% wrong.  The plan was showing just fine and will show aRead More →