Oracleアカウント

門外不出のOracle現場ワザ

日本オラクル株式会社コンサルティング統括本部テクノロジーコンサルティング本部小田圭二(おだけいじ)

第2章　万全の予防とテストで致命的トラブルを回避するOracle管理転ばぬ先の杖

日本オラクル株式会社コンサルティング統括本部テクノロジーコンサルティング本部小田圭二(おだけいじ)

Part1　監視／検知／対応の最適解運用時の大トラブルを防ぐポイント

システムは、一度構築してしまえばそれで終わりというわけではありません。そのシステムが役割を終えてなくなるまで、快適なサービスを提供し続けられるように適切に運用していく必要があります。しかし、実際には、何でもない領域拡張エラーが原因で業務停止が数時間に及んだり、パフォーマンス障害の原因を切り分けできずに数週間もパフォーマンス劣化が続いてしまったというような話が後を絶ちません。パート1では、小さな障害を大トラブルに発展させないための運用上の注意点について説明していきます。

障害の積極的な予防

単純なトラブルを未然防止する

大トラブルを引き起こす原因はさまざまですが、システムとしては妥当な動作でも、ユーザーにとって許容できる動作でなければ、トラブルになります。例えば、領域不足でバッチ処理が途中で中断してしまったり、断片化した領域の結合メンテナンスのためにデータベースがハング状態に陥ったという話は、非常に単純な問題ながらしばしば耳にする話です。こういったトラブルは、ある日突然発生したように見えるかも知れませんが、データベースの内部では徐々に原因が積み重なっていて、たまたまその原因に触れる操作をしたためにトラブルが顕在化するわけです。逆に言えば、常日ごろからデータベースの状態を監視し、問題の予兆がないか情報収集しておけば、いつトラブルが顕在化しそうか把握することは難しくありません。

事前検知のポイント

では、どのような観点で情報収集すれば良いのでしょうか？先ほど例に挙げた領域不足の場合には、リソースの上限値に引っかかって発生する問題ですから、「上限の80％を使い果たしたら領域を追加する」といった運用計画を立てておけば良いでしょう。また、断片化の例では、「定期的にオブジェクトや空き領域の断片数をチェックし、一定量を超えていたらメンテナンス時間帯に結合メンテナンスをする」という運用が考えられます。実際にどのような項目を確認していくかはシステムごとに検討が必要ですが、概ね以下のような観点でチェックすれば良いでしょう。

上限値 使用可能なリソースの上限値に達してしまい、拡張できなくなるリスクを事前に検知して対処します。主なチェック対象としては、各種プロセス数の上限や表領域の空き状況などがあります。プロセス数をはじめとしたインスタンスのリソース制限についてはV$RESOURCE_LIMIT、領域についてはDBA_FREE_SPACEなどのビューで確認できます。LIST1では、V$RESOURCE_LIMITビューから各リソースの使用量や制限値を確認しています。
LIST1 V$RESOURCE_LIMITビューを確認
状態意図せず使用不能状態になっているオブジェクトなどを見つけ出し、メンテナンスすることで、重要な業務がエラーになったり、想定外動作になることを未然に防止します。主なチェック対象としては、インデックスや制約、パッケージ、データファイルなどが考えられます。これらの情報取得には、DBA_OBJECTS、DBA_CONSTRAINTS、V$DATAFILEなどのビューを活用できます。
統計情報 統計情報の取得漏れや、統計情報が劣化して（古くなって）いるオブジェクトを見つけて対処することで、不適切な情報を基に実行計画が生成されることを防止します。チェック対象としては、テーブル、インデックスおよびそれらのパーティション、サブパーティションが考えられます。これらの情報取得には、DBA_TABLES、DBA_TAB_PARTITIONS、DBA_TAB_SUBPARTITIONSなどのビューを活用できます。LIST2では、統計情報の取得状況を確認しています。
LIST2 統計取得状況の確認
断片化 領域が断片化して大きなエクステントを確保できなくなったり、内部構造が断片化して処理時間が大幅に劣化してしまうリスクを事前に検知して対処します。主なチェック対象は、ディクショナリ管理表領域の空き領域断片数や、インデックスの削除済みエントリの割合などです。これらの情報取得には、DBA_FREE_SPACEやDBA_INDEXESなどのビューを活用できます。

