Oracleアカウント

門外不出のOracle現場ワザ

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

門外不出のOracle現場ワザ

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

日本オラクル株式会社コンサルティング統括本部テクノロジーコンサルティング本部

小田圭二(おだけいじ)

Part3　障害テストにおける5つの注意点と7つの障害箇所別テスト方法

システム構築の最後段階ではスケジュールが押していることが多く、テストを減らして遅れを取り戻す（?!）ことがよくあります。その犠牲になりやすいテストの1つが「障害テスト」です。しかし、そのツケは本番稼動後に払わされます。筆者の経験では、約半分のシステムにおいて、バックアップ／リカバリや耐障害性の仕組みが不十分のようです。

また、どう行なえば良いのかが一番分からないのも、障害テストではないでしょうか。一般に難しいとされる異常系（正常に処理されているとき以外を指す）のテストであり、さらにテストの対象（Oracle）が自分で作ったソフトウェアではないために、いっそう困難に思われます。本パートでは、このように難しい障害テストをいかに実施すべきかを解説します。

どんな点に注目してテストすべきか

個々の障害テストの説明に入る前に、テスト全般に言える5つの注意事項、

障害検知も手順に含めること
業務処理を動かしておくこと
リカバリの確認まで通しでやること
可能であれば、本番環境でDBAとなる人間が行なうこと
時間を測ること

を順に説明したいと思います。

(1) 障害検知も手順に含めること

障害テストは実施済みだったにもかかわらず、障害の対応が迅速にできなかったケースでは、「障害検知は、監視ソフト（もしくは管理者やエンドユーザー）がやってくれると思っていて、テストに含めていなかった」ことが理由の1つに挙がってきます。気持ちは分からなくはないのですが、市販の監視ソフトであっても検知できない障害は多いですし、検知できたとしても時間がかかる場合もあります。

もちろん、業務処理を動かしながらでないと検知しようがない障害もあるため、障害テストに障害検知を含めると言っても簡単ではありません。それでも、障害検知を手順に含めていなければ、テストとしては不十分と考えます。エンドユーザーから見れば、障害検知に時間がかかって障害時間が長くなることと、障害回復の手順が整っておらず障害時間が長くなることは同じだからです。

(2) 業務処理を動かしておくこと

これは省略できるケースもありますが、可能な限り、障害テスト中は業務処理を動かしてください。理由は、業務処理を動かしていないと発生しない類の障害があるためです。

ここで皆さんに質問です。アプリケーションサーバーがデータベースサーバーへSQL文を発行したあと、結果を返す前にデータベースサーバーがOSごと落ちてしまった場合、アプリケーションサーバーはどのような動きをするでしょうか？

答えは「（デフォルト設定であれば）永遠に待つ」です。次に、データベースサーバーがOSごと落ちた後、アプリケーションサーバーがデータベースサーバーに接続を要求したりSQL文を発行したりしたらどうなるでしょうか？答えは「それほど待たずにエラーが返る」です。

図1を見てください。ここに書かれているように、永遠に待つ動作はネットワークとOSレベルの動き（つまり仕様）です。データベースサーバーのネットワークケーブルを抜いてからアプリケーションサーバーにSQL文を投げさせるという実施しやすいテスト手順では、この現象は発生しません。

図1 業務のタイミングによって発生する問題の例

詳しい方であれば、Javaアプリケーションサーバーにはタイムアウトを設定できたり、コネクションプールを使用する前に該当コネクションが生きているかを自動的に確認する機能があることをご存知でしょう。もちろん、使用したほうが良い機能です。しかし、これらの機能は万能ではなく、タイミングによっては検知できないのです。

ここまで、ネットワークを例として、なぜ障害テストは業務処理を動かしながら行なうべきかを説明しました。もちろん、これは一例ですし、タイミングに関係する問題でもあるので、必ず発見できるものではありません。しかし、やるべきテストはやったと言うためには、業務処理を動かしながら障害テストを行なうべきです。アプリケーション側のエラー検知機能の確認にもなります。リカバリテストにおいては、きちんとリカバリできるかどうかの確認にもなります。

(3) リカバリの確認まで通しでやること

障害テストはバックアップ／リカバリの確認でもあります。意外に思われるかもしれませんが、きちんとバックアップがされていないために、本番環境のデータベースが壊れてもリカバリができないことは多いのです。このような後の祭りにならないように、データベースファイルを破壊するテストをして、破壊を検知し、バックアップからリカバリできることを障害テストにおいて確認するよう強く勧めます。リカバリについては、「完全回復」と「不完全回復」の2通り行ないましょう。すべてのプロジェクトにおいてこの2通りのリカバリで十分とは言いませんが、最低でも2通りは行なうべきと考えます。

