time」が多発?!たろーちゃんがこの謎のメッセージに挑みます。悪夢再び!の完結編、はじまりはじまり~。いうバックグラウンドプロセスのようだけど・・・。バックグラウンドプロセスが出力しているメッセージだ。」Aさん「それに、なんだこのファイル名は?『orcl1_lms0_8860_8865.trc』って、やけに数字が多いな。他のバックグラウンドプロセスのトレースファイルはプロセスIDだけなのに。マルチスレッド化されたんだよ。ファイル名の後ろに付いている数字は、<プロセスID>_<スレッドID>なんだ。バージョンアップの度に色々変わってるんだなぁ。インスタンス間でのメッセージの流れを制御する役割を担ってるんだよ。バックグラウンドプロセスに関しては、以前の記事『RACのリコンフィグ』の回をご参照下さい。Aさん「メッセージの流れ?」たろー「そうだ。同期を取るために、全インスタンスにブロードキャストメッセージを送信するんだ。」たろー「そして、そのメッセージを受け取ったノードは、ACK(応答メッセージ)を返す。ログファイルに書き込みを行う仕組みなんだ。」Aさん「なるほどなぁ。長時間返ってこなかった場合に出力されるメッセージだ。1590052.1に記載されている情報だ。」Aさん「なんだって?!」たろー「メッセージが出力される閾値は、500ミリ秒だ。500ミリ秒以上経過した場合にあのメッセージが出力されるんだよ。」たろー「と、いうことは、だ。レポートを開きました。time』の値が異常に高いな。ACK(応答)メッセージを受け取るまでの時間を現しているんだ。何らかの問題で、ACK(応答)メッセージを受け取るまでに時間が掛かっているのだろう。待機イベントとして現れているんだよ。待て、あわてるな、これは罠だ!たろー「いや、そう決めつけるのはまだ早い。サーバ側の負荷も関係するしな。サーバ管理者とネットワーク管理者に調査を依頼して、その時間帯に回線が輻輳状態だったり、サーバが高負荷状態だったりしないか、調べてもらおう。」たろーちゃんとAさんは、それぞれサーバ管理者とネットワーク管理者に調査を依頼しました。調査結果は?Aさん「調べてもらったよ、たろーちゃん。」たろー「どうだった?」Aさん「なんら問題なしだった。メモリにも余裕があった。ノード2においてはスカスカの状態だったよ。首を傾げるたろーちゃん。原因の切り分けたろー「Aさん。処理を流してみないか?」Aさん「ああ、構わないよ。し、Aさんは処理を実行しました。Aさん「おお、早い!もう処理が終わったぞ。ACK(応答)メッセージの問題だな。time』は発生していなかった。同期を取る必要がないからだな?」たろー「そういうことだ。」Aさん「ふーむ・・・。