このページは役に立ちましたか。
このページのコンテンツについての ご意見をお待ちしております
その他にご意見はありますか。
残り 1500 文字
エクスポート (0) 印刷
すべて展開

Azure SQL Database の調整

更新日: 2015年2月

このトピックでは、エンジン調整のメカニズム、関連するエラー コード、および発生する可能性があるエラーの対処方法について詳しく説明します。

次の表は、エンジン調整のメカニズム、それに対して返されるエラー コード、および推奨される対処方法についてまとめたものです。

 

エンジン調整のメカニズム 返されるエラー コード 推奨事項

エンジン調整は、次の手順で負荷を軽減し、システムの正常性を保護します。

  1. システムを正常な状態に戻すために必要な負荷の軽減を判断します。

  2. 過度にリソースを消費しているサブスクライバー データベースを調整の候補としてマークします。エンジン調整がわずかな超過のために発生する場合、特定のデータベースは調整の候補から除外されることがあります。エンジン調整が大幅な超過のために発生する場合、現在の調整サイクルの直前の調整サイクル中に負荷を受けなかったサブスクライバー データベースを除き、すべてのサブスクライバー データベースが調整の候補になりえます。

  3. 候補データベースによるリソースの使用パターンの履歴を評価して、システムを正常な状態に戻すためにはいくつの候補データベースを調整する必要があるかを計算します。

  4. システムの負荷が望ましいレベルに戻るまで、計算された数の候補データベースを調整します。調整がハード調整ソフト調整かに応じて、適用される調整の程度や調整モードが変わります。適用される調整の程度とモードを確認するには、エラー メッセージのインシデント ID とコード値を使用します。調整されたデータベースは、少なくとも 1 調整サイクル (10 秒) の期間、調整された状態のままになりますが、システムを正常な状態に戻すために調整が複数の調整サイクルにわたって続くことがよくあります。

40501: サービスは現在ビジー状態です。10 秒後に要求を再試行してください。インシデント ID: <ID>。コード: <コード>。

noteメモ
インシデント IDコード値を使用すると、どの要求が調整されたかと、それがソフト調整かハード調整かを判断できます。詳細については、このトピックの後の方の「調整インシデント ID」および「理由コードの解読」を参照してください。

バックオフして、10 秒後に要求を再試行してください。

エラー 40501 で報告される調整インシデント ID は、調整インシデントを一意に識別する GUID 値です。

40501: The service is currently busy. Retry the request after 10 seconds. Incident ID: <ID>. Code: <code>.

調整が行われた理由を特定できない場合、または調整が行われ続けて解決方法がわからない場合は、Microsoft サポートに問い合わせて、エラー メッセージに含まれているインシデント ID (<ID>) をお知らせください。Microsoft サポートはこのインシデント ID を使用して、発生した調整インシデントに関連する詳細情報を取得します。インシデント ID は、次のような情報を取得するために使用できます。

  • 調整インシデントの開始時刻。

  • 調整の種類 (ソフト調整またはハード調整)。

  • 調整インシデントが生じる原因になったリソースの種類 (CPU など)。

  • 調整インシデントの発生時に、ユーザーが何を実行していたか。

根本的原因に関する情報をマイクロソフト カスタマー サポートから受け取ったら、アプリケーションに対して適切な変更を行います。

ここでは、次のエンジン調整エラー コードによって返される理由コードの解読方法について説明します。

40501: The service is currently busy. Retry the request after 10 seconds. Incident ID: <ID>. Code: <code>.

エラー メッセージの理由コード (<コード>) は、調整モードと超過したリソースの種類についての情報を表す 10 進数値です。

  • 調整モードは、拒否されたステートメントの種類を列挙します。

  • リソースの種類は、超過したリソースを示します。調整は、CPU と IO など、複数のリソースの種類で同時に発生することがあります。

理由コードが 131075 である、次のサンプル エラー メッセージを例として考えてみましょう。

