Reduce Cost by Tuning Queries on Azure DBaaS
•Télécharger en tant que PPTX, PDF•
0 j'aime•103 vues
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.
Recommandé
Recommandé
Contenu connexe
Tendances
Similaire à Reduce Cost by Tuning Queries on Azure DBaaS
Similaire à Reduce Cost by Tuning Queries on Azure DBaaS (20)
Plus de Datavail
Plus de Datavail (20)
Dernier
Dernier (20)
Reduce Cost by Tuning Queries on Azure DBaaS
- 1. Reduce cost by tuning queries on Azure DBaaS Rajnikant Tandel, DBA Manager, Datavail
- 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
- 5. Rajnikant Tandel DBA Manager Datavail /rajnikant-tandel @tandelrajni raj.tandel.50 When he’s not working, he enjoys going for a run. Raj has over 15 years of experience in SQL Server and specialize in performance tuning.
- 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
- 7. Avoid ISNULL() in WHERE clause
- 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)
- 9. D E M O ISNULL()
- 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
- 11. When to use BETWEEN over IN?
- 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)
- 13. D E M O BETWEEN over IN
- 14. BETWEEN over IN Use BETWEEN over IN when applicable If possible, use BETWEEN with not equal to (<>) for filter Summary
- 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.
- 17. D E M O Implicit Conversion
- 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
- 20. Function in WHERE clause User Defined Function Inbuilt Function How to avoid function to get better performance?
- 21. D E M O Function in WHERE clause
- 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
- 23. Derived Table
- 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.
- 25. D E M O Derived Table
- 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
- 27. Table variable vs Temporary table
- 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
- 29. D E M O Table variable vs Temporary table
- 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
- 32. DISTINCT performance impact SELECT DISTINCT statement is used to return only distinct values. DISTINCT triggers the SORT and how to avoid it.
- 33. D E M O DISTINCT Performance Impact
- 34. DISTINCT performance impact DISTINCT invokes SORT operation SELECT column list having key from unique index avoids SORT operation 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
- 37. D E M O Lookup Table
- 38. Lookup Table Unindexed Lookup table could lead to more logical reads and affect performance Summary
Notes de l'éditeur
- 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.