N課長からの呼び出し

システムの「心臓」こと、Oracle Databaseに日々携わるたろーちゃん。
たろーちゃんがいつものように業務を行っていると、直属のN課長から呼び出しを受けました。N課長は怒った顔をしています。
何があったのでしょうか?

たろーちゃんを取り巻く相関図

N課長「・・・たろーさん。」
たろー「はい、何でしょうか?」
N課長「君はH課長の所の新人Tさんに、何かしたのかね?」
たろー「え?いいえ、何もしてないです。
この前、技術的に困っていたので、相談に乗っただけですけど・・・。」
N課長「・・・H課長に言われたんだけど、H課長はTさんに、『サポートに重要度1で問い合わせて』と指示したらしいじゃないか。何故そこに君が首を突っ込むんだ?」
たろー「いや、内容的に重要度1で問い合わせるようなことでは無かったですし、サポートに問い合わせるよりも、こちらで解決したほうが早いと思ったので……。」
N課長「どうして、たろーさんがそれを判断できるのかね?サポートに問い合わせたほうが確実だろう?君の判断に誤りがあって、もし更に深刻な障害になったらどう責任を取るつもりなんだ?」
たろー「!・・・申し訳ありません。」
N課長「TさんもH課長に怒られて落ち込んでいるらしいよ。
私もH課長から注意を受けたし、もうヨソに関わるのは辞めたまえ。」
たろー「すみませんでした・・・。」

N課長

心臓外科医の苦悩

良かれと思ってやったことが裏目に出て、直属のN課長からの叱責。
これには流石のたろーちゃんも落ち込みました。
そんな所に、隣の部署の先輩Dさんが通りかかりました。 

Dさん「どうした?たろーちゃん。すごく沈んだ顔して。」
たろー「あ、先輩・・・。」
Dさん「何かあったのか?」
たろー「実は・・・。」

Dさん

たろーちゃんはDさんに、事情を説明しました。

Dさん「なるほどなー。」
たろー「あの時、先輩に言われた『領空侵犯』の意味が、ようやく分かった気がします。」
Dさん「…あのね。たろーちゃんは、確かに優秀だよ。俺もこの前のUNDO障害や Statspack の件で随分助けられたからね。でも前にも言ったけど、H課長は自分の組織は自分色に染めないと気が済まないタイプなんだ。そんなH課長にとって、たろーちゃんは、目障りなんだよ。何せ自分の部署の新人が自分色に染まらないんだからね。」
たろー「・・・。」
Dさん「前にも忠告したけど、『触らぬ神に祟りなし』と言ったのはそういう意味だ。
『権力闘争』じゃ勝てないし、もう放っておくのがベストだよ。」
たろー「そんな・・・。私は別に『権力闘争』なんかする気は・・・。」
Dさん「分かってるって。たろーちゃんの性格はよく知ってるつもりだよ。」

悔しくて、涙が出てきた・・・。

 

 

 

 

 

Dさん「たろーちゃんは直球しか投げれないし、直球しか受け取れないんだ。
言ってみれば今回の件はH課長から変化球が来たんだよ。たろーちゃんには捕れないボールだ。」
たろー「変化球……?」
Dさん「気にすんなって言うのは無理かもしれないけど、今日は一緒に晩飯でも食いに行こうよ!
そういや、たろーちゃんはアプリケーション部門のAさんとも仲が良かったよな。
俺が奢るからAさんも連れて3人で美味い物でも食いに行こうぜ!」

Dさんの心遣いが嬉しくて、更に涙が出てきた・・・。

部長の指示

ある日のこと、部長がN課長の所にやってきました。
何かあったのでしょうか? 

部長「N課長、ちょっといいかね?」
N課長「はい、なんでしょうか?」
部長「実は今、H課長の所の某システムで、ちょっとした問題が発生していてね。
サポートにも問い合わせているんだが、前に進まない状態なんだ。
そこで、たろーちゃんにヘルプをお願いできないかな?」
N課長「はい、分かりました。」
部長「たろーちゃん、聞こえていたよね?
担当は新人のTさんなのだが、ちょっと助けてやってくれないか。」
たろー「え・・・いや、申し訳ありません、部長。私には・・・。」
部長「いや、無理なら無理でいいから、ちょっと見るだけ見てやってよ。」


部長は半ば強引にたろーちゃんをH課長のもとに連れて行きました。

H課長

部長「H課長。今、問題になっている状況をたろーちゃんに説明してやってくれ。」
H課長「お言葉ですが、部長。既にサポートに問い合わせていますので、たろーさんにお願いすることは何もありません。」
新人T「・・・。」
部長「H課長。『三人寄れば文殊の知恵』ということわざもあるじゃないか。
サポートへの問い合わせは継続しつつ、我々でも出来ることをやろう。」
H課長「はぁ・・・。」
たろー「・・・。」
H課長「じゃあTさん、説明してあげて。」
新人T「はい!」
たろー「どういう状況なの?」
新人T「先日診て頂いた4ノードRAC(Real Application Clusters)の環境なのですが、自動化メンテナンスタスクのウィンドゥ時間内にテーブルやインデックスの統計情報収集処理が収まらなくて困ってるんです。」
※このシステムについては、以前の記事『表領域には空きがあるのに』を参照してください。

