開発者のための SQL Server パフォーマンス チューニング/最適化講座

  • [アーティクル]

第 3 部 ‐ SQL Server の環境設定によるパフォーマンス向上

DAT 412
Presented at Tech-Ed 97

Adam Shapiro
Program Manager
Microsoft Corporation

目次

概要
SQL Server の環境設定情報
sysconfigures
SQL Server のメモリ管理および I/O 管理
SQL Server のメモリ使用
メモリに関連する環境設定オプション
DBCC MEMUSAGE
tempdb in RAM
SQL Server データ キャッシュ
ダーティ ページ
バッファ マネージャ ハッシュ
チェックポイント
レイジー ライタ プロセス
先読み処理
SQL Server プロシージャ キャッシュ
プロシージャ キャッシュの構成
プロシージャ キャッシュのサイズの設定
SQL Server の環境設定オプション
Max Worker Threads
データベースとセッションの設定
データベース オプション

概要

dat1e

SQL Server の環境設定情報

dat2e

Microsoft SQL Server には、環境設定および動作制御用のさまざまなオプションがあります。このモジュールでは、特に重要度の高いオプションについて学びます。

ハードウェア環境に合わせて調整する必要のあるオプションは、ごく一部にすぎません。ほとんどのオプションは、調整が不要です。

システムの環境設定情報は、次の 4 つの場所に格納されます。

sysconfigures

このシステム テーブルは、ユーザーによって設定される環境設定オプションごとに 1 行のデータを保持します。sysconfigures は、Microsoft SQL Server の前回の起動時以前に定義された環境設定オプションに加えて、それ以降に設定された動的な環境設定オプションを保持します。

Syscurconfigs
syscurconfigs システム テーブルは、sysconfigures と同様に環境設定オプションごとに 1 つのエントリを保持しますが、現在の値を格納する点が異なります。さらに、環境設定用の構造体を記述する 4 つのエントリを格納します。

このテーブルは sysobjects にもテーブルとして示されますが、実際にはユーザーが照会したときにだけ構築される "擬似" テーブルです。syscurconfigs の sysindexes 行を見ると、このテーブルにデータ行が存在しないことがわかります。

環境設定値を変更するには、SQL Server Enterprise Manager を使用するか、または sp_configure システム ストアド プロシージャを実行します。sp_configure を実行して環境設定オプションを変更する場合は、RECONFIGURE ステートメントに続けて sp_configure を実行する必要があります。SQL Enterprise Manager を使う場合でも、RECONFIGURE ステートメントが自動的に実行されます。

環境設定ブロック
RECONFIGURE ステートメントは、変更された環境設定オプションを "インストール" します。このとき、syscurconfigs テーブルの内容が MASTER デバイスの最初の 4 ページに書き込まれます。これらのページを環境設定ブロックと呼びます。MASTER デバイスの値は、次回 SQL Server を起動したときに sysconfigures テーブルに読み込むことができます。

Windows NT レジストリ
SQL Server は、起動時に MASTER デバイスから環境設定ブロックを読み取ります。MASTER デバイスの位置は、Microsoft Windows NT® レジストリに登録されます。

SQL Server のメモリ管理および I/O 管理

dat3e

環境設定項目のうち、最も調整が重要になるのは、SQL Server に割り当てるメモリの量です。

SQL Server のメモリ使用

dat4e

グローバルリソース
グローバル リソースは、すべてのプロセスおよびデータベースに使用されるリソースです。グローバル リソース領域の大半は、ほかの構造体へのポインタです。グローバル リソースとしてアクセスされる構造体には、サーバー上で定義されている各データベースを制御する構造体、ページ、エクステント、およびプロシージャのハッシュ テーブル、サーバー全体に適用する文字セットや並べ替え順に関する情報などがあります。この領域には、SQL Server の実行可能コードも格納されます。

ユーザー接続
ユーザー接続ごとに、30 KB の SQL Server メモリが必要になります。うち 27 KB はサーバー構造体に使用され、3 KB は ODS 構造体に使用されます。ユーザー接続ごとのメモリは、プロセス状態構造体 (PSS)、トランザクション記述子、セッション記述子、保護キャッシュ、ログイン レコード、およびパーサー作業領域に使用されます。これらは、いずれも SQL Server の初期化時に作成されるヒープから割り当てられます。

さらに、1 MB のグローバル スタックもユーザー接続用に予約されますが、このメモリは即時にはコミットされません。SQL Server の実行中にスタック領域の必要量が増えると、1 MB の制限範囲内で必要な量のメモリがコミットされます。新しいスレッド (つまり実際に使用されるユーザー接続) が作成されるたびに、20 KB のスタック領域が消費されます。

したがって、ユーザー接続ごとに必要になるメモリの総量は 50 KB から max worker threads オプションで設定した制限の範囲内になります。この制限を超えると、各接続に必要なメモリの量は 30 KB になります。

ロック、オープン中のデータベース、およびオープン中のオブジェクト
ロック、オープン中のデータベース、およびオープン中のオブジェクトには、それぞれの設定に応じてメモリが割り当てられます。これらのオプションに関する総メモリ消費量は、次の値を使用して見積もることができます。

ロック

60 バイト

オープン中のデータベース

162 バイト

オープン中のオブジェクト

240 バイト

システムの実際のメモリ使用量の詳細を確認するには、トレース フラグ 3635 をオンにしてから DBCC MEMUSAGE を実行します。

プロシージャとデータキャッシュ
このモジュールでは、プロシージャとデータ キャッシュについて後ほど詳しく述べます。

メモリに関連する環境設定オプション

dat5e

Memory
この環境設定オプションでは、利用可能なメモリのサイズを 2 KB 単位で設定します。初期値は、セットアップ プログラムの実行中に、コンピュータのメモリ容量に基づいて決定されます。

この値を最適化するには、物理メモリの総量から Windows NT に必要なメモリの量を引きます。SQL Server 以外も実行する場合は、ほかのシステムが使用するメモリの量も引きます。

SQL Server には、ページングが発生しないようにできるだけ多くのメモリを割り当てるのが理想的です。Windows NT パフォーマンス モニタを使用すると、システムのしきい値を調べることができます。生成に失敗したページがある場合は、Memory オブジェクトの Page Faults/sec カウンタに示されます。ページ フォルトが発生していれば、SQL Server のメモリが不足しています。しきい値は、システムによって異なります。

SQL Server のメモリ割り当ての推奨値を次の表に示します。この表では、SQL Server しか実行しないコンピュータを想定しています。

RAM (MB)

SQL Server のメモリ割り当て量 (MB 単位)

SQL Server のメモリ割り当て量 (2 KB 単位)

16

4

2,048

24

8

