この特集のトップページへ

○SQL Server:Buffer Manager:Free Buffers
　このカウンタは，SQL Server 7.0が自動的に構成して管理しているバッファの空き領域サイズを示している。SQL Serverに空きバッファがあるか否かを監視するには，このカウンタの値を調査すればよい。
　当然ながら，このカウンタの値が0になるのは望ましくない。このカウンタの値が0になったということは，SQL ServerのLazyWriterスレッドで提供可能な範囲を超えて，多数のユーザーがバッファの利用を要求しているということである。このカウンタの値が0または0に近い場合は，SQL Server:Buffer Manager:Lazy Writes/secカウンタの値を調べる。
　LazyWriterスレッドは，バッファキャッシュの空き領域が閾値以下になったときにバッファ内のダーティページをディスクに書き出し，空き領域を生成する。LazyWriterスレッドによるディスクI/Oが頻発している場合，ディスクがボトルネックとなるので，ディスクI/Oを並列化する必要がある。具体的には，ディスクドライブを分ける，ディスクコントローラを分ける，サーバーを分ける，テーブルをファイルグループでグループ化して各ファイルグループを別のディスクドライブに配置する，などの対処が必要となる。

○SQL Server:Buffer Manager:Lazy Writes/sec
　このカウンタの値は，LazyWriterスレッドがディスクに書き出したダーティページのページ数を示す。このカウンタの値が一貫して高い場合は，LogicalDisk:Current Disk Queue LengthカウンタまたはPhysicalDisk:Current Disk Queue Lengthカウンタの値を観察し，それぞれ2以上であればmax async IOオプションを調整するか，ディスクI/Oを並列化する。

○SQL Server:Buffer Manager:Page Reads/secと
　SQL Server:Buffer Manager:Page Writes/sec
　このカウンタは，SQL Serverが要求したデータの存在するページを物理的にデータベースから読み書きするために実行したディスクI/Oの回数を表す。一般的に，ランダムアクセスならば75〜90回程度，シーケンシャルアクセスなら150〜250回程度であろう。通常は両方のアクセス手法を混用するので，PageReads/secカウンタとPageWrites/secカウンタの和が150を超えるようであれば，LogicalDisk:Avg.Disk Queue Lengthカウンタの値とPhysicalDisk:Avg.Disk QueueLength カウンタの値を調べ，ディスクI/Oの待ち行列が生成されていないかどうかを調べる。

　メモリのボトルネックとディスクのボトルネックを切り分けることは難しい。通常は，メモリ不足はページフォルトで，ディスクの問題はAvg. Disk Queue Lengthカウンタの値で評価する。メモリオブジェクトのMemory:Page Inputs/secカウンタとMemory:Page Reads/secカウンタを比較し，Memory:Page Inputs/secカウンタの値に占めるMemory:Page Reads/secカウンタの値の比率が高ければ，仮想メモリからの読み込みが多いことになり，物理メモリが不足していると判断される。逆に，比率が低ければ，アプリケーションのデータ要求によるデータページあるいはインデックスページの読み込みが多いと思われるので，ディスクI/Oの過多またはバッファの不足を調べる。もしAvg. Disk Queue Lengthカウンタの値が2以上であれば，ディスクの処理能力以上のI/O要求がある。Page Reads/secカウンタとPage Writes/secカウンタの値を比較して，大きいほうのI/Oが多いことになる。Page Reads/secカウンタの値が大きければ，アプリケーションが検索中心か，検索効率が悪いか，ディスクのボトルネックと考えられる。この場合も，メモリを増やしてバッファを大きくできれば，先読みマネージャによって解決できる可能性が高まる。Page Writes/secカウンタの値が大きければ，アプリケーションからの挿入要求や更新要求が多いため，ディスクボトルネックになっていると考えられる。この場合でも，バッファサイズを大きくすることで書き込み頻度を下げることができる。

○SQL Server:Buffer Manager:Readahead Pages/sec
　SQL Serverが実際に必要とする以前にページを非同期にフェッチした要求数である。どれだけ先読みが行われているかをこのカウンタ値で判断することができる。 　先読みが効果的であるか否かを調査するには，DBCC SQLPERF(RASTATS)ステートメント（Fig.9-60参照）を実行し，RA Pages Placed in CacheカウンタとRA Pages Found in Cacheカウンタを調べる。RA Pages Found in CacheカウントがRA Pages Placed in Cacheカウンタより大きければフェッチが効率的であり，逆であればフェッチが非効率的であることがわかる。すなわち，ランダムアクセスが主に発生しているか，データページが断片化しているか，あるいはデータ配置が離散しているなどの状況が考えられる。データページの断片化は，DBCC SHOWCONTIGステートメントで調べることができる。データの配置が離散しているのであれば，テーブルの再構築が必要となる。

