前回のおさらい
前回は、たろーちゃんがORAエラーの原因がアプリケーション側にあるという
決定的な証拠を見つけたところで終わりました。
さて、ここからが面白いお話です
再度、交渉
お客様「え?アプリケーションサーバ側が長時間無応答になっているだって??」
たろー「はい。このトレースファイルを見て頂けますか。」
client details: O/S info: user: xxxxx, term: , ospid: 31821 machine: xxxxx program: xxxxx (TNS V1-V3) application name: xxxxx (TNS V1-V3), hash value=1851990384 Current Wait Stack: 0: waiting for 'SQL*Net message from client' driver id=0x54435000, #bytes=0x1, =0x0 wait_id=30 seq_num=33 snap_id=1 wait times: snap=1 min 37 sec, exc=1 min 7 sec, total=1 min 7 sec wait times: max=infinite, heur=1 min 7 sec wait counts: calls=0 os=0 in_wait=1 iflags=0x1a0 nt secondary err code: 0 nt OS err code: 0
たろー「これは Oracle Database から見たクライアント側(アプリケーションサーバ)の状態です。
待機イベント『SQL*Net message from client』で1分7秒も待ちが発生しています。
この時のアプリケーションサーバ側の状態を調査したいんです。」
お客様「むむむ。」
たろー「 ORA-3136 は、『時間内にユーザー認証が完了しなかった場合、接続がサーバーによってタイムアウトされた時に出力されるエラー』です。アプリケーションサーバ側が、何らかの理由で応答を返せていない可能性が高いんです。」
お客様「・・・分かった。アプリケーションサーバ側を調査してみよう。
しかし、たろーさんにアプリケーションサーバを触らせる訳にはいかない。
別の担当者に調査させるから、待っていてくれないかな?」
たろー「はい、分かりました。」
頑張った甲斐があり、なんとかアプリケーションサーバ側にメスを入れることが出来ました。
たろーちゃんが直接調査することは出来ませんが、それだけでも十分でした。
心臓外科医が心臓以外にメスを入れるのは、本当に大変なことなのです。
アプリケーションサーバ側の調査結果は?
お客様「たろーさん、お待たせ。アプリケーションサーバ側の調査が終わったよ。」
たろー「ありがとうございます、どうでしたか?」
お客様「たろーさんの言う通りだった。まずはこれを見てくれ。」
procs -----------memory---------- ---swap-- -----io---- --system- - -----cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 16 0 0 3129424 45532 2347280 0 0 0 0 2887 1844 85 15 0 0 0 15 0 0 3129424 45540 2347276 0 0 0 20 3346 1867 84 15 1 0 0 15 0 0 3129424 45540 2347284 0 0 0 0 3179 1888 83 17 1 0 0 15 0 0 3129424 45540 2347284 0 0 0 0 2653 1843 86 14 1 0 0 15 0 0 3129424 45540 2347284 0 0 0 0 2865 1855 85 15 0 0 0 15 0 0 3129424 45540 2347284 0 0 0 0 3400 1908 84 16 1 0 0 15 0 0 3129424 45540 2347284 0 0 0 0 3013 1832 85 15 0 0 0 15 0 0 3129424 45548 2347284 0 0 0 20 2648 1924 85 15 1 0 0 15 0 0 3129424 45548 2347284 0 0 0 0 2908 1869 85 15 1 0 0 15 0 0 3129424 45548 2347284 0 0 0 0 3273 1838 85 15 0 0 0 15 0 0 3129424 45548 2347284 0 0 0 0 3052 1804 85 15 0 0 0 14 0 0 3129424 45548 2347284 0 0 0 0 2665 1861 87 13 1 0 0 15 0 0 3129424 45548 2347284 0 0 0 0 2962 1872 85 15 1 0 0 14 0 0 3129424 45556 2347284 0 0 0 20 3401 1817 85 16 0 0 0 14 0 0 3129424 45556 2347284 0 0 0 0 3063 1827 85 15 1 0 0 14 0 0 3129424 45556 2347284 0 0 0 0 2680 1841 86 14 0 0 0 12 0 0 3129424 45556 2347284 0 0 0 0 2920 1819 86 14 1 0 0 14 0 0 3129424 45556 2347284 0 0 0 0 3455 1888 86 14 0 0 0 14 0 0 3129424 45564 2347284 0 0 0 20 3010 1862 84 15 1 0 0 13 0 0 3129424 45564 2347284 0 0 0 0 2680 1838 84 16 1 0 0 14 0 0 3129424 45564 2347284 0 0 0 36 2990 1854 83 16 1 0 0 14 0 0 3129424 45564 2347284 0 0 0 0 3477 1845 85 14 1 0 0 15 0 0 3129424 45564 2347284 0 0 0 0 2956 1893 83 16 1 0 0 <<以下、省略>>
たろー「 CPU のアイドルが殆ど無く、runキューも多いですね。」
お客様「調べてみた所、この時、アプリケーションサーバ上で動作しているJavaアプリケーションでFullGC(フル・ガベージコレクション)が頻発していたんだ。JavaVMに指定するヒープサイズが小さ過ぎたのが原因だ。」
たろー「よく OutOfMemoryError 発生しませんでしたね。」
お客様「まったくだ。いっそのこと OutOfMemoryError が発生してくれれば、アプリケーション側の監視で気づけたんだが・・・。」
たろー「FullGC実行中はJavaVMは完全に動作を止めますからね。それで Oracle Database に対して応答が返せなかったんですね。」
お客様「今回のことを踏まえ、アプリケーションサーバのCPU増強にメモリ増強。JavaVMのヒープサイズの見直しを行うことにしたよ。性能テストでこれらのことが分かったのは、すごく収穫だった。ありがとう、たろーさん。」
こうしてたろーちゃんは、自分の守備範囲外にまで飛び出して、原因を突き止めることに成功しました。
今回の「心臓外科医の術式」いかがだったでしょうか?
ORA-3136は、データベースサーバだけに原因があるとは限らないエラーです。
『血液検査』で異常がないということは、発想を逆転すると『心臓以外に異常がある』ということになります。
しかし今回のように、セキュリティ上の理由や役割・担当の境界で、データベース以外を調査することが困難なことがあります。そういう時は、データベース以外に異常があることを示す証拠が必要になります。
証拠の発見~原因究明までの、見事な「術式」だったのではないでしょうか。
次回も頑張りますので、応援よろしくお願い致します。