4,096

32

16

8,192

64

40

20,480

128

100

51,210

256

216

110,592

512

464

237,568

システムの物理メモリ容量やコンピュータの用途を変えた場合以外は、この値を変更しないでください。

メモリ オプションを変更すると、free buffers 環境設定オプションの値が自動的に変更されます。free buffers 環境設定オプションの値は、新しいメモリ サイズの 5% に設定されます。この値の意味については、後ほど詳しく学びます。

memory オプションの最大値は 2 GB です。ただし、tempdb in RAM オプションを使って RAM 内に tempdb を置いた場合は、memory オプションの値には tempdb に必要なメモリの量が含まれないことに注意してください。

Open Databases
この環境設定オプションでは、SQL Server 上で同時にオープンできるデータベースの最大数を設定します。既定値は 20 です。データベースをオープンするたびにメモリが消費されるので、この値を増やす場合は、SQL Server に割り当てるメモリの量を増やす必要が生じることがあります。

Open Objects
この環境設定オプションでは、SQL Server 上で同時にオープンできるデータベース オブジェクトの最大数を設定します。既定値は 500 です。

オープンできるオブジェクトの最大数を超えたというメッセージが表示される場合は、この値を増やします。データベース オブジェクトをオープンするたびにメモリが消費されるので、この値を増やす場合は、SQL Server に割り当てるメモリの量を増やす必要が生じることがあります。

User Connections
user connections オプションは、SQL Server で同時に確立できるユーザー接続の最大数を指定します。実際に認められるユーザー接続数は、データベース環境によって異なります。

ユーザー接続の最大許容数は、バージョンによっても異なります。SQL Workstation の場合は 15、SQL Server の場合は 32,767 が上限となります。ただし、実際の最大数は、アプリケーションやハードウェアによって異なります。

システムで確立できるユーザー接続の最大数を確認するには、次のステートメントを使います。

SELECT @@max_connections

各ユーザーに対して許容される接続数を単純な計算で求めることはできません。この値は、システムとユーザーの必要条件に基づいて設定する必要があります。DB-Library アプリケーションや ODBC アプリケーションを実行するユーザーは、1 つのアプリケーション内で複数の接続をオープンすることがあります。ユーザー数の多いシステムでは、ときどき発生するような接続については複数のユーザー間で共有される可能性が高くなります。

Locks
この環境設定オプションでは、利用可能なロックの数を設定します。ロックは、オープン中のデータベースやデータベース オブジェクトのような方法では共有されません。既定値は 5,000 です。

利用可能なロックの最大数を超えたというメッセージが表示される場合は、この値を増やします。ロックを使用するたびにメモリが消費されるので (ロックあたり 32 バイト)、この値を増やす場合は、SQL Server に割り当てるメモリの量を増やす必要が生じることがあります。

Procedure Cache
この環境設定オプションでは、SQL Server のメモリ ニーズが満たされた後でプロシージャ キャッシュに割り当てられるメモリのパーセンテージを指定します。SQL Server のメモリ ニーズは、ロック、オープン中のデータベース、オープン中のオブジェクト、ユーザー接続、コード、およびグローバル リソースに必要なメモリの合計です。残りのメモリは、この環境設定オプションで設定したパーセンテージに従って、プロシージャ キャッシュとデータ キャッシュに割り振られます。

プロシージャ キャッシュは、最近使用したプロシージャを格納するメモリ領域です。プロシージャ キャッシュは、プロシージャの作成時やクエリのコンパイル時にも使用されます。procedure cache 環境設定オプションの既定値は 30 です。これは、SQL Server の要求条件を満足した後の残りのメモリの 30% がプロシージャ キャッシュに割り当てられ、データ キャッシュには 70% が割り当てられることを意味します。

この環境設定オプションの最適値はアプリケーションによって異なるので、このオプションをリセットすると SQL Server のパフォーマンスが向上する場合があります。たとえば、多数の異なるプロシージャやアドホック クエリを実行する場合は、アプリケーションでプロシージャ キャッシュを使用する頻度が高いので、この値を増やすと効果的なことがあります。アプリケーションの開発中は、多くの場合、プロシージャ キャッシュの使用頻度が高くなります。

データ キャッシュのヒット率を向上するためにメモリを増加した場合は、プロシージャ キャッシュのサイズが大きくなりすぎないように、プロシージャ キャッシュのパーセンテージを減らすことができます。

DBCC MEMUSAGE

dat6e

DBCC MEMUSAGE
DBCC ステートメントを MEMUSAGE オプションとともに実行すると、メモリの使用状況に関する詳細情報を取得できます。このオプションで取得できるのは、次の 3 種類の情報です。

  • 起動時にサーバー メモリがどのように割り当てられたか

  • バッファ キャッシュ内のオブジェクトのうち、サイズの順で 20 番目までのオブジェクトに使用されているメモリの量

  • プロシージャ キャッシュ内のオブジェクト (ストアド プロシージャ、トリガ、ビュー、ルール、およびデフォルト) のうち、サイズの順で 20 番目までのオブジェクトに使用されているメモリの量

プロシージャ キャッシュ内に同じオブジェクトのコピーが複数存在する場合、DBCC MEMUSAGE では、使用されているメモリ量の合計が出力されます。複数のコピーがある場合、プリコンパイル済みオブジェクト (ツリー) とコンパイル済みオブジェクト (プラン) が混在している可能性があります。DBCC MEMUSAGE の出力では、ツリーとプランの両方のサイズが示され、キャッシュ内のツリーとプランの合計数が示されます。

tempdb in RAM

dat7e

tempdb データベースは、並べ替え時に作業空間として使用され、一部の結合操作に必要となる一時テーブルの作成にも使用されます。また、プログラマが明示的な一時テーブルや一時ストアド プロシージャを作成するときにも使用されます。

tempdb in RAM 環境設定オプションでは、tempdb の全体をメモリ内に常駐させることができます。メモリ内に常駐させることでパフォーマンスを向上できる場合もありますが、tempdb in RAM オプションを不適切に使用すると、本来なら SQL Server データ キャッシュに使用できるメモリが消費され、パフォーマンスが低下することがあります。

ほとんどの場合は、利用可能な RAM を tempdb に使用せずにデータ キャッシュに使用した方がパフォーマンスが向上します。tempdb 内のデータは、SQL Server の最長未使用時間 (LRU: least-recently-used) アルゴリズムによってキャッシュされます。

tempdb in RAM を使用すると tempdb に対する操作の速度が向上しますが、SQL Server データ キャッシュに使用できるメモリが少なくなるため、キャッシュのヒット率が低下する可能性があります。tempdb in RAM に使用するメモリは、memory オプションで設定したプール セットとは別に割り当てられるので、サーバーのオプションを適切に設定する必要があります。

