初めてのトラブル対応。これで直ると思ったのに！：システム開発プロジェクトの現場から（8）（1/2 ページ）

開発現場は日々の仕事の場であるとともに、学びの場でもある。先輩エンジニアが過去に直面した困難の数々、そこから学んだスキルや考え方を紹介する。

[新楽清高，アクセンチュア・テクノロジー・ソリューションズ]

初めてのトラブル対応

　今回は、システム開発にはつきもののトラブルに関する話題です。以前の職場で働いていたとき（社会人4年目ぐらい）に経験した、初めての本格的な（？）トラブル対応のお話をしたいと思います。

　Visual Basic＋Oracleで構成された、とあるアパレルメーカーの基幹系システムの構築・運用プロジェクトでのことです。運用フェイズに入ってしばらくたったころ、こんなトラブルが報告されました。

　「あるオンラインバッチ処理で、朝のうちは処理時間が速いが、時間が経過するとともに遅くなり、1時間以上かかるようになる」

　私はこのプロジェクトの担当ではありませんでしたが、当時社内で数少ないORACLE MASTERの有資格者（ORACLE MASTER Silver［現在のOracle Silver Fellow］を取得したばかりでした）だったため、そのトラブルの調査・対応を依頼されたのです。

　正直、そういう依頼が来るのは嫌いではありません。不謹慎ですが、ワクワクします。ちょっと頼られている感じも悪くありません（しかし、自分の担当領域で発生したトラブル対応は大嫌いです。胃が痛くなります）。

まずは事実のヒアリング

　ということで、プロジェクトの担当者と詳細に話をすることになりました。以下はそのときの会話です。

担当者　「ハンディターミナルで読み取った棚卸しのデータをいったんPCに転送して、その転送されたテキストファイルの内容をデータベースに格納するという処理をしています。100件、200件なら問題ないのですが、2000件を超えるくらいのデータを処理しようとすると、トラブルが発生します」

私　「な、なるほど」

担当者　「朝一番で実行すると5分ぐらいで終わりますが、10時を過ぎると1時間以上かかることがありますね」

私　「なぜ朝一番だと速いんですか？ データベースの再起動か何かをしているんでしょうかね」

担当者　「毎晩、データベースサーバの再起動がスケジュールされています」

私　「なるほど。ちょっとデータベースのパラメータを見てみますね。ちなみに現状は、1時間以上かけてお客さんに処理してもらっているのですか？」

担当者　「いまは、ハンディターミナルから転送されたテキストファイルを100件単位に分割して処理してもらっています」

私　「そうですか……」

導き出した仮説は

　この会話によって、私の頭の中では、以下のような整理がされ（てしまい）ました。

1．事実として……

• 大量のデータ（2000件以上）を扱うときに問題が発生する
• 少量のデータ（数百件程度）を扱うときには問題は発生しない
• データベース起動直後は問題がないが、使用ユーザーが増えてくると問題が発生する
• プログラム自体に問題はない

2．事実を整理すると……

• 通常のオンラインの処理が動いている状態で、大量のデータをデータベースに処理させるとパフォーマンスが劣化する

　そこから私が導き出した仮説は、以下のようなものでした。

　「データベースサーバのメモリ関連のパラメータが不適切なため、通常のオンライン処理によって共有プールもしくはデータベースバッファが占有されている。そのためバッチ処理を行う際、少量のデータなら問題ないが、大量のデータを扱う場合に割り当てができなくなることからパフォーマンスが劣化する」

　上記の仮説を基に、私はデータベースのパラメータを確認しました。すると案の定、パラメータは実際の物理メモリに対してかなり少なく設定されていたのです。私は内心、「いける」とほくそ笑みながら、パラメータのチューニングを行ったのでした。

　検証を行うため、大量のトランザクション処理を発生させるテストプログラムを作成し、パラメータのチューニング前・後でテストをすることにしました。やっぱり「いける」と思いながら。