同じデータベースに使用する必要があるデータベース分離はどれですか。どの分離レベルが最適ですか。

Question

SQLサーバー2005で

私は非常に多くのストアドプロシージャを使用して、いくつかの更新されたテーブルレコードをトランザクションで使用し、いくつかはテーブルレコードを取得するために使用します。

テーブルレコードを更新している1つのSPが1つのSEを呼び出すとき、テーブルデータを取得するために別のSPを実行すると、待たずに実行する必要があります。

同じデータベースに使用する必要がありますか、どの分離レベルが最適ですか。

「変換スナップショット分離レベル」では、これを実行できます。 Teampdbデータベースの古いスナップショットデータを選択するため、パフォーマンスが低下する可能性があります。

あなたがお勧めするものは？

Answer 1

READ COMMITTEDは、SQL Serverのデフォルトのトランザクション分離レベルです。 （私には、とにかく）他の分離レベルの

使用すると、特定のコンテキストでREAD UNCOMMITTEDの限られた使用の可能性を除いて、私にはcode smell —、いくつかの本当の正当化を必要とし、少なくとも—を構成しています。

Answer 2

一部のテーブルで最初のトランザクションがデータを更新した場合、このデータを取得するために2番目のトランザクションが待機します（READ UNCOMMITTED分離レベルは例外ですが、この場合は非常に矛盾したデータがあります）。

Answer 3

SNAPSHOTアイソレーションレベルを使用する必要があります。データベースレベルでREAD COMMITTED SNAPSHOTを有効にすると、デフォルトのREAD COMMITTEDトランザクションがすべて自動的にスナップショット・トランザクションに変換されます。

SNAPSHOTがアプリケーションに最適な理由、特に並行性の問題によりブロッキングを起こす可能性のあるアプリケーションのための理由は無数にあり、その利点は無限です。 SNAPSHOTの分離がcost in resources usedであることは事実ですが、問題の原因となっている行バージョンストアであるという決定的な証拠を測定して見つけない限り、それを前もって却下することはできません。

使用するべきではない1つの分離レベル1は、UNCOMMITTEDです。それはトラブルを求めています。 Dirty reads are inconsistent reads。

REPEATABLEとSERIALIZABLEは非常に狭いユースケースを持ち、ほとんど必要としません。残念ながら、SERIALIZABLEは.Net System.TransactionsとMTS/COM +によって悪用されるので、多くのアプリケーションはそれを使用して終了します（それゆえ、膨大なスケーラビリティの問題があります）。