たとえば、tempdb in RAM に 100 MB を使用する場合は、memory オプションの設定値を 100 MB 減らして、必要なメモリを解放しなければならなくなることがあります。利用可能なメモリの一部を tempdb in RAM に使用せずに、利用可能なメモリをすべて SQL Server に割り当てた方がキャッシュ ヒット率は高くなります。SQL Server では、すべてのディスク I/O 操作 (tempdb に関する操作を含む) がキャッシュされます。

tempdb in RAM オプションを使用する場合、多くのコンピュータでは、限られた RAM 容量の中で tempdb のサイズを決定しなければなりません。tempdb のサイズがどの程度まで拡張されるか予想できない場合は、これが問題になることがあります。この可能性がある場合は、tempdb を RAM に常駐させないでください。

通常は、利用可能な RAM を SQL Server データ キャッシュに使用した方が、tempdb in RAM に使用する場合よりもパフォーマンスが向上します。ただし、次の条件がすべて成立している場合は、tempdb in RAM オプションを使用するとパフォーマンスが上がる可能性があります。

  • システムの RAM 容量に十分な余裕がある場合。通常は 64 MB 以上、理想的には 128 MB 以上の RAM 容量があれば、tempdb in RAM オプションの使用を検討するとよいでしょう。

  • アプリケーションがローカルなデータにアクセスすることが多く、データ キャッシュのサイズを増やしてもキャッシュ ヒット率が向上しない場合。

  • tempdb に対する操作の頻度が高いアプリケーションの場合。tempdb のサイズは、パフォーマンス モニタで監視できます。SQL Server オブジェクトに関しては、Max TempDB Space Used (MB) カウンタを使うと、SQL パフォーマンスモニタ セッション中に tempdb データベース内で使用された空間の最大量を監視できます。

  • RAM の環境設定により、tempdb のサイズを増やさないように tempdb に対する操作が行われる場合。

tempdb を RAM に常駐させる場合は、パフォーマンス向上に寄与するかどうかを客観的に確認するようにしてください。このことを確認するには、次の手順に従ってください。

  1. tempdb に対して最も頻繁に実行される操作が含まれている単一または少数のクエリを選定します。

  2. それらのクエリを数回実行し、実行に要する時間を記録します。

  3. tempdb を RAM に常駐させてから、同じクエリを実行し、実行時間の違いを確認します。

実行時間にあまり差が生じない場合は、RAM を SQL Server データ キャッシュに割り当てた方がよいでしょう。

tempdb を RAM に常駐させること自体に危険性はなく、データベースの整合性や復旧性を損なうことはありません。tempdb は即時操作にのみ使用され、サーバーの起動時にそのつど、完全に再構築されるためです。

分析の結果、パフォーマンスの向上を確認できれば、tempdb in RAM オプションは重要なパフォーマンス ツールとなります。このオプションにより、パフォーマンスを大幅に向上できる場合があります。ただし、このオプションをむやみに使用することは避けてください。

RAM 内の tempdb の変更
tempdb データベースは、RAM 内に常駐している場合も含め、拡張が可能です。ただし、RAM 内に常駐している場合は、サーバーをいったんシャットダウンしてから再起動しない限り、tempdb の変更回数は 10 回以内に制限されます。RAM 内にある tempdb に変更を加えると、そのつど、新しいチャンクの連続メモリ領域が tempdb に割り当てられます。それぞれのチャンクは連続したメモリ領域ですが、RAM 内で tempdb に割り当てられた個々のメモリ チャンクが常に隣接し合うとは限りません。最大限のパフォーマンスを得るには、tempdb の変更後にサーバーをいったん停止してから再起動する必要があります。

RAM からの tempdb の削除
tempdb in RAM の設定値を 0 に設定すると、tempdb を RAM から削除できます。0 に設定した場合、tempdb は、2 MB の既定サイズで既定のデバイス上に作成されます。

注
アップグレード時に tempdb が RAM 内にあった場合は、アップグレード後、自動的に RAM から削除されます。既定のディスク デバイスには、tempdb を作成できるように、少なくとも 2 MB の空き容量が必要です。空き容量が 2 MB 未満の場合は、SQL Server の起動に失敗します。一時的に RAM 内に 2 MB の tempdb を作成するには、SQLSERVR.EXE のコマンド ラインに /f フラグを指定します。

SQL Server データ キャッシュ

dat8e

データ キャッシュとは、ディスクから読み取られたページを保持するためのバッファ (ページ フレーム) の集合です。データ キャッシュは、SQL Server に割り当てられたメモリ内に存在します。ページ キャッシュまたはバッファ キャッシュと呼ばれることもあります。

環境設定項目のうち、最も調整が重要になるのは、SQL Server に割り当てるメモリの量です。データ キャッシュのサイズは、割り当てメモリの量に直接比例します。アクセス対象のページがデータ キャッシュに保持されていなければ、そのページをディスクから物理的に読み取る必要が生じます。ディスクからの物理読み込みが多いと、SQL Server のパフォーマンスが低下します。

ここでは、特に次の用語が重要です。

ダーティ ページ

データ修正ステートメントによって変更されたデータ ページのうち、まだディスクに書き込まれていないデータ ページ。

空きページ
どのプロセスにも使用されておらず、ダーティになっていないページ。

最長未使用時間 / 最短未使用時間 (LRU/MRU) チェーン
最後に使用された時点が最も古いものから最も新しいものへの順でページを示すリンク リスト。

バッファ マネージャ ハッシュ

dat9e

SQL Server では、ページをすばやく検索でき、ページがデータ キャッシュ内に存在するかどうかを判定できるように、データ キャッシュ内のページを "ハッシュ" します。メモリ内のデータ キャッシュにページをハッシュするのに使用するバケットの数を設定するには、hash buckets 環境設定オプションを使います。ハッシュ バケットの数が多いほど、参照先ページを高速で検索できるようになります。これらのバケットは、使用中ページのリスト内で参照先ページに近接する位置にハッシュされ、正しいページに達するまでチェーン内を移動します。

どのハッシュ バケットについてもチェーン サイズの制限が必要です。バケットが多いほど、チェーンが短くなります。適切な数のハッシュ バケットだけを使用するようにすれば、サイズの非常に大きいデータ キャッシュでも高速で検索できるようになります。

例
ハッシュ バケットの既定のサイズは、約 8 KB です。各ハッシュ バケットが最適な長さ (4 ページ) であれば、SQL Server は次のサイズのデータ キャッシュをサポートできます。

4 x 8K = 32K pages = 64 MB

