Database (Cloud)

Turbonomic discovers SQL Databases through your Azure targets. In particular, it discovers the resources on individual databases that are managed under both the DTU (Database Transaction Unit) and vCore pricing models.

  • 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.

Note:

For more information about the DTU and vCore models, see the Azure documentation.

AWS RDS databases appear as Database Server entities in the supply chain. For details, see Database Server (Cloud).

Synopsis

Synopsis

Budget:

A database has unlimited budget.

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

Actions analysis also considers levels of concurrent workers and concurrent sessions, to constrain instance type selection. In all cases, Turbonomic database scaling actions aim to increase resource utilization and reduce costs while complying with business policies.

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 capacity for the database. DTU represents CPU, memory, and IOPS/IO Throughput bundled as a single commodity.

    • Storage

      Storage capacity for the database.

  • vCore Pricing Model

    • Virtual Memory (VMem)

      The utilization of VMem allocated to the Database instance

    • Virtual CPU (VCPU)

      The utilization of VCPU allocated to the Database instance

    • Storage Access (IOPS)

      The rate of input and output operations per second utilized by the Database instance

    • Throughput

      The throughput utilization of transaction log write IO available to the Database instance

    • Storage

      Storage capacity for the database.

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

  • Maximum concurrent sessions

    Maximum number of database connections at a time.

  • Maximum concurrent workers

    Maximum number of database processes that can handle queries at a time.

Actions

Scale

  • DTU Model

    Scale DTU and storage resources to optimize performance and costs.

  • vCore Model

    Scale vCPU, vMem, IOPS, throughput and storage resources to optimize performance and costs.

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 is nearing end-of-life 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.

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.

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

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.

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.