Microsoft Azure lets you easily create and deploy enterprise quality SQL Server on the cloud and scale it to suit your application’s needs. From the SQL Server database’s Azure dashboard, you can see the Database Transaction Unit (DTU) usage against the specified DTU limit for the database.
One Hour Usage Graph
This is what we saw for usage over one hour. The cyan line across the top is the DTU limit. The dark blue line is the DTU used. The limit is what you pay, so it’s important to scale it to what the application needs.
One Hour Azure SQL Server DTU use versus limit
While everything seemed fine at the weekly level, looking at the hourly graph gave us a shock. It looks like the database is maxed out for most of the hour. It seems conclusive that we need to increase our DTU level.
65 Minute Graph
But when we set the range to 65 minutes and saw this:
65-minute Azure SQL Server DTU use versus limit
These are completely different displays of the same period of time. The 65 minute graph never hits the maximum DTU. What’s going on?
Visit our page Monitoring SQL Server Usage on Microsoft Azure and Setting DTU Limits for an explanation.
Thanks for the tip about monitoring Azure. We are building an Azure hosted Access system for a multinational client and need to use two Azure databases connected by Data Sync (https://docs.microsoft.com/en-us/azure/sql-database/sql-database-get-started-sql-data-sync) because the latency between the UK and Australia is too high to give acceptable performance with a single database. Data Sync has been in preview for years and we can’t find out if it will be continued and become chargeable. We need to tell the client what the charge will be! Have you looked at Data Sync?
Hi John,
Thank you for your feedback. We are experienced using Data Sync between SQL Azure databases. It’s my understanding that’s used to keep SQL Server databases in sync from other hosts like on-premise or non-Azure copies.
SQL Azure databases have an option for geo-replication. You can specify a copy of the database to be mirrored in another data center, which may address your UK/Australia issue. People often use geo-replication to improve disaster recovery should a data center fail.
Our current knowledge about geo-replication is that the mirrored copies are read-only. Edits can only occur on the primary copy. However, it does make it easy to separate the read-only portion of an application(s) from the editable side. For instance, an online catalog is read-only but the shopping cart is editable. The catalog queries can be run on databases closer to the user. By diverting the read-only queries from the primary database, it reduces the load on the primary database which may provide the performance improvement you seek in the editing sections of your application.
If that architecture works for your needs, you can avoid using Data Snyc.
Hope this helps.