発生しているパフォーマンスの問題が明らかになったら、この記事を読むと次のことに役立ちます。プラクティスを適用します。performance.データをより効率的に処理するようにインデックスとクエリを変更して、データベースをチューニングします。自動チューニングの推奨事項に従った作業を既に行っているものとします。監視とチューニングの概要に関する記事およびパフォーマンスの問題のトラブルシューティングに関するその関連記事を読んであるものとします。レベルを上げてデータベースに対するリソースを増やすことで解決できる実行関連のパフォーマンスの問題がないことを前提としています。多くの場合、初回の容量計画のプロセスは、運用環境でアプリケーションを実行するプロセスから分離されます。最初にハードウェアと製品ライセンスが購入され、パフォーマンス調整は後で行われます。使用する場合、アプリケーションの実行と調整のプロセスを組み合わせることをお勧めします。オンデマンド容量の支払いモデルでは、現在必要とされる最小のリソースを使用するようにアプリケーションを調整できます。アプリケーションの将来的な成長計画の推測に基づいて、ハードウェアに過剰プロビジョニングを行うことはしません。リソースを過剰にプロビジョニングすることを選ぶユーザーもいます。この方法は、利用が集中する期間に重要なアプリケーションの変更を望まない場合に適していることがあります。レベルを使用する際に毎月の請求額を抑えることができます。レベルは、アプリケーションのパフォーマンスの安定性と予測可能性を高めるように設計されています。サイズ内でリソースを最大限に活用するようアプリケーションを調整できます。レベルに切り替えることでパフォーマンスが大幅に向上します。レベルの利点を活かすためにさらに調整が必要になります。次のような特性を備えたアプリケーションでは、パフォーマンスを向上させるためにアプリケーションに調整を加えることを検討してください。アクセス操作が過度に発生します。アクセス操作の数を減らすよう変更を施す必要があります。プロシージャにクエリを移動したりするなどの手法を使って、アプリケーションのパフォーマンスを向上させることができます。クエリ」を参照してください。サイズのリソースを超えるデータベースでは、ワークロードのスケールアウトを活用できる場合があります。詳細については、「データベース間のシャーディング」と「機能的パーティション分割」を参照してください。サイズの利点を活かせないことがあります。句がない、インデックスが足りない、統計が古いクエリです。パフォーマンスの標準的な調整方法で効果が得られます。詳細については、「インデックスの不足」と「クエリの調整とヒント」を参照してください。サイズの利点を活かせないことがあります。トリップを減らすことを検討してください。アプリケーション層のキャッシュ」を参照してください。調整するいくつかの手法について説明します。サイズでアプリケーションを実行することができます。応用することができます。データベースのパフォーマンスの一般的問題は物理的なデータベース設計に関連します。規模の面で試験することなく設計され、出荷されます。プランのパフォーマンスは、規模が小さい場合には許容されることがあるものの、実稼働レベルのデータ量では大幅に低下する可能性があります。この問題の最も一般的な原因は、適切なインデックスがなく、クエリのフィルターまたはその他の制約を満たせないことにあります。スキャンが行われます。プランでスキャンが使用されます。インデックス不足の一般的な状態を発見して修正するのに役立ちます。コンパイルが表示されます。クエリを実行するために見積もられたコストをインデックスで大幅に削減できる場合があります。プランの間で見積もられるギャップが追跡されます。コストを全体的に改善できる物理データベース設計の変更をすばやく推測できます。workload.次のクエリは、潜在的なインデックス不足の評価に使用できます。DESCこの例では、クエリの結果として次が推奨されました。ステートメントを実行すると、異なるプランが選択されます。スキャンではなくシークが使用され、プランがより効率的に実行されます。容量より限られているということです。内でシステムを最大限に活用することが重要です。ユニットごとに処理される同時要求のスループットを大幅に改善し、クエリを満たすために必要なコストを最小限に抑えることができます。関する詳細については、「sys.dm_db_missing_index_details」を参照してください。オプティマイザーと似ています。活かすことができます。クエリを調整すると、総リソース要求を減らせる場合があります。サイズで実行できるため、クエリが調整されていない場合に比べて少ないコストでアプリケーションを実行できます。プランを生成できるかどうかが判断されます。プランが生成されます。両方で動作が不完全です。パラメーターがスニッフィングされなかったり、パラメーターがスニッフィングされたものの、生成されたプランがワークロードのすべてのパラメーター値に関して最適でなかったりする場合があります。既定の動作で特定のユーザーのワークロードに完全に対応できない問題を修正できます。プロセッサによって生成されるようすを示しています。データベースのクエリの実行時間とリソース要件を抑えることができることもわかります。コードによって、傾斜データ分布が含まれたテーブルが作成されます。プランは、選択されたパラメーターによって異なります。キャッシング動作では、常に最も一般的なパラメーター値に基づいてクエリが再コンパイルされるとは限りません。そのため、平均すると別のプランの方がプランとしてより良い選択になる場合でも、最適でないプランがキャッシュされ、多くの値に使用される可能性があります。プランによって作成されます。分待つことをお勧めします。データの結果の差異がはっきりします。"スニッフィング")。結果として生成されたプランがプロセッサによってキャッシュされ、パラメーター値が異なる場合でも、後の呼び出しで使用されます。最適なプランが使用されないことがあります。クエリが最初にコンパイルされたときのケースではなく、平均的なケースに対して最適なプランを選択するように、オプティマイザーを調整する必要がある場合があります。対して最適ですが、テーブルにある他のすべての値に対しては最適ではありません。各プランを無作為に選択した場合、結果は望んだものと異なることが予想されます。これは、プランの実行が遅く、より多くのリソースが使用されるためです。設定してテストを実行すると、この例の論理スキャン作業がバックグラウンドで行われます。つの場合、非効率的です)。プロセス中に特定の値を使用するようにオプティマイザーに伝えます。プロセッサに強制します。結果として生成されるプランはシークベースのプランです。プランより全体的に少なくなっています。(テストを実行してからデータがテーブルに入力されるまでの間に遅延があります)。時間枠で実行されています。(プランの効率性改善が理由)。DESC注意この例では規模を意図的に小さくしてありますが、最適でないパラメーターの影響は特に大規模なデータベースで顕著になります。極端なケースでは、速い場合は数秒単位、遅い場合は数時間単位の差異になります。調べると、あるテストで使用されるリソースが別のテストより多いか少ないか判断できます。分の枠に入らないようにテストのタイミングを離します。リソースを最小限に抑えることではありません。一般的に、待ち時間のコードの一部を最適化すると、リソースの消費量も減ります。エクスペリエンスに対し変更による悪影響がないことを確認してください。サイズ単位を把握できるため、たいてい、プラン選択肢の最適性を理解して検証することは合理的です。検証した後、プランのパフォーマンスが低くなっていないことを確認するために、ときどきプランを調べ直してください。(Transact-SQL)」をご覧ください。つのデータベースに対する容量制限が低くなります。つのデータベースの制限内に収まらないときにシャーディング手法を使用して、複数のデータベースに操作を分散しているユーザーもいます。つのディメンションのデータを複数のデータベースで分割します。行のみ、またはほんの数行から成るグループに適用されるトランザクションを実行することを理解しておく必要があります。シャーディングを支援するライブラリが追加されました。ライブラリの概要」をご覧ください。含まれている場合、関連する注文と注文明細の情報を使って顧客をグループ化することで、このデータを複数のデータベースに分割できます。つのデータベース内にとどめておくことができます。アプリケーションはデータベース間で顧客を分割し、効果的に負荷を分散します。シャーディングではソリューションの総リソース容量を減らすことはできませんが、複数のデータベースにまたがる非常に大規模なソリューションに対応する際に非常に効果的です。データベースに対応できます。つのデータベースのさまざまな機能を組み合わせます。プロシージャ、月末報告を管理するインデックス付きビュー/具体化されたビューが含まれていることがあります。この手法では、バックアップなどの操作に関するデータベースの管理が容易になりますが、アプリケーションの機能全体でピーク負荷を処理できるようにハードウェアのサイズを調整する必要もあります。アーキテクチャを使用する場合、アプリケーションの異なる機能を異なるデータベースに分割することをお勧めします。この手法を使用すると、各アプリケーションは独立してスケールされます。サイズを個別に選択できます。台の汎用コンピューターで処理できる範囲を超えてアプリケーションの規模を大きくできます。これは、複数のコンピューター間で負荷が分散されるためです。層の間で行われるネットワーク通信の応答に、相当な時間が費やされます。つの間のネットワーク待機時間は長くなる可能性があります。プロシージャとしてそれらをコンパイルすることを検討してください。プロシージャにコンパイルすると、それらを一括処理した場合と同じ結果が得られます。プロシージャを再度使用できます。again.一部のアプリケーションでは、書き込みが集中します。総負荷を減らすことができます。トランザクションではなく明示的なトランザクションを使用するのと同じくらい単純です。アプリケーションのバッチ処理手法に関する記事を参照してください。独自のワークロードで実験を行って、一括処理に適したモデルを見つけてください。モデルによってはトランザクションの整合性の保証がわずかに異なる場合があることを理解しておいてください。リソース使用を最小限に抑える適切なワークロードを見つけるには、整合性とパフォーマンスの適度なバランスを見つける必要があります。アプリケーションでは、ワークロードの大半が読み取りになります。キャッシュ層を利用すれば、データベースの負荷を減らすことができます。サイズを下げられる可能性があります。データベースの外部にそのデータを格納することができます。減らすことができるものの、トランザクションの整合性に影響があります。データがキャッシュから読み込まれると、データベースのデータとの同期が失われることがあるためです。多くのアプリケーションではある程度の不整合が許容されますが、すべてのワークロードで許容されるとは限りません。アプリケーション層のキャッシュ手法を実装する前に、あらゆるアプリケーション要件を完全に理解しておく必要があります。ベースの購入モデルに関するページを参照してください。レベルの詳細については、仮想コアベースの購入モデルに関するページを参照してください。プールの概要」を参照してください。プールの使用を検討する場合に関するページを参照してください。Articlesこのページはお役に立ちましたか?はいいいえ追加のフィードバックはありますか?スキップ送信ありがとうございます。直接フィードバックを残すこともできます。直接フィードバックを残すこともできます。Cookie利用条件サイトのフィードバック商標このページはお役に立ちましたか?はいいいえ追加のフィードバックはありますか?スキップ送信ありがとうございます。Cookie利用条件サイトのフィードバック。