以上のような確認項目をはじめから網羅的に策定できれば理想的ですが、実際には作業負荷やシステムの重要度との兼ね合いで、初期段階では重大なリスクにつながりかねない項目のみをピックアップするケースが多くなると思います。ただし、その場合でも確実に計画しておきたいのが、確認項目自体のブラッシュアップ計画です。データベースの使用状況は日々変化していくため、定期的もしくはイベント発生ごとに確認項目自体もブラッシュアップすることを勧めます。

ご存知の方も多いと思いますが、Oracle8iからDBMS_STATSパッケージで統計情報を取得できるようになりました。従来のanalyzeコマンドと比べて次の利点があるので、統計情報の収集にはこちらを使用すると良いでしょう。

パラレル実行が可能
スキーマ単位、データベース単位など、複数のオブジェクトの統計情報を一括で取得可能
パーティションオブジェクトで、グローバル統計を取得可能

データベースを運用している間にテーブル構成の変更やインデックスの追加が行なわれると、統計取得漏れが発生しがちです。DBMS_STATS.GATHER_DATABASE_STATSプロシージャを活用するなどして、統計取得漏れを防止する工夫をしてください。

確認タイミング

確認項目を策定したら、項目ごとに確認タイミングを定義しておきましょう。通常は、確認作業の人的／システム的なオーバーヘッドや、確認対象の変化の速度に応じた間隔を検討して、定期的に確認します。明確なしきい値を設定できる項目は、監視ツールを活用してしきい値超過時に通知が発せられるようにしておけば、管理の手間を省けるでしょう。サードベンダのツールも多数ありますし、Oracle Enterprise Manager Diagnostics 注1でもこのような設定を行なえます。

また、当たり前のようで意外と実施されていないのが、データベースに対してイベントが行なわれた後の確認です。もちろん、定期的な確認は非常に重要ですが、最もデータベースの状態が変化しやすいのは、大規模なバッチ処理やデータベースに対するメンテナンス作業などのイベント発生時です。バッチ処理によるデータ増加量が予想以上に多く急激に領域を圧迫していたり、メンテナンス作業の中で意図せず統計情報が削除されていたりすると、その後の業務で大トラブルを招く危険が非常に高くなります。その点では、イベント発生後は非常に費用対効果の高い確認タイミングと言えますから、ぜひ確認作業を実施するようにしてください。

注1：Oracle製品に付属するGUIベースの運用管理ツール「Oracle Enterprise Manager」のオプション製品。しきい値ベースのアラート通知や詳細なパフォーマンス監視などが行なえる。

製品障害の未然防止

大トラブルの発生原因の1つとして、製品不具合が考えられます。製品不具合による障害が発生してしまった場合には、当然製品ベンダに依頼して修正してもらう必要がありますが、可能な限りそのようなことが発生しないように事前に対処しておきたいものです。

そのためには、大トラブルに発展しかねない製品障害に対して、積極的に修正や回避策を適用しておくことが有効です。日本オラクルでは、保守契約ユーザー向けに不具合修正を集約した「パッチセットリリース（PSR）」を提供しています。PSRの中には、重大障害につながるおそれのある多くの重要な修正が含まれています。

にもかかわらず、実際の現場ではなかなか適用されていないのが現状で、大トラブルを解析してみると、実は既存のPSRに修正が含まれていたというケースを非常に多く目にします。よく、安定稼動しているのであえてPSRを適用する必要はないと言う管理者がいますが、そんなシステムでも実は日常的に新規アプリケーションを追加していたり、アプリケーションは変化しなくても、データ量や負荷状況が日々大きく変化していることが少なくありません。

毎日同じ運用をしていても、データ量が変化したことにより実行計画が変動し、これまでは発生しなかった製品障害が、ある日突然発生してしまうことは十分に考えられます。安定稼動していると思われるシステムでも、大トラブルのリスクを確実に低減させるためには、やはり積極的に修正や回避策を適用してリスクを下げる取り組みが必要です。

