Azure SQL Database は、インフラストラクチャ管理なしでシームレスなコンピューティングスケーリングを提供します。スケーリング操作には、vCore の調整だけでなく、新しいコンピューティングのプロビジョニング、データの準備、接続の切り替え、古い環境のクリーンアップが含まれます。スケーリングにかかる時間は、2 つのデータベース間で一見同じような変更であっても、大きく異なる場合があります。データベースサイズは重要な要因であり、データベースが大きいほど、ターゲットコンピューティングでのデータ準備に時間がかかります。データベースのアクティブなワークロードもスケーリング時間に影響を与える可能性があります。ターゲット環境の準備中、データベースはオンラインのままです。切り替え時に存在する長時間実行されるトランザクションは、接続遷移を遅延させ、操作を長引かせることがあります。Azure SQL 内のリソースの可用性も、操作が保留状態に入る原因となり、全体的な時間を増加させる可能性があります。スケーリング操作は、Azure PowerShell の Get-AzSqlDatabaseActivity および Get-AzSqlDatabase コマンドレットを使用して監視できます。sys.dm_operation_status DMV は、PENDING や IN_PROGRESS のような操作状態の SQL 側のビューを提供します。sys.dm_operation_status の PercentComplete 列は、通常、スケーリングの細かい進捗状況ではなく、操作の状態を示します。スケーリング中、データベースは利用可能なままで、切り替えまで接続は元のコンピューティングに継続されます。切り替え自体は短い中断を引き起こし、アプリケーションは再試行ロジックを実装する必要があります。スケーリング操作が遅いことは、必ずしも失敗を示すわけではありません。正当に複雑な準備段階を処理している可能性があります。トラブルシューティングには、正確な変更の確認、データベースサイズの比較、ワークロードアクティビティ、および長時間実行されるトランザクションの有無の確認が含まれます。