【トレースフラグ 1211】──ロックエスカレーションを無効化する:SQL Serverトレースフラグレファレンス(21)
「Microsoft SQL Server」が稼働するデータベースシステムを運用する管理者に向け、「トレースフラグ」の活用を軸にしたトラブル対策のためのノウハウを紹介していきます。今回は「トレースフラグ1211の詳細と使い方」を解説します。
本連載では、「Microsoft SQL Server(以下、SQL Server)」で発生するトラブル対策を踏まえた「SQL Serverのトレースフラグ」の使いこなしTipsを紹介していきます。
今回は「トレースフラグ1211」の詳細と使い方を解説します。
トレースフラグ1211は、ロックエスカレーションを無効化する設定です。SQL Serverの全バージョンに対応します。
SQL Serverではクエリがロックリソースを1つ確保するたびに、ロック管理のためのメモリ領域を必要とします。このとき、テーブルロックと行ロックはロック範囲が異なるものの、内部管理上は同じメモリ量を消費します。
メモリリソースには限りがあるため、条件を満たすとSQL Serverのメモリ枯渇が起きないよう「ロックエスカレーション」が発生します。具体的には多数の行ロックをテーブルロックに変換して、メモリ消費量を減らします。
トレースフラグ1211はこのロックエスカレーションを抑制します。メモリリソースが少なくなってもロックエスカレーションが発生しないため、メモリ不足によるエラーが発生する可能性があります。この点には注意が必要です。
設定可能なスコープ
設定方法 | 可/不可 | 要/不要 |
---|---|---|
スタートアップ | ○ | − |
グローバルスコープ | ○ | − |
セッションスコープ | ○ | − |
クエリスコープ | × | − |
トレースフラグ 3604/3605 | − | 不要 |
動作例
ロックエスカレーションにはメリットとデメリットがあります。
効果 | 内容 |
---|---|
メリット | バッファープール(メモリ)の消費量を抑制し、インスタンス全体として効率的なメモリ利用が可能となる。加えてロックの取得と解放のオーバーヘッドが減少する。 |
デメリット | 一般には行ロックがテーブルロックに変換されるため、不必要な箇所までロックされてしまう。これにより、場合によってアプリケーションの同時実行性が低下する。 |
ロックエスカレーションが発生する条件は何でしょうか。Microsoftが公開した情報に記載があります(以下の3項目は「ロックのエスカレーション(データベースエンジン)」から引用した)。
- 1つのTransact-SQLステートメントがパーティション分割されていない1つのテーブルまたはインデックスに対して少なくとも5000個のロックを獲得した場合
- 1つのTransact-SQLステートメントがパーティションテーブルの1つのパーティションに対して少なくとも5000個のロックを獲得し、ALTER TABLE SET LOCK_ESCALATIONオプションがAUTOに設定されている場合
- データベースエンジンのインスタンスのロック数がメモリまたは構成のしきい値を超えた場合
トレースなどの資料を採取していない限り、どの条件に該当しているのか、状況から総合的に判断するしかありません。かつては3つ目の条件であるメモリの閾値を超えることで発生していた場合が多かったように思います。
構成閾値であるLocksパラメーターは規定値では0、つまりデータベースエンジンに委ねられており、データベースエンジンが利用するメモリ量の24%を超えたところでエスカレーションが発生します。
昨今ではサーバが搭載するメモリ量が多いため、発生頻度は少なくなったように思いますが、ロックによる待ちが多い場合はロックエスカレーションの存在を思い出してください(図1)。
一般にオンライントランザクション処理(OLTP)システムでは、短いトランザクションが多数動作するため、ロックエスカレーション発生時の影響が大きくなります。
筆者紹介
内ヶ島 暢之(うちがしま のぶゆき)
ユニアデックス株式会社 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ボトルネックの病巣はこれで究明できる