完全回復とは文字どおり、業務データをまったく損なうことなく、コミット済みのデータをすべて元に戻すリカバリです。それに対して不完全回復とは、ある時点までデータを元に戻すリカバリです。Oracleはきちんと設定すれば、通常言われるSPoF（Single Point of Failure：一重障害）に関しては、完全回復が行なえます。しかし、特殊なSPoFや多重障害に関しては完全復旧できないケースがあります。

例えば、ストレージのアダプタが壊れて、異常なデータをデータファイルのみならずREDOログファイルすべてに書き込んだらどうなるでしょう？人によってはこれを多重障害と呼ぶでしょうが、起きない話ではありません。このような理由により、不完全回復に対する備えも必要です。

(4) 可能であれば、本番環境でDBAとなる人間が行なうこと

DBAとなる担当者が来る前に障害テストを行なう場合も多いため、無理なプロジェクトも多いと思います。しかし、DBAが障害テストを行なうことにより学ぶことは多く、一度で構わないので、どこかのプロジェクトで経験を積むべきです。また、可能であれば、定期的にリカバリのテストをするべきです。

研修を受けた方や本番環境でリカバリを行なった経験を持つ方はご存知かと思いますが、経験のあるなしは、いざ本番環境で障害になったときの対応スピードと作業の正確さに大きく表われます。これは、サポートサービスの指示に従ってリカバリを行なう場合でも同様です。筆者は、本番環境でリカバリを行なう場合、リカバリの経験を積んでいないDBAだけではとても不安です。それくらい大きな差を生むため、DBAとなる人は研修でも自宅の環境でも良いので、経験を積むようにしてください。

本番環境でメディアリカバリをすることになった場合、保守契約を結んでいれば、サポートから指示を仰いだほうが良いケースが多いようです。理由は、すべての障害パターンをテストできているプロジェクトはまずなく、想定していない何かが起きる可能性があるためです。また、本番環境の障害対応ではオペレーションミスが発生しやすいため、エキスパートの指示を仰いだほうが間違ってファイルを上書きしてしまうなどのミスを減らせます。リカバリに自信がない場合には、サポートの指示を仰ぐことを勧めます。

(5) 時間を測ること

障害テストにかかる時間をきちんと測っているプロジェクトは少ないようです。例えば、本番環境の復旧に数日かかったらどうでしょう？障害検知に数時間かかったら、そのシステムは要件を満たしていることになるのでしょうか。障害が発生してから復旧するまでの時間が短いことも大事なテストの項目です。筆者はリカバリに1日以上かかるシステムや、エラー検知に時間がかかっていたシステムを多く知っています。もちろん、仕方がない障害もあり得るため、すべてのケースにおいて短時間で復旧できることをテストすべきと言っているわけではありません。想定する主な障害に関しては、短時間で復旧できることを確認すべきという意味です。

特にバックアップからのリカバリに関しては、図2のようなアーキテクチャ上の理由により、システムごとにリカバリ時間がまちまちです。アーカイブログファイルのサイズから時間を見積もることは不可能です。そのため、できるだけ本番に近いデータを用いて、数時間負荷をかけた上でリカバリテストを行なってください。この方法が理想論であることは筆者も認めますが、長いリカバリ時間を許容できないシステムについては実施を勧めます。

図2 リカバリのアーキテクチャ（左側がリカバリしたいトランザクション。右側がその実際のリカバリの動作）

なお、ほとんどデータ挿入／更新／削除が発生しないシステムに関しては、それほどバックアップからのリカバリ時間はかからないため、時間の確認は不要でしょう。

どのようにテストするべきか

ここからは、実際の個々のテストケースについてのノウハウを説明します。テストケースとして、「リスナー障害」「シャドウプロセス障害」「領域フル」「バックグラウンドプロセス障害」「ディスク障害その1：データファイル障害」「ディスク障害その2：REDOログファイル全損障害」「ネットワーク障害」を取り上げます。

リスナー障害

リスナー障害は盲点ですが、発生すると重大な結果をもたらします。理由は、データベースに対してアプリケーションから接続できなくなるからです。そのため、クラスタウェアなどでもリスナーダウンを検知すると、リスナーを再起動するように設定されているものもあります。

