- ベストアンサー
トランザクションの考え方
トランザクションの考え方を教えて下さい。 「データの参照や追加・更新・削除といった処理に矛盾がないことを保証する」という記述を見たのですが、下記の場合も良いのでしょうか。 トランザクションの開始 SELECT * FROM Aテーブル WHERE 項目A = '1' --処理-- UPDATE Aテーブル SET 項目B = '2' WHERE 項目A = '1' トランザクションの終了 開始から終了までの間に他のPCによって SELECT対象のデータが増える可能性があります。 この場合UPDATEするときはやはりSELECTの結果でLOOPするべきなのでしょうか。 上記のようにするとSELECT件数とUPDATE件数は異なってしまうのでしょうか。 環境はVB2005+SQL Server です。
- みんなの回答 (2)
- 専門家の回答
質問者が選んだベストアンサー
「トランザクション 分離レベル ファントム」などで検索することをおすす めします。 MS SQL-SERVERの分離レベルはデフォルトでは「READ COMMITTED」なので、 トランザクション単位では読み取りの一貫性を保証しません。 他のトランザクションが挿入しCOMMITしたデータをUPDATE段階で読み込んで しまいますね。 だからといって分離レベルをSERIALIZABLEに上げると、パフォーマンスの劣化やデッドロックエラーが頻発する危険が大きいです。 楽観的ロックでループ回すのが一般的かもしれませんね。
その他の回答 (1)
- nda23
- ベストアンサー率54% (777/1415)
トランザクションは更新の一貫性を保つために使われるので、 SELECTのように参照を目的とするクエリを実行する場合は無用です。 また、「一貫性」という意味では単一テーブル、単一レコードの更新では、やはり意味が乏しい。 この「一貫性」とは例えば、AテーブルとBテーブルがあり、両方のテーブルを更新する時に、 Aテーブルだけ更新され、Bテーブルが更新されないという事態を防ぐことを意味します。 よって、以下のように記述します (1)トランザクション開始 (2)Aテーブルの更新 (3)Bテーブルの更新 (4)トランザクション終了(コミット)※ここで、DB上に更新が反映される。 上記手順中、(2)と(3)の間でエラーになった時はロールバックがかかり、(2)の更新は「なかったこと」になります。 しかし、「SELECTとUPDATEをLoopする」とは変な発想ですね。何か根本的な間違いがあるのでは?
お礼
「SELECTとUPDATEをLoopする」は言葉足らずですね。 「SELECTしたデータのKEY項目をWHEREで指定しUPDATEする」です。 処理としてはSELECTした全件の処理をすべて行う最中に、 エラーになったらロールバックし、 全件OKな時だけ更新したかったのですが、 同じロールバックするなら「データテーブル1件づつ読み込み、 処理をしてUPDATE」を繰り返しても同じだという事に今気が付きました(-_-;) が、質問にもありますSELECT件数とUPDATE件数が変わらないようであれば、 質問のロジックで良いと思ったのですが、 >SELECTのように参照を目的とするクエリを実行する場合は無用 ということはやはりSELECT件数とUPDATE件数は違ってくる可能性が大なのですね。 トランザクション開始でACCESSのスナップショットのようなもの作られるようなイメージを持ってしまっていました。 ご指摘のように根本的に考え違いをしているようです。 有難うございました。
お礼
>楽観的ロックでループ回すのが一般的かもしれませんね。 こちらの方で対応したいと思います。 >他のトランザクションが挿入しCOMMITしたデータをUPDATE段階で >読み込んでしまいますね。 やはりそうなのですね。 本番で発生されたら大問題でした。 これで自信を持って(!?)修正できます。 分離レベルの方も勉強したいと思います。 ありがとうございました。