Database - Azure SQL

Edit online

Azure SQL database is an individual database that is managed under the DTU (Database Transaction Unit) or vCore pricing model. Turbonomic for Government Standard discovers SQL databases through your Azure targets, and represents them as Database entities in the supply chain.

Database in the Supply Chain

  • DTU Pricing Model

    In the DTU model, Azure bundles CPU, memory, and IOPS as a single DTU metric. Turbonomic for Government Standard 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 for Government Standard actions on these databases are driven by CPU, memory, IOPS, throughput and storage utilization.

Monitored resources

The resources that Turbonomic for Government Standard 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 (vMem) 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 for Government Standard database scaling actions aim to increase resource utilization and reduce costs while complying with business policies.

Turbonomic for Government Standard 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 for Government Standard 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 for Government Standard 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 for Government Standard 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 for Government Standard 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.

Supported instance types for SQL database scale actions

For a list of supported instance types, see Supported Azure database instance types.

You can also view the supported instance types from the Turbonomic for Government Standard user interface.

  1. Navigate to Settings > Policies.

  2. In the Policy Management page, search for and open Database Defaults.

  3. In the Edit automation policy page:

    1. Expand Scaling constraints.

    2. In the Cloud instance types section, click Edit.

    3. Review the items in the table. Expand an item to see available sizes.

To determine the most optimal instance type for a database, Turbonomic for Government Standard considers all relevant instance types in its analysis. However, you may have configured some of your databases to only scale to certain instance types to reduce complexity and cost, or meet demand. To limit scaling to certain instance types, create policies for the affected databases and configure an inclusion or exclusion list as a scaling constraint.

Utilization charts for scale actions

Turbonomic for Government Standard 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 for Government Standard'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.

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