たろー「相当大きなデータが入ってるんだね。」
新人T「そうなんです。サポートにも問い合わせているのですが、
『処理時間は御客様のハードウェア環境やデータ量に依存します』という杓子定規な回答ばかりで
進展がないんです。ちょっとこれを見て頂けないでしょうか?」


そう言うと新人Tさんはパソコンの画面をたろーちゃんに見せました。
 

SQL> SELECT JOB_NAME, ACTUAL_START_DATE,
       TO_CHAR(LOG_DATE - ACTUAL_START_DATE) as "TIME",
       STATUS,
       INSTANCE_ID
  FROM DBA_SCHEDULER_JOB_RUN_DETAILS
 WHERE JOB_NAME Like 'ORA$AT_OS%'
 ORDER BY ACTUAL_START_DATE desc
;


JOB_NAME               ACTUAL_START_DATE   TIME                       STATUS    INSTANCE_ID
---------------------- ------------------- -------------------------- --------- -----------
ORA$AT_OS_OPT_SY_14359 2013/08/05 22:00:09 +000000000 01:26:33.794625 SUCCEEDED           3
ORA$AT_OS_OPT_SY_14339 2013/08/04 06:00:07 +000000000 14:58:46.144770 SUCCEEDED           4
ORA$AT_OS_OPT_SY_14319 2013/08/03 06:00:05 +000000000 19:59:54.315054 STOPPED             3
ORA$AT_OS_OPT_SY_14299 2013/08/02 22:00:06 +000000000 03:59:53.295947 STOPPED             3
ORA$AT_OS_OPT_SY_14279 2013/08/01 22:00:08 +000000000 03:59:51.902880 STOPPED             2
ORA$AT_OS_OPT_SY_14259 2013/07/31 22:00:14 +000000000 03:59:45.756109 STOPPED             3
ORA$AT_OS_OPT_SY_14239 2013/07/30 22:00:08 +000000000 03:59:52.510702 STOPPED             3
ORA$AT_OS_OPT_SY_14219 2013/07/29 22:00:08 +000000000 03:59:51.727279 STOPPED             3
ORA$AT_OS_OPT_SY_14199 2013/07/28 06:00:07 +000000000 08:47:15.665403 SUCCEEDED           2
ORA$AT_OS_OPT_SY_14179 2013/07/27 06:00:06 +000000000 19:59:53.651116 STOPPED             3
ORA$AT_OS_OPT_SY_14159 2013/07/26 22:00:08 +000000000 03:59:51.458149 STOPPED             4
ORA$AT_OS_OPT_SY_14139 2013/07/25 22:00:03 +000000000 03:59:56.349018 STOPPED             1
ORA$AT_OS_OPT_SY_14119 2013/07/24 22:00:08 +000000000 03:59:52.115471 STOPPED             4
ORA$AT_OS_OPT_SY_14099 2013/07/23 22:00:08 +000000000 03:59:51.330451 STOPPED             2
ORA$AT_OS_OPT_SY_14079 2013/07/22 22:00:10 +000000000 03:59:50.271542 STOPPED             2
ORA$AT_OS_OPT_SY_14059 2013/07/21 06:00:07 +000000000 19:59:52.726010 STOPPED             4
ORA$AT_OS_OPT_SY_14039 2013/07/20 06:00:02 +000000000 19:59:57.891111 STOPPED             1
ORA$AT_OS_OPT_SY_14019 2013/07/19 22:00:08 +000000000 03:59:51.773966 STOPPED             2

<中略>


たろー
「うわ、こりゃ酷いな。STATUSが殆どSTOPPEDになってるね。
平日は22時からスタートして4時間稼働しても終わってない。
土日は6時からスタートして20時間も稼働してるのに、それでも終わってない。」
新人T「あまりにも統計情報収集の対象オブジェクトが多くて、ずっと前からこんな状況なんです。」
たろー「これじゃあ、正しい統計情報は取得出来てないだろうな。
サポートにはいつから問い合わせしてるの?」
新人T「かれこれ2週間前からです。」

新人T

統計情報収集の高速化

新人T「何かいい方法は、無いでしょうか?」
たろー「そうだなぁ…。統計情報収集のパラレル度は設定してる?」
新人T「パラレル度ですか?」
たろー「そう。この Oracle Database は Enterprise Edition の4ノードRACなんだよね? であれば、パラレル処理を使うのも一つの手だよ。」
新人T「どのように使うのでしょうか?」
たろー「ちょっと、貸してみて。」
 

SQL> SELECT DBMS_STATS.GET_PREFS('DEGREE') FROM dual ;


DBMS_STATS.GET_PREFS('DEGREE')
--------------------------------------------------------------------------------
NULL


