接続の問題とその他のエラーのトラブルシューティング

適用対象:Azure SQL DatabaseAzure SQL マネージド インスタンスMicrosoft Fabric 内の SQL データベース

Azure SQL Database、Microsoft Fabric の SQL データベース、または Azure SQL Managed Instance への接続が失敗すると、エラー メッセージが表示されます。

いつも通り、アプリケーションの設計プロセスで、ベスト プラクティスと設計のガイドラインを適用してください。

一般的な接続に関する問題を修正するための手順

1. アプリケーション サーバーで TCP/IP がクライアント プロトコルとして有効になっていることを確認します。 SQL ツールがインストールされていないアプリケーション サーバーでは、cliconfg.exe (SQL Server クライアント ネットワーク ユーティリティ) を実行して、TCP/IP が有効になっていることを確認します。

2. アプリケーションの接続文字列を調べ、正しく構成されていることを確認します。 たとえば、接続文字列で正しいポート (1433) と完全修飾サーバー名が指定されていることを確認します。 「SQL Server Management Studio を使用した接続情報の取得」を参照してください。

3. 接続タイムアウトの値を増やしてみます。 30 秒以上の接続タイムアウトを使用することをお勧めします。

4. クイック スタート:SSMS を使用して Azure SQL データベースまたは Azure SQL Managed Instance に接続してクエリを実行する、UDL ファイル、ping、または telnet を使用して、アプリケーション サーバーと Azure SQL データベース間の接続をテストします。 詳細については、接続問題のトラブルシューティングと接続問題の診断に関するページをご覧ください。

   注

   トラブルシューティングの手順として、別のクライアント コンピューターでの接続をテストすることもできます。

5. ベスト プラクティスとして、クラウドに接続されたアプリケーションでは再試行ロジックを使用する必要があります。

これらの手順で問題が解決しない場合は、さらにデータを収集してから、サポートに連絡してみてください。 アプリケーションがクラウド サービスの場合は、ログ記録を有効にします。 この手順により、エラーの UTC タイムスタンプが返されます。 ログ記録を有効にする方法の詳細については、「Azure App Service でのアプリの診断ログの有効化」を参照してください。 さらに、SQL Database によりトレース ID が返されます。 Microsoft カスタマー サポート サービスはこの情報を使用できます。

カスタム DNS またはホスト ファイルのオーバーライドによって発生する接続エラー

Azure SQL サービスが正常である間に特定のクライアント ネットワークに分離された永続的なログイン エラー (エラー 18456、40532、または 40615) がアプリケーションにある場合、原因は、サーバー FQDN を古いAzure SQL ゲートウェイ IP にピン留めするカスタム DNS 構成である可能性があります。

これが発生する理由

Azure SQL Databaseでは、リージョナル ゲートウェイのクラスターが使用されます。 Azureは、ハードウェアの更新、スケーリング、正常性に基づく移行など、通常の操作の一環としてゲートウェイを定期的に廃止し、置き換えます。 <server>.database.windows.net のAzure権限のある DNS は、現在のアクティブなゲートウェイを反映するように自動的に更新されます。

環境でこの DNS 解決がオーバーライドされると (ホスト ファイル エントリ、静的 CNAME レコード、またはサーバー FQDN を特定の IP にマップするプライベート DNS ゾーンを通じて)、クライアントはその IP にピン留めされます。 その IP のゲートウェイが後で廃止または再割り当てされた場合、接続は間違ったエンドポイントに移動します。 Azure SQL ゲートウェイは、ターゲット サーバーに対して受信 FQDN を検証し、不一致によってログインエラーが発生します。

DNS オーバーライドを検出する

影響を受けるクライアントから次のチェックを実行します。

1. ローカル ホスト ファイルでオーバーライドを確認します。

   :: Windows
   type C:\Windows\System32\drivers\etc\hosts | findstr /i "database.windows.net"
   

   # Linux or macOS
   grep -i "database.windows.net" /etc/hosts
   

2. クライアント DNS 解決とAzure権限のある DNS を比較します。

   :: Client or recursive resolver
   nslookup <server>.database.windows.net
   
   :: Authoritative public DNS
   nslookup <server>.database.windows.net 208.67.222.222
   

   # PowerShell
   Resolve-DnsName -Name "<server>.database.windows.net" -DnsOnly
   

   クライアント リゾルバーが権限のある DNS とは異なる IP を返す場合、DNS オーバーライドがアクティブになります。

3. CNAME またはプライベート DNS ゾーンのオーバーライドを確認します。

   nslookup -type=CNAME <server>.database.windows.net
   

   az network private-dns record-set list \
     --resource-group <ResourceGroup> \
     --zone-name database.windows.net \
     --output table
   

オーバーライドを修正する

1. オーバーライドを削除します。 hosts ファイル エントリを削除するか、静的な CNAME レコードを削除するか、サーバー FQDN を特定の IP にピン留めするプライベート DNS ゾーン レコードを削除します。

2. クライアントと中間リゾルバーで DNS キャッシュをフラッシュします。

   :: Windows
   ipconfig /flushdns
   

   # Linux (systemd-resolved)
   sudo systemd-resolve --flush-caches
   
   # macOS
   sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
   