ハッシュ チェーンの長さが最適な場合に最大数のハッシュ バケット (256K) を使用すると、SQL Server は次のサイズのデータ キャッシュをサポートできます。

4 x 256K = 1024K pages = 2 GB

どのチェーンの長さも 4 ページ未満であれば、最適な設定になっています。チェーンの長さが 4 ページを超えている場合は、hash buckets 環境設定オプションの値を増やします。

これらのハッシュ バケットはごくわずかなメモリしか消費しないので、SQL Server はハッシュ バケットの実際の数を入力値に最も近い素数に設定します。ハッシュ バケットの数の既定値は 7,993、最大値は 265,003 です。

DBCC BUFCOUNT を使うと、現在のハッシュ設定の効果を検査できます。

DBCC TRACEON(3604) 
GO 
DBCC BUFCOUNT 
GO 
THE 10 LONGEST BUFFER CHAINS ****
bucket number = 20 chain size = 2 
bucket number = 276 chain size = 2 
bucket number = 532 chain size = 2 
bucket number = 1044 chain size = 2 
bucket number = 1300 chain size = 2 
bucket number = 1556 chain size = 2 
bucket number = 1812 chain size = 2 
bucket number = 2324 chain size = 2 
bucket number = 3092 chain size = 2 
bucket number = 3604 chain size = 2 
The Smallest Chain Size is: 0 
The Average Chain Size is: 0.671668

チェックポイント

dat10e

チェックポイントシステムプロセス
チェックポイント プロセスは、SQL Server 上で常に実行されているシステム プロセスです。チェック時以外は、スリープ状態になっています。sp_who プロシージャを実行すると、このプロセスを確認できます。チェックポイント プロセスは 1 分ごとにアクティブになり、各データベースのトランザクション ログを検査します。前回のチェックポイント以降に十分なトランザクションが発生したとチェックポイント システム プロセスが判断すると、SQL Server はそのデータベースに対してほかのチェックポイントを発行します。

十分なトランザクションが発生したかどうかは、recovery interval 環境設定オプションの値に基づいて判定されます。このオプションは、分単位で設定します。チェックポイント システム プロセスでは、復旧にかかる時間がこの設定値に一致すれば、十分なトランザクションが発生したと判断します。

CHECKPOINT ステートメント
CHECKPOINT は、DBO または SA により手動で発行できるステートメントです。

チェックポイント中に行われる処理
SQL Server は、チェックポイントの発行時にすべてのダーティ ページをディスクに書き込みます。ページはデータベースごとにリンクされているので、チェックポイント対象のページをすばやく検索できます。

SQL Server による自動発行時も、CHECKPOINT ステートメントによる手動発行時も、チェックポイントでは 2 段階の処理が行われます。第 1 段階では、フラッシュの必要なページすべてにマークが付けられます。チェックポイント ログが有効な場合 (トレース フラグ 3502 が発行された場合) は、SQL Server エラー ログに次のような情報が記録されます。

Ckpt dbid 6 started (4000) (checkpoint begins)  
Ckpt dbid 6 phase 1 ended (0) (1st phase ends) 
Ckpt dbid 6 complete. (2nd phase and the checkpoint ends)

第 2 段階では、マークの付いたページがすべてチェックポイント スレッドによってフラッシュされます。第 2 段階の方が、第 1 段階よりも長時間続きます。この段階に要する時間は、フラッシュするページの数、ディスク サブシステムの速度、サーバーの飽和レベルなどの要因によって異なります。ダーティ ページをすべてデータ キャッシュからディスクにフラッシュし終えた時点でチェックポイントが完了します。

チェックポイント中には、単一ページの書き込み数 (Object: SQLServer、Counter: I/O ・Single Page Writes/sec) が増加することがあります。このカウンタは、通常は 0 になります。チェックポイント中に、チェックポイント スレッドによってまだフラッシュされていないページが新しいトランザクションに要求されると、SQL Server がそれらのページを要求に応じてフラッシュします。これが通常の処理です。

SA が SHUTDOWN ステートメントを発行すると、各データベースに対してチェックポイントが発行されます。また、SQL Server の起動時にもチェックポイントが発行されます。各データベースは、復旧後にチェックポイントされます。

注
trun. log on chkpt. データベース オプションが設定されている場合は、システム チェックポイント プロセスがアクティブになるたびにログが切り捨てられます。

レイジー ライタ プロセス

dat11e

"レイジー ライタ" は、SQL Server でサポートされているシステム プロセス (sp_who を実行すると表示されるプロセス) の 1 つです。このプロセスは、利用可能な空きバッファの数が free buffers 環境設定オプションで指定されたしきい値よりも少なくなると、自動的にバッファのフラッシュを開始します。

レイジー ライタ プロセスは、チェックポイントをあまり頻繁に発行しなくても利用可能なバッファを作成できるようにします。レイジー ライタで使用するバッチ I/O のサイズは、max lazywrite IO 環境設定オプションで設定できます。

ダーティページのフラッシュ

dat12e

SQL Server がキャッシュからディスクにページをフラッシュするのは、次の場合です。

  • チェックポイントが発行されたとき。

  • 新しいページをキャッシュに読み込む必要があるとき。
    キャッシュに保持されていないページが必要なときに空きバッファ リストにバッファがなければ、SQL Server はキャッシュ ページ チェーンから空きバッファを検索します。チェーン内の検索が完了すると、最も古いバッファのページがディスクにフラッシュされます。

    未使用のバッファがなく、空きバッファ リストにバッファがない場合は、ページが利用可能になるまでの間、ページの要求元プロセスが待機させられます。

  • SELECT INTO の実行完了時または bcp の各バッチの実行完了時。
    高速 bcp (ログなし) を使用している場合や、SELECT INTO を使用してテーブルを作成している場合には、新しく挿入した行はログに記録されません。また、それらの行の多くまたはすべてがまだキャッシュ内に保持されていることがあります。SQL Server がチェックポイントなしで停止された場合にデータが失われる可能性を低くするために、bcp バッチまたは SELECT INTO の終了時には、すべてのダーティ ページがディスクにフラッシュされます。

  • トランザクションが完了すると、ログ ページがフラッシュされます。
    トランザクションのコミット時またはアボート時には、ログ ページがディスクにフラッシュされます。

  • ページが分割されたとき。
    ページが分割されると、新しく割り当てたページが即時にディスクにフラッシュされます。

  • LOAD DATABASE が実行されたとき。
    LOAD DATABASE ステートメントでデータベースを復元する場合は、ダンプ内のすべてのページがディスクに直接書き込まれます。さらに、データベース内のページのうち、バックアップに含まれていないページも初期化された上、ディスクにフラッシュされます。たとえば、4 MB のデータベースから 10 MB のデータベースにバックアップをロードする場合なら、残りの 6 MB のページがすべて初期化され、ディスクに書き込まれます。

  • レイジー ライタ プロセスの実行時。
    レイジー ライタ プロセスは、利用可能な空きバッファの数が特定のしきい値よりも少なくなると、自動的にバッファのフラッシュを開始します。レイジー ライタは、フラッシュ可能なバッファが存在しなければ、エラー ログにメッセージを書き込みます。

