2009年5月18日月曜日

ロック・タイムアウトの調査

先日のClubDB2で質問いただいたロック・タイムアウトの調査方法をメモっときます。

1.スナップショットを見る

ロック・タイムアウトは、

- データベース・スナップショット
- アプリケーション・スナップショット

で確認できます。この回数が多い場合は、アプリロジックの並行性とか
データベース構成パラメーター(get db cfg の LOCKTIMEOUT)の値の変更を考えます。

でも実際はスナップショットを取った時にはすでにロックの問題がなくなって、スナップショットから必要な情報が取れないこともありますよね…

で、これ ↓

2.DB2_CAPTURE_LOCKTIMEOUTを利用する(でもこれ、V9.5かV9.1+FP4)

これはレジストリ変数なんですよね。そういう意味でちょっと敷居高い感あるけど、便利。
通常はOFFです。

db2set DB2_CAPTURE_LOCKTIMEOUT=ON

DIAGPATH(/home/db2inst1/sqllib/db2dump)に移動

db2locktimeoutという文字列で始まる名前のファイルの中身を確認

発生日時とか、対象のロック、アプリケーション情報などなど出力されますよん


ジョビン

3 件のコメント:

ひらの さんのコメント...

ブログ開設おめでとうございます。

「DB2_CAPTURE_LOCKTIMEOUT」は初めて目にしました。
ロックタイムアウトのみを検出でき、かつパフォーマンスへの影響が少ないように感じます。もちろんロックタイムアウトが頻発すれば負荷にはなるのでしょうが・・・しかし、実際のところ「使ってるよ」という声を聞きません。まだまだ新しい機能だからでしょうか?ロックタイムアウトの原因追求のために是非使いたいのですが、実績とか負荷とかどうなんでしょうか?

Admin ClubDB2 さんのコメント...

ひらのさん
レス遅くなってすみません、
問題判別系の新機能は安心して使ってもらって問題ないと思います。むしろ新機能の方が負荷が小さく、出力される情報が詳細かつ見やすい形式で出力されるからです。
考慮点といえば、結構な情報が出力され、diagpathにはかれるので、出力されたファイルをクリーンアップする必要あるっていうのが考慮点じゃないですかね~

平野 さんのコメント...

ジョビンさん

使ってみましたが、確かに負荷が小さいと感じました。
あまり頻繁に起きるようだと、確かにdiagpathが心配ですね。ログのメンテナンスが必要かもしれません。
有益な情報をありがとうございました。

コメントを投稿