- PR -

SQLServer2000の排他ロックタイミングについて

1|2 次のページへ»
投稿者投稿内容
kaki@
会議室デビュー日: 2006/05/25
投稿数: 15
投稿日時: 2006-08-08 10:23
お世話になります。

SQLServer2000において、排他ロックのデッドロック回避策について、お力添えを承りたく存じます。

現状は
**************************
サーバー機
Windows2003ServerSP1
SQLServer2000SP4
**************************

の環境にて、クライアント端末からSQLを発行しております。

しかし、下記手順にて実行するとデッドロックが発生してしまい、その回避策を模索しております。
①端末Ａを利用
②分散トランザクションレベルをReadUnCommittedに指定
③トランザクションを開始
④テーブルαに対して、Insert文を発行
⑤端末Ｂを利用し、テーブルαのSelect文を発行
⑥再度、端末Ａを利用し、テーブルαに対して、Insert文を発行

この場合、⑤の段階でブロッキングが発生し、⑥の段階でタイムアウトエラーとなってしまいます。

ReadUnCommittedを用いた場合、参照クエリの排他ロックはSQLServerの仕様上ないはずですが、実際は発生するようです。

冗長な内容となってしまいましたが、何卒宜しくお願い致します。
囚人
ぬし
会議室デビュー日: 2005/08/13
投稿数: 1019
投稿日時: 2006-08-08 12:32
何がロックされているのかを Enterprise Manager なり何なりで参照してみてはどうでしょうか。
_________________
囚人のジレンマな日々
minminnana
大ベテラン
会議室デビュー日: 2004/02/05
投稿数: 246
お住まい・勤務地: 盛岡
投稿日時: 2006-08-08 12:40
端末Ｂから発行されるSelect文のトランザクション分離レベルもReadUnCommittedになっているのでしょうか。
kaki@
会議室デビュー日: 2006/05/25
投稿数: 15
投稿日時: 2006-08-08 13:01

囚人様
minminnana様


お世話になっております。
早々のご返答ありがとうございます。

-------------------------------------------------------
【1】
-------------------------------------------------------
>何がロックされているのかを Enterprise Manager なり何なりで参照してみてはどうで>しょうか。

-------------------------------------------------------
【2】
-------------------------------------------------------
>端末Ｂから発行されるSelect文のトランザクション分離レベルもReadUnCommittedにな
>っているのでしょうか。

上記二点に関しまして
まとめてお答えさせて頂きます。

★★★★★★★★★★★★★★★★★★★★★★★★★★★★
実は、Enterprise Manager の現在の利用状況にてロックオブジェクト
及びロックプロセスを確認しながらの確認作業をおこなっております。

それによると
⑤Select文を実行したタイミングで排他(IX)にロック種類が切り替わり、デッドロックが発生いたします。
そして、⑥のInsertのタイミングにてタイムアウトが発生いたします。

たとえば、
⑤Select文にNoLockなどのロックHintを設定し実行すると
デッドロック自体起こりえないのですが、⑤Select文はマージレプリケーション
の同期プロセス内での自動実行により発行されるSqlなのです。

マージレプリケーションの同期を実行しているストアド自体にロックヒントを
設定できれば何も問題ないのですが、Microsoftに問合せを行ったところ
マージレプリケーションの同期プロセス内のストアドを変更することはできない
そうなのです。

そこで他の何らかの設定にて、この現象を回避したいのですが
例えばSqlServerのデフォルトロックレベルを変更し、マージレプリケーション
の同期トランザクションレベルを設定する方法など
何か良い方法をご存知ではないでしょうか。




[ メッセージ編集済み 編集者: kaki@ 編集日時 2006-08-08 13:05 ]
minminnana
大ベテラン
会議室デビュー日: 2004/02/05
投稿数: 246
お住まい・勤務地: 盛岡
投稿日時: 2006-08-08 16:30
引用:
マージレプリケーションの同期を実行しているストアド自体にロックヒントを
設定できれば何も問題ないのですが

通常は整合性を保つためにそれが必要だから排他が掛かるものと思うのですが、とにかく更新が掛かれば問題ないという事なのでしょうか。
タイムアウトが発生するほど排他が長引くレプリケーションの方に問題があるわけではありませんか？
kaki@
会議室デビュー日: 2006/05/25
投稿数: 15
投稿日時: 2006-08-08 16:41
引用:

minminnanaさんの書き込み (2006-08-08 16:30) より:
引用:
マージレプリケーションの同期を実行しているストアド自体にロックヒントを
設定できれば何も問題ないのですが

通常は整合性を保つためにそれが必要だから排他が掛かるものと思うのですが、とにかく更新が掛かれば問題ないという事なのでしょうか。
タイムアウトが発生するほど排他が長引くレプリケーションの方に問題があるわけではありませんか？


上記件、ご回答ありがとうございます。

>通常は整合性を保つためにそれが必要だから排他が掛かる
その通りです。
ただ今回の場合、SqlServer側で予期せぬ排他ロックを獲得してしまい
困っております。

>とにかく更新が掛かれば問題ないという事なのでしょうか。
とにかく、更新(Insert)が掛かれば問題はありません。

>タイムアウトが発生するほど排他が長引くレプリケーションの方に問題があるわけでは>ありませんか？
上記件に関しまして、
レプリケーションは排他処理自体は行っておりません。
マージレプリケーションの同期処理内のSelect文をトリガーとして
自身トランザクションの排他がおこなわれてしまいます。
よって以下となります。

引用:

①端末Ａを利用
②分散トランザクションレベルをReadUnCommittedに指定
③トランザクションを開始
④テーブルαに対して、Insert文を発行
⑤端末Ｂを利用し、テーブルαのSelect文を発行
⑥再度、端末Ａを利用し、テーブルαに対して、Insert文を発行

⑤の段階で、ブロッキングが発生
⑥の段階で、タイムアウトエラー



[ メッセージ編集済み 編集者: kaki@ 編集日時 2006-08-08 16:44 ]
Mako
会議室デビュー日: 2006/05/01
投稿数: 4
投稿日時: 2006-08-08 16:46
確かにマージレプリケーションの同期を実行している
内部的なトリガ、及び内部的なストアドのロックレベルは設定出来ない。
及びロックヒントも設定が出来ないと聞いたことがあります。
kaki@
会議室デビュー日: 2006/05/25
投稿数: 15
投稿日時: 2006-08-08 16:58
Mako 様

早速のご回答ありがとうございます。

引用:

確かにマージレプリケーションの同期を実行している
内部的なトリガ、及び内部的なストアドのロックレベルは設定出来ない。
及びロックヒントも設定が出来ないと聞いたことがあります。


そうですね、
Microsoftの担当者もそれがSQLServer2000の仕様であるとおっしゃってました。

その為なのか、この件に関する資料が非常に乏しく、
お恥ずかしながら、難航している状況というところです。

改めまして、お力添えをお願い申し上げます。


[ メッセージ編集済み 編集者: kaki@ 編集日時 2006-08-08 17:00 ]
1|2 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）