非同期 I/O

dat13e

特定のディスクサブシステムにおける高レベルのパフォーマンス
パフォーマンスに対する非同期 I/O の効果は、ディスク サブシステムの種類によって異なります。ここでは、この違いを示す具体例として、3 つの異なるディスク サブシステムを想定します。1 番目のディスク サブシステムでは、1 つの非インテリジェント型コントローラが 4 つのディスク ドライブに接続されています。2 番目のディスク サブシステムでは、4 つの非インテリジェント型コントローラがそれぞれ 1 つのディスク ドライブに接続されています。3 番目のディスク サブシステムでは、1 つのインテリジェント型コントローラが 4 つのディスク ドライブに接続されています。

単一のコントローラと 4 つのドライブ
まず最初に、単一のコントローラに 4 つのドライブが接続されている場合のデータ転送について考察します。アウトバウンド転送シーケンスでは、デバイス ドライバがデータのバッファをコントローラのオンボード バッファに転送します。この転送は、ダイレクト メモリ アクセス (DMA)、共有メモリ、またはプログラム I/O を使用して非常に高速で行われます。典型的なバス速度では、数百マイクロ秒の転送時間になります。次に、コントローラが、デバイス ドライバの補助を得て、ドライブに対し必要なシーク操作を指示します。この処理には、50 ミリ秒ほどかかります。つまり、バスからコントローラへの転送に要する時間の数百倍の時間がかかります。

この後、ドライブの種類によって決まる転送速度で実際のデータがコントローラ バッファからディスク ドライブに転送されます。転送前に、回転待ち時間が発生することもあります。多くのシステムでは、ハード ディスク ドライブが利用可能になるまでの間、デバイス ドライバと呼び出し元のタスクがそのまま待機しなければなりません。コントローラが複数の保留中操作を追跡するために必要なロジックを備えていないため、最初のドライブで操作が完了するまで、2 番目以降のドライブでは操作を実行できません。

個別のドライブを接続した 4 つのコントローラ
4 つのコントローラをそれぞれ個別のドライブに接続しているディスク サブシステムでは、Windows NT のストライピングを使用している場合には、2 番目以降のコントローラまたはドライブに対して即時に転送シーケンスを開始できます。この場合、各ドライブの転送フェーズは、そのドライブに対応するコントローラによって追跡されるので、4 つのドライブの転送フェーズは同期されません。

このハードウェア環境設定で Windows NT の非同期 I/O を使用すると、未処理の I/O のプールを作成し、ドライブ サブシステムを並列で (4 つ同時に) 処理させることができるので、パフォーマンスを向上できます。ドライブ サブシステムが要求を処理する速度はサブシステムによって異なるので、SQL Server から未処理の要求のプールを作成すると、サブシステムをフルに使用できることがあります。また、システム固有の多くの要因に依存しますが、SQL Server の環境設定を変更して、非同期 I/O の許容数を増やすことも効果がある可能性があります。ただし、大半のシステムの処理能力では、ドライブごとにコントローラを使用するだけの余裕がありません。

4 つのディスクドライブを接続した単一のインテリジェント型コントローラ
技術の進歩により、従来は複数の非インテリジェント型コントローラに頼っていた処理を単一のインテリジェント型コントローラで効果的に実現できるようになりました。インテリジェント型コントローラでは、デバイス ドライバからの複数の I/O 要求を高速で処理できるので、接続されているドライブ (通常は、RAID アレイ内でストライピングされたドライブ) への同時転送操作を効果的に維持できます。この場合、コントローラの能力と設定によっては、SQL Server の環境設定を変更して、非同期 I/O の許容数を増やすことでパフォーマンスを向上できることがあります。実際に使用する値は、サーバーとコントローラによって異なります。また、ディスク サブシステムの環境設定により特定のサーバーやコントローラや、アプリケーションの I/O 特性によって特定のディスク サブシステム環境設定によっても変わります。

max async IO オプションの設定

dat14e

max async IO オプションでは、発行可能な非同期ディスク I/O 要求の最大数を設定します。既定値は、8 です。この値を変更する必要が生じるのは、データベースが複数の物理データベース デバイス上に定義されており、それらのデータベース デバイスが個別の物理データベースか、またはディスクのストライピングを利用したシステムに維持されている場合だけです。

max async IO 環境設定オプションの最適値を決定するには、Microsoft TPC-B Benchmark Kit または独自のベンチマークを使用し、既定値の 8 を基準値として、値を徐々に増やしながら対照テストを実施することをお勧めします。それ以上のパフォーマンス向上が認められなくなった時点の値が最適値ということになります。このような実験を実施しない場合は、このオプションは既定値のままにしてください。

この環境設定オプションの変更を反映させるには、SQL Server を再起動する必要があります。

max lazywrite IO オプションの設定

dat15e

max lazywrite IO 環境設定オプションでは、レイジー ライターが行うバッチ非同期 I/O 動作の優先度をチューニングします。一括コピーやチェックポイントなどのバッチ I/O は max async IO オプションで設定できますが、max lazywrite IO はレイジー ライタを対象とするオプションです。このオプションは、複数のハード ディスクが存在するシステムの場合にのみ設定できます。このオプションの値は、max async IO で指定した値を上限として、動的に設定できます。

この環境設定オプションへの変更は、即時に反映されます。

バッファマネージャの設定

dat16e

Free Buffers
システムが使用できる空きバッファのしきい値を指定します。最小値は 20、最大値はサーバー起動時に利用可能なバッファ数の半分の値です。レイジー ライタ プロセスにより、システムで利用できる空きバッファの数は、このしきい値より少なくならないように制御されます。

memory オプションの値を変更すると、このオプションの値が自動的に変更されます。free buffers は、利用可能なメモリ容量の 5% に設定されます。memory オプションを変更すると、free buffers の変更を示すメッセージが表示されます。この後、free buffers を適切な値に手動で変更できます。

Sort Pages
ユーザー別の並べ替えに割り当てるページの最大数を指定します。大規模な並べ替えを実行するシステムでは、この値を増やすとパフォーマンスを向上できます。並べ替えページを追加するたびにメモリが消費されるので、この値を増やす場合は、SQL Server に割り当てるメモリの量を増やす必要が生じることがあります。

