2012-01-23 7 views
0

で複数の挿入によって生じる:デッドロックは、私はこのような文を挿入しているSPを持っているため、トランザクション

begin transaction 

insert into table1 
insert into table2 
. 
. 
. 
insert into table n 

commit transaction 

このすべては限りSPが同時に呼び出されないようで結構です。しかし、spが同時に呼び出されると、最初のテーブルのプライマリキーでデッドロックの問題が発生することがあります。

+0

挿入中にテーブルをロックしていますか? – Shredderroy

+0

私が行っているのは、上記の例のようにトランザクション内でコードを実行することだけです。 –

答えて

0

ReadCommittedのような信頼性の高い分離レベルをDBに設定しましたか?

+0

設定されていません。しかし、私はReadCommitedがデフォルトのものだと信じています。 –

1

デッドロックが発生する可能性のある方法があります。実際のデッドロックグラフ(実際の xml、デックストックの画像ではありません!)を投稿してください。

本当に挿入(読み込みなし)以外に何もない場合、最も可能性の高い原因は外部キー制約です。正確なスキーマ定義(すべてのテーブル定義、すべてのインデックス定義、プライマリキーと外部キーを含むすべての制約)を投稿します。ところで、トリガーが定義されている場合、デッドロックは任意のトリガーコードによって引き起こされる可能性があるため、すべてのベットはオフになっています。

+0

あなたは正しいです。最初のテーブルの主キーを使用する外部キーがあります。現時点で問題を再現できません。どんな提案も感謝します。 –

+0

安価な方法は、データロードウィンドウ中にFK制約を無効にし、ETL後に有効にすることです。 [ALTER TABLE ... WITH NOCHECK ...](http://msdn.microsoft.com/en-us/library/ms190273.aspx)を参照してください。テーブルが大きくなっている場合、FK制約は検証する必要があるため、時間がかかることがあります。 –

+0

もう1つの比較的安価な方法は、バージョニング(スナップショットの分離または読み取りコミットされたスナップショットの有効化)を使用することです。[データベースエンジンの行のバージョニングベースの分離レベル](http://msdn.microsoft.com/en-us/library/ms177404)を参照してください。 .aspx) –

関連する問題