NOLOCKアプリケーションの一部のユーザーはデータベースに直接アクセスでき、データベースにロックを作成せずにクエリを実行するため、サーバーのロックを減らしたいと考えています。
これを減らすために、データベースの新しいスキーマを作成し、このスキーマでデータベースに存在するすべてのテーブルのビューを作成します。このビューでは、次のように記述します。
select * from TABLE_NAME(nolock).
次に、このスキーマの権限のみをユーザーに付与します。これにより、ロックが軽減されます。
このアプローチは良いアプローチですか？また、データベースにオーバーヘッドが発生しますか?
提案してください。
( ) ヒントのBOLから:NOLOCKREADUNCOMMITED
ダーティ リードを許可することを指定します。他のトランザクションが現在のトランザクションによって読み取られたデータを変更できないようにする共有ロックは発行されず、他のトランザクションによって設定された排他ロックは、現在のトランザクションがロックされたデータを読み取ることをブロックしません。ダーティ リードを許可すると、同時実行性が向上しますが、データ変更の読み取りが犠牲になり、他のトランザクションによってロールバックされます。 これにより、トランザクションでエラーが発生したり、コミットされていないデータがユーザーに表示されたり、ユーザーがレコードを 2 回表示したり (またはまったく表示しない) したりする可能性があります。
これが受け入れられる場合は、アプローチを検討できます。確かに、すべてのクエリのパフォーマンスが向上します。NOLOCKただし、後の操作で読み取ったデータを使用すると、他の多くの予測できないバグが発生する可能性があるため、あまり良い考えではないと言わざるを得ません。
これは、使用の危険性と、使用NOLOCKを避けるために実装できるその他の解決策についての素晴らしいブログ投稿です。
いいえ、あなたのアプローチには多くのレベルで欠陥があります。少なくとも、次の 2 つの問題に注意する必要があります。
READUNCOMMITTED および NOLOCK ヒントは、データ ロックにのみ適用されます。READUNCOMMITTED および NOLOCK ヒントを含むすべてのクエリは、コンパイルおよび実行中に Sch-S (スキーマの安定性) ロックを取得します。このため、並行トランザクションがテーブルの Sch-M (スキーマ変更) ロックを保持している場合、クエリはブロックされます。
次の 2 つの代替案を検討する必要があります。
これらのユーザーがクエリを実行するためだけに、データベースのスタンバイ読み取り専用コピーを作成することをお勧めします。AG 読み取り可能なセカンダリ(贅沢なオプション)、スタンバイログ配布データベース、ローカルデータベース スナップショット、または最後のオプションとしてレプリケーションを使用できます。
別の方法として、データベースで読み取りコミット スナップショットを有効にし、行のバージョン管理によって競合を排除します。行のバージョン管理はリソースを消費し、読み取り/書き込みデータへのアクセス権を持つユーザーが誤ってデータを変更したり、スキーマを変更したりする可能性があるため、これは間違いなく、ユーザーにスタンバイ データのクエリを実行させるよりも悪いオプションです。
何を選んでも、必ず NOLOCK を取り除くようにしてください。役に立たない、うまくいかない。