と、ここまでPSRの適用を推奨してきましたが、本番環境にいきなりPSRを適用することは勧められません。PSRに含まれている修正の内容により、データベースの動作が変化して、性能などへの影響が出てくるケースもゼロではないからです。PSRを適用する前には、必ずテスト環境でPSRを適用した稼動テストを実施してください。これは、PSR適用によるトラブルを防止するだけでなく、PSR適用作業に必要な時間の見積もりやオペレーションの確認にもなります。

実際にどこまでのテストを実施するかは、そのシステムの重要度に応じて検討する必要がありますが、最低限、テスト環境に適用してしばらく様子を見るくらいのことはしておきましょう。この段階で何か異変があれば、本番環境への適用を延期して原因を調査できます。可能であれば、負荷テストを実行して、PSR適用前とのパフォーマンスやインスタンス稼動状況の変化を確認しておくと、より安心して本番に適用できます。インスタンス稼動状況の収集については、本パート「パフォーマンス障害切り分け」およびパート2で紹介しているので、そちらを参照してください。

データディクショナリや動的パフォーマンスビューについては、Oracle Databaseリファレンスマニュアルに定義が紹介されています。データベース内部の状態を確認するスクリプトは、このリファレンスマニュアルを参照すれば作成できます。

定期的なメンテナンス時間

もし、障害の予兆を検知したり、新たなPSRがリリースされたら、早めに対処する必要があります。24時間365日無停止運用をうたっているシステムでは、対処するためのメンテナンス時間を確保できず、そのまま運用を続けざるを得ないところがあるようですが、これでは障害を予防できません。また、そういったシステムでも、よく聞いてみると無停止の必然性は特になく、単に停止時間を確保する必要性が理解できていない場合が多くあります。重大トラブルの発生を抑えるためには、障害の未然防止策の適用を重要な運用の1つとして位置付け、最低でも月に1度、数時間はメンテナンスのためのサービス停止時間を確保しておくことを勧めます。

このことは、メンテナンス時間の運用方法を定義することにもつながります。24時間無停止運用を前提としたシステムでは、緊急メンテナンス時間を確保しても、情報伝達が不十分でアプリケーションからのアクセスを完全に遮断できないケースも見受けられます。しかし、計画段階からメンテナンス時間を確保しておき、その時間帯の運用方法をはじめから定義しておけば、メンテナンス中の不要なトラブルを防止し、問題に対して迅速かつ確実に対処できます。

どうしても24時間365日完全無停止のサービスが必要なシステムでは、2系統のデータベースシステムを準備して、アプリケーション側で処理要求を制御しながら順次PSRを適用するしかないでしょう（図1）。しかしこの方法は、2系統のデータベースを正しく同期を取りながら運用する仕組みを構築する必要があり、膨大なコストがかかってしまいます。一般的には、無停止と言っても数十分程度のメンテナンス時間は確保できる場合が多く、費用対効果を考えて、極力短い停止時間でPSRを適用できるように工夫するケースが大半です。データベースは1つでも、クラスタソフトによるHA（High Availability）構成や、RAC（Real Application Clusters）構成を取っていれば、PSRの適用自体はサーバーごとに順次行なうことができますし、catalogスクリプトの実行時のみサービスを停止するといった方法をとることで、サービス停止時間を短くできます。

図1 完全無停止メンテナンスを目指した構成

Oracle Database 10g以降では、2系統のデータベースに対して、サービス無停止のままPSRを順次適用できるローリングアップグレードがサポートされます。データベース間のデータ同期はOracle DataGuardの機能によって実現されるため、同じことをアプリケーションに作り込んで実行する必要がなくなり、大幅に楽になります。

障害発生の早期検出と初動対応

ここまでしておけば、何もしていないよりもはるかに多くのトラブルを未然に防止できると思います。しかし、それでも障害が発生する可能性はゼロにはなりません。新規の製品障害が発生したり、確認対象外の項目で問題が発生するなど、予期せぬ事態は必ず発生します。ですから、未然防止策で障害発生回数を減らすと同時に、小さな障害を大きなトラブルに発展させない工夫が必要です。そのための第一歩は、障害発生にいち早く気付き、対応に取りかかることです。