テストのポイントは、「検知をしてきちんと自動的に再起動されるか」と「ダウンしていた際にコネクト要求をしていたアプリケーションはきちんとリトライもしくはエラー表示をしているか」です。リスナー障害の発生方法は、OSコマンド「kill -9 <リスナープロセスのPID>」の実行で構いません。

シャドウプロセス障害

シャドウプロセス（サーバープロセスとも言う）は、SQL文の処理を実際に行なう大事なプロセスです。シャドウプロセスの障害は、コネクションプールを使用しているかどうかで、2通りに分かれます。

コネクションプールを使用している場合には、クライアント側がエラーを受け取ることの確認のほかに、コネクションプールを張り直す動作の確認まで必要です。コネクションプールを使用していない場合には、アプリケーションがエラーを受け取り正しくハンドリングするまでの確認で構いません。アプリケーション側のタイムアウトやコネクション生死確認機能の動作を確認するためにも、このテストは業務処理を動かしながら行なってください。シャドウプロセス障害の発生方法は、OSコマンド「kill -9 <シャドウプロセスのPID>」の実行で構いません。

領域フル

領域フル（満杯）には2通りあります。Oracleの表領域内で領域フルになった場合と、ファイルシステムが領域フルになった場合です。両方とも、まず事前に検知できるか確認すべきです。Oracleの表領域内における領域フルに関しては、dba_free_spaceビューなどを用いて、各表領域がしきい値を超えていないかを確認します。しきい値には80％や90％などを用います。

ここで大切なのは、次のエクステントを割り当てできるかどうかです。稀にしきい値を下回っていても、次のエクステントのサイズが大きいために、次のエクステントを割り当てできないケースがあります（図3）。テストでは、手動でallocate extentを実行したり、多量のデータを投入して自動的にエクステントを拡張させたりして、しきい値を超えたところで検知できるかを確認します。

図3 意味のないしきい値の例

なお、表領域が「自動拡張」で、かつ最大エクステント数が“unlimited”に設定されている場合には、ファイルシステムの領域監視のみでも構いません。筆者のお勧めは、領域不足の場合の対処まで行なっておくことです。データファイルを追加する手順まで含めて確認しておけば、いざというときにも安心です。

ファイルシステムの監視は、swapなどを除く、基本的にすべてのファイルシステムに対して行ないます。本番で起こりがちな障害は、アーカイブログファイルの領域があふれることと、ログ領域（listener.logやuser_dump_destなどのトレースログ領域）があふれること、そして自動拡張の場合はデータファイルが入った領域があふれることです。これらをテストしてみるといいでしょう。テストは、どんなファイルでも構わないので、大きなファイルを置いてファイルシステムの空きを少なくすればOKです。このテストでは、業務処理を動かしておく必要はありません。

バックグラウンドプロセス障害

バックグラウンドプロセス（群）は、シャドウプロセスとは異なる裏方のプロセスですが、多くのバックグラウンドプロセスは、障害が発生するとインスタンスごと落ちてしまうので、障害対策の観点からは非常に重要なプロセスです。そのため、バックグラウンドプロセス障害のテストは、インスタンス障害のテストを兼ねることにもなります。テストのポイントは、「インスタンスがダウンした後に適切にデータベースサーバーのオペレーションが動くか」「アプリケーションは適切にエラーを表示し、必要であればリトライするか」の2点です。

「インスタンスがダウンした後に適切にデータベースサーバーのオペレーションが動くか」をテストする理由は、クラスタウェアや監視ソフトによって、インスタンスを再起動させたり、インスタンスが落ちていることを通知したり、HA切り替え（HA［High Availability］構成クラスタにおいて、スタンバイ側のマシンが稼動状態になること）をするなど、障害回復の方法がまちまちなためです。このテストが業務処理の再開まで含めて正しく行なえなければ、障害時に復旧できません。このテストも、業務処理を動かしながら行なうことを勧めます。障害の発生方法は、OSコマンド「kill -9 <PMONプロセスのPID>」の実行で構いません。

ディスク障害その1：データファイル障害

この障害および次項で説明する障害が、バックアップからのリカバリを必要とする障害テストケースです。この2つこそ難易度が高く、かつ経験しておくべきテストです。

このテストが難しい理由として、まず、ディスク障害を再現すること自体が難しい点が挙げられます。プロセスをkillしたり、ネットワークのケーブルを抜くといった具合に、簡単に障害発生をシミュレートすることはできません。データファイルを消すか、ほかのファイル（Oracleと関係のないファイルで可）で上書きするのが良いでしょう。テストが難しいもう1つの理由は、データファイルが壊れたことをOracleが検知するまでに時間がかかるためです。Oracleは、四六時中データファイルが壊れたかを確認しているわけではなく、データを読み込むタイミングなどで気が付きます。意外と長い間、キャッシュのデータでOracleは動いてしまうものなのです。

