行レベルとページレベルのロックの違いと結果
メンテナンスプランを実行しようとすると、次のエラーが表示されます。
クエリ ""の実行は次のエラーで失敗しました： "ページレベルロックが無効になっているため、テーブル" "のインデックス" "（パーティション1）を再編成できません。"
現在、このインデックスで行レベルのロックが有効になっています。ページレベルのロックを有効にすることはできますが、どのような影響があるのかわかりません。
私の質問は： 2つのロック方式の違いは何ですか、そして実際の（運用中の）結果は何ですか？
クエリ ""の実行は次のエラーで失敗しました： "ページレベルロックが無効になっているため、テーブル" "のインデックス" "（パーティション1）を再編成できません。"
保守計画は、オンライン操作であるALTER INDEX REORGANIZEを試行している必要があります。断片化（ページの順序が正しくない）を削除するには、ページをロックして移動する必要があります。これは、ページロックが無効になっている場合は不可能です。ページロックなしでデフラグする唯一の方法は、パーティション全体をロックすることです。これは、REORGANIZEがオンラインのみであるため不可能です。
2つのロックスキームの違いは何ですか、そして実際の（運用中の）結果は何ですか？
特定のロックタイプを許可しないことの影響を評価するには、レコードとページが何であるかを把握する必要があります。 SQL Serverストレージの内部に慣れていない場合は、 レコードの分析 および ページの分析 から始めます。簡単に言えば：
- 行=レコード
- 行は8kbのページに保存されます
許可されたロックタイプを変更する場合：
- ページロックを無効にする=行とテーブルのロックのみ
- 行ロックを無効にする=ページおよびテーブルロックのみ
- 両方を無効にする=テーブルロックのみ
私が知っている2つのシナリオで、ロックタイプを禁止することが有益な場合があります。他の人がいないという意味ではありません。うまくいけば、他の誰かが例を示してくれるでしょう。
頻繁にアクセスされるルックアップテーブル、変更頻度が低い-ページレベルと行レベルの両方のロックを無効にすることで、すべてのリーダーが共有テーブルロックを取得します。これは、テーブルでの通常のインテント共有よりも高速/安価で、ページでのインテント共有、最後に特定の行の共有ロックが続きます。
特定のデッドロックシナリオの防止-同じページで頻繁にロックを取得する同時プロセスによってデッドロックが発生した場合、行ロックを禁止すると、ページロックが発生します。代わりに撮影。その後、一度に1つのプロセスだけがページにアクセスでき、もう1つのプロセスは待機する必要があります。
最初の例はマイクロ最適化であり、典型的なシステムで測定可能な利益をもたらす可能性は低いです。 2番目は、特定のデッドロックシナリオを解決しますが、予期しない副作用を引き起こす可能性があります。コードの別のセクションで同時実行を強制終了します。影響を完全に評価することは難しいため、注意してアプローチしてください。
デフォルトでは両方が有効になっていますが、これは正当な理由がない限り変更しないでください。
おそらく何もない。 MSはあなたや私よりもよく知っていると思います
私は大量のOLTP=システムで作業しており、設定を変更する必要性を感じたことはありません。いずれにしてもデッドロックが発生するため、デッドロックを再試行する必要があります
引用 SQL Server Storage Engineブログ、「SQL2005のロックエスカレーション」 nとにかく完全に読む価値があります。
デフォルトでは、ROWロックとPAGEロックの両方が有効になっています... SQL Serverは、ほとんどの場合、ROWロックの粒度を選択しますが、必要に応じてPAGEロックを選択する場合があります。したがって、指定したケースでは、ROWロックが発生する可能性があります。データベースまたはインスタンスレベルでPAGEロックをオフにする方法はありません。ページロックのためにブロックが発生していますか？
行ロックのみを強制すると、他の場所でより効果的に使用できるリソースを消費することになると思います。負荷が問題になるほど高い場合、なぜメモリを消費するのでしょうか。ブログ記事はこれに入ります
これらのように、この背後には迷信があると思います：