スナップショット分離と読み取りコミット-OLTPおよびレポートデータベース
分離レベルに関する優れた記事を読み終えたところです here 。弊社は、現在の製品の書き直しと拡張に関する開発を間もなく開始します。私の望みは、OLTPデータベースと、より非正規化された別のレポートデータベースを用意することです。ある程度の規律があり、アドホックおよびレポートタイプのクエリのほとんどが実際にレポートデータベースに行くと仮定します。 、OLTPデータベースのデフォルトの分離レベルはRead Committed（OLTPの場合、より厳格な分離レベルは必要ありません）であり、レポートデータベースはスナップショット分離（おそらくRCSI）であることが適切でしょうか。 ）？
私の考えでは、OLTPデータベースが実際に真のOLTPデータベースであり、レポートDBとしての役割を果たしていない場合、スナップショット分離は必要ありません。 、およびそれに伴うオーバーヘッド。ただし、レポートデータベースではスナップショット分離が望ましいため、定期的に受信するデータのフローによってリーダーがブロックされず、最後に保存された行のバージョンを読み取ることが許容されます。
他の答えに追加するだけです。
SQL Serverは、READ COMMITTEDの2つの異なるフレーバー、レガシーロックREAD COMMITTEDとREAD COMMITTED SNAPSHOTをサポートしています。大容量のOLTP READ COMMITTEDのアプリケーションの構築とサポートをこれまでに行ったことがある場合は、RCSIが導入された理由がわかります（OracleアプリケーションをSQL Serverに簡単に移植できることに加えて）。
READ COMMITTEDのロックは、並行性を取得するのが難しく、リーダーがライターをブロックし、ライターがリーダーをブロックするため、デッドロックが発生しやすくなります。デッドロックはアプリケーションの一種のバグですが、テストで見つけるのは非常に困難です。したがって、テストが難しいバグの数を減らす選択をする機会があります。それは大きな価値があります。 RCSIはまた、アプリケーションの並行性を高め、複数のコアをより簡単に使用できるようにスケールアップできるようにします。
したがって、RCSIはアプリケーションのスケーラビリティと信頼性を向上させますが、UPDATESとDELETES（およびトリガーがある場合はINSERTS）の追加の簿記と、行あたり14バイトの追加コストがかかります。
RCSIは全体的にプログラムする方が簡単です。主なことは、行を読み取ってすぐに更新したいときに、他のセッションでこの処理が行われないようにする必要がある場合に、UPDLOCKテーブルヒントを使用してロック読み取りをオプトインする必要がある場合があることです。同じことを同時に。
スナップショットまたはREAD COMMITTED SNAPSHOTによってオーバーヘッドが必ず増加し、パフォーマンスの低下につながるとは思いません。待機時間が短縮されると、スループットが向上する可能性があります。
RCSとSNAPSHOTの危険性は、アプリのコード化方法と関係があります。クエリがスナップショットモードで実行されるときにプログラマがREAD COMMITTEDのブロッキングセマンティクスを想定している場合、問題が発生する可能性があります。例えば
UPDATE foo SET bar = 1 + (SELECT MAX(bar) from foo);
複数のリーダーが同時に同じMAX（bar）値を取得するため、高スループットの状況で問題が発生する可能性があります。
ただし、何らかのOLAP以外の運用レポートとクエリが依然として必要になる可能性が高く、スナップショットモードはそこでのパフォーマンスに非常に役立ちます。
私のポイントは、RCSモードのOLTPシステムを設計および開発でき、それを検討する必要があるということです。結局のところ、これがほとんどのOLTPシステムOracleは書かれています。