イベント発生時の対応で差

図1●リモートDB監視の付加サービス
監視サービス単体で導入してもあまり意味がない。付加サービスと組み合わせることで価値が出る。付加サービスには,(1)リモート運用,(2)保守,(3)レポート,(4)チューニング――の大きく4つがある。各ベンダーによって,用意する付加サービスの範囲が異なる

 ベンダー間のサービス内容に違いが出るのは,障害などイベントが発生した時のアクションにある(図1[拡大表示])。

 基本サービスでは,イベント発生時にユーザーに通知が行くだけでサービスが完結する。原因究明や復旧のヒントを併せて提供するベンダーもあるが,実際の作業はすべてユーザー側で行う必要がある。

 通知に加え,オペレータがリモートでDBにログインし,アラート通知時にその確認をしたり,障害発生時に復旧作業を実行したりするベンダーもある。サイトロックのSite Management Serviceなどが標準サービスに含めているほか,IIJテクノロジーのiBPS運用管理サービスDBサーバー監視やネットベインのDatabase Monitorなどがオプションで用意している。

 ただこの場合,あらかじめどういうケースでどういう作業を行うかを,サービス前の運用設計の段階でドキュメント化する必要がある。つまり定型範囲内での対応になる。

 サービスを受けるための回線コストを含めると月額50万円を超えるケースもある。高価だが,多くのイベントに対して自動化が図れる。「アラートが1つ上がったからといって,それがすべて障害に直結するわけではない。プロセス再起動などのリモートで処理できるものはしてしまう」(IIJテクノロジー 沖田氏)。

 保守との連携が可能なサービスもある。通常,保守を使う場合は,保守窓口に電話またはメールで問い合わせて,エラーの内容を自分で細かく説明する必要がある。リモート監視と保守を連携すると,保守が必要になった時に監視サービス部門が保守担当者にエラー情報を自動的に渡す。その分,解決時間を短縮できる。ただし,保守契約を当該ベンダーと別途契約しておく必要がある*2

 パフォーマンス・チューニングでの付加サービスもある。Oracleの統計値などを見るV$ビューのデータを分析してレポーティングするなどのサービスが中心だが,最近になってDBコンサルティング会社とMSPが提携する動きも出てきた。例えばサイトロックやCTCはインサイトテクノロジーとの提携を計画している。プロセスやアラート・ログなど可用性に関する項目はMSP側で対応し,V$ビューなどパフォーマンス関連の監視はインサイトテクノロジー側で対応するという役割分担だ。

ユーザーの運用ミスには対応困難

表3●リモートDB監視サービスでは対応できないトラブルの例

 これらのDB監視サービスでは対応できないトラブルもある(表3[拡大表示])。特に,運用ミスに起因するトラブルの多くは対応が困難である。

 運用ミスとしては例えば,Oracleで一部のテーブルのみにANALYZE*コマンドを実行するといった操作ミスがある。この場合,コスト・ベース・オプティマイザ*の挙動がおかしくなる場合があり,結果,パフォーマンスが劇的に落ちる。DBそのものは正常に稼働しているので,リモートDB監視でこれを突き止めることは難しい。インデックスを誤って消去してしまった場合も,似たようなことが起こる。どちらの場合も,その直前にDBに対してどういう処理を行ったか聞き取り調査する必要がある。

 また,リモート運用サービスを受けていても,オペレータが行うのはプロセスやインスタンスの再起動など定型的な作業に限定される。判断を伴う非定型な作業は原則としてサービスの対象外だ。例えば,ディスク障害時にOracleではREDOログ・ファイルを使ってリカバリ作業を行うが,REDOログ・ファイルの損傷状況によって,完全リカバリを行うか不完全リカバリを行うかの判断が必要である。こうした判断を実施する技術者はユーザー側で確保しなければならない。

 日本オラクルの「OnlineDBA」では,そうした判断までカバーする。想定した範囲で対応できない場合に,用意するDBA(Database Administrator)が復旧作業を実施する。DBAはあらかじめシステム構成を把握しておき,エラーの内容などから問題の切り分けと復旧作業を行う。同社はこのサービスを他のMSPなどパートナを通じて提供する方針である。他ベンダー経由でもこのサービスを受けられるようになる可能性が高い。

(尾崎 憲和=ozaki@nikkeibp.co.jp)