そこで、ここでは次のような手順を紹介します（図4）。この手順であれば、業務を動かしながらはできないものの、テストを簡単に行なえます。なお、次項で紹介するテストで時間を測れば、このテストでは時間を測らなくても構いません。本テストケースは、データによっては短時間でリカバリできてしまうためです。

図4 データファイル障害のテストを簡単に行なう手順

ディスク障害その2：REDOログファイル全損障害

当たり前ですが、復旧用のログであるREDOログファイルの中身が失われてしまうと、Oracleはデータを復旧できません。そのため、障害に備えて冗長化をするわけですが、世の中には信じられない障害（中途半端に壊れるハードウェア障害など）が多数あり、冗長化したREDOログファイルが全滅するようなケースもあります。そのようなときでも、アーカイブされたREDOログファイルを使って途中まで復旧させることはできます（不完全回復）。

通常のレベルのプロジェクトにおいては、このテストまで行なえば、やるべきことはやったと言っていいと思います。このテストも、前テストと同様にOracleに検知させるのが難しいテストです。そのため、ここでは次のような手順を紹介します（図5）。なお、このテストではリカバリ時間を測るようにしてください。

図5 REDOログファイル全損障害のテストを行なう手順

ネットワーク障害

これも難度の高いテストケースです。しかし、ミッションクリティカルシステムであれば行なう価値があります。

まず、プロセス障害と何が違うかを説明します。たしかに、通信相手がいなくなるという意味ではシャドウプロセスをkillした状態と同じように思えます。しかし、ネットワークレベルで捉えると、OSが生きていて、かつネットワークケーブルもつながっている場合には、両者の動作は異なります。シャドウプロセスが死んだときにOSがそのことを通知してくれたり、パケットの再送の動きが変わります（OSが生きているほうが検知が早い）。

このような事情により、ネットワーク障害をテストする価値はあります。具体的には業務処理を動かしながら、ネットワークケーブルを何回か引き抜いてください。ケーブルは数分間抜きっぱなしにしておくと良いでしょう（ネットワークのタイムアウトのため）。アプリケーションがきちんと検知できるか、監視ソフトが検知できるか、ネットワークの復旧後に自動的に業務処理が復旧するかを確認してください。

この障害対策は難度が高く、設計時点からアプリケーションに組み込んでいないと完全な自動対応はできません。そのため、このテストにより、アプリケーションやデータベースの再起動が必要なことが判明するかもしれません。そうであっても、あらかじめ知っておいて、いざというときに再起動のオペレーションができるだけでも大きな違いになります。

おわりに

障害テストについては、テスト内容とコマンドをリカバリ手順書としてまとめておくことを勧めます。そして、いざ本番障害というときに参考にしてください。手順書によって不完全回復後のバックアップ忘れや、領域不足後のデータファイル追加の際のバックアップ登録漏れを回避できるでしょう。

実は、ミッションクリティカルシステムを想定した場合、運用計画、パフォーマンステスト、障害テストのすべてにわたって、ほかにも勧めたい作業や理想論があります。しかし、すべてを書くことは前提となる知識が膨大なためできませんでした。もっと学びたい人は、まずOSとストレージとネットワークについて勉強し、その後Oracleの内部構造を勉強してください。結局、Oracleもそれらの上で動いているアプリケーションにしか過ぎないためです。また、理想論どおりにすべてを行なうことはできないため、コストを考えてリスクと折り合いを付けることが重要です。なお、今回は扱えなかったトラブルを防ぐ設計については機会を見て寄稿したいと思います。

CulUMNアドバイス:リカバリしながら業務を運用する方法について

ご存知の方も多いと思いますが、Oracleは表領域やデータファイルをリカバリしながら、ほかの表領域やデータファイルは業務処理に開放することができます。しかし、製品機能としては可能でも、現実の運用で使えるケースは稀なようです。理由は、一部のデータファイルや表領域がオフラインのままでも運用できると判断するのは難しいためです。DBAが「この表領域は、この業務処理のみに関係するからほかの業務処理は稼動できる」と即座に判断できるプロジェクトはそうはないはずです。もしこのような運用を行ないたいのであれば、表領域と業務処理との関係を事前にしっかり把握しておくことです。

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

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

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

小田圭二

小田圭二(おだけいじ)

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

門外不出のOracle現場ワザ