たろー「うん。やっぱりパラレル度は設定されてないな。」
新人T「NULL になってますね。」
たろー「そう。NULLがデフォルトなんだよ。これを変更するんだ。」
 

SQL> exec dbms_stats.set_global_prefs('degree', 'DBMS_STATS.AUTO_DEGREE');

PL/SQLプロシージャが正常に完了しました。

SQL> SELECT DBMS_STATS.GET_PREFS('DEGREE') FROM dual ;

DBMS_STATS.GET_PREFS('DEGREE')
--------------------------------------------------------------------------------
DBMS_STATS.AUTO_DEGREE


新人T
「DBMS_STATS.AUTO_DEGREE?」
たろー「そう。ここにパラレル度を決め打ちで入力してもいいんだけど、DBMS_STATS.AUTO_DEGREEにしておけば、Oracle Database が最適なパラレル度で統計情報を収集してくれるんだ。」
H課長「!」
新人T「分かりました!これで今夜の処理がどのくらい掛かるか、様子を見てみます!」

次の日の朝

新人T「たろーさん!ありがとうございました!
昨晩の統計情報収集処理ですが、数分で終わっていました!」
たろー「ちゃんとSTATUSも確認したかい?」
新人T「はい!SUCCEEDEDで終わっていました!信じられない早さです!」
たろー「それはよかった。パラレル化っていうのは、対象のオブジェクトが大きければ大きいほど効果が得られるんだ。特にこのシステムは1ノード8CPUの4ノードRACだったよね?単純計算で32倍の早さになるよ。」
新人T「そうなんですね。全く知りませんでした。」
たろー「ただパラレル度を上げるってことは、それだけリソースを消費するってことだからね?
重たい業務処理が走っている時は注意が必要だよ。」
新人T「分かりました。一度アプリケーションチームに確認して、負荷の低い時間帯に
メンテナンスウィンドゥ時間を変更しようと思います。」

本当はデータベース設計時に、アプリケーションチームに負荷の低い時間帯のヒアリングを実施しておくべきなんだけど・・・。H課長はそこまでやってないのかな?

 

 

 

 


今回の問題も無事解決しました。
そんな所へDさんがやってきました。

Dさん「聞いたよ、たろーちゃん。H課長の所の某システムの問題を解決したんだって?」
たろー「あ、先輩。お疲れ様です。自動化メンテナンスタスクの処理がウィンドゥ時間内に収まってなかったので、ちょっと知恵を貸しただけです。サポートもあてにならない様子だったので…。」
Dさん「うーん…。たろーちゃんは本当に直球しか投げれないんだなぁ。」
たろー「え?」
Dさん「そういう時はね、答えを持っていたとしても、『すみません、サポートも分からないようなことなので、私もわかりません』で済ませておけばいいんだよ。」
たろー「!」
Dさん「業務が止まるようなクリティカルな障害でもなかったんだろう?
これでまたたろーちゃんに対する、H課長からの当たりが強くなるぞ。」
たろー「そうか・・・考えもしませんでした。」
Dさん「次はどんな変化球が来るか分からないぞ。注意しておけ。」
たろー「私はただ、目の前に困っている人がいたので、その人を助けたくて…。
苦しんでいる『心臓』をなんとかしてやりたかっただけなんです…。」
Dさん「まぁ、それがたろーちゃんの良い所なんだけどな。会社全体で見れば、たろーちゃんの行動は絶対に会社のプラスになっていると思うし。」
たろー「先輩のご意見、とても勉強になります。」
Dさん「よしてくれよ。俺はたろーちゃんに、すごく助けられてるんだから。
今日も一緒に昼飯食べに行こうぜ。」

Dさん

なんとも、モヤモヤが晴れない結果となりました。
馬鹿正直なたろーちゃんには、生きづらい世界なのかもしれませんね。

But…

部長「Dさん。あの時よく知らせてくれたね。」
Dさん「いいえ。経験したこともないような変化球がきた上にN課長に叱責されたままでは、
たろーちゃんが潰れてしまいそうだったので、つい出しゃばった真似をしてしまいました。」
部長「組織を健全な状態で動かすのは、とても難しいことだ。
たろーちゃんに足りないもの。H課長に足りないもの。
それらを補え合えるような組織に出来れば一番よいのだが・・・。」
Dさん「何かあったら、また報告しますよ。」


今回の「心臓外科医の術式」いかがだったでしょうか?

自動化メンテナンスウィンドゥ時間内に統計情報収集処理が終わらなくて、困っているDBAの方もいらっしゃるのではないでしょうか?
そんなときは一度、パラレル化を検討してみて下さい。

次回も頑張りますので、応援よろしくお願い致します。

投稿者プロフィール

たろーちゃん
たろーちゃん
株式会社システムサポート インフラソリューション事業部に在籍するPlatinumホルダー。
Oracle Databaseのパフォーマンスチューニングを得意とする。
データベースは Oracle 以外興味がないという変わり者。
一番嫌いなエラーメッセージは CRS-02625。
連載「心臓外科医の術式」を執筆。