SQL Server で READ COMMITTED SNAPSHOT よりも SNAPSHOT 分離レベルを使用するタイミングを理解するのを手伝ってくれませんか?
ほとんどの場合、READ COMMITTED SNAPSHOT が機能することは理解していますが、いつ SNAPSHOT 分離を行うかはわかりません。
ありがとう
SQL Server で READ COMMITTED SNAPSHOT よりも SNAPSHOT 分離レベルを使用するタイミングを理解するのを手伝ってくれませんか?
ほとんどの場合、READ COMMITTED SNAPSHOT が機能することは理解していますが、いつ SNAPSHOT 分離を行うかはわかりません。
ありがとう
READ COMMITTED SNAPSHOT
楽観的な読み取りと悲観的な書き込みを行います。対照的に、SNAPSHOT
楽観的な読み取りと楽観的な書き込みは行います。
Microsoft はREAD COMMITTED SNAPSHOT
、行のバージョン管理が必要なほとんどのアプリに推奨しています。
この優れた Microsoft の記事をお読みください:行のバージョン管理に基づく分離レベルの選択。両方の分離レベルの利点とコストについて説明します。
そして、ここにもっと徹底的なものがあります: http://msdn.microsoft.com/en-us/library/ms345124(SQL.90).aspx
Bill のコメントから始めて、私はさらに読み、他の誰かに役立つかもしれないメモを作成しました。
デフォルトでは、単一のステートメント (SELECT を含む) は「コミットされた」データ (READ COMMITTED) で動作します。問題は、データが「アイドル状態」になるのを待って、読み取り時に他のステートメントの動作を停止するかどうかです。
DB を右クリックして設定「プロパティ -> オプション -> その他」:
同時実行/ブロック: コミットされた読み取りスナップショットをオンにする [デフォルトはオフ、オンにする必要があります]:
ALTER DATABASE <dbName> SET READ_COMMITTED_SNAPSHOT [ON|OFF]
SELECT name, is_read_committed_snapshot_on FROM sys.databases
一貫性: スナップショットの分離を許可[デフォルトはオフ、議論の余地あり – OK オフ]:
SET TRANSACTION ...
)ALTER DATABASE <dbName> SET ALLOW_SNAPSHOT_ISOLATION [ON|OFF]
SELECT name, snapshot_isolation_state FROM sys.databases
質問へ: Read Committed Snapshot と Allow Snapshot Isolation のどちらかではありません。これらはスナップショットの 2 つのケースであり、独立してオンまたはオフにすることができます。スナップショットの分離を許可することは、もう少し高度なトピックです。Allow Snapshot Isolation を使用すると、コードはスナップショット ランドをさらに制御できます。
1 つの行について考えると、問題は明らかです。デフォルトでは、システムにはコピーがないため、他の誰かが書き込みを行っている場合、リーダーは待機する必要があり、他の誰かが読み取りを行っている場合は、ライターも待機する必要があります。行はすべての行をロックする必要があります。時間。「Is Read Committed Snapshot On」を有効にすると、DB が「スナップショット コピー」をサポートするようにアクティブ化され、これらのロックが回避されます。
とりとめのない...
私の意見では、「Is Read Committed Snapshot On」は、通常の MS SQLServer データベースでは TRUE である必要があり、デフォルトで FALSE を出荷するのは時期尚早の最適化です。
ただし、テーブル全体で複数の行をアドレス指定している可能性があるためだけでなく、SQL Server では行ロックが "ブロック" レベルのロック (ストレージの近接性に関連付けられたランダムな行をロックする) を使用して実装されているため、1 行のロックが悪化すると言われています。複数のロックがテーブルのロックをトリガーするしきい値があります。おそらく、ビジーなデータベースでブロックの問題が発生するリスクがある、より「楽観的な」パフォーマンスの最適化です。