Teradataの待ち行列の捌き方・readロックがreadロックを排他しているように見える現象
Teradataでは、readロックがwriteロックを排他する。
つまり、あるテーブルの読み取りのみ行うトランザクションAを実行中に、そのテーブルを更新するトランザクションBを開始すると、更新トランザクションBは、Aがreadロックを解放するまで待ちになる。
ここで、さらに読み取りのみのトランザクションC, D, E...が続々と開始されたらどうなるか。
読み取りのみのトランザクション同士は同時実行可能なのだから、C, D, E...が更新トランザクションを追い抜いて実行開始してくれてもよいような気がするが*1、そのようにはならない。
C, D, E...は問題のテーブルのreadロックを取ろうとして、Bのwriteロック解放待ちになってしまう。
つまり、Bさえいなければすべての処理が並列で走るのだが、更新トランザクションが1つ混ざることで、長大な待ち行列ができてしまう。
□ 読み取りのみトランザクション ■ 更新トランザクション 待ち 実行中 □□□□□□□■ □ ↑こいつのせいで後ろがつっかえてしまう
まあ、待ち行列とはそんなものなのかもしれませんが。
こういうことがあるので、Teradataでは更新だけでなく、参照でも短時間でロックを解放しなくてはならない。
オンラインバッチなどでは注意が必要。
＃＃＃
あと、トランザクションCを実行したテスターから「画面が固まった」という連絡を受けて調査を始めたら、AがCを止めている(＝readロックがreadロックを排他している)ように見えてしまい、「こんなことあるはずない...」と困ってしまったことがあった。そういうときは、間にwriteロック取得待ちのトランザクションが挟まっている。