3. DNS が現在のAzure ゲートウェイに解決されたことを検証します。

   nslookup <server>.database.windows.net
   

   返された IP が、サーバーのリージョンの発行済みゲートウェイ IP 範囲に含まれることを確認します。 一覧については、「接続アーキテクチャ」の「ゲートウェイ IP アドレス」セクションを参照してください。

4. Azure SQL 接続チェッカー または SQL Server Management Studio (SSMS) を使用して接続を再テストします。

この問題を回避する

• ホストファイル、静的 CNAME レコード、またはプライベート DNS ゾーンで、Azure SQL サーバーの FQDN を特定の IP アドレスにピン留めしないでください。 Azure SQLゲートウェイは動的であり、時間の経過と伴って変化します。
• ゲートウェイ IP に基づくファイアウォール許可リストを使用する場合は、個々の IP ではなく、リージョンのすべてのゲートウェイ IP 範囲を許可します。 可能な場合は、 Sql.<region> サービス タグを使用します。
• プライベート接続の場合は、DNS オーバーライドの代わりに Azure Private Link またはプライベート エンドポイント を使用します。 プライベート エンドポイントは、仮想ネットワーク内で安定したプライベート IP を提供し、ゲートウェイに直接ルーティングします。
• Azure SQL Databaseの Service Health アラートをサブスクライブして、リージョン内のゲートウェイ移行に関する通知を受信します。

クイック リファレンス

再試行ロジックの実装

クライアント アプリケーションが再試行ロジックを使用することで、一時障害に自動的に修復する時間を確保した後、接続の再確立を試行できるようにすることをお勧めします。 最初に再試行する前に、5 秒間待つことをお勧めします。 5 秒未満で再試行すると、クラウド サービスに過度の負荷がかかるおそれがあります。 再試行するたびに、待ち時間を大幅に長くし、最大 60 秒待つ必要があります。

再試行ロジックのコード例については、以下のページを参照してください。

• ADO.NET で SQL に弾性的に接続する
• PHP で SQL に弾性的に接続する

アプリケーションでの一時的なエラーの処理の詳細については、「 一時的な接続エラーのトラブルシューティング」を参照してください。

ADO.NET を使用するクライアントのブロック期間については、「接続プール (ADO.NET)」をご覧ください。

一時的な障害のエラー メッセージ (40197、40613、その他)

Azure インフラストラクチャには、SQL Database サービス内で負荷の大きいワークロードが生じた場合に、サーバーを動的に再構成する機能があります。 この動的な動作によって、クライアント プログラムがデータベースやインスタンスへの接続を失うことがあります。 この種のエラーは、 「一時的な障害」 と呼ばれます。 データベースの再構成イベントは、計画されたイベント (ソフトウェアのアップグレードなど) または計画されていないイベント (プロセスのクラッシュ、負荷分散など) が原因で発生します。 ほとんどの再構成イベントは一時的であり、長くても 60 秒未満で完了します。 これらのイベントは、場合によって、大規模なトランザクションによる長時間の復旧が発生する場合のように、完了までに時間がかかることがあります。 次の表に、Azure SQL Database に接続するときにアプリケーションが受け取る可能性のあるさまざまな一時的エラーの一覧を示します。

一時的な障害のエラー コードの一覧

一時的な接続の問題を解決する手順

1. アプリケーションがエラーを報告する時間帯に発生した既知の障害については、Microsoft Azure サービス ダッシュボードのページを参照してください。
2. Azure SQL Database など、クラウド サービスに接続するアプリケーションは、定期的な再構成イベントを想定し、アプリケーション エラーをユーザーに示すのではなく、再試行ロジックを実装してこれらのエラーを処理します。
3. データベースがリソースの制限に近づくと、一時的な接続の問題に見える場合があります。 リソース制限に関するページを参照してください。
4. 接続の問題が解消されない場合、アプリケーションでのエラーの継続時間が 60 秒を超えた場合、または 1 日にエラーが複数回発生した場合は、 Azure サポート サイトの [サポートの要求] を選択して、サポート要求を送信してください。

サーバーへの接続を確立しているときにネットワーク関連またはインスタンス固有のエラーが発生しました

この問題は、アプリケーションでサーバーに接続できない場合に発生します。

この問題を解決するには、「一般的な接続に関する問題を修正するための手順」セクションの手順を (示されている順に) 試してください。

サーバー/インスタンスが見つからなかったか、アクセスできませんでした (エラー 26、40、10053)

エラー 26:指定されたサーバーの位置を特定しているときにエラーが発生しました

System.Data.SqlClient.SqlException: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections.(provider: SQL Network Interfaces, error: 26 – Error Locating Server/Instance Specified)

エラー 40:サーバーへの接続を開けませんでした

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)

エラー 10053:サーバーから結果を受信しているときに、トランスポート レベルのエラーが発生しました

10053: A transport-level error has occurred when receiving results from the server. (Provider: TCP Provider, error: 0 - An established connection was aborted by the software in your host machine)

これらの問題は、アプリケーションでサーバーに接続できない場合に発生します。

これらの問題を解決するには、「一般的な接続に関する問題を修正するための手順」セクションの手順を (示されている順に) 試してください。

ファイアウォールの問題のため、サーバーに接続できません

