【トレースフラグ 652】──ページプリフェッチを無効にする:SQL Serverトレースフラグレファレンス(12)
「Microsoft SQL Server」が稼働するデータベースシステムを運用する管理者に向け、「トレースフラグ」の活用を軸にしたトラブル対策のためのノウハウを紹介していきます。今回は「トレースフラグ652の詳細と使い方」を解説します。
本連載では、「Microsoft SQL Server(以下、SQL Server)」で発生するトラブル対策を踏まえた「SQL Serverのトレースフラグ」の使いこなしTipsを紹介していきます。
今回は「トレースフラグ652」の詳細と使い方を解説します。
トレースフラグ652は、ページプリフェッチ機能を無効にする設定です。SQL Serverの全てのバージョンに対応します。
ページプリフェッチとは、SQL Serverが備えるデータ先読み機能です。
クエリを実行して、あるページの一団を読み出し、バッファに載せてデータ処理を進める一連の流れでは、次に必要なデータをSQL Server側で予測可能な場合が少なくありません。ここでページプリフェッチが有効になっていると、あらかじめ必要なデータを読み出し、バッファキャッシュに載せることができます。例えば、ほぼ全データを読み出すスキャン処理などではページプリフェッチが有用です(図1)。
一般にページプリフェッチには処理性能を改善する効果があります。しかし、サーバが搭載しているメモリが少ないなど、バッファキャッシュの量が小さい環境下で大量のデータを操作している場合は考慮が必要です。先読みが悪影響を及ぼすことがあるからです。
このような場合はトレースフラグ652を使ってページプリフェッチを無効にしてください。
設定可能なスコープ
設定方法 | 可/不可 | 要/不要 |
---|---|---|
スタートアップ | ○ | − |
グローバルスコープ | ○ | − |
セッションスコープ | ○ | − |
クエリスコープ | ○ | − |
トレースフラグ 3604/3605 | − | 不要 |
動作例
トレースフラグ652の設定によって、ページプリフェッチ動作がどのように変化するのか、図2に示しました。
前半ではページプリフェッチが有効な状態でテーブルのスキャン操作を実行しました。赤い折れ線で示した「Readahead pages/sec」の値が上昇しています。後半ではトレースフラグ652を用いて先読み機能をオフにすると、この値は0にとどまりました。
メモリが不足しているかどうかを見積もる
トレースフラグ652を使ってページプリフェッチを無効にするかどうかを決める際、バッファキャッシュが不足しているかを調べて判断する必要があります。
バッファキャッシュが十分足りているかを確認するためには、「Page Life Expectancy」の値が300秒よりも大きいことが1つの目安となります(*1)。
Page Life Expectancyとは別に、SQL Serverには「Buffer Cache Hit Ratio」というパフォーマンスカウンターもあります。こちらはSQL Serverのワーカースレッドが必要なページを要求した際、バッファキャッシュ上にページが見つかった割合を示します。一般にこの値は90%台後半になります。
実はメモリ不足の状態でも、Buffer Cache Hit Ratioの値が下がらないことは少なくありません。こうなる理由が、ページプリフェッチの存在です。ページの先読みをしているが故に、必要なデータを要求したときには既にバッファキャッシュ上に存在しているというわけです。
以上のことから、Buffer Cache Hit Ratioはメモリ不足をリアルタイムに検知する目的にはあまり向いていないと、私は考えています。
*1:Page Life Expectancyについては連載「SQL Serverトラブルシューティング」に解説した内容が参考になる(「老朽化したデータベースを刷新したのに、かえってアプリケーションのレスポンスが悪くなった」)
筆者紹介
内ヶ島 暢之(うちがしま のぶゆき)
ユニアデックス株式会社 NUL System Services Corporation所属。Microsoft MVP for Data Platform(2011〜)。OracleやSQL Serverなど商用データベースの重大障害や大型案件の設計構築、プリセールス、社内外の教育、新技術評価を担当。2016年IoTビジネス開発の担当を経て、現在は米国シリコンバレーにて駐在員として活動中。目標は生きて日本に帰ること。
椎名 武史(しいな たけし)
ユニアデックス株式会社所属。Microsoft MVP for Data Platform(2017〜)。入社以来 SQL Serverの評価/設計/構築/教育などに携わりながらも、主にサポート業務に従事。SQL Serverのトラブル対応で社長賞の表彰を受けた経験も持つ。休日は学生時代の仲間と市民駅伝に参加し、銭湯で汗を流してから飲み会へと流れる。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- それでは“ダメ”な「トラブル対応例」
本連載は、「Microsoft SQL Server」で発生するトラブルを「どんな方法で」「どのように」解決していくか、「SQL Serverで起こりがちなトラブル」を厳選して、具体的な対処方法を紹介していきます。第1回目は「トラブルを適切に対処するための考え方」を解説します。 - 「パラメータースニッフィング」によって、あるタイミングから処理が遅くなった(パフォーマンストラブル)
本連載は、「Microsoft SQL Server」で発生するトラブルを「どんな方法で」「どのように」解決していくか、正しい対処のためのノウハウを紹介します。今回は、「あるタイミングで処理遅延が発生し、それが継続して発生するようになってしまった場合の対処例.2」を解説します。 - I/Oボトルネックの病巣はこれで究明できる