web-dev-qa-db-ja.com

SQLサーバーでコミットされた読み取りスナップショットを有効にすると、どのようなリスクがありますか？

私は here を読みました。行ごとにいくつかの追加データが格納されるため、パフォーマンスが低下する可能性がありますが、他にどのようなリスクがありますか？

例えば。これはデータベースの回復に影響しますか？これを利用するために他に必要なことはありますか？

これらのコマンドを実行する予定です。

ALTER DATABASE DatabaseName SET READ_COMMITTED_SNAPSHOT ON
ALTER DATABASE DatabaseName SET ALLOW_SNAPSHOT_ISOLATION ON

これにより、Oracleに近いものが得られ、1つのトランザクションが他のトランザクションを更新している場合でも、古いデータを読み取ることができます。これは正しいです？

SQL Server 2005のロックの問題にうんざりしているので、これを調べています。これにより、ユーザーに表示される不定期のデッドロックが軽減され、アプリケーションの全体的なパフォーマンスが向上し、トランザクションごとに複数の操作を行わなくても済むようになります。恐れ。

sql-serversql-server-2005transaction
73
Adam Butler

まとめ

  1. ロックの問題がある場合は、コードに問題があります。それはデータベースエンジンではありません。
  2. 魔法の弾ではない
  3. さらに問題を追加することができます

負荷

Tempdbと [〜＃〜] cpu [〜＃〜] の負荷も増加します。こちらもご覧ください：

安全性

最も重要なのは、スナップショット分離が安全ではない多くの場合デフォルトではです。書き込みスキューの異常について詳しくは、読み取り "スナップショット分離"（Wikipedia） を参照してください。次のセクションは、これを回避するための「スナップショットアイソレーションのシリアライズ可能化」です。

したがって、一般に、スナップショット分離では、潜在的な落とし穴や考えられる解決策のいずれも理解できない可能性があるユーザーに、自明ではない制約を維持するという問題の一部が発生します。この転送の利点は、パフォーマンスが向上することです。

こちらもご覧ください：

49
gbn

私はこれが古いスレッドであることを知っていますが、大まかにスナップショット分離isは魔法の弾丸です。 allリーダーとライター間のブロッキングを排除します。ただし、notは、ライターが他のライターをブロックするのを防ぎます。それを回避する方法はありません。

私の経験では、TEMPDBへの追加の負荷はごくわずかであり、ブロックされたリーダーを削減する際の行のバージョン管理のメリットは非常に大きいです。

参考までに、行のバージョン管理（スナップショット分離）は、リーダーがブロックされずに分離を実現するためにOracleが数十年にわたって使用してきた方法であり、私が20年近く経験してきたOracle DBの経験far SQLよりもブロックの問題が少ないサーバーはありません。ほとんどのSQL開発者は、デフォルト設定を使用するデータベースに対してコードをテストしただけなので、スナップショット分離の使用をためらっています。

36
Chuck

他の回答に追加するいくつかの追加ポイント：

SET ALLOW_SNAPSHOT_ISOLATION ONは、データベースでスナップショット分離のみを有効にします。これを利用するには、再コーディングして、適用するトランザクションをSET TRANSACTION ISOLATION LEVEL SNAPSHOTする必要があります。更新の競合エラーを処理するには、呼び出しコードを変更する必要があります。

SET READ_COMMITTED_SNAPSHOT ONの後、読み取りコミット時のステートメントは行バージョン管理を使用します。これはステートメントレベル読み取り専用の行バージョン管理であることに注意してください。更新の場合、「実際の」行が取得され、更新ロックが適用されます。 行バージョン管理ベースの分離レベルについて の「動作の概要」セクションを参照してください。

どちらの方法でも、徹底的なテストを行わないと、システムにまったく新しい一連の問題が発生する可能性があります。

26
Mark Storey-Smith

これにより、Oracleに近いものが得られ、1つのトランザクションが他のトランザクションを更新している場合でも、古いデータを読み取ることができます。これは正しいです？

はい、これは 正しい です。

Gbnの回答にあるリンクを読む価値は十分ありますが、スナップショット分離モードのSQL Serverと同じことがOracleのデフォルトMVCCにも当てはまると思います。潜在的な落とし穴を理解していれば、IMOの利点は追加された困難をはるかに上回ります（Oracleの観点から言えば）-もちろん、いくつかのロックの問題は正当に解消されます。それがMVCCのポイントです（クラスのクラスもあります）コードの問題で解消されないロックの問題ですが、私はあなたがこれを理解していると思います）。

19
Jack says try topanswers.xyz

SQL Server DBを使用するすべてのプロジェクトでSNAPSHOT ISOLATIONを使用しています。アプリケーションコードの誤りが原因ではなく、デフォルトのページロックと行ロックの動作が原因で発生する1205 SQLエラーはなくなりました。

パフォーマンスへの影響は最小限であり、これまでの7年間で、何億もの操作がさまざまなシステムで処理され、スナップショット分離に関する問題は発生していません。

複数の異なるスレッドが1行でビジネスクリティカルな情報を並行して更新している状況は非常に例外的であり、SNAPSHOT ISOLATIONが不整合の問題の原因となる可能性は非常にゼロに近いです。

OLTP=システムがある場合、設計により、多くのスレッドの現在の行データに基づいて単一の行が更新されます。もちろん、SNAPSHOTSはそのような場合には受け入れられません。

10
Alexander Nemsadze