エラー 40615: < servername > に接続できません

この問題を解決するには、Azure portal 経由で SQL Database のファイアウォール設定を構成します。

エラー 5: < servername > に接続できません

この問題を解決するには、クライアントとインターネット間のすべてのファイアウォールで、送信接続用にポート 1433 が開いていることを確認します。

サーバーにログインできません (エラー 18456、40531)

ユーザー '< User name >' はログインできませんでした

Login failed for user '<User name>'.This session has been assigned a tracing ID of '<Tracing ID>'. Provide this tracing ID to customer support when you need assistance. (Microsoft SQL Server, Error: 18456)

この問題を解決するには、サービス管理者に連絡し、有効なユーザー名とパスワードを提供するよう依頼してください。

通常、サービス管理者は、次の手順を使用してログイン資格情報を追加します。

1. SQL Server Management Studio (SSMS) を使用して、サーバーにログインします。

2. ログイン名が無効になっているかどうかを確認するには、master データベースで次の SQL クエリを実行します。

   SELECT name, is_disabled FROM sys.sql_logins;
   

3. 対応する名前が無効になっている場合は、次のステートメントを使用して有効にすることができます。

   ALTER LOGIN <User name> ENABLE;
   

4. SQL ログイン ユーザー名が存在しない場合は、次の SQL クエリを編集して実行し、新しい SQL ログインを作成します。

   CREATE LOGIN <SQL_login_name, sysname, login_name>
   WITH PASSWORD = '<password, sysname, Change_Password>';
   GO
   

5. SSMS オブジェクト エクスプローラーで、 [データベース] を展開します。

6. ユーザーにアクセス許可を付与するデータベースを選択します。

7. [セキュリティ] を右クリックし、 [New](新規) 、 [ユーザー] を選択します。

8. プレースホルダーを含むスクリプトで、手順に従い、SSMS テンプレート パラメーターを置き換え、実行します。例を次に示します。

   CREATE USER [<user_name, sysname, user_name>]
   FOR LOGIN [<login_name, sysname, login_name>]
   WITH DEFAULT_SCHEMA = [<default_schema, sysname, dbo>];
   GO
   
   -- Add user to the database owner role
   EXEC sp_addrolemember N'db_owner', N'<user_name, sysname, user_name>';
   GO
   

   sp_addrolemember を使用して、特定のユーザーを特定のデータベース ロールにマップすることもできます。

   注

   Azure SQL Database では、データベース ロールのメンバーシップを管理するために、より新しい ALTER ROLE 構文を検討してください。

詳細については、「データベースへのアクセスを承認する」を参照してください。

接続のタイムアウト期限切れエラー

System.Data.SqlClient.SqlException (0x80131904): 接続タイムアウトが発生しました

System.Data.SqlClient.SqlException (0x80131904): Connection Timeout Expired. The timeout period elapsed while attempting to consume the pre-login handshake acknowledgement. This could be because the pre-login handshake failed or the server was unable to respond back in time. The duration spent while attempting to connect to this server was - [Pre-Login] initialization=3; handshake=29995;

System.Data.SqlClient.SqlException (0x80131904):タイムアウトが期限切れになりました

System.Data.SqlClient.SqlException (0x80131904): Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.

System.Data.Entity.Core.EntityException:基になるプロバイダーがオープンで失敗しました

System.Data.Entity.Core.EntityException: The underlying provider failed on Open. -> System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. -> System.ComponentModel.Win32Exception: The wait operation timed out

< server name > に接続できません

Cannot connect to <server name>.ADDITIONAL INFORMATION:Connection Timeout Expired. The timeout period elapsed during the post-login phase. The connection could have timed out while waiting for server to complete the login process and respond; Or it could have timed out while attempting to create multiple active connections. The duration spent while attempting to connect to this server was - [Pre-Login] initialization=231; handshake=983; [Login] initialization=0; authentication=0; [Post-Login] complete=13000; (Microsoft SQL Server, Error: -2) For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft%20SQL%20Server&EvtSrc=MSSQLServer&EvtID=-2&LinkId=20476 The wait operation timed out

これらの例外は、接続またはクエリの問題が原因で発生する可能性があります。 このエラーが接続の問題によって発生したことを確認するには、「エラーの原因が接続の問題かどうかを確認する」を参照してください。

接続のタイムアウトは、アプリケーションでサーバーに接続できないために発生します。 この問題を解決するには、「一般的な接続に関する問題を修正するための手順」セクションの手順を (示されている順に) 試してください。

プライベート エンドポイントの接続エラーのトラブルシューティング

プライベート エンドポイントを介したAzure SQL Databaseへの接続は、接続タイムアウトまたはログイン前ハンドシェイク エラーで失敗する可能性があります。 次の手順を順番に実行します。 各ステップでは、個別の障害モードが解決されます。

手順 1: プライベート エンドポイントと DNS 解決を確認する

プライベート エンドポイントがプロビジョニングされ、DNS がプライベート IP に解決されることを確認します。

手順 2: エグレス IP のサーバー レベルのファイアウォール規則を追加する

プライベート エンドポイントを使用する場合でも、Azure SQL Databaseはゲートウェイに表示されるソース IP に対してサーバー レベルの IP ファイアウォール規則を適用します。

