With the recent introduction of new service/performance tier previews (Basic, Standard and Premium) for Azure SQL Database service, there have been many questions from customers on how to evaluate and decide which service tier is best fit for their database. To streamline this determination, Azure SQL Database has added a new dynamic management view (DMV – sys.dm_db_resource_stats) which exposes fine-grained, real-time resource consumption data. For a detailed description of this new DMV and its usage, see the MSDN documentation here. This blog post describes some simple steps and guidelines on the process of using the information from this DMV to evaluate and pick the right performance tier for your database workload.
Picking the right service tier/performance level
1. Determine the service tier that provides you the minimum level of feature capability required for your application or business requirements. For example, a business requirement for how long backups are retained or overall database size will impact your minimum service tier (Refer to the service tier announcement blog for more details).
2. Create your database at the lowest performance level in your chosen service tier. For e.g. if you decide on the Standard service tier, start with performance level S1.
Note: Changing the service/performance tier of your DB is as simple as a click of a button in the Azure SQL Database portal page. This is a fully on-line operation and your DB is up and available for use during the period of this operation.
3. Run a representative workload for your application for at least one hour over a time period that captures the expected range of database usage in normal production deployment.
4. Query the new DMV sys.dm_db_ resource_stats to get the resource consumption information for the last one hour. The following query provides you the information on the percent of times your database’s resource consumption fits within the resource limits provided by this performance tier, (fit percent) making an assumption that you want to have your database run within 80% of your performance level limits.
SELECT
(COUNT(end_time) - SUM(CASE WHEN avg_cpu_percent > 80 THEN 1 ELSE 0 END) * 1.0) / COUNT(end_time) AS 'CPU Fit Percent'
,(COUNT(end_time) - SUM(CASE WHEN avg_log_write_percent > 80 THEN 1 ELSE 0 END) * 1.0) / COUNT(end_time) AS 'Log Write Fit Percent'
,(COUNT(end_time) - SUM(CASE WHEN avg_data_io_percent > 80 THEN 1 ELSE 0 END) * 1.0) / COUNT(end_time) AS 'Physical Data Read Fit Percent'
FROM sys.dm_db_resource_statsBased on your database service level objective (SLO), you can decide if your workload fits in this performance level. For e.g. if your database workload SLO is 99.9% and If the query above returns a value less than 99.9% for any of the three resource dimensions, you should consider either moving to the next higher performance level or tune your application to reduce the load on the Azure SQL Database.
Note: If you need more than an hour’s worth of high fidelity data, you can keep querying the above DMV every hour and save the data in another local DB/excel spread sheet. Alternatively, the catalog view sys.resource_stats can also be queried to get same data for the last 14 days, although at a lower fidelity of 5 minute averages.
1. If you decide to try the higher performance level, upgrade your database to the next higher performance level and repeat steps 3-4 above.
2. Once you have found the right performance level that fits your workload with desired SLO and latencies, you can monitor the resource usage consumption regularly using this DMV. This resource usage consumption information and relevant graphs are also available through the Microsoft Azure portal pages.
What happens when database workload reaches the resource limits?
Performance levels are calibrated and governed to provide the needed resources to run your database workload up to the max limits allowed for your selected service tier/performance level. If your workload is hitting the limits in one of CPU/Data IO/Log IO limits, you will continue to receive the resources at the maximum allowed level, but you are likely to see increased latencies for your queries. These limits will not result in any errors, but just a slowdown in your workload, unless the slowdown becomes so severe that queries start timing out. If you are hitting limits of maximum allowed concurrent user sessions/requests (worker threads), you will see explicit errors (Refer to the MSDN documentation here) for any further connections/requests.
Guidelines for web/business tier databases
The new DMV sys.dm_db_resource_stats does not get populated with resource consumption data for web/business tier databases. However the older sys.resource_stats view in master database has the resource consumption data for web/business tier databases also. Since Web/Business tier databases do not have any guaranteed DTUs/resource limits associated with them, we normalize the percentage values in terms of the amount of resources available to a database in S2 performance level. DTU consumption information in terms of an S2 database level will allow you to normalize the current consumption of your Web/Business databases in terms of new tier databases and see where they fit better. The following query on master database allows you to calculate the average DTU consumption of Web/Business tier in terms percentage of DTU power of an S2 database.
SELECT start_time, end_time, (SELECT Max(v) FROM (VALUES (avg_cpu_percent), (avg_physical_data_read_percent), (avg_log_write_percent)) AS value(v)) as [avg_DTU_percent] FROM sys.resource_stats where database_name = ‘’ order by end_time desc
For example, if your DTU consumption shows a value of 80%, it indicates it is consuming DTU at the rate of 80% of the limit an S2 database would have. If you see values greater than 100% in this view it means that you need a performance tier larger than S2.
As an example, let’s say you see a percentage value of 300%. This tells you that you are using three times more resources than would be available in an S2. To determine a reasonable starting size, compare the DTUs available in an S2 (50 DTUs) with the next higher sizes (P1 = 100 DTUs, or 200% of S2, P2 = 200 DTUs or 400% of S2). Because you are at 300% of S2 you would want to start with a P2 and re-test.
Based on the DTU usage percent you can determine if your database can fit within S2 performance level (OR a lower/higher level as indicated through DTU percentage and relative DTU powers of various performance tiers as documented in MSDN site).
Note:Relative DTU numbers between various performance levels are based on the Azure SQL Database Benchmark workload. Since your database’s workload is likely to be different from you should use the above calculations as the guideline for an initial fit for your web/business database in the new tiers. Once you have moved the database to the new tier, use the process outlined in the previous section to validate/fine tune the right service tier that fits your workload needs.