PSR適用にあたっては、必ず製品保守ベンダから提供されるリリースノートや注意事項に従って、慎重に実施してください。

本編ではPSRによる予防保守について紹介しましたが、予防保守の大きな情報源として、日本オラクルが提供している「KROWN」もあります。主に保守契約を結んでいるユーザーが参照可能なナレッジ集で、既知の重要な不具合に対する回避策や、間違えやすいOracleの使い方など、数万件に及ぶ有用な情報がまとまっています。新しい機能を使う場合やバージョンアップなど、Oracle利用環境が変化するタイミングで参照すれば、使用上の注意点や既知の障害の回避策が事前に分かります。詳細は KROWNのWebサイトを参照してください。

できるところから確実に

Oracleの障害を検知する上で、最も基本的で重要なことはアラートログファイルの監視です。アラートログファイルには、Oracleの起動／停止といった重要なイベントや、重要なエラーの発生状況などが書き込まれています。監視ツールなどを利用して、「ORA-」や「Warning」などのキーワードを監視しておくと良いでしょう。障害の内容によっては別途トレースファイルが出力されるため、障害発生時間前後に出力されたトレースファイルを参照することで、障害の内容をより具体的に把握できます。また、ご存知のとおり、Oracleはハードウェア、OS、ストレージなどのさまざまなコンポーネントと協調して動作しています。OSのsyslogなどのOracle以外のコンポーネントについても、アラートログファイルと同様に最低限のメッセージを監視するようにしましょう。重要なシステムの管理者であれば、これらのファイルを必ず監視していると思いますが、適切に対処しないために大きなトラブルになるケースが見受けられます。例えば、バッチ処理中にディスク障害などによるデータファイル異常を示すエラーが発生していたとします。偶然そのときにはアクセスがなかったとしても、朝になってオンライン業務が始まったとたんにそのデータファイルへのアクセスが多発して、データベースが処理不能状態に陥ったなどのケースです。このように、ユーザーからのクレームがないからといって放置しておくと、後々の重大トラブルの原因になる可能性もあります。エラーの内容を確認し、対処が必要であれば早い段階で実施してください。

いったん運用に入ってしまうと、つい忘れてしまいがちなのが製品の保守期限です。サポート契約を結んでいても、使用しているバージョンの保守期限が切れていると、障害が発生しても問い合わせができなかったり、修正を依頼できなくなってしまいます。サポート期限が切れてしまう前に、計画性を持ってバージョンアップを行なうようにしましょう。

外部からの監視

Oracle上では重大なエラーが出ていなくても、アプリケーションからアクセスできなければ何らかの障害が発生している可能性があります。例えば、リソース競合が多発してデータベースがハング状態に陥っていたとしても、アラートログファイルには何のエラーも出力されません。ですから、アラートログファイルによる内部からの監視に加えて、外部からのアクセスによる監視も重要になります。監視方法としては、アプリケーションと同等の条件でデータベースへアクセスして、監視用のテーブルを検索／更新するようなスクリプトを数秒～数分おきに実行し、何回か連続してレスポンスが得られない場合にはデータベース障害と判断するという方法が考えられます。これによって、もし異常を検知した場合には、アプリケーションも同じ状態に陥っている可能性が高く、管理者は迅速に対応するべきです。

Oracleがエラー発生時などに出力する警告やトレースファイルは、通常「xxx_dump_dest」という領域に作成されます。アラートログファイルやバックグラウンドプロセスのトレースが出力される「background_dump_dest」と、SQL*Traceなどのサーバープロセスの情報が出力される「user_dump_dest」の位置は確認しておくと良いでしょう（LIST-A）。また、障害時の状況によっては、xxx_dump_destに指定した領域にトレースが出力できない場合もあります。その場合には、デフォルトのログ出力領域（$ORACLE_HOME/rdbms/log）に出力される場合もあるので、こちらも確認してみてください。

LIST-A 領域xxx_dump_destの位置を確認LIST-A 領域xxx_dump_destの位置を確認

