#はじめに
Azure SQL Databaseへの接続が断続的に失敗するような現象は、データセンター側の問題(データベースが配置されたクラスタノードで問題が発生しているなど)、サービスレベルに応じたデータベースのリソース制限など、様々な要因によって発生する可能性があるかと思います。
サービスレベルに応じたデータベースのリソース制限が要因の場合、データベースのサービスレベル／価格レベルをあげる、データベースへの処理量を減らすなどの対処を実施することにより問題を解決できる可能性があります。
また、データセンター側の問題が疑われる場合は、**データベースの再構成(Reconfiguration：リコンフィグレーション)**を実施することにより、現象が解消できる可能性があります。
今回は、手動でデータベースの再構成を実施する方法について、紹介したいと思います。

#目次
1. Azure SQL Database 手動によるデータベースの再構成 (Reconfiguration)
2. SQL データベース - 設定：構成から価格レベル、サービスレベル (仮想コア数)を変更
 3. まとめ
 4. 参考情報

#1. Azure SQL Database 手動によるデータベースの再構成 (Reconfiguration)
■ Invoke-AzSqlDatabaseFailover (PowerShell) コマンドを実行
「Invoke-AzSqlDatabaseFailover」 (PowerShell) コマンドを実行することにより、手動でデータベースの再構成(Reconfiguration) を実行することが可能です。

【コマンド例】

※ Azure ポータル - Cloud Shell (PowerShell) から「Invoke-AzSqlDatabaseFailover」コマンドを実行することが可能です。

【補足】
「Invoke-AzSqlDatabaseFailover」コマンドは、1回実行すると30分間は再実行できなくなります。

#2. SQL データベース - 設定：構成から価格レベル、サービスレベル (仮想コア数)を変更
SQL データベース - 設定：構成から価格レベル、サービスレベル (仮想コア数)を変更することで、 Invoke-AzSqlDatabaseFailover (PowerShell) コマンドを実行した場合と同様に、データベースの再構成(Reconfiguration) を行うことが可能です。

※ 必要に応じて、価格レベル、サービスレベル (仮想コア数) を元の設定に戻す場合にも、データベースの再構成(Reconfiguration)が行われることになります。

#3. まとめ
今回は、Basic、Standard および General Purpose サービスレベルを想定した内容となりますが、Premium、Business Critical サービスレベルの場合でも同様に**「Invoke-AzSqlDatabaseFailover」コマンドを実行することが可能です。なお、Premium、Business Critical サービスレベルでは、SQL Server Always On 可用性グループと同様のテクノロジーを使用しているため、本コマンドの「-ReadableSecondary」**オプションを指定することで、フェールオーバーテストを手動で実行することが可能になるようなので、ゾーン冗長を構成した場合におけるアプリケーションの性能試験、再試行ロジックのテストを柔軟に実行することができるかと思います。

#4. 参考情報
・Azure SQL Database と SQL Managed Instance の高可用性
・Invoke-AzSqlDatabaseFailover
・アプリケーションの障害回復性のテスト