40501: The service is currently busy. Retry the request after 10 seconds. Incident ID: {5DE17AB8-A6E34BE5-A2E95BB5D4CC4155}. Code: 131075.

次の図は、理由コードの解読方法を示しています。

理由コードの解読

調整モードを取得するには、理由コードに 4 の剰余を適用します。剰余演算は、ある値を別の値で除算した結果の余りを返します。調整の種類とリソースの種類を取得するには、手順 1. のように理由コードを 256 で除算します。次に、手順 2 と手順 3 のように、結果をそれに等しい 2 進数値に変換します。図には、すべての調整の種類とリソースの種類が示されています。図に示すリソースの種類のビットと調整の種類を比較してください。

次の表は、調整モードの一覧を示します。

 

調整モードのコード 説明 拒否されたステートメントの種類 まだ処理できるステートメント

0

調整なし

なし

すべて

1

更新/挿入の拒否

INSERT、UPDATE、CREATE TABLE | INDEX

DELETE、DROP TABLE | INDEX、TRUNCATE

2

すべての書き込みの拒否

INSERT、UPDATE、DELETE、CREATE、DROP

SELECT

3

すべて拒否

すべて

なし

調整モードを取得するには、理由コードに 4 の剰余を適用します。131075 % 4 = 3 です。結果 "3" は、調整モードが "すべて拒否" であることを意味しています。

調整の種類およびリソースの種類を取得するには、理由コード 256 を除算します。次に、結果をそれに等しい 2 進数値に変換します。131075 / 256 = 512 (10 進数) and 512 (10 進数) = 10 00 00 00 00 (2 進数).これは、データベースが CPU (リソースの種類: 4) およびハード調整 (10) で調整されたことを意味します。

次のサンプル コードは、Enterprise Library Integration Pack for Azure の一時エラー処理アプリケーション ブロック ("Topaz" とも呼ばれます) の ThrottlingCondition クラスを使用して、エンジン調整エラー (40501) の理由コードを解読します。ThrottlingCondition クラスを使用するための一時エラー処理アプリケーション ブロック アセンブリとソース コードをダウンロードするには、「Enterprise Library 5.0 Integration Pack for Azure」を参照してください。

次のサンプル コードは、ユーザーにエンジン調整エラー (40501) で取得した理由コードを入力するように求めて、指定された理由コードの調整モード、調整の種類、およびリソースの種類を表示します。

using System;
using Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling.Data;

namespace ThrottlingDecoder
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.Write("Enter a throttling code to be decoded: ");
            var rawCode = Console.ReadLine();
            int reasonCode;

            if (Int32.TryParse(rawCode, out reasonCode))
            {
                var throttlingCode = ThrottlingCondition.FromReasonCode(reasonCode);

                Console.WriteLine("\nBreakdown for throttling reason code {0}:\n", reasonCode);

                Console.WriteLine("Throttling mode: {0}", throttlingCode.ThrottlingMode);
                Console.WriteLine("Throttled On CPU: {0}", throttlingCode.IsThrottledOnCpu);
                Console.WriteLine("Throttled On DB Size: {0}", throttlingCode.IsThrottledOnDatabaseSize);
                Console.WriteLine("Throttled On DB Reads: {0}", throttlingCode.IsThrottledOnDataRead);
                Console.WriteLine("Throttled On DB Free space: {0}", throttlingCode.IsThrottledOnDataSpace);
                Console.WriteLine("Throttled On Log Free Size: {0}", throttlingCode.IsThrottledOnLogSpace);
                Console.WriteLine("Throttled On Log Writes: {0}", throttlingCode.IsThrottledOnLogWrite);
                Console.WriteLine("Throttled On Worker Threads: {0}", throttlingCode.IsThrottledOnWorkerThreads);
                
                Console.WriteLine("\nThrottled resources:");

                foreach (var res in throttlingCode.ThrottledResources)
                {
                   if (res.Item2 != ThrottlingType.None) Console.ForegroundColor = ConsoleColor.Red;
                    Console.WriteLine("Resource type {0} is throttled on {1}", res.Item1, res.Item2);
                    if (res.Item2 != ThrottlingType.None) Console.ResetColor();
                }
            }
            else
            {
                Console.WriteLine("Sorry, but the input you provided does not seem to be a valid number.");
            }
            Console.Read();
        }
    }
}