1. エグレス IP を特定します。 VPN ゲートウェイまたは ExpressRoute 経由でルーティングされるオンプレミス トラフィックの場合、エグレス IP は通常、仮想ネットワーク内のゲートウェイまたは NAT プライベート IP です。 Azure内からは、VM のプライベート IP またはロード バランサーのフロントエンド IP になります。

2. その IP またはサブネットのサーバー レベルのファイアウォール規則を追加します。

   EXECUTE sp_set_firewall_rule
       @name = N'AllowPrivateEndpointSubnet',
       @start_ip_address = '10.0.1.0',
       @end_ip_address = '10.0.1.255';
   

手順 3: エッジまたはオンプレミスのファイアウォールで正しいポートを開く

必要なポートは、接続ポリシーによって異なります。

仮想ネットワーク内から接続に成功したが、オンプレミスから失敗した場合、オンプレミスのファイアウォールが 1433-65535 範囲の上位のポートをブロックしている可能性があります。 そのポート範囲を開くか、サーバーの接続ポリシーをプロキシに変更 します。 詳細については、「 プライベート エンドポイントでリダイレクト接続ポリシーを使用する」を参照してください。

手順 4: UDR、NVA、NAT のシナリオの対称ルーティングを確認する

SQL プライベート エンドポイントへのトラフィックがネットワーク仮想アプライアンス (NVA)、Azure Firewall、または NAT ゲートウェイを通過する場合、リターン トラフィックは同じパスに従う必要があります。 非対称ルーティングでは、TCP リセットまたはサイレント ドロップが発生します。

重要な事実:

• Azureは、すべてのプライベート エンドポイント IP に対して /32 システム ルートを作成します (たとえば、次ホップの種類が 10.0.1.4/32 の InterfaceEndpoints)。 ユーザー定義ルート (UDR) は、同じまたはより具体的なプレフィックス (別の /32) を持つシステム ルートのみをオーバーライドできます。

• NVA に送信トラフィックをルーティングする場合、NVA は送信元ネットワーク アドレス変換 (SNAT) を適用して、クライアントに直接移動するのではなく、リターン パケットが NVA に戻るようにする必要があります。 SNAT がない場合、戻りパスは非対称です。

• プライベート エンドポイント ネットワーク ポリシー (プライベート エンドポイント サブネットでの NSG と UDR のサポート) は、既定で無効になっています。 プライベート エンドポイント トラフィックに NSG または UDR ルールを適用するには、サブネットでネットワーク ポリシーを有効にします。

  az network vnet subnet update \
    --name <SubnetName> \
    --vnet-name <VNetName> \
    --resource-group <ResourceGroup> \
    --private-endpoint-network-policies Enabled
  

NVA なしで接続が機能するが、1 つ経由でルーティングされるとタイムアウトになった場合、 /32 システム ルートはリターン トラフィックをクライアントに直接送信し、NVA 状態テーブルをバイパスします。 NVA を指すプライベート エンドポイント IP の /32 UDR を追加し、NVA で SNAT を有効にします。

手順 5: Network Watcherを使用してエンド ツー エンド接続を確認する

前の手順が正しく見えても接続が失敗する場合は、Azure Network Watcher を使用してエラーを分離します。

クイック リファレンス

ネットワーク接続終了エラー

SQL クライアント ライブラリは、TCP ネットワーク プロトコルを使用して、Azure SQL Database と Azure SQL Managed Instance に接続されます。 クライアント ライブラリでは、TCP プロバイダーと呼ばれる下位レベルのコンポーネントを使用して、TCP 接続を管理します。 リモート ホストで既存の TCP 接続が予期せず終了したことが TCP プロバイダーで検出されると、クライアント ライブラリでエラーが発生します。 そのエラーはクライアントのエラーであり、SQL サーバーのエラーではないため、SQL エラー番号は含まれません。 代わりに、エラー番号は 0 で、TCP プロバイダーからのエラー メッセージが使用されます。

例として、次のようなネットワーク接続終了エラーが挙げられます。

A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.) An existing connection was forcibly closed by the remote host

A transport-level error has occurred when sending the request to the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)

The client was unable to establish a connection because of an error during connection initialization process before login. Possible causes include the following: the client tried to connect to an unsupported version of SQL Server; the server was too busy to accept new connections; or there was a resource limitation (insufficient memory or maximum allowed connections) on the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)

A connection was successfully established with the server, but then an error occurred during the login process. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)

データベースまたはエラスティック プールが一時的に使用できないことが原因で、接続終了エラーが発生することがあります。 また、ファイアウォール、ネットワーク アプライアンスなど、データベース サーバーとクライアント アプリケーションの間のネットワーク インフラストラクチャのさまざまな問題が原因で発生することもあります。これらの問題は、一時的である場合もあれば、永続的である場合もあります。 一般的なガイダンスとして、アプリケーションでは、それらを永続的なエラーと見なす前に、そのようなエラーに対して固定された数の再試行回数を使用することをお勧めします。

リソース ガバナンス エラー

Azure SQL Database では、Resource Governor に基づくリソース ガバナンスの実装を使用して、リソース制限を適用します。 Azure SQL Database でのリソース管理について詳細を確認してください。

