運用って、あまりいいイメージはなかったけれど：システム開発プロジェクトの現場から（14）（1/2 ページ）

運用中のシステムにトラブル発生！

　こんにちは。アクセンチュア・テクノロジー・ソリューションズ（ATS）の新楽です。今回は、どうしても地味な印象のある「運用」についてのお話です。

　自分が手掛けたシステムを運用するのは、どんなに安定稼働していても、どこか落ち着かない感じがするものです。

　ATSに入社する前は、カットオーバーしたシステムの運用は基本的に自分で行っていました。プロジェクトの規模も大きくなかったことから、1人で複数のプロジェクトを運用していました。何かトラブルが起こった際の責任は常に自分が取り、対応するのも自分1人というのは大きなプレッシャーです。そのため私は、運用に対して、あまり前向きなイメージを持っていませんでした。

　ATSに入社し、初めてかかわったプロジェクトは、カットオーバーしてから大きなトラブルもなく、開発したシステムは半年ほど安定して稼働していました。

　しかしその後、トラブルが発生しました。システムの要であるデータベースが利用不能になるという現象が発生したのです。複数台のデータベースサーバをクラスタ構成（Oracle Real Application Clusters）で運用していたため、影響が出たのはほんの一瞬でした。ですが、たとえ一瞬であっても、本番システムが停止するというのは一大事です。いや、一大事という認識を持たないといけないのだと思います。

　第一報は、「本番環境でエラーが発生している」というものでした。それだけで十分冷や汗ものです。データベースサーバの1台から「ORA-04031 共有メモリーのXXXバイトを割当てできません」というエラーが出ているとのこと。該当のサーバを再起動することで、取りあえずその時点でのエラーの発生は収まりました（クラスタはすごい！ と実感した瞬間でした）。

　当然ですが、ここで対応を終了できるはずはありません。根本原因を特定し、再発しないような対策を打つ必要があります。

データベースエラーの原因は？

　エラーの原因は何でしょうか？

　このように、エラーメッセージの原因については、「Oracle9i データベース・エラー・メッセージ リリース1（9.0.1）」（pdfファイルにリンクします）より簡単に調べることができました。

　しかし、「そうか、共有プールが足りないからエラーが出ているのか。じゃあさっそく共有プールを増やしましょう。それで解決ですね」とは、さすがになりませんよね。

　物理的に余裕があれば、共有プールを増やしておくことは応急処置としてはよいと思います。ですが、気を付けなければいけないのは、応急処置を根本治療と勘違いしてはならないということです。応急処置で問題が一時的に出なくなると、ついつい解決したと思ってしまいます。痛みが引いたので治ったと勘違いし、きちんと検査もせず、気付いたときには手遅れ……なんてことには絶対になりたくないものです。