Hash Buckets
ページをメモリ内のバッファにハッシュするのに使用するバケットの数を設定します。指定した値が素数でない場合は、最も近似の素数が使用されます。たとえば、8,000 と指定すると、7,993 個 (既定値) のハッシュ バケットが作成されます。大容量のメモリを搭載したシステムでは、この値を増やすと、データ キャッシュ内のデータへのアクセス速度を向上できます。160 MB 以下のメモリを搭載したシステムでは、7,993 が適切な値になります。このオプションの変更を反映させるには、サーバーをいったん停止してから再起動する必要があります。

Recovery Interval
システム障害の発生時に SQL Server が復旧手順を完了するために必要となるデータベースあたりの時間を分単位で設定します。既定では、データベースあたり 5 分に設定されます。

recovery interval は、アプリケーションとそのニーズの変化に応じて調整できます。たとえば、変更が頻繁にディスクに書き込まれる場合は、更新処理がより頻繁に行なわれるよう、recovery interval の値を減らします。recovery interval の値を減らすと、チェックポイントが頻度に行なわれるようになります。ただし、システムの実行速度が若干低下します。逆に recovery interval の値を増やしすぎると、復旧時間が異常に長くなる可能性があります。

キャッシュ内に常駐するテーブルの指定

dat17e

部分構文

sp_tableoption @TableNamePattern [, 'pintable'] [, true | false ]

pintable オプションを "true" に設定すると、テーブルをインデックスとともにデータ キャッシュ内に常駐させることができます。新しいページを格納する空間を開放する際に、常駐させたテーブルに所属しているページはデータ キャッシュからフラッシュされません。常駐しているテーブルに対する修正はすべてログに記録されます。レイジー ライタとチェックポイントでは、すべての常駐テーブルのダーティ ページを通常どおり書き出します。

常駐としてマークしたテーブルは、sysobjects 内でステータス ビットが設定されます。

このストアド プロシージャを実行しても、テーブルとインデックスは即時にはメモリにロードされません。データとインデックスは、アクセスされたときにデータ キャッシュに取り込まれます。それ以降、SQL Server が停止されるか、pintable が "false" に設定されるまでの間、これらのデータとインデックスはキャッシュ内に常駐します。常駐としてマークしたテーブルをメモリに即時にロードするには、非クラスタ化インデックスが置かれていない列に対し SELECT COUNT(column_name) FROM table_name などの単純なコマンドを使用して、テーブルにアクセスします。

環境によっては、多用されるテーブルを常駐させると、パフォーマンスが大幅に向上することがあります。テーブルを常駐させた後でデータ キャッシュの容量が十分にあることを常に確認してください。

テーブル名は、ワイルドカードを使って指定できます。これにより、複数のテーブルの常駐と非常駐を切り替えることができます。"true" または "false" を指定せずにコマンドを実行すると、指定したテーブルの現在の pintable の設定値が返されます。

注
テーブルのサイズに制限はありませんが、テーブルのサイズが大きければ、キャッシュ内の領域がその分多く消費されます。

キャッシュ内に維持するインデックスページの指定
トレース フラグ 1081 を指定すると、インデックス ページがデータ キャッシュがすぐにはフラッシュされなくなります。SQL Server が新しいインデックス ページをキャッシュに入れるために既存のインデックス ページをフラッシュするときには、指定したインデックス ページが既に一度バイパスされたページでない限り、別のインデックス ページがフラッシュ対象として選択されます。したがって、インデックス ページがデータ キャッシュ内に通常よりも長い期間保持されるようになります。

先読み処理

dat18e

先読みは、並列データ スキャン (PDS) とも呼ばれます。SQL Server では、このテクニックを使用して、クエリの処理に必要な物理読み取りの数を低減しています。キャッシュ内に必要数のページが見つからなければ、SQL Server は現在の SQL Server プロセスで必要になる可能性があるページを読み取るほかのスレッドを開始できます。

先読み処理は、データの行方向スキャンの実行中の任意の時点で開始できます。これには、テーブル スキャン、インデックスのリーフ レベル スキャン (非クラスタ化インデックスの場合)、DBCC ステートメント、および UPDATE STATISTICS が含まれます。

先読み処理の設定

dat19e

RA Cache Miss Limit
データの行方向スキャンの実行中に、このオプションで設定した数のページがデータ キャッシュ内に見つからなければ、先読みが開始されます。RA cache miss limit を 1 に設定すると、ディスクからデータ ページを読み取ろうとするたびに、先読み要求が発生します。このため、スラッシングが発生し、パフォーマンスが低下する可能性があります。

RA Pre-fetches
このオプションでは、プリフェッチ マネージャがアイドル状態になる前に先読み (RA) マネージャが先読みするエクステント数を設定します。このオプションの値を 3 に設定すると、要求が発行されるたびに、RA マネージャがページ チェーンに続けて、現在のスキャン位置より先のエクステントを 3 つ保持します。

RA Cache Hit Limit
必要なページのうち、キャッシュ内に既に存在するページの数がこのオプションで設定した数に達すると、先読みが停止されます。その後、キャッシュ内に必要ページが見つからなかったときに、先読みが再開されます。このオプションは、先読みマネージャがすべての必要ページをキャッシュ内に見つけたが、それらがクエリにほとんど役立たないケースを見つけるのに使用されます。ほとんどのシステムでは、既定値の 4 が適切な設定になります。

RA Worker Threads
各スレッドは設定可能な数の構造体 (RA slots per thread オプション参照) を管理しますが、各構造体 (スロット) が個々の範囲スキャンを表します。このオプションは、システム上の同時ユーザーの最大数に設定します。先読みスキャンを要求するスレッドの数が設定済み RA スロットの数を超えると、エラー ログに警告が書き込まれます。このオプションを 0 に設定すると、先読みが無効になります。

RA Slots Per Thread
このオプションでは、各先読みサービス スレッドが管理する同時要求の数を指定します。スレッド数にスロット数を掛けると、システムでサポートされる同時先読みスロットの総数になります。ほとんどのシステムでは、既定値で十分です。システムが効率的な I/O サブシステムを備えている場合は、単一のスレッドで処理できるスキャンの数を増やすことでパフォーマンスを向上できることがあります。

RA Delay
クエリ スレッドで先読みスレッドを呼び出してからオペレーティング システムが実際に先読みスレッドをアクティブにするまでの間に、若干の遅延が発生することがあります。このオプションでは、クエリ スレッドが先読みスレッドの起動を待機するように、クエリ スレッドが処理を再開するまでの遅延時間を設定します。このオプションを 0 に設定すると、先読みスレッドがアクティブになる前にクエリ スレッドが常に次のページを取得するので、先読みが完全に無効になります。

先読みの監視と制御