正しい初動対応のために

障害を検知した後は、迅速かつ正確な対応が求められます。火事では初期消火に失敗すると大火災になるように、初動対応の品質は、障害が大トラブルに発展するかどうかに大きく関わってきます。障害が長期化する要因とそれに対する事前対策を、図2にまとめました。

図2 障害が長期化する要因とそれに対する事前対策

障害時の復旧を遅らせる大きな原因の1つは、判断にかかる時間です。データベースがハングしていたにもかかわらず、その場にいた方のスキルではどう対処したら良いのか分からず、数時間も対応できなかったという話をよく聞きます。上層部と連絡が取れなかったために、対処の必要性を分かっていながら手を下せなかったという話もあります。また、復旧を焦るあまり、2次障害、3次障害を引き起こしているケースも多くあります。データベースの異常を検知して即座に「shutdown abort 注2」したものの、偶然オンラインバックアップ中だったためにメディアリカバリが必要になったケースや、ロールバックセグメントのエラーを発見して誤ってUNDO表領域を構成しているファイルを削除してしまい、バックアップ漏れと重なって完全なリカバリができなかったというケースもあります。このように、初動対応でミスしてトラブルを長期化させないためには、極力属人的な判断を要する部分を減らし、初動対応の手順を決め事としてまとめておくのが有効です。具体的には、「切り分け手順書（図3）」「対策実施手順書」「緊急連絡手順書」をまとめておき、運用関係者に周知徹底します。切り分け手順書の中には、次の内容を含めます。

確認すべきファイル
切り分けのためのスクリプト
切り分け基準
切り分けの結果実施すべき対策手順書

対策実施手順書の中には、作業をミスなく行なうための具体的な手順を記述しておきます。これらの手順書は、システムの運用が開始されてから作成するのではなく、構築中のテストフェーズで各種障害パターンを想定したテストを実施し、その成果物として作成するものです。そのために、テスト計画の段階で実施すべき内容については、本特集パート3で詳しく説明します。

図3 切り分け手順書サンプル（データファイル障害）

注2：Oracleデータベースを強制終了するコマンド。

アラートログファイルやトレースファイルは、一度出力されると自動的に削除されることはありません。したがって、長期間運用していると、xxx_dump_destの領域があふれてしまいます。これらのファイルは、何らかの問題が発生したときの解析に使用するため、問題がない場合やすでに問題が解決した後は長期間残しておく必要はありません。定期的に削除したり、圧縮してほかの領域へ移動するなど、保存ポリシーを決めておくと良いでしょう。このように、定期的なメンテナンスが必要なファイルやデータとして、主に表Bのような出力があります。

表B 定期的な削除が必要な情報

パフォーマンス障害切り分けの準備

実際の現場で最も多い部類のトラブルはパフォーマンス障害です。レスポンスが大幅に劣化したり、バッチ処理が予定時間を超過するといった事象が突然発生すると、実質業務停止に陥ることもあります。にもかかわらず、製品のエラーやトレースなどが出力されないため、問題の切り分けが難しく、思わぬ大トラブルに至ることが少なくありません。

正常時の状態は分かりますか？

パフォーマンス障害で大トラブルになっている現場に突然呼ばれ、すぐに何とかしてほしいと言われることがありますが、残念ながら情報不足で適切な手が打てないケースが多々あります。データベースの動作を正しく把握できなければ、どんなエンジニアが対応しても正しい対処はできません。まずは適切な情報を収集することから始めることになりますが、そのような現場では大抵すでに大トラブルになってしまっています。パフォーマンス障害における問題の切り分けの第一歩は、正常時と障害時の違いを比較することです。データベース的に見て、正常時と比べて何がどう異なっているためにパフォーマンスが悪化しているのかを把握して、原因を突き止めていきます。そんな比較をしなくても、障害時の情報だけを見て判断できるような基準が欲しいと思われるかも知れません。確かに、一般的な指標としての善し悪しは指摘できます。しかし、データベースの処理内容はシステムごとに千差万別で、一般的には好ましくない値であっても、そのシステムでは正常値であることも多くあります。例えば、障害時の情報として、1回のディスクI/Oに30ミリ秒かかっていることが分かったとしましょう。このシステムでは通常3ミリ秒でI/Oを完了しているのであれば、10倍のI/Oレスポンス劣化となり、これがパフォーマンス障害のキッカケかも知れません。しかし、日常的にI/O負荷が高く、ラッシュの時間帯には50ミリ秒かかっていても、レスポンス要件を満たしているシステムだとしたら、この点を掘り下げて解析してもパフォーマンス障害の原因には行き着けないでしょう（図4）。

