Database - Azure SQL

Azure SQL database is an individual database that is managed under the DTU (Database Transaction Unit) or vCore pricing model.

  • DTU Pricing Model

    In the DTU model, Azure bundles CPU, memory, and IOPS as a single DTU metric. Turbonomic actions on these databases consider both DTU and storage utilization.

  • vCore Pricing Model

    In the vCore model, analysis can track CPU, memory, IOPS, and throughput metrics in isolation. Turbonomic actions on these databases are driven by CPU, memory, IOPS, throughput and storage utilization.

Turbonomic discovers SQL databases through your Azure targets, and represents them as Database entities in the supply chain.

Synopsis

Database in the Supply Chain

Synopsis

Provides:

Transactions to end users

Consumes:

  • DTU Pricing Model:

    DTU and storage resources in an Azure region

  • vCore Pricing Model:

    vCPU, vMem, IOPS, throughput, and storage resources in an Azure region

Discovered through:

Azure targets

Monitored resources

The resources that Turbonomic can monitor depend on the pricing model in place for the given database entity.

  • DTU Pricing Model

    • DTU

      DTU is the measurement of compute capacity for the database. DTU represents CPU, memory, and IOPS/IO Throughput bundled as a single commodity.

    • Storage Amount

      Storage Amount is the measurement of storage capacity that is in use.

  • vCore Pricing Model

    • Virtual Memory (VMem)

      Virtual Memory is the measurement of memory that is in use.

    • Virtual CPU (VCPU)

      Virtual CPU is the measurement of CPU that is in use.

    • Storage Amount

      Storage Amount is the measurement of storage capacity that is in use.

    • Storage Access (IOPS)

      Storage Access, also known as IOPS, is the per-second measurement of read and write access operations on a storage entity.

    • I/O Throughput

      I/O Throughput is the measurement of an entity's throughput to the underlying storage.

Scale actions for SQL databases

Turbonomic database scaling actions aim to increase resource utilization and reduce costs while complying with business policies.

Turbonomic drives scaling actions based on the utilization of resources, and treats the following limits as constraints when it makes scaling decisions:

  • Maximum Concurrent Sessions

    Maximum concurrent sessions is the maximum number of database connections at a time.

  • Maximum Concurrent Workers

    Maximum concurrent workers is the maximum number of database processes that can handle queries at a time.

Points to consider:

  • Turbonomic will not recommend:

    • Scaling from one pricing model to another

    • Scaling vCore databases to instance types running Gen4 hardware. This hardware generation has been retired and pricing information can no longer be retrieved via the Azure API.

    • Scaling vCore databases on the serverless compute tier

    • Scaling provisioned memory for vCore databases on the Hyperscale service tier. VMem utilization data is currently unavailable for Hyperscale due to an issue in the Azure API.

  • On DTU databases, a single action can scale both DTU and storage. On vCore databases, a single action can scale vCPU, vMem, IOPS, throughput, and storage.

  • In some cases, Turbonomic might recommend scaling up storage, even if there is no storage pressure on the database, to take advantage of storage provided at no extra cost. For example, Turbonomic might recommend scaling from the S3 to the S0 tier because of low DTU and storage utilization. Since the S0 tier includes 250 GB of storage at no extra cost, Turbonomic will also recommend scaling up to this storage amount. If you want to scale DTU but keep the storage amount unchanged, adjust the values for aggressiveness (percentile) and observation period in your database policies.

Utilization Charts for Scale Actions

Turbonomic uses percentile calculations to measure resource utilization, and drive scaling actions that improve overall utilization and reduce costs. When you examine the details for a pending scaling action on a database, you will see charts that highlight resource utilization percentiles for a given observation period, and the projected percentiles after you execute the action.

Utilization Charts for Scale Actions

The charts also plot daily average utilization for your reference. If you have previously executed scaling actions on the database, you can see the resulting improvements in daily average utilization. Put together, these charts allow you to easily recognize utilization trends that drive Turbonomic's scaling recommendations.

Note:

You can set scaling constraints in database policies to refine the percentile calculations. For details, see Aggressiveness and Observation Period.

Non-disruptive and reversible scaling actions

All scaling actions shown in the Action Center view and Action Details page are non-disruptive and reversible.

For actions to scale vCore databases from General Purpose or Business Critical to Hyperscale, there are certain caveats associated with reversing such actions. To learn more, see the Azure documentation.

Actions in charts

Use the Necessary Investments and Potential Savings charts to view pending database actions. These charts show total monthly investments and savings, assuming you execute all the actions.

Necessary Investments and Potential Savings charts

Click Show All for each chart to review and execute the actions.

The table shows the following:

  • Actions that are pending for each database

  • Savings or investments for each database