最初に、最も一般的なリソース ガバナンスのエラーを、詳細と共に列挙します。それに続いて、リソース ガバナンスのエラー メッセージの表を示します。

エラー 10928 と 10936: リソース ID : 1。 [データベースまたはエラスティック プール] の要求制限 %d に達しました

データベース レベルの制限に達すると、この場合の詳細なエラー メッセージは次のようになります。Resource ID : 1. The request limit for the database is %d and has been reached. See 'http://go.microsoft.com/fwlink/?LinkId=267637' for assistance.

エラスティック プールの制限に達すると、この場合の詳細なエラー メッセージが表示されます。 Resource ID : 1. The request limit for the elastic pool is %d and has been reached. See 'http://go.microsoft.com/fwlink/?LinkId=267637' for assistance. エラスティック プールの制限がデータベースの制限を超えています。詳細については、「 Azure SQL Database でのリソース管理」を参照してください。 プール内の複数のデータベースでリソース (ワーカーなど) が同時に使用される場合、制限が適用される場合があります。

このエラー メッセージは、データベースまたはエラスティック プールのワーカーの制限に達したことを示しています。 プレースホルダー %d の代わりに、データベースまたはエラスティック プールのサービス目標の最大同時実行ワーカー数の値が示されます。

必要な場合は専用管理者接続 (DAC) で接続する

ワーカーの制限に達したライブ インシデントが進行中の場合は、 SQL Server Management Studio (SSMS) を使用して接続するときにエラー 10928 が発生する可能性があります。 ワーカーの最大しきい値に達した場合でも、データベース管理者用の診断接続 (DAC) を使用して 1 つのセッションで接続できます。

SSMS から DAC との接続を確立するには:

• メニューから [ファイル] > [新規] > [データベース エンジン クエリ] の順に選択します
• [サーバー名] フィールドの [接続] ダイアログ ボックスで、admin:<fully_qualified_server_name> を入力します (admin:servername.database.windows.net など)。
• [オプション >>] を選択します
• [接続プロパティ] タブを選択します
• [データベースへの接続:] ボックスに、データベースの名前を入力します
• [接続] を選択します。

エラー 40613、Database '%.*ls' on server '%.*ls' is not currently available. Please retry the connection later. If the problem persists, contact customer support, and provide them the session tracing ID of '%.*ls'、が表示される場合、これは、既に別のセッションが DAC に接続されていることを示している可能性があります。 1 つのデータベースまたはエラスティック プールのための DAC に一度に接続できるセッションは 1 つだけです。

[接続] の選択後に "サーバーに接続できませんでした" というエラーが発生したとしても、バージョンが 18.9 より前のバージョンの SSMS を使用している場合は、DAC セッションが正常に確立されている可能性があります。 初期バージョンの SSMS では、DAC への接続に Intellisense を提供しようとしていました。 DAC でサポートしているのは 1 つのワーカーのみで、Intellisense には別のワーカーが必要なため、これは失敗しました。

SSMS では、オブジェクト エクスプローラーで DAC 接続を使用することはできません。

max_worker_percent の使用状況を確認する

データベースのリソース消費量統計を 14 日間分見つけるには、sys.resource_stats システム カタログ ビューに対してクエリを実行します。 max_worker_percent 列には、データベースのワーカーの制限に関連して、使用されているワーカーの割合が示されます。 master上の データベースに接続し、sys.resource_stats に対してクエリを実行します。

SELECT start_time, end_time, database_name, sku, avg_cpu_percent, max_worker_percent, max_session_percent 
FROM sys.resource_stats;

sys.dm_db_resource_stats 動的管理ビューから、過去 1 時間のリソース消費量統計のクエリを実行することもできます。 データベースに直接アクセスして sys.dm_db_resource_stats のクエリを実行します。

SELECT end_time, avg_cpu_percent, max_worker_percent, max_session_percent
FROM sys.dm_db_resource_stats;

可能な場合はワーカーの使用量を削減する

ブロッキング チェーンにより、データベース内のワーカーの数が急激に増加する場合があります。 同時並列クエリが大量にあると、多数のワーカーを発生させる可能性があります。 並列処理の最大限度 (MAXDOP) を増やしたり、MAXDOP を 0 に設定したりすると、アクティブなワーカーの数が増加する可能性があります。

以下の手順に従って、ワーカー数が不十分であることによるインシデントをトリアージします。