図4 一般的な指標とシステム固有の指標は異なる

また、日常的にあるブロックに集中的にアクセスするような、データベースからするとあまり好ましくないアプリケーションであっても、それで性能要件を満たしていたのであれば、それをチューニングしたからといって短期的なトラブルの解決にはつながりません。これらのボトルネックを取り去ること自体は、中長期的には非常に重要な作業ですが、突然のパフォーマンス悪化を解決するのとは別問題なのです。ですから、常日ごろからパフォーマンス情報を取得し、正常時の状態を把握しておくことは非常に重要です。また、単に正常時といっても、システムの利用サイクルの中でさまざまな状態があります。業務開始／終了前後のオンラインの集中、バッチ処理時間、月末／月初など、それぞれのタイミングによってシステムにかかる負荷の傾向も大きく異なります。業務の種類とそれが行なわれるタイミング、そのときのデータベースの稼動傾向を把握しておくと良いでしょう。

実際に障害が発生した際には、手順書をメンテナンスする体制も整備しておくと良いでしょう。はじめからすべての障害パターンを想定した手順書を作れなくても、障害発生時に随時付け加えていくことで、そのシステム特有のノウハウを十分に蓄積することができます。また、メンテナンスした内容は、運用部門やインフラ部門の担当者へ正しく伝達する方法も確立しておくと良いでしょう。同じ内容のトラブルに二度三度と遭遇して、同じように対応に時間がかかってしまうのは何としても避けるべきです。

キッカケはSTATSPACK

Oracleに関する一般的なパフォーマンス情報は、STATSPACKで取得します。STATSPACKでは、Oracleインスタンス全体の稼動状況を俯瞰できるため、正常時と障害時でデータベースにどのような動作の違いがあったのかを大まかにつかめます。特に、はじめのほうにレポート出力される「Load Profile」セクションと「Top 5 Timed Events」セクションには全体的な情報がまとまっており、パフォーマンス障害解析のとっかかりとして非常に重要な情報を与えてくれます。 Load Profileセクションでは、SQL実行回数やトランザクション量、物理I/O量、論理I/O量、REDOログ生成量など、Oracleにかかる基本的な負荷の重さを一覧することができます。1秒あたりの統計値を比較することでデータベースにかかる負荷の変化を読み取れますし、1トランザクションあたりの統計値では、アプリケーションからOracleにかかる負荷特性の変化が分かります。一方、Top 5 TimedEventsセクションでは、Oracleがどのリソースを確保するためにどれくらい時間を費やしていたかを一覧できるため、正常時との要求リソースの違いからボトルネックとなっているリソースの変化を読み取れます。

STATSPACKのスナップショットは、30分～1時間置きくらいに取得しておくと良いでしょう。STATSPACKのユーザー（デフォルト“PERFSTAT”）で次のようにスクリプト「spauto.sql」を使用すると、1時間置きにスナップショットを自動取得するジョブが登録されます。

@?/rdbms/admin/spauto.sql

さらに、スナップショット取得間隔を変更する場合には、次のプロシージャを実行してジョブを変更します。この例では、30分おきにスナップショット取得ジョブが実行されるように変更しています。

execute dbms_job.interval（:jobno, 'SYSDATE+(1/48)');

また、このように定期的にスナップショットを取得していると、スナップショットを格納している表領域が領域不足になるおそれがあります。定期的に次のスクリプトを実行して、不要になったスナップショットを削除するようにしてください。

@?/rdbms/admin/sppurge.sql

詳細情報はV$表を活用

