SQL Azure database DTU increses after upsizing with no other changes

Question

When a single Azure SQL database is upsized to (S1->S3, S7->S9, P2->P4 etc.) with no other changes (no code deployment, no changes in load) the DTU percentage decreases, which is expected. What could explain the DTU percentage increasing upon moving to the higher tier and then decreasing back when downgraded to the smaller tier?

In other words, normally one could expect P2 @ ~80% becoming P4 @ ~40% . What could explain P2 @ ~80% becoming P4 @ ~90% at stable load, no code changes, and no increase is db size (the database is read and write heavy (updates, not many inserts).

For example, could Query Store become busier when more DTUs are available?

Please note this is not after optimizing this database (this work is being done but this is not part of this question)

Answer 1

When you increase the DTUs you also get an increase in the transaction log throughput rate.

As your database has a heavy UPDATE load, it is likely the case that at the lower tier your writes are being heavily throttled as well as your CPU and Memory overhead being close to the MAX>

Increasing your DTUs allows you more CPU and Memory headroom, but potentially your throughput rate is still being throttled with the high number of UPDATES.

The formula used for avg_dtu_percent is avg_dtu_percent = MAX(avg_cpu_percent, avg_data_io_percent, avg_log_write_percent) therefore you can see that your DTU can still appear high if only one of the resource types is being heavily used.

To track more detailed usage information, sys.dm_db_resource_stats dynamic management view (DMV) lets you view resource consumption for the last hour. The sys.resource_stats catalog view displays resource consumption for the last 14 days, but at a lower fidelity of five-minute averages.