【トレースフラグ 692】──高速インサートの無効化:SQL Serverトレースフラグレファレンス(14)
「Microsoft SQL Server」が稼働するデータベースシステムを運用する管理者に向け、「トレースフラグ」の活用を軸にしたトラブル対策のためのノウハウを紹介していきます。今回は「トレースフラグ692の詳細と使い方」を解説します。
本連載では、「Microsoft SQL Server(以下、SQL Server)」で発生するトラブル対策を踏まえた「SQL Serverのトレースフラグ」の使いこなしTipsを紹介していきます。
今回は「トレースフラグ692」の詳細と使い方を解説します。
トレースフラグ692は、「高速インサート」を無効化する設定です。SQL Serverの全てのバージョンに対応します。
SQL Serverではデータロードの方法として「BULK INSERT」というステートメントを利用できます。データベースが「単純」または「一括ログ」の復旧モデルの場合は、BULK INSERTの動作は最小ログ記録になり、SQL Serverの負荷を下げます。
トランザクションログには通常1行ずつ変更を記録します。ところが、最小ログ記録の動作時には、データロードの開始と終了だけを記録するよう変化します。こうしてトランザクションログへの負荷を下げることができます。この動作を「高速インサート」と呼びます。
高速インサート時には既存の空き領域を探さず、新しい領域を割り当てた上でデータを挿入します。そのためデータの状況によっては不必要な領域確保を行う可能性があります。これを防ぐため、トレースフラグ692で高速インサートを無効にできます。
設定可能なスコープ
設定方法 | 可/不可 | 要/不要 |
---|---|---|
スタートアップ | ○ | − |
グローバルスコープ | ○ | − |
セッションスコープ | ○ | − |
クエリスコープ | ○ | − |
トレースフラグ 3604/3605 | − | 不要 |
動作例
DBCC LOGコマンド(*1)を利用してBULK INSERT時のトランザクションログの記録を確認しました。
既定動作時にはビット操作の記録(一括操作を行った記録)を保存します(図1)。トレースフラグ692を有効にすると、ビット操作の記録ではなく多数のインデックスリーフへのデータ挿入を記録します(図2)。
*1:動作確認の項目ではDBCC LOGコマンドを使ってトランザクションログの中を確認している。DBCC LOGコマンドは非公開コマンドのため仕様が公開されていないが、LOP_XXというオペレーションコードで動作の違いが分かる。
データリカバリーは大丈夫なのか
高速インサート動作時、トランザクションログにはデータロード開始と終了だけを記録します。もしその後データベースが破損してバックアップからリカバリーしたとしても、ロードしたデータが失われることはありません。
トランザクションログには開始と終了だけを記録しますが、この他にも記録があるのです。データページの中に、高速インサートでデータロードしたページがどこにあるのかを記録している「Bulk Change Map(以下、BCM)」という領域があります。
運用の中でトランザクションログのバックアップを行う際、BCMをたどって高速インサートでロードした実際のデータをバックアップファイルに記録します。つまり高速インサートによるデータ変更はトランザクションログには残りませんが、トランザクションログのバックアップには記録されます。
つまり、データを記録するタイミングをインサート時から変更することで、インサート時のパフォーマンスを向上させているのです。
筆者紹介
内ヶ島 暢之(うちがしま のぶゆき)
ユニアデックス株式会社 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ボトルネックの病巣はこれで究明できる