SQL Server の適切な環境設定を確認する方法

この資料の内容

概要

この資料では以下の環境設定およびその使用方法に関する注意事項について説明します。

  • affinity mask

  • lightweight pooling

  • max async IO

  • max worker threads

  • メモリ

  • priority boost

  • set working set size

SQL Server では、比較的少数の環境設定をチューニングするだけで、非常に高いレベルのパフォーマンスが得られます。 大規模な構成チューニングではなく、優れたアプリケーションおよびデータベース設計を使用することで、高いレベルのパフォーマンスを得ることができます。 さまざまな SQL Server のパフォーマンスに関する問題を解決する方法の詳細については、この資料の「関連情報」を参照してください。


パフォーマンスの問題に対処する場合、現在システムを適切に構成していない限り、構成の調整から得られる改善の程度は通常わずかです。 SQL Serverバージョン7.0以降では、SQL Serverは自動構成チューニングを使用します。構成設定(特に詳細設定)に変更が必要になることはほとんどありません。 通常、SQL Server の環境設定の変更は、変更を避けられない理由があり、かつ入念に計画したテストを行い、環境設定を変更する必要性が確認できている場合にのみ行います。 環境設定の変更後の利点を評価できるように、環境設定の変更を行う前に、ベースラインを確立する必要があります。


SQL Server が適切に設定されていないと、一部の環境設定によってサーバーの安定性が損なわれることや、SQL Server の動作が不安定になることがあります。 長年にわたるさまざまな環境に対するサポートの経験により、既定以外の環境設定を使用すると、その結果が不明のものから非常に望ましくない悪影響まで、さまざまな結果がもたらされる可能性があることがわかっています。

環境設定を変更する場合、変更の前後に厳密に計画したパフォーマンスのテストを行って、改善の程度を評価する必要があります。

実際のサポート事例によると、SQL Server 7.0 以降では手動で環境設定をチューニングせずに、非常に高いレベルのパフォーマンスが得られることがわかっています。

SQL Serverバージョン7.0以降では、ユーザー接続、ロック、およびオープンオブジェクトの設定を変更しないでください。デフォルトでは、SQL Serverはこれらの設定を動的に調整します。

affinity mask

affinity mask の設定は、スレッドが特定の CPU にどの程度緊密にバインドされているかを表しています。 デフォルトでは、Microsoft Windows NTとMicrosoft Windows 2000は「ソフト」アフィニティを使用します。これは、最後に実行されたCPU上のスレッドを再スケジュールしようとします。 前回の CPU に再スケジュールできない場合は別の CPU で実行されることがあります。

実際には、affinity mask の既定の設定を変更すると、パフォーマンスが向上することはほとんどなく、多くの場合、パフォーマンスは低下します。

affinity mask では SQL Server の実行を使用可能な CPU のサブセットに制限し、競合する他のサービスにより多くの CPU の使用機会を与えます。 SQL Serverは通常の優先順位で実行されるため、ほとんどの場合、これは不要です。 Windows NTまたはWindows 2000のスレッドスケジューラは、競合するすべてのスレッドのスレッド優先順位を動的に調整して、使用可能なすべてのCPUで確実に公平になるようにします。

きわめて例外的な場合を除き、affinity mask は調整しないでください。 affinity mask を調整する場合、変更の前後に厳密に計画したテストを行って、改善の必要性と改善の程度を確認する必要があります。


lightweight pooling

既定では、SQL Server ではアクティブな SPID またはユーザー プロセスごとに 1 つのスレッドを使用します。 これらのスレッドはプールされた構成で動作し、スレッドの数を管理できるようにしています。 高度な設定オプション "lightweight pooling"( "ファイバーモード"とも呼ばれます)は、Windows NTの "ファイバー"サポートを使用して、基本的に単一スレッドで複数の実行コンテキストを処理します。


実際の運用によると、きわめて例外的な場合を除き、ファイバー モードを使用する必要はありません。 軽量プーリングは、以下の条件がすべて満たされている場合にのみ、潜在的に有用です。 慎重に管理されたテストを通して、それが実際に役立つかどうかを判断しなければなりません。

  • 大容量のマルチプロセッサ サーバーを使用している場合

  • すべてのサーバーが最大容量に達しているか、または最大に近い容量で動作している場合

  • 多数のコンテキスト切り替え (毎秒 20,000 回以上) が発生している場合

コンテキスト切り替えを検索するには、パフォーマンス モニターで Thread オブジェクトの Context switches/sec" カウンターを選択し、すべての SQL Server インスタンスを監視します。

ファイバー モードでサーバーを実行する場合、SQL Server 2000 または SQL Server 2005 の SQL Mail はサポートされません。 SQL Mail は、64 ビット版の SQL Server 2000 ではサポートされません。 詳細については、SQL Server 2000 (64 ビット版) Books Online の「64 ビット リリースの 32 ビット リリースとの相違点 (64 ビット)」を参照してください。
関連情報を参照するには、以下の「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。

308604 PRB: ファイバー モードでサーバーを実行すると SQLMail がサポートされない

303120 [FIX]: 軽量プーリングを使用するとConnectionWriteエラーが発生する

max async IO

