セールス: 1-800-867-1380

Azure SQL データベースのリソース管理

更新日: 2015年3月

このトピックでは、Azure SQL データベース がデータベース専用リソースを制御してパフォーマンスの予測可能性を最大化する方法について説明します。各データベースに使用できるリソースの量はデータベースに割り当てられたパフォーマンス レベルに依存します。このトピックの情報を使用し、リソースの制御メカニズムを理解します。この情報は、最適なパフォーマンスが得られるようにアプリケーションを開発する際に便利です。このトピックには、各カテゴリで発生する問題に対する推奨対応案が含まれています。

Azure SQL Database では、リソース制御に 3 種類の異なるメカニズムを使用します。

  • リソース統制

    CPU、メモリ、ログの書き込み、および IOPS のクエリは、リソース統制の対象となります。新しく導入されたこのメカニズムは、上限の適用や調整とは異なり、クエリの実行を妨げたり終了したりすることはありませんが、クエリをキューに登録し、リソースが利用可能になった時点で、キューに登録されたクエリに対してリソースが割り当てられます。

  • 上限の適用

    上限は、データベースに対して開くことのできる接続数と、クエリの並列実行 (ワーカー スレッド) に対して適用されます。

  • 調整

    調整は、データベースをホストするコンピューターの負荷が深刻な量に達し、システム停止のおそれがある場合に発生します。調整はシステムが自身を過負荷から保護するための最終的な手段で、めったに発生しません。

Basic、Standard、および Premium サービス層の設計目標の 1 つは、Azure SQL Database の動作を、あたかもデータベースが他のデータベースから完全に隔離された専用のコンピューターで稼働しているかのようにすることです。リソース統制では、クエリの実行時にこの動作がエミュレートされます。リソース使用率の合計が、データベースに割り当てられた利用可能な CPU、メモリ、ログの書き込み、および IOPS クエリ リソースの最大量に達すると、実行中のクエリがリソース統制によってキューに登録され、リソースが解放されると、登録済みクエリに割り当てられます。

専用のコンピューターの場合と同様、利用可能なリソースをすべて利用すると、現在実行中のクエリの実行時間が長くなり、クライアントのタイムアウトが発生する場合があります。積極的な再試行ロジックを使用するアプリケーションや、データベースに対して高い頻度でクエリを実行するアプリケーションでは、新しいクエリを実行しようとしたときに、ワーカー スレッドが利用できないためにエラーが発生することがあります。

推奨事項: データベースの最大利用率に近づいてきたら、リソース利用率と、クエリの平均応答時間を監視します。クエリの実行時間が長くなっている場合、一般的には 3 つのオプションがあります。

  1. データベースへの受信要求を削減して、タイムアウト、およびワーカー スレッドの積み上がりを防ぎます。

  2. データベースに現在より高いパフォーマンス レベルを割り当てます。

  3. クエリを最適化して、各クエリのリソース利用率を削減します。詳細については、「Azure SQL データベースの Basic、Standard、および Premium プレビュー」の「クエリのチューニング/ヒント設定」セクションを参照してください。

Azure SQL データベース は、同時実行ワーカー スレッド (リクエスト) と各データベースの同時セッションに対する最大制限を設定して、リソース統制を行います。リソース統制メカニズムはターゲット データベースのパフォーマンス レベルによって異なります。詳細については、「Azure SQL データベース リソース統制」を参照してください。

SQL データベースへの接続数と、並列処理可能な要求の数が制限されます。SQL Database では、データベースへの接続数を同時要求の数より大きくして、接続プールをサポートすることが可能です。

利用可能な接続の数はアプリケーションで容易に制御できますが、並列要求の数を見積もって制御することは、多くの場合難しくなります。特に、アプリケーションの送信する要求が多すぎる場合や、データベースがリソース制限に達し、クエリの実行にかかる時間が長くなり、ワーカー スレッドの積み上がりが始まった場合など、ピーク時の負荷では、エラーが発生することがあります。

推奨事項: ワーカー スレッドが枯渇している場合、一般的には 3 つのオプションがあります。

  1. データベースへの受信要求を削減して、ワーカー スレッドの積み上がりを防ぎます。

  2. データベースに現在より高いパフォーマンス レベルを割り当て、より多くの同時要求を可能にします。詳細については、「Azure SQL データベースのサービス階層とパフォーマンス レベル」を参照してください。

  3. クエリを最適化して、各クエリのリソース利用率を削減します。詳細については、「Azure SQL データベースの Basic、Standard、および Premium プレビュー」の「クエリのチューニング/ヒント設定」セクションを参照してください。

次の表は、Azure SQL Database が要求を拒否するか、関連リソースへの接続を終了するリソースの制限と返されるエラー コードをまとめたものです。

 

リソース 上限 返されるエラー コード

Database Size

データベース クォータ (MAXSIZE) に応じて

40544

Memory Usage

20 秒より長い、16 MB のメモリ許可

40553

Sessions

セッションの制限は、データベースのパフォーマンス レベルに依存します。詳細については、「Azure SQL データベースのサービス階層とパフォーマンス レベル」を参照してください。

10928

Tempdb

State 1:5 GB の tempdb 領域

State 2:tempdb のトランザクションごとに 2 GB

State 3:tempdb の全ログ領域の 20%

40551

Transaction Duration

State 1:24 時間

State 2:基になるシステム タスクで必要なリソースをトランザクションがロックする場合は 20 秒

40549

Transaction Lock Count

100 万ロック (トランザクションあたり)

40550

Transaction Log Length

State 1:2 GB (トランザクションあたり)

State 2:全ログ領域の 20%

40552

Worker Threads (max concurrent requests)

同時要求の最大数は、データベースのパフォーマンス レベルに依存します。詳細については、「Azure SQL データベースのサービス階層とパフォーマンス レベル」を参照してください。

  • 10928

  • 10929

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

調整の重大度は、次の 2 段階のいずれかになります。

  • ソフト調整:これは、トランザクション ログ、I/O、ストレージなどのコンピューター リソースが、事前に定義された安全性しきい値を超えた場合の最初の段階です。SQL データベースは、ほとんどのリソースを消費しているデータベースのサブセットを選択し、そのアクティビティを調整します。調整されるのは、コンピューター上のすべてのデータベースではなく、リソースのほとんどを使用しているデータベースのみです。使用率が定義済みしきい値を下回っている場合は、サーバー上のデータベースすべてに十分なリソースがあることを意味します。

  • ハード調整:これは、コンピューターが過負荷のために深刻な影響を受けている、2 番目で最後の段階です。ハード調整では、リソースが解放されるまで、コンピューターでホストされているデータベースへの新しい接続は許可されません。新たに接続しようとすると、超過しているリソースを示すエラー メッセージが返されます。

エンジン調整メカニズムと調整エラーに対処する方法に関する推奨事項については、「Azure SQL Database の調整」を参照してください。

関連項目

この情報は役に立ちましたか。
(残り 1500 文字)
フィードバックをいただき、ありがとうございました
表示:
© 2015 Microsoft