ここでは、行ごとにいくつかの追加データが保存されるため、パフォーマンスの低下が見られる可能性があることを読みましたが、他にどのようなリスクがありますか？
例えば。これはデータベースの回復に影響しますか？これを利用するために私たちがしなければならないことは他にありますか？
これらのコマンドを実行する予定です。
ALTER DATABASE DatabaseName SET READ_COMMITTED_SNAPSHOT ON
ALTER DATABASE DatabaseName SET ALLOW_SNAPSHOT_ISOLATION ON
これにより、1つのトランザクションが他のトランザクションを更新している場合でも古いデータを読み取ることができるオラクルに近いものが得られると思います。これは正しいです？
SQL Server 2005のロックの問題にうんざりしているので、これを検討しています。これにより、ユーザーが時折発生するデッドロックを減らし、アプリケーションの全体的なパフォーマンスを向上させ、恐れ。
回答:
概要
負荷
また、tempdbとCPUの負荷も増加します。参照：
安全性
最も重要なことは、多くの場合、デフォルトではスナップショット分離は安全ではないということです。読む「スナップショットアイソレーション」（ウィキペディア）を書き込みスキュー異常の詳細については。次のセクションは、これを回避するための「スナップショット分離をシリアル化可能にする」です。
したがって、一般的に、スナップショット分離は、潜在的な落とし穴や可能な解決策のいずれかを理解していない可能性のある、自明でない制約を維持するという問題の一部をユーザーに課します。この転送の利点はパフォーマンスの向上です。
参照：
私はこれが古いスレッドであることを知っていますが、スナップショットの分離は大部分が魔法の弾丸であると言えます。それは排除するすべての読者と作家の間であなたのブロッキングのを。ただし、ライターが他のライターをブロックするのを防ぐことはできません。それを回避する方法はありません。
私の経験では、TEMPDBへの追加の負荷は無視でき、ブロックされたリーダーを減らす行のバージョン管理の利点は大きいです。
参考までに、行のバージョン管理（スナップショット分離）は、読者をブロックせずに分離を実現するためにOracleが長年使用してきた方法であり、私が20年近く取り組んできたOracle DBは、SQL Serverよりもはるかに少ないブロックの問題を経験します。ほとんどのSQL開発者は、デフォルト設定を使用するデータベースに対してのみコードをテストしているため、スナップショット分離を使用することにheしています。
他の回答に追加するいくつかの追加ポイント：
SET ALLOW_SNAPSHOT_ISOLATION ONデータベースでのスナップショット分離のみを有効にします。それを利用するには、再コーディングSET TRANSACTION ISOLATION LEVEL SNAPSHOTする必要があります。また、トランザクションを適用する必要があります。更新の競合エラーを処理するには、呼び出しコードを変更する必要があります。
の後SET READ_COMMITTED_SNAPSHOT ON、コミットされた読み取りのステートメントは行バージョン管理を使用します。これは、読み取り専用のステートメントレベルの行バージョン管理であることに注意してください。更新の場合、「実際の」行が取得され、更新ロックが適用されます。行バージョン管理ベースの分離レベルについての動作の概要セクションを参照してください。
いずれのルートでも、徹底的なテストを行わないと、システムにまったく新しい問題が発生する可能性があります。
これにより、1つのトランザクションが他のトランザクションを更新している場合でも古いデータを読み取ることができるオラクルに近いものが得られると思います。これは正しいです？
はい、これは正しいです。
gbnの回答のリンクを読む価値があり、スナップショット分離モードのSQL Serverと同様に、OracleのデフォルトMVCCにも同じことが当てはまると思います。潜在的な落とし穴を理解すれば、IMOの利点は追加された困難をはるかに上回ります（Oracleの観点から言えば）-もちろん、いくつかのロックの問題は合法的になくなります、それがMVCCのポイントです（クラスもあります）コードの問題が原因でなくなることのないロックの問題がありますが、これを理解していると思います）。
SQL Server DBを使用するすべてのプロジェクトでSNAPSHOT ISOLATIONを使用しています。1205 SQLエラーはもうありません。これは、アプリケーションコードの誤りではなく、デフォルトのページロックと行ロックの動作が原因です。
パフォーマンスへの影響は最小限であり、これまで7年が経過し、異なるシステムで何億もの操作が処理されました。スナップショットの分離に関する問題はありません。
複数の異なるスレッドが単一行のビジネスクリティカルな情報を並行して更新している状況は非常に例外的であり、SNAPSHOT ISOLATIONが不整合問題の原因になる可能性はほとんどゼロに近いです。
OLTPシステムを使用している場合、多くのスレッドの現在の行データに基づいて単一行を更新するように設計されているため、SNAPSHOTSはそのような場合には当然受け入れられません。