The following is the third in a series of posts about the Azure SQL Database DTU Calculator. The first post in this series described the need for the calculator and the process of creating it. The second post described using the calculator. This post will focus on analyzing the results.
Single Azure SQL Database
Assuming you’ve captured your SQL Server’s performance and uploaded it in the calculator, you will now see the results page. The example below is for a single database so your results may vary slightly if you’re using Elastic Database, but in general, the results page is divided into three basic sections: ‘Service Tier and Performance Level’, ‘DTUs Over Time’, and ‘View More Details’. Note that the ‘View More Details’ section is collapsed by default so you’ll need to expand it in order to analyze CPU, IOPS, and Log recommendations individually.
Service Tier/Performance Level
The ‘Service Tier/Performance Level’ section provides an overall recommendation for migrating to Azure SQL Database. This recommendation is calculated by taking the maximum number of DTUs for either CPU, IOPS, or Log at each interval and using that maximum as the basis for the recommendation. Since the calculator recommends the Service Tier/Performance Level which maximizes performance while minimizing costs, it’s important to note the recommendation may not cover 100% of your workload. There may be some portion of your workload that falls into a higher Service Tier and Performance Level so you’ll want to validate your database’s performance post migration.
Note: You can gain additional insights by hovering your mouse over each section of the chart to see what percentage of your workload is covered by a specific Service Tier/Performance Level as well as how much that Service Tier/Performance Level covers the entire workload.
DTUs Over Time
The ‘DTUs Over Time’ section is similar to the ‘Service Tier/Performance Level’ recommendation in that it uses the maximum DTU for CPU, IOPS, and Log. The difference is the ‘DTUs Over Time’ chart displays the DTU value at each interval. This type of visualization is useful since it shows how DTUs relate to performance. In general, you would hope your performance is somewhat consistent but having this chart allows you to identify performance spikes that may cause problems with your Azure SQL Database deployment and do some additional investigation to identify and resolve those performance issues before migrating to Azure SQL Database.
View More Details
The ‘View More Details’ section is broken down into four subsections. The first three sections show individual recommendation for CPU, IOPS, and Log. Having individual recommendation allows you to quickly identify how your workload is bound. For example, the following shows recommendations for CPU and IOPS. Notice the recommendation for CPU is Standard – S1 and the recommendation for IOPS is Standard – S0. This means your workload is CPU bound as your workload requires more CPU than disk.
The last chart shows how much of your workload’s CPU, IOPS, and Log is covered by a Service Tier/Performance Level. By utilizing this chart you can visualize how your workload changes across Service Tiers and Performance Levels. For example, the following chart shows that 30% of CPU, 78% of IOPS, and 100% of Log are immediately covered by the Basic Service Tier and it isn’t until Standard – S1 that all three metrics have over 90% coverage.
The Elastic Databases recommendation is almost identical to the recommendation for a single database with two major differences. The first difference is that elastic database pools don’t have a concept of Performance Levels so the recommendation only provides a Service Tier (Basic, Standard, or Premium). The second difference is the Elastic Databases recommendation shows the total eDTUs required for the pool. The total eDTUs required for the pool is important because of the way Elastic Databases are billed. You pay for the total eDTUs required for all databases in the pool. See the SQL Database Pricing page for more information.