Google
オフコン練習帳内を検索
インターネット全体を検索

NECオフコン関連
オフコン一般
情報

トップ  >  障害解析支援ツール

ファイルなどのデッドロックの解析ツール

もう皆さんご存知なのかもしれませんが、最近便利そうなツールを見つけたので紹介します。

A−VXには障害が起きた時にダンプファイルを取る機能がありますが、そのダンプファイルを自分で解析できれば、便利だと思いませんか。A−VX01のフォルダの中にある「障害解析支援ツール」というものを使うとダンプファイルを解析できるようです。
”解析できるようです”とあいまいに書いたのは簡単な使い方の説明のみしかなく、いまひとつ使い方がわからないからです。そこで少し試してみました。

説明を読むと「障害解析支援ツール」というのは、レコードやファイル、ロックテーブルの排他の問題調査に使用できるようです。

実際にファイルのオープンの排他待ち状態を作ってダンプファイルを取り、障害解析支援ツールを使って調査してみます。

●排他待ち状態を作る ●ダンプをとる ●障害解析支援ツールを使う  (1)ダンプファイルの指定  (2)解析作業

排他待ち状態を作る

まず障害解析支援ツールで解析するためのダンプファイルを作らなければならないので、問題発生状態のジョブを作り出します。

下の図のような状態を作ってみます。(全然デッドロック状態ではありませんが・・・。)


#ABCで”TAHSHOHIN”というファイルをProtect属性でオープンします。これで他のジョブが”TAHSHOHIN”をオープンできなくなります。


”TAHSHOHIN”をオープンするSMARTプログラムを実行します。オープンできないので、「ファイルは使用中です;MSD001/AVX001/TAHSHOHIN」と出ました。
この後はファイルがクローズされるまで、ずっとこのSMARTプログラムは止まったままです。今回は#ABCがProtect属性でオープンしたままなのが悪いとすぐわかりますが、実際にはいっぱいジョブがあるとどのジョブが悪いのかなかなかわかりません。

ダンプをとる

問題発生状態を作り出せたので、この状態でダンプをとります。ダンプをとる操作は超危険操作なので、ここでは詳しく説明しません(誰でも気軽に操作してほしくないので)。ダンプをとるリスクを知らない人がダンプをとると痛い目に合います(私の経験から)。

ダンプをとるモードはいろいろありよくわからないので、私の場合は一番リスクが低そうな「スナップショットモード(ランニング)」を選択しました。

障害解析支援ツールを使う

ようやく本題に入ります。

(1)ダンプファイルの指定

A−VXをインストールしたドライブの¥AVX¥PADIFAS¥TOOLというフォルダの中にあるDifAS.exeを実行します。これが障害解析支援ツールです。
下が実行した画面です。

ダンプをとる」でとったダンプファイルの在り処を指定します。OSAP.DMPというファイルにファイル情報が入っているようで、このOSAP.DMPというダンプファイルを入力します。


次に下側を設定します。左下側にはサーバ名(ダンプをとったサーバ)を入れます。右下側はよくわからないので最初に入っていたままにします。(もしかしてこっちのダンプにファイル情報が入っているのか?)

最後に「開始ボタン」を押します。



うまくいくと「ダンプの採取が終了しました。」というメッセージが出ます。

ちなみに最初A−VXのドライブとは別のドライブにダンプファイルをとるように設定していたのですが、「ダンプ採取に失敗しました。確認してください」というメッセージが出てうまくいきませんでした。ダンプファイルをとるドライブを初期設定状態に戻すとうまくいきました。私の操作がまずいだけなのかもしれませんが、情報として書いておきます。

(2)解析作業

ダンプファイルの指定が終わったので、次に解析作業に入ります。

左上の「解析(A)」を選択すると「ステーション番号からのタスク一覧(S)」を選択します。


下のような解析画面が出ます。

左上に見たいジョブが実行されているステーション番号を入力して、実行ボタンを押します。
今回はステーション番号0番でジョブを実行したので、「000」と入力します。


すると右上にステーション番号0番で実行していたジョブの一覧が表示されます。#ABCとSMARTのプログラム(#FMNT2?)の2つを実行したので、この2つが表示されています。


今回はSMARTのプログラムが止まってしまった原因を調査したいので、まずSMARTのプログラムを見てみましょう。
「#FMNT2」をダブルクリックすると、下側にSMARTのプログラムの情報が表示されます。
下半分は(たぶん)このジョブで使っているファイルの一覧です。
真ん中のところに注目してください。
タスク状態にTAHSHOHINでファイル排他待ちと書いてあります。その下に原因タスクとしてステーション0番で実行している#ABCが挙げられています。
タスクというのは、厳密に言うと違いますが、ジョブとかアプリケーションといったような意味の言葉です。


それでは、ステーション0番の#ABCはどうなっているのでしょうか。#ABCの文字をダブルクリックして、#ABCの情報を出してみます。(もしステーション0番以外ならば、左上のステーション番号にそのステーション番号を入力して実行ボタンを押してからジョブ名をダブルクリックします。)
タスク状態は「STNIO完了待ち」となっています。この意味はよくわかりませんが、原因タスクが「なし」となっています。他のタスクから原因だと指摘されていて、「原因タスク=なし」となっているタスクが悪いタスクです。今回は#ABCがProtect属性でTAHSHOHINというファイルをオープンしっぱなしなのが悪いということになります。

例えば2つジョブの状態を見て、
ジョブAジョブB
タスク状態ファイルA排他待ちファイルB排他待ち
原因タスクジョブBジョブA
ファイル一覧両ジョブ共にファイル一覧にファイルAとファイルBが載っている

と互いにファイルを待っている状態ならばデッドロックになっています。
今回は単純にSMARTのプログラムの次の#ABCで原因タスクが「なし」でしたが、さらにそこから別のジョブが原因になっているなど、「原因タスク=なし」が出るまで2段3段とさかのぼっていくような複雑なものもあるはずです。