問題タブ [isolation-level]

ロックのエスカレーションに関連すると思われる問題を調査し、READ_COMMITTED_SNAPSHOT が解決策になると考えていたときに、それが既に有効になっているかどうかを確認しました。驚いたことに、データベースの互換性レベルは 80 でした (SQL Server 2000、私はここに来たばかりで、誰もその理由を知らないようです!)。

しかし、READ_COMMITTED_SNAPSHOT は 2005 年の新機能です。有効にされていても、2000 互換モードで実行している場合に影響はありますか?

SQLServerの分離レベルを完全に理解しようとしています-特にREPEATABLEREAD。

トランザクションを開始し、いくつかのデータの周りにカーソルを置くsprocがあります（ブーヒス）。これはかなりの量のデータになる可能性があるため、実行に時間がかかる場合があります。

その後、COMMITまたはROLLBACKします。

この間、トランザクションが閉じられる前に、影響を受ける行の一部をREADにするメソッドを誰かが呼び出すと、最初のメソッドが完了するまでこのメソッドが停止することを理解しています。その後、データが提供されます（最初にタイムアウトが発生しない限り）

私は正しいと思いますが、質問は-私ですか？！

私たちは EF4 を評価していますが、私の DBA は、すべての SELECT ステートメントで NOLOCK ヒントを使用する必要があると言います。そのため、EF4を使用するときにこれを実現する方法を検討しています。

EF4 でこれを実現する方法に関するさまざまなアイデアを読みましたが、すべて回避策のようであり、Microsoft または EF4 によって認可されていません。LINQ-to-SQL / LINQ-to-Entities および EF4 を使用するときに SELECT ステートメントに NOLOCK ヒントを含めたいという人への「公式の Microsoft」応答は何ですか?

ちなみに、私が見つけた最高の情報はここにあり、このトピックに関心のあるすべての人にこのスレッドを読むことをお勧めします.

ありがとう。

SET TRANSACTION ISOLATION LEVEL REPEATABLE READを使用する場合のリスクまたはパフォーマンスの低下は何ですか？

BizTalkサービスから呼び出されるSPがいくつかあります。時々デッドロックが発生します。分離レベルを変更した場合、どのようなリスクとパフォーマンスの低下の可能性がありますか？

IfxCommand を使用して単純な選択クエリを実行しようとしています。分離をダーティ リードに設定したいのですが、IfxTransaction のコンテキストで分離レベルを設定する例しか見つかりませんでした。select ステートメントを発行するだけなので、トランザクションは必要ありません。以下は私の現在のコードですが、これが最善のアプローチですか? また、分離レベルがダーティ リードに設定されたままになる時間を知っている場合は、知りたいです。

「すべてのステートメント（選択/挿入/削除/更新）には、トランザクションに関係なく分離レベルがあります」というのは本当ですか？

トランザクション内でステートメントの更新を設定したシナリオがあります（ReadCommitted）。そして、トランザクションにない別のセット（selectステートメント）。

1. この場合、最初のセットが実行されているとき、別の待機があります。

2. DBにREAD_COMMITTED_SNAPSHOTを設定すると、デッドロックが発生します。

   /li>

この問題を解決するには、TransactionScopeに「Select」ステートメントを配置する必要がありますか？

Django で使用されるトランザクションのデフォルトの分離レベルを知っていますか? データベースに依存しない方法で分離レベルを設定することは可能ですか?

私は主に mysql と postgres に興味があります。

NHibernate を利用するプロジェクトで、テスト ケースに sqlite を使用しています。ReadUncommitted トランザクションを作成しようとする場合を除いて、すべてがうまく機能しています。

例: Session.BeginTransaction(System.Data.IsolationLevel.ReadUncommitted)

エラーメッセージは次のとおりです。

「分離レベル」

（それでおしまい）

コール スタックは次のようになります。

別の分離レベル (シリアル化または readcommitted など) に切り替えると、すべてが正しく実行されます。

アイデア？

C# システムが、SQL (SQL2k5) では真相を解明できない奇妙な現象を引き起こしています。

状況は、同じテーブルを参照して同時に実行されている 2 つの別個のプロセスがあり、両方が 2 つの異なるクラスター上の 2 つの異なるサービス COM+ コンポーネントで独自のトランザクション内で実行されているということです。どちらもSQL テーブルOrderと通信しています。OrderItemどちらもREAD COMMITTED分離レベルで実行されています。

ジョブ 1: 注文と 1 つ以上のアイテムをこれらのテーブルにロードします。

ジョブ 2: 完全に処理されたすべての注文を見つけて、上記のテーブルから選択する数分ごとに発生するスケジュールされたタスク。

問題:私たちが発見したことは、ジョブ 1 が完全に完了する前に、過去 8 か月間に 4 回、ジョブ 2 がジョブ 1 からの部分的にロードされた注文に反応したことです (注文のアイテムは在庫がないため、在庫がありません)。終了ステータスであるため、注文の残りの部分がまだロードされていないため、ジョブによって表示されます)。

調査によると、ジョブ 1 の進行中は次のことを行うことができません。

注文から*を選択

注文が挿入されたら。ただし、次のことができます。

select * fromOrder o 内部結合 OrderItem oi on oi.orderid = o.id

同時に（これはなぜですか？）。

同じ状況を再現する調査では、ジョブ 1 から部分的に作成された注文をジョブ 2 で確認することはできません。いくつかの行は返されますが、ジョブ 1 によって挿入された注文は返されません。しかし、これは実際の環境で起こっていることです。 !

なぜこれが起こっているのかについての洞察を持っている人はいますか?

不適切な IsolationLevels を使用したデータベース接続で、アプリケーションに問題があるかどうかを把握しようとしています。私たちのアプリケーションは、SQL Server 2005 を使用する .Net 3.5 データベース アプリです。

接続が接続プールに返されたときに接続の IsolationLevel がリセットされないことを発見し (こちらを参照)、このブログ投稿で、作成された新しい TransactionScope ごとに独自の接続プールが割り当てられることを読んで本当に驚きました。

データベースの更新は (ビジネス オブジェクトを介して) TransactionScope 内で行われます (ビジネス オブジェクト グラフの更新ごとに新しいトランザクションが作成されます)。しかし、フェッチは明示的なトランザクションを使用しません。したがって、私が疑問に思っているのは、フェッチ操作 (デフォルトの IsolationLevel - Read Committed を使用する必要があります) が、更新に使用されたプールからの接続を再利用し、更新の IsolationLevel を継承するという状況に陥る可能性があるということです。 (RepeatableRead)? それとも、TransactionScope にラップされているため、更新は別の接続プールを使用することが保証されますか?

前もって感謝します、

グラハム