SQL データベースの TDS ゲートウェイは、失敗を報告する前に約 30 秒間、接続を再試行します。アプリケーション トラフィックが大量になることが予想される場合は、アプリケーション内に再試行ロジックを組み込みます。接続が失敗した場合は、次のように対処します。

  • アイドル状態と一時的な接続解除状態を処理します。

    noteメモ
    切断された接続をアプリケーションに返す SqlClient の問題を修正する、.NET Framework 4.0 の信頼性に関する更新プログラム 1 をインストールします。この更新プログラムにより、SqlClient はプール内の接続をアプリケーションに返す前に、その接続が切断されているかどうかを確認します。接続が切断されている場合、SqlClient はそれを再接続してからアプリケーションに返します。この問題の詳細については、「SQL Azure での接続プール エラーの最小化」を参照してください。

  • リソースが使用可能になって接続が再確立されるまで、10 秒間隔で SQL データベースへの接続を再試行します。アプリケーション、データベース、およびネットワーク ワークロードによっては、必要に応じて遅延時間を増やす必要があります。

  • 接続が再び終了される場合は、ワークロードを変更します。接続が再び終了される場合は、エラー コードを確認し、実際の問題を調査して、ワークロードを変更してみます。ワークロードを減らすには、クライアント アプリケーションにキューまたは遅延メカニズムを実装します。

    別のソリューションとしては、アプリケーションおよびデータベースを再設計して、リソース ボトルネックを解消することが考えられます。アプリケーションが過剰な DDL または DML 操作によって tempdb に負荷をかけ過ぎないようにします。また、トランザクションによってリソースがブロックされないようにします。必要に応じて、データベースを複数のデータベースにパーティション分割することを検討してください。

  • コードが調整から復旧できるようにします。ユーザーは、アプリケーションでいつでも接続を切断できると考えています。そのため、できるだけ、1 つのトランザクションでバッチ要求を作成するようにします。そうすることで、バッチの部分的な完了によってデータベースが予期していない未テストの状態になるケースを最小限に抑えることができます。そのためには、各アドホック バッチの周囲と、各ストアド プロシージャの開始と終了位置に、BEGIN TRANS/COMMIT TRANS を配置します。

  • 再試行ロジックがアプリケーションの正しい動作にどのように影響するかを理解します (べき等性)。更新や挿入の実行時に、成功が返される前に接続が切断された場合にどうなるかを理解しておくことが重要です。トランザクションが中止された場合、接続を再試行することは適切な手順です。トランザクションが実際にはコミットされた場合は、トランザクションの再実行が正しくないことがあります。非べき等性の変更を行うユーザーは、切断からの保護のために使用されている再試行ロジックに基づいてトランザクションのコミットの繰り返しを検出できるように、論理データベース スキーマを変更しなければならない場合があります。

再試行コードを使用して調整エラーをログ記録し、一時的な接続、調整およびハード障害、構文エラー、不明なストアド プロシージャなどを区別します。これは、SQL データベースに接続できない場合のトラブルシューティング シナリオに特に便利です。この場合、トラブルシューティングの作業はログ記録された情報が中心になります。効果的なトラブルシューティングができるかどうかは、ログ記録された情報の品質にかかっています。SQL データベース アプリケーションでのログ記録の実装の詳細については、「SQL データベース アプリケーション用のログ記録の実装」を参照してください。

関連項目

表示:
© 2015 Microsoft