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