1. ブロッキングが発生しているか、大量の同時実行ワーカーを識別できるかを調査します。 次のクエリを実行して現在の要求を調べ、データベースがエラー 10928 を返しているときにブロッキングがないか調べます。 クエリを実行するには、専用管理者接続 (DAC) に接続する必要がある場合があります。

   SELECT
       r.session_id, r.request_id, r.blocking_session_id, r.start_time, 
       r.status, r.command, DB_NAME(r.database_id) AS database_name,
       (SELECT COUNT(*) 
           FROM sys.dm_os_tasks AS t 
           WHERE t.session_id=r.session_id and t.request_id=r.request_id) AS worker_count,
       i.parameters, i.event_info AS input_buffer,
       r.last_wait_type, r.open_transaction_count, r.total_elapsed_time, r.cpu_time,
       r.logical_reads, r.writes, s.login_time, s.login_name, s.program_name, s.host_name
   FROM sys.dm_exec_requests as r
   JOIN sys.dm_exec_sessions as s on r.session_id=s.session_id
   OUTER APPLY sys.dm_exec_input_buffer (r.session_id,r.request_id) AS i
   WHERE s.is_user_process=1;
   GO
   

   1. ブロックされているセッションを識別するため、blocking_session_id が含まれる行を探します。 一覧でそれぞれの blocking_session_id を探し、そのセッションもブロックされているかどうかを判断します。 blocking_session_id および session_id の値を追っていくと、最終的にヘッドブロッカー（自らはブロックされていないが、他をブロックしているセッション）にたどり着きます。 ヘッド ブロッカー クエリを調整します。

      ヒント

      実行時間の長いクエリまたはブロック クエリのトラブルシューティングの詳細については、「 ブロックの問題を理解して解決する」を参照してください。

   2. 大量の同時実行ワーカーを識別するには、要求全体の数と、各要求の worker_count 列を確認します。 Worker_count はサンプリングされた時点でのワーカーの数であり、要求が実行されるにつれて時間の経過とともに変化する可能性があります。 ワーカー増加の原因が、最適な程度の並列処理で実行されている同時実行クエリである場合は、リソースの使用率を下げるためにクエリを調整します。 詳しくは、「クエリの調整とヒント」をご覧ください。

2. データベースの並列処理の最大限度 (MAXDOP) 設定を評価します。

ワーカーの最大数を増やす

ブロッキングへの対処、クエリの最適化、MAXDOP 設定の検証を行っているにもかかわらず、データベースまたはエラスティック プールのワーカー数が絶えず制限に達する場合は、データベースまたはエラスティック プールをスケールアップし、ワーカーの最大数を増やすことを検討してください。

サービス レベルとコンピューティング サイズごとに、Azure SQL Database のリソース制限を確認してください。

• 仮想コア購入モデルを使用した単一データベースに対するリソース制限
• 仮想コア購入モデルを使用したエラスティック プールに対するリソース制限
• DTU 購入モデルを使用した単一データベースに対するリソース制限
• DTU 購入モデルを使用したエラスティック プールのリソース制限

Azure SQL Database でのワーカーのリソース ガバナンスに関する詳細を確認してください。

エラー 10929:リソース ID:1

10929: Resource ID: 1. The %s minimum guarantee is %d, maximum limit is %d and the current usage for the database is %d. However, the server is currently too busy to support requests greater than %d for this database. See http://go.microsoft.com/fwlink/?LinkId=267637 for assistance. Otherwise, please try again later.

エラー 40501:サービスは現在ビジー状態です

40501: The service is currently busy. Retry the request after 10 seconds. Incident ID: %ls. Code: %d.

エラー 40501 は、リソースの制限を超えていることを示すエンジン調整エラーです。

リソース制限の詳細については、「Azure SQL データベースのリソース管理」を参照してください。

エラー 40544:データベースのサイズ クォータに達しました

40544: The database has reached its size quota. Partition or delete data, drop indexes, or consult the documentation for possible resolutions. Incident ID: <ID>. Code: <code>.

このエラーは、データベースのサイズ クォータに達したときに発生します。

以下の手順は、問題を回避したり、より多くのオプションを提供したりするのに役立つ場合があります。

1. Azure portal のダッシュボードを使用して、データベースの現在のサイズを確認します。

   注

   最も多くの領域を消費しているため、クリーンアップの候補となるテーブルを特定するには、次の SQL クエリを実行します。

   SELECT o.name,
    SUM(p.row_count) AS 'Row Count',
    SUM(p.reserved_page_count) * 8.0 / 1024 AS 'Table Size (MB)'
   FROM sys.objects o
   JOIN sys.dm_db_partition_stats p on p.object_id = o.object_id
   GROUP BY o.name
   ORDER BY [Table Size (MB)] DESC;
   GO
   

2. 現在のサイズが、使用しているエディションでサポートされている最大サイズを超えていない場合は、ALTER DATABASE を使用して MAXSIZE の設定を増やすことができます。

3. データベースが、使用しているエディションでサポートされている最大サイズを既に超えている場合は、次の 1 つまたは複数の手順を試してください。

   • 通常のデータベース クリーンアップ アクティビティを実行します。 たとえば、truncate/delete を使用して不要なデータをクリーンアップしたり、SQL Server Integration Services (SSIS) または一括コピー プログラム (bcp) ユーティリティを使用してデータを移動したりします。
   • データをパーティション分割するか、データを削除するか、インデックスを削除してください。その他の解決方法についてはドキュメントを参照してください。
   • データベースのスケーリングについては、単一データベースのリソースのスケーリングに関する記事と、エラスティック プールのリソースのスケーリングに関する記事を参照してください。

エラー 40549:トランザクションが長時間実行されているため、セッションを終了しました

40549: Session is terminated because you have a long-running transaction. Try shortening your transaction.

このエラー メッセージが繰り返し表示される場合は、これらの手順に従って問題を解決してみてください。