STATSPACKでは、データベース全体の稼動状況を大まかに把握することはできますが、個々のアプリケーションの瞬間的な処理状況や時間を追った状況の推移は把握できません。例えば、特定のアプリケーションだけパフォーマンスが悪いといった場合には、STATSPACKを解析しても原因追及に役立つ情報を取得できない場合があります。このように、よりミクロな単位で的確な状況を把握するためには、動的パフォーマンスビュー（V$表）の情報を定期的に取得しておくのが効果的です。代表的なものとして、次のビューがあります。

V$SESSION_WAIT データベースに接続して処理を実行中の各セッションの待機状況を示します。競合してボトルネックになっているリソースが分かります。
V$SESSION データベースに接続している各セッションの稼動状況を示します。どのようなアプリケーションがどのタイミングでどういうSQLを実行しているかを把握できます。なおOracle Database10gでは、V$SESSION_WAITビューの情報もこちらのビューに集約されています。

ほかにも、ロック情報（V$LOCK）やラッチ情報（V$LATCH、V$LATCHHOLDER）など、多岐にわたる情報を取得できる動的パフォーマンスビューが用意されています。特に、パフォーマンス障害発生時に問題の切り分けを即座に行なわなくてはならないような、極めて重要なシステムでは、リファレンスマニュアルを参照して、これら詳細な情報についても定常監視することを検討してください。なお、これらの情報はSTATSPACKと違い、情報取得を実施した瞬間のデータベースの状態を表わします。そのため、1時間に1回といった取得間隔では、瞬間瞬間の断面になってしまい、連続的な動作を把握することができません。システムの負荷や処理特性によりますが、一般的には数秒間隔で取得しておくと良いでしょう。ただし、セッション数やリソース量といった環境によって情報取得の負荷が変わってきますので、必ずシステムにかかる負荷を確認してから本番環境に適用してください。

Oracle Database 10gでは「Automatic Workload Repository（AWR）」という機能で自動的にSTATSPACK相当の情報を取得し、「AutomaticDatabase Diagnostic Monitor（ADDM）」という診断機能で自動的にパフォーマンス診断を実行できます。利用には、Oracle Enterprise ManagerのDiagnostics PackおよびTuning Pack（いずれも有償オプション）が必要ですが、Oracleが自動診断した結果を参照したり、その結果推奨されたSQLチューニングを適用したりといった対処までGUIで行なえるようになるので、データベースのパフォーマンス解析に不慣れな管理者の方には便利でしょう。もちろん、STATSPACKで従来通りの情報を取得することも可能です。

パフォーマンス情報の保持期間

収集したパフォーマンス情報は、そのまま溜めておくと領域を圧迫してしまいますので、定期的に削除するなどの対応が必要です。保持しておく期間としては、キャパシティプランニングにも有効なSTATSPACKの出力は最低1ヶ月程度、パフォーマンス障害解析の意味合いが強い動的パフォーマンスビューの出力は、最低1週間程度確保しておくと良いでしょう。可能であれば、データベースへのアクセスパターンのバリエーションを一通り確認できる程度保持できるのがベストです。アクセスパターンが日常的に大きく変動する場合や、長期的な情報をキャパシティプランニングに活用したい場合には、すべてのログを保持しておくのではなく、取得した情報の中からキーとなる統計値を抽出して、別途保持／管理していく方法もあります。いずれにしても、運用計画の中でこれらの情報保持期間のポリシーと、運用手順を策定しておきましょう。

データ損失を防止するために

リカバリはできるか

バックアップ／リカバリはトラブル防止の最後の要となる大切な運用です。データの損失は、データベースシステムにとって致命傷になってしまいます。Oracleではアーカイブログ運用を行なうことによって、万一データファイルが破壊されても、最新のコミットされたトランザクションまで回復することができます。しかし、実際のトラブル現場では、バックアップを行なっているのにもかかわらず、うまく回復できないことが非常に多くあります。典型的なのが「バックアップ漏れ」です（図5）。

図5 Oracleのリカバリの仕組みと典型的なバックアップ運用ミス

