Skip to content

Commit e398d62

Browse files
authored
Merge pull request #78150 from jovanpop-msft/patch-65
Moving monitoring via portal to how-to
2 parents 5848e4d + a57c786 commit e398d62

File tree

2 files changed

+20
-19
lines changed

2 files changed

+20
-19
lines changed

articles/sql-database/sql-database-manage-after-migration.md

Lines changed: 20 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -23,6 +23,7 @@ Moving from the traditional self-managed, self-controlled environment to a PaaS
2323

2424
This article discusses some of the core characteristics of Azure SQL Database as a platform that you can readily leverage when working with single databases and pooled databases in elastic pools. They are the following:
2525

26+
- Monitor database using the Azure portal
2627
- Business continuity and disaster recovery (BCDR)
2728
- Security and compliance
2829
- Intelligent database monitoring and maintenance
@@ -31,6 +32,25 @@ This article discusses some of the core characteristics of Azure SQL Database as
3132
> [!NOTE]
3233
> This article applies to the following deployment options in Azure SQL Database: single databases and elastic pools. It does not apply to the managed instance deployment option in SQL Database.
3334
35+
## Monitor databases using the Azure portal
36+
37+
In the [Azure portal](https://portal.azure.com/), you can monitor an individual 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. Add the following metrics:
38+
39+
- CPU percentage
40+
- DTU percentage
41+
- Data IO percentage
42+
- Database size percentage
43+
44+
Once you've added these metrics, you can continue to view them in the **Monitoring** chart with more information on the **Metric** window. All four metrics show the average utilization percentage relative to the **DTU** of your database. See the [DTU-based purchasing model](sql-database-service-tiers-dtu.md) and [vCore-based purchasing model](sql-database-service-tiers-vcore.md) articles for more information about service tiers.
45+
46+
![Service tier monitoring of database performance.](./media/sql-database-single-database-monitoring/sqldb_service_tier_monitoring.png)
47+
48+
You can also configure alerts on the performance metrics. Click the **Add alert** button in the **Metric** window. Follow the wizard to configure your alert. You have the option to alert if the metrics exceed a certain threshold or if the metric falls below a certain threshold.
49+
50+
For example, if you expect the workload on your database to grow, you can choose to configure an email alert whenever your database reaches 80% on any of the performance metrics. You can use this as an early warning to figure out when you might have to switch to the next highest compute size.
51+
52+
The performance metrics can also help you determine if you are able to downgrade to a lower compute size. Assume you are using a Standard S2 database and all performance metrics show that the database on average does not use more than 10% at any given time. It is likely that the database will work well in Standard S1. However, be aware of workloads that spike or fluctuate before making the decision to move to a lower compute size.
53+
3454
## Business continuity and disaster recovery (BCDR)
3555

3656
Business continuity and disaster recovery abilities enable you to continue your business, as usual, in case of a disaster. The disaster could be a database level event (for example, someone mistakenly drops a crucial table) or a data-center level event (regional catastrophe, for example a tsunami).

articles/sql-database/sql-database-monitor-tune-overview.md

Lines changed: 0 additions & 19 deletions
Original file line numberDiff line numberDiff line change
@@ -39,25 +39,6 @@ You have the following options for monitoring and troubleshooting database perfo
3939
> [!TIP]
4040
> See [performance guidance](sql-database-performance-guidance.md) to find techniques that you can use to improve performance of Azure SQL Database after identifying the performance issue using one or more of the above methods.
4141
42-
## Monitor databases using the Azure portal
43-
44-
In the [Azure portal](https://portal.azure.com/), you can monitor an individual 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. Add the following metrics:
45-
46-
- CPU percentage
47-
- DTU percentage
48-
- Data IO percentage
49-
- Database size percentage
50-
51-
Once you've added these metrics, you can continue to view them in the **Monitoring** chart with more information on the **Metric** window. All four metrics show the average utilization percentage relative to the **DTU** of your database. See the [DTU-based purchasing model](sql-database-service-tiers-dtu.md) and [vCore-based purchasing model](sql-database-service-tiers-vcore.md) articles for more information about service tiers.
52-
53-
![Service tier monitoring of database performance.](./media/sql-database-single-database-monitoring/sqldb_service_tier_monitoring.png)
54-
55-
You can also configure alerts on the performance metrics. Click the **Add alert** button in the **Metric** window. Follow the wizard to configure your alert. You have the option to alert if the metrics exceed a certain threshold or if the metric falls below a certain threshold.
56-
57-
For example, if you expect the workload on your database to grow, you can choose to configure an email alert whenever your database reaches 80% on any of the performance metrics. You can use this as an early warning to figure out when you might have to switch to the next highest compute size.
58-
59-
The performance metrics can also help you determine if you are able to downgrade to a lower compute size. Assume you are using a Standard S2 database and all performance metrics show that the database on average does not use more than 10% at any given time. It is likely that the database will work well in Standard S1. However, be aware of workloads that spike or fluctuate before making the decision to move to a lower compute size.
60-
6142
## Troubleshoot performance issues
6243

6344
To diagnose and resolve performance issues, begin by understanding the state of each active query and the conditions that cause performance issues relevant to each workload state. To improve Azure SQL Database performance, understand that each active query request from your application is either in a running or a waiting state. When troubleshooting a performance issue in Azure SQL Database, keep the following chart in mind as you read through this article to diagnose and resolve performance issues.

0 commit comments

Comments
 (0)