Monitoração de performance no Azure SQL Database e também como podemos planejar a implementação de uma estrutura de alta performance em cloud.

1. WORKING WITH AZURE SQL
DATABASE
Performance and tuning guide

2. • MVP Data Platform
• Principal Database Architect at Vita Database
Solutions
• Pass Chapter Leader at SQLManiacs
• SQL Server Database Consultant at Pythian
• Vitor.fava@vitadbsolutions.com
• http://vfava.wordpress.com
• http://www.youtube.com/vitortff
• https://groups.google.com/group/sqlmaniacs
Vitor Fava

3. What is SQL Database?
• Relational database service in the cloud based on the
market-leading Microsoft SQL Server engine, with mission-
critical capabilities.
• Delivers predictable performance, scalability with no
downtime, business continuity and data protection—all
with near-zero administration
• Focus on rapid app development and accelerating your
time to market, rather than managing virtual machines and
infrastructure.
• Because it’s based on the SQL Server engine, SQL
Database supports existing SQL Server tools, libraries and
APIs, which makes it easier for you to move and extend to
the cloud.

4. Monitor databases using the Azure portal
• In the Azure portal, you can monitor a single database’s utilization by selecting your database and
clicking the Monitoring chart;
• This brings up a Metric window that you can change by clicking the Edit chart button and add the
following metrics:
• CPU percentage
• DTU percentage
• Data IO percentage
• Database size percentage
• You can also configure alerts on the performance metrics

5. Monitor databases using DMVs
• The same metrics that are exposed in the portal are also available through system views:
sys.resource_stats in the logical master database of your server, and sys.dm_db_resource_stats
in the user database;
• Use sys.resource_stats if you need to monitor less granular data across a longer period of time;
• Use sys.dm_db_resource_stats if you need to monitor more granular data within a smaller time
frame;

6. Monitor databases using DMVs
SQL Database partially supports three categories
of dynamic management views:
• Database-related dynamic management views;
• Execution-related dynamic management views;
• Transaction-related dynamic management views;

7. SQL Database Advisor
• Azure SQL Database learns and adapts with your application and provides customized
recommendations enabling you to maximize the performance of your SQL databases;
• The SQL Database Advisor provides recommendations for creating and dropping indexes,
parameterizing queries, and fixing schema issues;
• The advisor assesses performance by analyzing your SQL database's usage history;
• The recommendations that are best suited for running your database’s typical workload are
recommended;

8. SQL Database Advisor
• Create Index recommendations appear when the SQL Database service detects a missing index
that if created, can benefit your databases workload (non-clustered indexes only);
• Drop Index recommendations appear when the SQL Database service detects duplicate indexes
(currently in preview and applies to duplicate indexes only);
• Parameterize queries recommendations appear when you have one or more queries that are
constantly being recompiled but end up with the same query execution plan. This condition opens
up an opportunity to apply forced parameterization, which will allow query plans to be cached and
reused in the future improving performance and reducing resource usage;

9. SQL Database Advisor
• Fix schema issues recommendations appear when the SQL Database service notices an
anomaly in the number of schema-related SQL errors happening on your Azure SQL Database.
• This recommendation typically appears when your database encounters multiple schema-related
errors (invalid column name, invalid object name, etc.) within an hour.
SQL Error Code Message
201
Procedure or function '' expects parameter '', which was not
supplied.
207 Invalid column name '*'.
208 Invalid object name '*'.
213
Column name or number of supplied values does not match table
definition.
2812 Could not find stored procedure '*'.
8144 Procedure or function * has too many arguments specified.

10. Azure SQL Database Query Performance
Insight
• Managing and tuning the performance of relational databases is a challenging task that requires
significant expertise and time investment;
• Query Performance Insight allows you to spend less time troubleshooting database performance
by providing the following:
• Deeper insight into your databases resource (DTU) consumption;
• The top queries by CPU/Duration/Execution count, which can potentially be tuned for improved
performance;
• The ability to drill down into the details of a query, view its text and history of resource utilization;
• Performance tuning annotations that show actions performed by SQL Azure Database Advisor

11. Azure SQL Database Query Performance
Insight
• A couple hours of data needs to be captured by Query Store for SQL Database to provide query
performance insights;
• If the database has no activity or Query Store was not active during a certain time period, the
charts will be empty when displaying that time period;

12. Extended events in SQL Database

13. Performance Guidance - Tiers
Basic
• You're just getting started with Azure SQL Database. Applications that are in development often don't
need high-performance levels. Basic databases are an ideal environment for database development, at
a low price point.
• You have a database with a single user. Applications that associate a single user with a database
typically don’t have high concurrency and performance requirements. These applications are
candidates for the Basic service tier.
Standard
• Your database has multiple concurrent requests. Applications that service more than one user at a
time usually need higher performance levels. For example, websites that get moderate traffic or
departmental applications that require more resources are good candidates for the Standard service
tier.

14. Performance Guidance - Tiers
Premium
• High peak load. An application that requires substantial CPU, memory, or input/output
(I/O) to complete its operations requires a dedicated, high-performance level;
• Many concurrent requests. Some database applications service many concurrent
requests, for example, when serving a website that has a high traffic volume;
• Low latency. Some applications need to guarantee a response from the database in
minimal time;
• Premium RS. Designed for customers that have IO-intensive workloads but do not require
the highest availability guarantees. Examples include testing high-performance workloads,
or an analytical workload where the database is not the system of record.

15. Performance Guidance - Maximum
concurrent logins
• You can analyze your user and application patterns to get an idea of the frequency of
logins;
• If multiple clients use the same connection string, the service authenticates each login;
• If 10 users simultaneously connect to a database by using the same username and
password, there would be 10 concurrent logins;
• This limit applies only to the duration of the login and authentication;
• If the same 10 users connect to the database sequentially, the number of concurrent
logins would never be greater than 1;

16. Performance Guidance -
sys.dm_db_resource_stats
• You can use the sys.dm_db_resource_stats view in every SQL database;
• The sys.dm_db_resource_stats view shows recent resource use data relative to
the service tier;
• Average percentages for CPU, data I/O, log writes, and memory are recorded
every 15 seconds and are maintained for 1 hour;
• Because this view provides a more granular look at resource use, use
sys.dm_db_resource_stats first for any current-state analysis or
troubleshooting;

17. Performance Guidance - sys.resource_stats
• The sys.resource_stats view in the master database has additional information
that can help you monitor the performance of your SQL database at its specific
service tier and performance level;
• The data is collected every 5 minutes and is maintained for approximately 14
days;
• This view is useful for a longer-term historical analysis of how your SQL database
uses resources;

18. Performance Guidance - Tune your
application
• Chatty applications make excessive data access operations that are
sensitive to network latency. You might need to modify these kinds
of applications to reduce the number of data access operations to
the SQL database.
Applications that have slow
performance because of
"chatty" behavior
• Databases that exceed the resources of the highest Premium
performance level might benefit from scaling out the workload
Databases with an intensive
workload that can't be
supported by an entire
single machine

19. Performance Guidance - Tune your
application
• Applications, especially those in the data access layer, that have poorly
tuned queries might not benefit from a higher performance level;
• This includes queries that lack a WHERE clause, have missing indexes, or
have outdated statistics. These applications benefit from standard query
performance-tuning techniques;
Applications that
have suboptimal
queries
• Applications that have inherent data access concurrency issues, for
example deadlocking, might not benefit from a higher performance level;
• Consider reducing round trips against the Azure SQL Database by caching
data on the client side with the Azure Caching service or another caching
technology;
Applications that
have suboptimal
data access design

20. Questions