システムは常に変化しており、構築当初はリカバリテストも万全に行なって問題なくリカバリできても、その手順がいつまでも使えるとは限りません。例えば、バッチ処理の最中に領域不足が発生した際、緊急メンテナンスでデータファイルを追加したあと、バックアップ運用でそれに対応しなかったらどうなるでしょう？当然、そのファイルはバックアップが取られませんが、バックアップが取られたものとして、アーカイブログファイルが消し去られていくことになります。こういった問題を避ける良い方法は、ファイル追加など、バックアップに影響するメンテナンスについて手順書を作成しておき、その中にバックアップスクリプトの修正を手順として組み込んでおくことです。そして、必ずその手順に従ってメンテナンスを行なうよう徹底することが大切です。

アーカイブログファイルのリストア

リカバリ関連でもう1つ盲点になるのは、アーカイブログファイルをリストアするためのディスク領域（リストア領域）です。リカバリの際には、テープに吸い上げてあるアーカイブログファイルをディスクにリストアしますが、その際、リストア領域が不足しないかに注意します。特にRAC環境では、複数のアーカイブログファイルへ同時にアクセスしながらリカバリを行なうため、同時に複数のアーカイブログファイルをリストアできるだけの領域が必要になります。しかし、当初は確保されていたリストアのためのディスク領域が、トラブル対応のための一時ファイルに占拠されていて、いざリストアしようとして立ち往生するケースが見られます。このような現場では、領域を空けるために必要なファイルを削除してしまうなどの2次障害が発生したり、ディスクの手配に時間を要してトラブルが長期化するなど、ただでさえ重大なトラブルがさらに大きなトラブルにつながることが少なくありません。

安心してリカバリに踏み切れるために

ここで紹介した2つの失敗例は、いずれもあり得ない話のように思われるかも知れませんが、驚くほど重要なシステムでもこのような事態は実際に発生します。このような事態に陥らないよう、計画フェーズでリカバリ許容時間を定義し、テストでその実現性や必要なリソース、変動要因を確認し、日々の運用の中で変動要因と影響分析をしていくことが大切です。さらに、効果的な方法として、定期的にリカバリ訓練を行なうことを推奨します。こちらについては、パート3で詳しく説明します。

システムの重要性に応じた運用計画を

ここまでは、大トラブルを防止するための、運用の観点での考慮点を説明しました。運用そのものは利益を生み出さないため、そのコストはどうしても低く抑えられる傾向にあると思います。したがって、常に最大のコストをかけて万全の運用を目指すのではなく、システムの重要度に見合った運用を計画しなければなりません。本パートで紹介した「トラブル対策」の実施は、とても手間のかかる作業だと思われたかもしれません。しかし、トラブルで業務を止められないような重要なシステムであれば、やはりそれなりの準備は必要です。このことを、システム計画の段階から意識して、障害の未然防止と迅速な業務復旧のための施策を運用計画に組み込んでいただけると幸いです。以降のパートでは、トラブルを防止するための、テストフェーズでの考慮点を説明していきます。

"門外不出のOracle現場ワザ" インデックスに戻る

この文書はあくまでも参考資料であり、掲載されている情報は予告なしに変更されることがあります。日本オラクル社は本書の内容に関していかなる保証もいたしません。また、本書の内容に関連したいかなる損害についても責任を負いかねます。

Oracleは米国Oracle Corporationの登録商標です。文中に参照されている各製品名及びサービス名は米国Oracle

Corporationの商標または登録商標です。その他の製品名及びサービス名はそれぞれの所有者の商標または登録商標の可能性があります。

小田圭二(おだけいじ)

1996年日本オラクル入社。人事教育本部にて、新卒や中途採用社員に対し、データベースやOS、ネットワークの講師を5年ほど経験した後、2000年にテクノロジーコンサルティング本部に異動。テクノロジーのコンサルタントとして、主に大規模ミッションクリティカルシステムを担当。ポリシーは、「OracleもOS上で動くアプリケーションにすぎない。だから、OS、ストレージ、ネットワークを学ぶべき」。スキル面の興味は、アーキテクチャ、DBA、インフラ技術、教育、コンサル手法など。