dat20e

DBCC SQLPERF(RASTATS) は、4 つの統計値を返します。出力例を次に示します。

Statistic Value 
------------------------------------ ------------------------ 
RA Pages Found in Cache 297.0 
RA Pages Placed in Cache 12933.0 
RA Physical IO 1644.0 
Used Slots 0.0

4 つの出力値の意味は、次の表に示すとおりです。

統計値

定義

RA Pages Found in Cache

RA マネージャがスキャンを実行しようとしたときにキャッシュ内に見つかったページの数。

RA Pages Placed in Cache

RA マネージャがキャッシュに取り込んだページの数。

RA Physical IO

RA マネージャが実行した 16 KB の読み込みの数。

Used Slots

アクティブなクエリで使用されている RA スロットの数。1 つのクエリが複数の RA スロットを使用することがあります。

SQL Server プロシージャ キャッシュ

dat21e

プロシージャ キャッシュの構成

dat22e

プロシージャ キャッシュは、次の要素で構成されます。

  • Proc buffer 配列
    キャッシュ ページと同数のプロシージャ バッファ スロットがあり、固定配列に格納されます。各プロシージャ バッファ スロットは、プロシージャ キャッシュ内で 122 バイトを使用します。DBCC MEMUSAGE の出力で、プロシージャ バッファの保持用の空間を Proc Header と呼びます。

  • Proc Header
    使用されている各プロシージャ バッファ スロットは、1 つのProc Header を指します。Proc Header は、キャッシュ内のプロシージャ プランまたはプロシージャ ツリーの最初のページになります。この最初のページには、プランまたはツリー内のほかのページのアドレスなどの管理情報が格納されます。また、プランの場合は最初のステートメントへのポインタが格納され、呼び出し元のプロシージャがある場合は、そのプロシージャへのポインタも格納されます。この構造体は、最初の 2 KB ページのうち、606 バイトを消費します。2 KB ページの残りの空間は、プランやツリーで使用します。プランまたはツリーのサイズによっては、プランやツリーにその他のページが関連付けられることがあります。DBCC MEMUSAGE の出力で、プロシージャ キャッシュ用の空間を Proc Cache Buf と呼びます。

  • 使用されているページには、クエリ プランまたはクエリ ツリーが格納されます。

  • アクティブ ページには、現在実行中のプロシージャのプランが格納されます。

  • 空きページは、新しいプランに使用できます。

同じプロシージャに複数のプランがある場合、各プランには専用のプロシージャ バッファ スロットと Proc Header が割り当てられます。

プロシージャ キャッシュのサイズの設定

dat23e

Procedure Cache 環境設定オプション
procedure cache オプションでは、SQL Server で最近使用したストアド プロシージャの格納、新しいストアド プロシージャの作成、および新しいクエリの作成に使用するメモリの量を指定します。

このオプションでは、SQL Server のメモリ ニーズが満足された後でプロシージャ キャッシュに割り当てられるメモリのパーセンテージを指定します。SQL Server のメモリ ニーズは、ロック、ユーザー接続、コードなどに必要なメモリの合計です。残りのメモリは、この環境設定オプションで設定したパーセンテージに従って、プロシージャ キャッシュとデータ キャッシュに割り振られます。

ストアド プロシージャ、トリガ、ビュー、ルール、およびデフォルトに必要なプロシージャ キャッシュの量は、それらの数とサイズによって決まります。複数のユーザーが同じストアド プロシージャにアクセスする場合、キャッシュ内に未使用のコピーがなければ SQL Server が別のコピーを作成することに注意してください。

このオプションの変更を反映させるには、SQL Server を再起動する必要があります。

プロシージャキャッシュの使用状況の監視
DBCC MEMUSAGE を使うと、プロシージャ キャッシュ内のプロシージャのうち、サイズの順で 20 番めまでのプロシージャを監視できます。

DBCC MEMUSAGE の出力は、プロシージャ キャッシュに必要なメモリの見積もりに役立ちます。出力にはキャッシュ内のプランのサイズが示されるので、この数を同時ユーザーの予測数に掛けることで、必要なメモリを見積もることができます。

プロシージャ キャッシュが満杯状態になる状況として、次の 2 つが考えられます。

  • Proc Buffer 配列にサイズの小さいプロシージャが多数取り込まれると、空きページがまだ存在する場合でも、Proc Buffer 配列が満杯状態になることがあります。また、アクティブとなっていない上書き可能な使用中ページがある場合にも同じことが起こります。

  • Proc Buffer 配列内に利用可能なスロットが残っていても、サイズの大きいプロシージャがいくつか取り込まれると、利用可能なメモリがすべて消費されることがあります。

プロシージャ キャッシュが満杯状態で新しいプロシージャを実行できない場合は、エラー 701 が返されます。

There is insufficient system memory to run this query.

パフォーマンスモニタのカウンタ
Object: SQLServer ™ Procedure Cache

Counters: Procedure Cache Size and Procedure Cache Used %

Procedure Cache Size カウンタは、プロシージャ キャッシュのサイズを 2 KB ページ数で示します。このカウンタの値は、memory 環境設定オプションまたは procedure cache 環境設定オプションの値を変更して SQL Server を再起動しない限り変化しません。

Procedure Cache Used % カウンタは、プロシージャ キャッシュのうち、ストアド プロシージャ、トリガ、ビュー、ルール、およびデフォルトによって消費されている空間の量のパーセンテージを監視します。

Procedure Cache Used % の値が長期にわたって 90% ～ 95% の範囲内に落ち着いていれば、理想的です。

Procedure Cache Used % カウンタの値が大幅に低下している場合は、プロシージャ キャッシュに割り当てたメモリの量が多すぎて、データ キャッシュで使用できるメモリの量が不足しているので、procedure cache 値を減らし、SQL Server を再起動した後、このカウンタを引き続き監視してください。

Procedure Cache Used % カウンタが常に 95% を上回っている場合は、プロシージャ キャッシュへのメモリ割り当てが不足している可能性があります。その場合は、procedure cache 環境設定オプションの値を増やし、SQL Server を再起動した後、プロセスの監視を継続してください。

SQL Server の環境設定オプション

dat24e

Max Worker Threads

SQL Server プロセスに使用できるワーカー スレッドの数を設定します。SQL Server は、オペレーティング システムのネイティブなスレッド サービスを使用します。単一のワーカー スレッドではなく、多数のワーカー スレッドが使用されます。SQL Server が同時にサポートする各ネットワークを 1 つ以上のスレッドがサポートします。別のスレッドがデータベース チェックポイントを処理し、スレッド プールがすべてのユーザーを処理します。