SQL Server 7.0 の場合: SQL Server 7.0 では、max async IO の環境設定を使用できます。 高速 RAID システムとその利点を評価する方法がある場合には、この環境設定の変更が適切な場合があります。 結果を評価するベースラインがない場合は、この設定を変更しないでください。 ディスクの利用状況を監視して、ディスクのキューイングを発生させている問題を特定します。 関連情報については、SQL Server Books Online の以下のトピックを参照してください。

  • max async IO オプション

  • ディスク利用状況の監視

  • パフォーマンス監視の例 :ボトルネックの特定

SQL Server 2000 以降の場合: SQL Server 2000 以降では、max async IO の環境設定を変更できません。 SQL Server 2000 以降では、この環境設定は自動的にチューニングされます。

max worker threads

既定では、SQL Server 2000 では、max worker threads の設定は 255 です。 したがって、最大255個のワーカースレッドを作成できます。 ほとんどの場合に既定の設定 255 を使用します。 これは、確立できるユーザー接続が 255 のみという意味ではありません。 システムは何千ものユーザー接続(基本的には255のワーカースレッドまで多重化されています)を持つことができ、一般的に、ユーザーは一般に遅延を感じません。 このような場合、同時に実行できるクエリは255個だけですが、これは使用可能なCPUの数まで多重化されるため、構成されたワーカースレッドの数に関係なく、並行性は認識されるだけです。

注: 既定では、SQL Server 2005 および SQL Server 2008 の max worker threads 設定は 0 です。

ワーカー スレッドの数を既定の設定よりも大きな値に設定すると、ほとんどの場合、スケジュールとリソースのオーバーヘッドにより、生産性が低下し、パフォーマンスが低下します。 きわめて例外的な場合、および厳密に計画したテストにより、この設定値の増加が有効であることが確認できた場合にのみ、この設定値を増やします。


メモリ


メモリ設定の詳細については、SQL Server Books Online のトピック「メモリ設定オプションを使用したサーバー パフォーマンスの最適化」を参照してください。

クラスター化された SQL Server のメモリ設定の詳細については、SQL Server Books Online のトピック「フェールオーバー クラスタの作成」の「使用上の注意」を参照してください。

関連情報を参照するには、以下の「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。

274750 SQL Server で 2 GB を超えるメモリを構成する方法

224818 SQL Server 7.0 と Exchange 5.5 Service Pack 2 の両方が BackOffice Small Business Server 4.5 にインストールされている場合、簡単なメモリ チューニングを行う必要がある

316749 PRB: 多数のデータベースを含むシステムで仮想メモリが不足することがある

priority boost

デフォルトでは、[優先度の向上] の設定は0です。これにより、SQL Serverを単一プロセッサのコンピュータでも対称型マルチプロセッサ(SMP)コンピュータでも、通常の優先順位でSQL Serverを実行できます。 priority boost を 1 に設定すると、SQL Server プロセスは高い優先度で実行されます。 この設定により、SQL Server プロセスがオペレーティング システムの最高の優先度で処理されることはありません。

実際のサポート事例によると、パフォーマンスを向上させるために priority boost を使用する必要はありません。 priority boost を使用すると、一部の状況においてはサーバーの正常な動作を妨げることがあります。そのため、きわめて例外的な場合を除き、priority boost を使用しないでください。 例外的な状況としては、Microsoft Product Support Services が、パフォーマンスの問題を調査する際に priority boost を使用する場合が挙げられます。

重要: SQL Server 7.0 以降を実行中のクラスター化されたサーバーでは、priority boost を使用しないでください。

set working set size

set working set size の既定の設定を変更しないでください。 デフォルトの0では、Windows NTまたはWindows 2000の仮想メモリマネージャがSQL Serverのワーキングセットサイズを決定できます。 SQL Serverをインストールすると、セットアップは自動的にWindows NTまたはWindows 2000にネットワークアプリケーションのパフォーマンスを最適化するように指示します。 したがって、Windows NTまたはWindows 2000の仮想メモリマネージャでは、ワーキングセットのトリミングはほとんど行われず、SQL Serverインスタンスのワーキングセットへの干渉は最小限に抑えられます。

この設定を変更しても、通常はパフォーマンス上の利点はありません。 実際のサポートケースに基づいて、この設定の変更は通常、良いよりも多くのダメージを引き起こします。

set working set size を変更すると、SQL Server のエラー メッセージ 844 または 845 を発生させる原因にもなります。 エラー メッセージ 844 または 845 の一般的な原因に関する詳細については、この資料の「関連情報」を参照してください。

関連情報

関連情報を参照するには、以下の「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。

310834 PRB: エラー メッセージ 844 または 845 (バッファー ラッチ タイムアウト エラー) の一般的な原因

298475 アプリケーションのパフォーマンスに関する問題のトラブルシューティングを行う方法

243589 SQL Server 7.0 以降で実行に時間のかかるクエリのトラブルシューティング

243588 アドホック クエリのパフォーマンスのトラブルシューティングを行う方法

224587 SQL Server のアプリケーション パフォーマンスのトラブルシューティングを行う方法

166967 適切な SQL Server 6.5 構成の設定

254321 SQL Serverのクラスタ化に関する注意事項、禁止事項、および基本的な警告

297864 SQL Server 6.5からのアップグレードに関するパフォーマンス上の考慮事項

ヘルプを表示

スキルを磨く
トレーニングの探索
新機能を最初に入手
Microsoft Insider に参加する

この情報は役に立ちましたか?

フィードバックをお送りいただきありがとうございます!

フィードバックをお寄せいただき、ありがとうございます。Office サポートの担当者におつなぎいたします。

×