1. 次のクエリを実行して、開いているセッションのうち、duration_ms 列の値が高いものをすべて表示します。

   SELECT
       r.start_time, DATEDIFF(ms,start_time, SYSDATETIME()) as duration_ms, 
       r.session_id, r.request_id, r.blocking_session_id,  
       r.status, r.command, DB_NAME(r.database_id) AS database_name,
       i.parameters, i.event_info AS input_buffer,
       r.last_wait_type, r.open_transaction_count, r.total_elapsed_time, r.cpu_time,
       r.logical_reads, r.writes, s.login_time, s.login_name, s.program_name, s.host_name
   FROM sys.dm_exec_requests as r
   JOIN sys.dm_exec_sessions as s on r.session_id=s.session_id
   OUTER APPLY sys.dm_exec_input_buffer (r.session_id,r.request_id) AS i
   WHERE s.is_user_process=1
   ORDER BY start_time ASC;
   GO
   

   input_buffer 列に sys.fn_MSxe_read_event_stream から読み取るクエリが表示される行は、無視することもできます。これらの要求は、拡張イベント セッションに関連しています。

2. blocking_session_id 列を調べて、ブロッキングが実行時間の長いトランザクションの原因となっているかどうかを確認します。

   注

   Azure SQL Database でのブロックのトラブルシューティングの詳細については、「ブロックの 問題を理解して解決する」を参照してください。

3. クエリをバッチ処理することを検討してください。 バッチ処理に関する詳細は、「バッチ処理を使用して Azure SQL データベースと Azure SQL Managed Instance アプリケーションのパフォーマンスを強化する方法」を参照してください。

エラー 40551: tempdb の使用量が多すぎるため、セッションを終了しました

40551: The session has been terminated because of excessive TEMPDB usage. Try modifying your query to reduce the temporary table space usage.

この問題を回避するには、次の手順に従ってください。

1. クエリを変更して、一時テーブル領域の使用量を減らします。
2. 不要になった一時オブジェクトを削除します。
3. テーブルを切り捨てるか、使用されていないテーブルを削除します。

エラー 40552:トランザクション ログの使用領域が多すぎるため、セッションを終了しました

40552: The session has been terminated because of excessive transaction log space usage. Try modifying fewer rows in a single transaction.

この問題を解決するには、次の方法を試してください。

• この問題は、挿入、更新、または削除の各操作が原因で発生する可能性があります。 バッチ処理を実装したり、複数の小さなトランザクションに分割したりして、すぐに操作される行の数を減らしてみてください。
• この問題は、インデックスの再構築操作によって発生する可能性があります。 この問題を回避するには、テーブルで影響を受ける行の数 * (更新されるフィールドの平均サイズ (バイト単位) + 80) < 2 ギガバイト (GB) であることを確認します。
• インデックスの再構築の場合は、更新されるフィールドの平均サイズを、平均インデックス サイズに置き換える必要があります。
• 詳細については、「 Azure SQL Database でのフル トランザクション ログのトラブルシューティング」と「Azure SQL Managed Instance でのフル トランザクション ログのトラブルシューティング」を参照してください。

エラー 40553:メモリの使用量が多すぎるため、セッションを終了しました

40553: The session has been terminated because of excessive memory usage. Try modifying your query to process fewer rows.

この問題を回避するには、クエリを最適化してみてください。

詳細なトラブルシューティング手順については、「クラウドでクエリが正常に実行されているか」を参照してください。

他のメモリ不足エラーおよびサンプル クエリについて詳しくは、「Azure SQL Database によるメモリ不足エラーのトラブルシューティング」を参照してください。

リソース ガバナンスのエラー メッセージの表

エラスティック プールのエラー

次のエラーは、エラスティック プールの作成と使用に関連しています。

このログインで要求されたデータベース "master" を開けません。 ログインに失敗しました

この問題は、アカウントに master データベースにアクセスするアクセス許可がないために発生します。 しかし、既定では、SQL Server Management Studio (SSMS) で master データベースへの接続が試行されます。

この問題を解決するには、次の手順に従ってください。

1. SSMS のログイン画面で [オプション] を選択してから、 [接続プロパティ] を選択します。

2. [データベースに接続] フィールドで、既定のログイン データベースとしてユーザーの既定のデータベース名を入力し、 [接続] を選択します。

   

読み取り専用エラー

読み取り専用のデータベースに書き込もうとすると、エラーが発生します。 状況によっては、データベースが読み取り専用状態になっている原因が、すぐにわからないことがあります。

エラー 3906: データベース 'databaseName' を更新できませんでした。データベースが読み取り専用です。

読み取り専用データベースを変更しようとすると、次のエラーが発生します。

Msg 3906, Level 16, State 2, Line 1
Failed to update database "%d" because the database is read-only.

データベースが読み取り専用である理由については、複数の要因が考えられます。

手動フェールオーバー後も、アプリケーションは引き続き古いレプリカに接続しています

Azure SQL Database では、別のレプリカへのフェールオーバー後も、DNS が原因でアプリケーションが以前のプライマリ レプリカに接続している可能性があります。 フェールオーバー グループの接続ルーティングは、DNS を使用して実装されます。

考えられる根本原因

