Poorly written queries on on-premise servers slow down the server performance.But in the case of Azure SQL database, those queries not only degrade the application performance but also cost money. When you tune queries in Azure SQL Database, you may benefit from reducing resource demands as your application might run at a lower compute size and then eventually you can reduce cost.
In any given SQL Server instance, there are likely 8 to 10 queries or stored procedures that are responsible for 80 to 90 percent of the server load. If you can identify these problem queries and tune them, you can make a significant impact on the overall performance of your database. This presentation will explain some simple techniques of tuning the queries and will demonstrate before and after performance differences.
3. everything PASS
has to offer
Free online
webinar events
Free 1-day local
training events
Local user groups
around the world
Online special
interest user groups
Business analytics
training
Get involved
Free Online Resources
Newsletters
PASS.org
Explore
4. Session
Evaluations
Submit by 5pm Friday,
November 15th to
win prizes.
Download the GuideBook App
and search: PASS Summit 2019
Follow the QR code link on session
signage
Go to PASSsummit.com
3 W A Y S T O A C C E S S
6. Agenda 1. Avoid ISNULL() in WHERE
2. When to use BETWEEN over IN
3. Implicit Conversion
4. Functions in WHERE clause
5. Derived Table
6. Table variable over Temporary table
7. DISTINCT performance impact
8. Lookup Table and Index
8. ISNULL()
ISNULL ( check_expression , replacement_value )
Return the specified value IF the expression is NULL,
otherwise return the expression.
ISNULL (check_expression , replacement_value)
SELECT ISNULL(Weight, 50)
10. ISNULL()
ISNULL() on a column in a filter condition forces table scan
Set a default value for a column
Avoid ISNULL on a column, rather use on variable and
write SQL for variable value NULL or NOT NULL
Summary
12. BETWEEN over IN
BETWEEN operator selects values within a given range.
Begin and end values are included.
IN operator allows to specify multiple values in a WHERE
clause
select * from member where member_no between 1 and 10
select * from member where member_no in (1,3,5,6,10)
16. Implicit Conversion
Occurs data types are mismatch in a WHERE or JOIN
condition
SQL Server automatically converts the data from one
data type to another.
18. Implicit Conversion
Implicit conversions can cause performance problems,
especially when there is column side conversion
happening
The data types have precedence order and the lower
precedence data type is converted to the higher
precedence data type.
It is easy to prevent such performance issues by matching
the data types
Summary
22. Functions in WHERE clause
The database engine executes a scalar and multi line table
valued function for each row returned by the query, while
table-value function only once, regardless of the number
of rows returned by the query
Consider replacing scalar function with an inline table
valued function
Using function over column ignores indexes
Prefer using function on a variable instead of a column
Summary
24. Derived Table
It's just an interim result set that can be references as if it
were a table.
A derived table is the result of using another SELECT
statement in the FROM clause of a SELECT statement.
26. Derived Table
Summary
Derived Table resides in the memory itself, it is usually
faster than Temporary tables which are created in the
Tempdb database
With the temporary tables approach, you need to have
multiple steps in your process
28. Table variable vs Temporary table
Table Variable
Can only be accessed within
the batch and scope in which
they are declared
Generally uses fewer
resources than a temporary
table
No statistics-based
recompiles
Temporary Table
Can create Indexes
Performs better with large
number of rows
Statistics-based recompiles
30. Table variable vs Temporary table
Table variable performs better for smaller set of rows
Low maintenance cost
No statistics-based recompiles
Temporary Table performs better for larger result set
Can Create Indexes and Statistics
Summary
36. Lookup Table
They are very small relative
to event-related tables
Often, they are viewed as a
simple location for pulling
the values for a drop-down
list
Good Morning everyone…Welcome to the session “Reduce cost by Tuning queries on Azure database”.
Please silence your cell phone.
Apart from SQL PASS conference, PASS offers many other things like 24 hours of PASS, PASS marathon, local user groups. Please visit PASS website for more detail.
Please submit the session evaluation by 5PM today.
Implicit conversion example
Automatic tuning feature
On-premise server
Any query running not optimally
Agenda - Start load with untuned/tuned queries
Included/not included
Agenda list
Credit database diagram
In this session, I am going to talk about how to reduce the cost of your Azure database by tuning queries. Before I walk you through my agenda, I would want to talk about how I came up with this presentation topic. I work at Datavail and we are managed database service provider. One of my DBA’s client moved to Azure and they went with very high-end premium database service tier with a lot of DTU capacity (they were paying around $8,000 per month). But they were not happy with the performance of Azure database, always complaint about it and asked my DBA to look. After spending several hours and maybe couple of days, my DBA was able to find couple queries having implicit conversion happening. Those queries were very simple but running very frequently like, more than 100 times in a minute. My DBA suggested to correct the data types for variable. Client implemented it and within a flash DTU usage came down to 10% which was hitting 100% all the time. Client observed server for few days and then lowered their database tier which was costing $1700 per month. Meaning, client started saving $6,300 per month and that is for lifetime or as long as client uses that database. This was such a simple change but very impactful and saved a lot of money and improved performance as well. That’s how I came up with this topic. Like implicit conversion, there are some other query tuning techniques which could help saving the cost and obviously improving the performance.
In this presentation, I will go over some simple query tuning techniques and will show how that makes significant difference in database performance and reduce the monthly payment. There is an automatic tuning feature available in Azure database and many people think that once you move your database to Azure, Azure takes care of everything including tuning but that is not the case. I am going to talk on scenarios which are not picked by automatic tuning feature.
Also, in traditional on-premise SQL Server, the process of setting up new server is usually start with capacity planning, then buying hardware, then purchasing license and then performance tuning afterwards. But even if you tune your database or application afterwards, since you have already paid for your hardware, you don’t save any money.
When you use SQL Azure database and with mode of paying for capacity on demand, you can tune your application to use the minimum resources needed, tuning an application can minimize resource requirements and lower monthly bills when you use the service tiers in Azure SQL Database.
Basically, any queries running on Azure or AWS and it’s not tuned or running optimally, that costs extra money. I work on many performance tuning projects and many time I interact with database developers or programmers and they think query tuning is very hard and complex, but according to me, it is not that hard, it is just an art of tuning a query in a such a way that it accesses minimum number of pages to get the data. If you look for 100 rows from a million rows table, write a query or have an index on a table in a such a way that it accesses pages belong to those 100 rows only.
Here is my agenda for today’s presentation.
First I am going to start the load on Azure database where I’ll run stored procedure uspPerformanceTesting and it has a parameter IsTuned. I am going to run this SP with IsTuned = 0 so all untuned queries will run. Once load completes, I’ll start a load again with IsTuned = 1 so all tuned queries will run. At the end if we have enough time, I’ll lower database service tier and test tuned queries again.
When load is running, I am going to talk on these scenarios and will have demo for each.
ISNULL returns the second argument if the first argument is NULL. Many times, I see that developer uses ISNULL for no reason. I have seen usage of ISNULL even when a column is not nullable. We should use ISNULL only when it is necessary, otherwise it could cause a lot of performance problem. Let’s see a quick demo for ISNULL.
The BETWEEN operator selects values within a given range. The values can be numbers, text, or dates. The BETWEEN operator is inclusive: begin and end values are included.
The IN operator allows you to specify multiple values in a WHERE clause.
An explicit conversion occurs when you use the CONVERT or CAST keywords explicitly in your query.
An implicit conversion happens when you have differing datatypes in an expression and SQL Server casts them automatically according to the rules of datatype precedence.
Implicit conversions are not visible to the user. SQL Server automatically converts the data from one data type to another. The data type conversion happens based on data type precedence rule. The data type precedence rule specifies which data type is converted to the other.
When an expression has different data types, the data type with the lower precedence is first converted to the data type with the higher precedence. For example, when a smallint is compared to an int, the smallint is implicitly converted to int before the comparison proceeds.
If the conversion isn't a supported implicit conversion, an error is returned.
A derived table, despite the name, is not a real table, it's just an interim resultset that can be references as if it were a table.
Derived tables are essentially SELECT statements within SELECT statements.
When you troubleshoot the performance issue, after going over all possible factors like long running queries, checking wait-stats, any blockings on the server, CPU and memory utilization, high IO consuming queries, min-max memory setting, MAXDOP, tempdb utilization; many times you end up with the one SQL and that could be the reason for the slowness on the server and that query might have temporary table or table variable. In this topic, I’m going to talk about the main factors involved in choosing table variable or temporary table and demonstrate a few simple rules to get the best performance.
When we work with the large data sets, we might require storing the intermediate results so that we can access them further in the stored procedure. SQL Server provides multiple options to achieve the same such as CTE, Temporary Tables, or Table Variables.
Table variables are created like any other variable, using the DECLARE statement. Like local temporary tables, table variables are accessible only within the session that created them. However, unlike the temporary tables, if a table variable is declared in a stored procedure, it is local to that stored procedure and cannot be referenced in a nested procedure. They are not visible outside of the batch.
They are also not fully logged, so creating and filling them is faster and require less space in the transaction log. Table variable are like a variable it won't get affected by commit or rollback transaction.
Also, SQL Server does not maintain the statistics on a table variable, and as you know the statistics are used heavily by the query optimizer to determine the best method to execute a query. We’ll see how that affect the performance.
More the rows in table variable, larger the discrepancies between estimation and reality, and the more inefficient becomes the optimizer’s plan choices.
The SELECT DISTINCT statement is used to return only distinct values.
Many people use DISTINCT keyword in a SELECT statement to remove duplicate rows returned by a query. If you need to use distinct regularly to eliminate duplicate rows, it could be a poor database design or an ineffective query, or both. To eliminate duplicate rows, SQL engine invokes SORT operation and that has extra cost and can slow down your query.
Let see when DISTINCT triggers the SORT and how to avoid it.
Make sure your table design is good, follow normalization rules.
Check on JOIN criteria and make sure it doesn’t bring duplicate rows.
Lookup tables are very small relative to transaction tables. Often, they are viewed as nothing more than a simple location for pulling the values for a drop-down list.
For ex- Category table here.