ページ)開発現場は日々の仕事の場であるとともに、学びの場でもある。先輩エンジニアが過去に直面した困難の数々、そこから学んだスキルや考え方を紹介する。今回は、システム開発にはつきもののトラブルに関する話題です。以前の職場で働いていたとき(社会人4年目ぐらい)に経験した、初めての本格的な(?)トラブル対応のお話をしたいと思います。Basic+Oracleで構成された、とあるアパレルメーカーの基幹系システムの構築・運用プロジェクトでのことです。運用フェイズに入ってしばらくたったころ、こんなトラブルが報告されました。Fellow]を取得したばかりでした)だったため、そのトラブルの調査・対応を依頼されたのです。いう依頼が来るのは嫌いではありません。不謹慎ですが、ワクワクします。頼られている感じも悪くありません(しかし、自分の担当領域で発生したトラブル対応は大嫌いです。事実のヒアリングということで、プロジェクトの担当者と詳細に話をすることになりました。以下はそのときの会話です。「ハンディターミナルで読み取った棚卸しのデータをいったんPCに転送して、その転送されたテキストファイルの内容をデータベースに格納するという処理をしています。データベースのパラメータを見てみますね。導き出した仮説はこの会話によって、私の頭の中では、以下のような整理がされ(てしまい)ました。1.事実として......大量のデータ(2000件以上)を扱うときに問題が発生する少量のデータ(数百件程度)を扱うときには問題は発生しないデータベース起動直後は問題がないが、使用ユーザーが増えてくると問題が発生するプログラム自体に問題はない2.事実を整理すると......通常のオンラインの処理が動いている状態で、大量のデータをデータベースに処理させるとパフォーマンスが劣化するそこから私が導き出した仮説は、以下のようなものでした。「データベースサーバのメモリ関連のパラメータが不適切なため、通常のオンライン処理によって共有プールもしくはデータベースバッファが占有されている。上記の仮説を基に、私はデータベースのパラメータを確認しました。すると案の定、パラメータは実際の物理メモリに対してかなり少なく設定されていたのです。私は内心、「いける」とほくそ笑みながら、パラメータのチューニングを行ったのでした。検証を行うため、大量のトランザクション処理を発生させるテストプログラムを作成し、パラメータのチューニング前・後でテストをすることにしました。「いける」と思いながら。メールマガジンをご購読ください。申し込みページへITmediaはアイティメディア株式会社の登録商標です。