○SQL Server:Database:Log Flushes/sec
　このカウンタは，ディスクにログを書き込んだ回数を示す。ディスクへの書き込みがボトルネックであれば，トランザクションログをディスクに書き込む処理が主たる原因か否かを判断する必要がある。そのときに利用するのが，このカウンタである。
　ログマネージャは，60Kバイト以下の単位でシーケンシャルにトランザクションログをディスクに書き出す。したがって，ログの書き込みによるトランザクションログの転送速度がディスクの最大転送速度に近似していれば，トランザクションログの書き込みがボトルネックになっている可能性がある。トランザクションログの書き込みの転送速度に近似していなくても，ほかのカウンタ（SQL Server:Buffer Manager:Pages Writes/secまたはPhysicalDisk:Disk Writes/ sec）と比較してトランザクションログの書き込みの影響度を判断する。比率が大きければ，トランザクションログの書き込みがディスクのボトルネックとなっている可能性がある。

○SQL Server:Database:Log Flush Waits/sec
　このカウンタは，ログファイルへの書き込みを待っていたログのコミット数を示す。トランザクションログの書き込みを待っているトランザクションログが存在すれば，PhysicalDisk:Avg. Disk Queue Lengthカウンタを調べ，ディスクI/Oの待ち行列が生成されているか否かを確認する。

○SQL Server:Database:Log Flush Wait Times
　このカウンタは，ログマネージャがログファイルへの書き込みを待っていた総時間（ミリ秒）である。トランザクションログの書き込みを待っている時間は，小さいほど好ましい。SQL Server:Database:Log Flushes/secカウンタの値で除算すると，1回のトランザクションログの書き込みあたりの平均待ち時間が得られる。この値が正の値であれば，PhysicalDisk:Avg. Disk Queue Lengthカウンタを調べ，ディスクI/Oの待ち行列が生成されているか否かを確認する。

○SQL Server: Access Methods: Page Splits/sec
　このカウンタは，テーブルにページ分割がどの程度発生しているかを示す。カウンタの値が1以上であれば， DBCC SHOWCONTIGステートメントを実行して， Scan Densityカウンタの値を確認する。 Scan Densityカウンタの値は100％であることが望ましい。たとえば，このカウンタの値が70％以下であれば，テーブルの再構築を実施する。 　DBCC SHOWCONTIGステートメントを実行するときには，引数としてテーブルIDを指定しなければならない。テーブルIDがわからなければ，次のようなSELECTステートメントで調べることができる。

　　　SELECT object_id('テーブル名')

Fig.9-74 DBCC SHOWCONTIGステートメントの実行例

　Fig.9-74に示される各データは，次のような意味を示している。

Table 9-11　DBCC SHOWCONTIG

データ名 説明
スキャンされたページ数 テーブルまたはインデックスのページ数を示す
スキャンされたエクステント数 テーブルまたはインデックスのエクステント数を示す
切り替えられたエクステント数 エクステント間をまたがってテーブルまたはインデックスのページをスキャンした回数を示す
エクステントごとの平均ページ数 1エクステントあたりのページ数を示す
スキャン密度［最善：実際］ 「最善」は，すべてのエクステントが連続的にリンクされている場合のエクステントスキャンの回数を示す。「実際」はエクステントをスキャンした回数を示す。すべて連続的にリンクされているときは，スキャン密度が100になり，100未満であれば，断片化が生じていることを示す
論理スキャンフラグメンテーション インデックスのリーフページをスキャンするとき，IAMで示される次ページと，リーフページの次ページポインタで示されるページとが異なる比率を示す
エクステントスキャンフラグメンテーション インデックスのリーフページをスキャンするとき，インデックス上の現在のページを含むエクステントの物理的な位置が，インデックス上の前ページを含むエクステントの直後でないエクステントの比率を示す
ページごとの平均空きバイト数 スキャンしたページの平均の空きバイト数を示す。数値が小さいほど効率がよくなる。行長が大きいと，数値も大きくなる
平均ページ密度（全体） パーセントで表した平均ページ密度。値が大きいほど好ましい

　Scan Densityカウンタの値が100％を相当下回っている場合は，次のようにしてクラスタ化インデックスを再構築する。

　　　CREATE INDEX......DROP_EXISTING
前へ Chapter 9　43/46 次へ