max worker threads オプションを使うと、ユーザー プールに割り当てるスレッドの数を制御できます。ユーザー接続の数が max worker threads の値より少なければ、各接続が 1 つのスレッドによって処理されます。接続の数が max worker threads の値を超えている場合は、スレッド プールが使用されます。さらに、この値を超えると、次のワーカー スレッドが現在のタスクを完了した後で要求を処理します。既定値は、255 です。

Logwrite Sleep
バッファに余裕がある場合にログへの書き込みを何ミリ秒間待機させるかを指定します。この値を増やすと、ほかのユーザーによってデータがログ バッファに追加される可能性が高くなり、物理的なログ書き込みが必要になる頻度が低くなります。このオプションには、1 ～ 500 の値を指定できます。また、ログ書き込みを遅延させたくない場合は、特殊な値 - 1 を指定できます。このオプションは既定では 1 に設定され、ほかのユーザーが実行可能な状態になっている場合にのみサーバーが待機します。

このオプションへの変更は、即時に反映されます。

Priority Boost
SQL Server を同じコンピュータ上のほかのプロセスよりも高い優先度で実行するかどうかを指定します。このオプションを 1 に設定すると、SQL Server は高い優先度で実行されます。既定値は 0 です。SQL Server 専用の Windows NT システムを使用している場合以外は、変更しないでください。ほかの必要なプロセス (ネットワークなど) の実行に支障が生じないように注意してください。

SMP Concurrency
SQL Server が Windows NT に対して実行用に解放するスレッドの数を制御し、SQL Server が使用する CPU の数を制限します。単一プロセッサのコンピュータの場合、最適値は 1 です。SMP (Symmetric Multi-Processor) コンピュータでは、サーバーを SQL Server 専用に使用するかどうかに応じて設定します。SQL Server 専用のサーバーではない場合は、この値を変更すると、同じマシンで実行されるほかのアプリケーションに対する応答時間が低下することがあります。ほかのアプリケーションに対する応答時間が問題にならないのであれば、SMP concurrency を -1 (専用 SMP サポート) に設定して、制限をなくすことができます。

SQL Server のインストール時には、SMP concurrency が 0 (自動設定) に設定されます。自動設定モードでは、SQL Server の起動時に検出されたプロセス数を n とすると、制限は n-1 に設定されます。単一プロセッサのコンピュータでは、このオプションは 1 に設定されます。

このオプションの変更を反映させるには、SQL Server を再起動する必要があります。

Set Working Set Size
Windows NT に対し、memory オプションの設定値と同じ量のメモリ空間を SQL Server 用に予約するように指示します。tempdb が RAM 内にある場合は、tempdb のサイズも加算されます。

Network Packet Size
サーバー全体に適用する既定ネットワーク パケット サイズを設定します。クライアント アプリケーションでパケット サイズを指定した場合は、この既定サイズは無視されます。複数の異なるネットワーク プロトコルを使用しているシステムでは、最もよく用いるプロトコルのパケット サイズをこのオプションに指定してください。ネットワーク プロトコルでサポートしているパケットのサイズが大きい場合は、このオプションを使うとネットワークのパフォーマンスを向上できます。このオプションへの変更は、即時に反映されます。既定値は、4,096 です。

このオプションへの変更は、即時に反映されます。

データベースとセッションの設定

dat25e

データベース オプション

データベース オプションは、データベース所有者または SA だけが設定できるオプションです。これらのオプションはすべて master データベースに保存されるので、ほかのユーザーがデータベース所有者を装って変更することはできません。

クエリのパフォーマンスに影響を及ぼす可能性があるデータベース オプションには、次のものがあります。

read only

single user only
どちらのオプションの場合も、ロックの取得やチェックなしで操作が行われます。次のモジュールで学ぶように、マルチ ユーザー環境では、ロックの競合がパフォーマンス上の問題になることがよくあります。

その他のデータベース オプションも、間接的にパフォーマンスに影響することがあります。trunc. log on chkpt. オプションを設定すると、システム チェックポイント プロセスを実行するたびに余分なシステム オーバーヘッドが発生します。select into/bulkcopy オプションを使うと、高速一括コピーや SELECT INTO 操作を実行できます。ほかの方法を採る場合に比べて、転送速度が大幅に向上します。

テーブルオプション
一部のテーブル オプションもパフォーマンスに影響する可能性があります。これらのオプションは、sp_tableoption で設定します。テーブル オプションのうち、pintable については前述したとおりです。次のモジュールでは、もう 1 つのテーブル オプションとして insert row lock を取り上げます。

セッションオプション
セッション オプションは SET コマンドによって制御され、セッションの継続中だけ有効となります。ストアド プロシージャでセッション オプションをオンにする場合は、ストアド プロシージャが完了するまでの間だけ、それらのオプションが有効になります。

クエリのパフォーマンスに影響を及ぼす可能性があるセッション オプションには、次のものがあります。

FORCEPLAN

FROM 句にテーブルが指定されているのと同じ順序で、SQL Server オプティマイザが結合を処理するように設定します。FORCEPLAN は、実質上、オプティマイザによる選択を無効にします。

DEADLOCKPRIORITY {LOW | NORMAL}

このセッションでデッドロックが発生した場合にどう対処するかを指定します。LOW に設定すると、デッドロック時には、このプロセスを犠牲にしてデッドロックを解決します。セッションを既定のデッドロック処理方法に戻すには、NORMAL に設定します。

TRANSACTION ISOLATION LEVEL

この接続を通じて実行するすべての SQL Server SELECT ステートメントに対する既定のトランザクション ロック動作を制御します。このオプションに設定できる値については、次のモジュールで説明します。

IMPLICIT_TRANSACTIONS

ステートメント実行時にトランザクションを暗黙的に開始するかどうかを制御します。このオプションがパフォーマンスに及ぼす影響については、次のモジュールで説明します。

DISABLE_DEF_CNST_CHK

違反チェックを一時的に遅延するよう指定します。このオプションの意味とパフォーマンスに及ぼす影響については、後のモジュールで説明します。

© 1997 Microsoft Corporation. All rights reserved.

本書に記載されている情報は、発行時点で議論されている問題点に関する Microsoft Corporation の最新の見解を示しています。Microsoft は変化する市場状況に対処しなければならないため、本書の内容を Microsoft の確約事項として解釈してはならず、Microsoft は発行日以降に提示された情報の精度についてはいかなるものであれ保証致しません。

本書は、情報の通知のみを目的としており、Microsoft は本書に記載されている情報について明示的にも暗黙的にも一切の保証を致しません。

Microsoft、Windows NT は米国 Microsoft Corporation の米国およびその他の国における登録商標または商標です。

その他、記載されている会社名および製品名は、各社の商標および登録商標です。