1. フェールオーバー中、フェールオーバー グループ エンドポイントは、適切な DNS エントリのターゲットを変更することで、適切な新しいプライマリ サーバーと新しいセカンダリ サーバーを指すよう更新されます。 既定では、DNS エントリは TTL が 30 秒で作成されます。つまり、DNS クライアントはこれらのエントリを 30 秒間キャッシュします。 その結果、DNS レコードの更新はすぐに反映されません。エントリは、すべてのクライアントと中間ノードがキャッシュを更新するまで以前の状態のままです。 そのため、フェールオーバー後、フェールオーバー グループ エンドポイントへのログインが新しいターゲットにルーティングされるまでの時間は、(ネットワーク トポロジに応じて) 0 から約 10 分となります。 DNS 要求に応答する中間ネットワーク ノードも DNS の結果を一定期間キャッシュするため、DNS キャッシュのフラッシュは問題解決に役立つ場合もあれば、役に立たない場合もあります。

   この問題の推奨される回避策は、クライアントで DNS エントリが更新されるまで待機することです。 現時点では、この回避策により、問題は 10 分以内に自己解決されます。

2. 一部の SQL クライアント ライブラリでは、"接続プール" と呼ばれる機能を使用します。この機能は、接続を閉じて再度開くのではなく、新しいデータベース接続が必要になったときに同じデータ ソースへの接続を再利用します。 特に、ADO.NET では、既定で接続プールが有効になります。 1) で説明した問題と組み合わせると、接続プーリングにより新しく開いた接続が古いデータベースへの接続を再利用するため、アプリケーションが新しいプライマリ データベースにずっと接続できなくなる場合があります。

ソリューション

フェールオーバー グループのフェールオーバー後に、この DNS 問題に対して考えられる回避策は 3 つあります。

1. "読み取り専用" エラー発生時に SQLConnection.ClearAllPools または SQLConnection.ClearPool(conn) を呼び出すアプリケーションを変更します。
2. アプリケーション 接続文字列で、Pooling=False を接続プールを無効にするように指定します。 アプリケーションが頻繁に接続を開いて閉じるとパフォーマンスに大きな影響を与える可能性があるため、これをテストする必要があります。
3. DNS レプリケーション/キャッシュの遅延を回避するもう 1 つのオプションは、3906 が発生した後の一定期間、Azure SQL Database の論理サーバー名 (以前のセカンダリ サーバー、現在は新しいプライマリ) を使用して直接接続することです。

読み取り専用レプリカに接続されている可能性がある

Azure SQL Database と Azure SQL Managed Instance のどちらの場合も、読み取り専用レプリカのデータベースに接続されている可能性があります。 この場合、DATABASEPROPERTYEX() 関数を使って次のクエリを行うと、READ_ONLY が返されます。

SELECT DATABASEPROPERTYEX(DB_NAME(), 'Updateability');
GO

SQL Server Management Studio を使用して接続している場合、ApplicationIntent=ReadOnly[追加の接続パラメーター] タブで を指定しているかどうかを確認します。

接続文字列を使ってアプリケーションまたはクライアントから接続している場合は、接続文字列で ApplicationIntent=ReadOnly が指定されているかどうかを確認します。 詳しくは、「読み取り専用レプリカに接続する」をご覧ください。

データベースが読み取り専用に設定されている可能性がある

Azure SQL Database を使っている場合は、データベース自体が読み取り専用に設定されている可能性があります。 データベースの状態は、次のクエリを使って確認できます。

SELECT name, is_read_only
FROM sys.databases
WHERE database_id = DB_ID();

Azure SQL Database のデータベースの読み取り専用状態は、ALTER DATABASE Transact-SQL を使って変更できます。 現在、マネージド インスタンスのデータベースを読み取り専用に設定することはできません。

エラーの原因が接続の問題かどうかを確認する

接続の問題が原因でエラーが発生しているかどうかを確認するには、次のような接続を開くための呼び出しを示すフレームのスタック トレースを確認します (SqlConnection クラスへの参照に注意)。

System.Data.SqlClient.SqlConnection.TryOpen(TaskCompletionSource`1 retry)
 at System.Data.SqlClient.SqlConnection.Open()
 at AzureConnectionTest.Program.Main(String[] args)
ClientConnectionId:<Client connection ID>

クエリの問題によって例外がトリガーされた場合、次のような呼び出し履歴が表示されます (SqlCommand クラスへの参照に注意)。 このような場合は、クエリを調整します。

  at System.Data.SqlClient.SqlCommand.ExecuteReader()
  at AzureConnectionTest.Program.Main(String[] args)
  ClientConnectionId:<Client ID>

パフォーマンスの微調整の詳細については、以下を参照してください。

• Azure SQL のインデックスと統計情報を管理する方法
• Azure SQL Database でアプリケーションとデータベースのパフォーマンスを調整します
• 動的管理ビューを使用してパフォーマンスを監視する
• Azure SQL Database でクエリ ストアを運用する

関連するコンテンツ

• 接続アーキテクチャ
• Azure SQL Database と Azure Synapse Analytics のネットワーク アクセスの制御
• Azure SQL Database でのフル トランザクション ログのトラブルシューティング
• Azure SQL Managed Instance でのフル トランザクション ログのトラブルシューティング
• 一時的な接続エラーのトラブルシューティング
• Azure SQL Database と Fabric SQL データベースでのデッドロックの分析と防止