Starting with SQL Server 2016 sp1 execution plans from the cache now contain “Estimated Number Of Rows to be Read”. If you are interested in how this is different from “Estimated Rows Per Execution” and how this value can help identify a performance problem in your plan read on… How does it differ from Estimated […]
Read MorePerformance implications of using DATEDIFF function in WHERE
These might be narrow cases I’m describing, but as I’ve seen it happen often enough I figured it is worth writing a post about. In this post I’ll describe two different scenarios where the DATEDIFF function caused a query to perform poorly due to DATEDIFF not being sargable. The first scenario I’ll be describing is […]
Read MorePerformance implications of using ISNULL vs IS NULL
Quite often I see queries that are not sargable due to the use of the ISNULL function in the query’s predicate (WHERE clause). If you’re not familiar with sargable it means whether or not a condition in the predicate can take advantage of an index. I won’t dive too deep into sargability here, but I’ll […]
Read MoreConnecting to a read only replica with SSMS
If you are using always on availability groups and need to connect to a read only replica, you might get the following error message in SSMS: Msg 978, Level 14, State 1, Line 1 The target database (‘Database’) is in an availability group and is currently accessible for connections when the application intent is set […]
Read MoreIndex seeks on date and CONVERT
Using functions on columns typically prevents SQL Server from being able to efficiently use an index with a seek (sargability). When it comes to DATE and DATETIME data types, there are some exceptions. A common use case I see is where a column contains a DATETIME data type; however, a query needs to look at […]
Read MoreFixing an implicit type conversion without a code change
If you have ever run into the problem of implicit type conversions you will be aware that the fix for it involves a code change or a table change. In a previous post I showed a common cause of such implicit conversions. In this post I will show a fix for this problem that does […]
Read MoreDealing With “Bad” Plans
SQL Server does the best it can to generate an efficient execution plan when a query is executed. This process can be expensive. To avoid the expense, SQL Server attempts to cache a plan once it is generated. This eliminates the need for subsequent calls to the same query to generate the plan. In an […]
Read MoreMaking Queries With Leading Wildcards Faster
Queries with leading wildcards generally are slow because they are not sargable. If by chance they pick up an index, they will usually full scan the index. Below is one example of a typical query that you might see when using a leading wildcard. SELECT * FROM CustomerAccount WHERE AccountNumber LIKE ‘%518370’ From looking at […]
Read MoreCreating a database per customer VS single database for all customers (SQL Server)
With so many applications being built as SAAS offerings, an important decision that must be made when defining the data architecture is: Should each customers’ data be in a separate database, or can a shared database (keyed by a customer identifier) be used for all customers. Pros of database per customer There’s a variety of […]
Read MoreWhat’s filling up tempdb?
If you’ve ever received an alert that tempdb was running out of space, you probably want to know what session/query is consuming tempdb. There are two ways tempdb gets consumed. User tempdb usage and system tempdb usage. User temdpb usage is related to creating and populating @table variables or #temporary tables and explicitly populating them. […]
Read More