10gリリース2（10.2）
B19215-02
 目次 |
 索引 |
| Oracle Database 概要 10gリリース2（10.2） B19215-02 |
|
ほとんど常時に近い可用性を提供するように構成されたコンピューティング環境は、高可用性システムと呼ばれます。Oracleには、予定されていたかどうかを問わず、停止時間が発生した場合に高可用性を提供する多数の製品と機能が用意されています。
この章の内容は、次のとおりです。
ほとんど常時に近い可用性を提供するように構成されたコンピューティング環境は、高可用性システムと呼ばれます。通常、この種のシステムには、障害が発生してもシステムを使用できるように冗長ハードウェアおよびソフトウェアがあります。適切に設計された高可用性システムでは、単一の障害箇所が回避されます。
Oracleには、予定されていたかどうかを問わず、停止時間が発生した場合に高可用性を提供する多数の製品と機能が用意されています。
計画外停止時間の発生には、様々な原因が考えられます。Oracleには、計画外停止時間中の高可用性を維持するために、次の機能が用意されています。
この項では、システム障害に対する次のようなOracleのソリューションについて説明します。
Oracle Enterprise Editionには、インスタンス・リカバリを制御するファスト・スタート・リカバリ機能が組み込まれています。この機能により、最新のREDOレコードと最後のチェックポイントの間に生成される使用済バッファの数とREDOレコードの数を制限することで、キャッシュ・リカバリの所要時間が短縮され、リカバリが境界化されて予測可能になります。
ファスト・スタート・リカバリの基盤は、ファスト・スタート・チェックポイント・アーキテクチャです。大量の書込みを行う従来のイベント・ドリブン（つまりログ・スイッチ）チェックポイントのかわりに、増分ファスト・スタート・チェックポイントが発生します。各DBWnプロセスは定期的にバッファをディスクに書き込んで、チェックポイント位置を進めます。すべての書込みでチェックポイントが確実に進むように、最も古い変更済ブロックから順に書き込まれます。ファスト・スタート・チェックポイントにより、大量の書込みがなくなり、その結果、従来のチェックポイントで発生していたI/Oの変動がなくなります。
ファスト・スタート・リカバリにより、OracleデータベースはUNDOフェーズまたはロールバック・フェーズの完了を待たずにアプリケーションからのアクセス用にオープンされます。コミットされていないトランザクションによりロックされていたデータのロールバックは、必要に応じて動的に行われます。ユーザー・プロセスでは、クラッシュしたトランザクションによりロックされている行が検出されると、単にその行がロールバックされます。問合せで要求された行のロールバックによる影響はごくわずかです。
ファスト・スタート・リカバリは、UNDOデータがログ・ファイルではなくデータベースに格納されるため、きわめて高速です。ブロックのUNDOには、高コストを伴うログ・ファイルの順次スキャンを必要としません。単に、データベース内でデータ・ブロックの適正バージョンの検出のみが行われます。
ファスト・スタート・リカバリにより平均リカバリ時間が大幅に短縮され、オンライン・アプリケーションのパフォーマンスに対する影響が最小限に抑えられます。リカバリ時間は継続的に見積もられ、目標リカバリ時間に合わせてチェックポイント・レートが自動的に調整されます。
本来、Real Application Clusters（RAC）データベースは、可用性の高いシステムです。典型的なRAC環境であるクラスタでは、計画停止または計画外停止に対して、継続的にサービスを提供できます。RACは、標準的なOracle機能の最上位に、より高い可用性レベルを構築します。ファスト・スタート・リカバリやオンライン再編成など、シングル・インスタンスのすべての高可用性機能は、RACにも適用されます。
通常のすべてのOracle機能に加えて、RACはクラスタ化による冗長性を利用して、nノード・クラスタでn-1ノードの障害が発生した場合の可用性を実現します。つまり、クラスタに1つでも使用可能なノードがあれば、すべてのユーザーがすべてのデータにアクセスできます。
この項では、データ障害に対する次のようなOracleのソリューションについて説明します。
Oracleには、ファスト・スタート・リカバリと平均リカバリ時間に加えて、データ障害とメディア障害からの保護およびリカバリを目的とした複数のソリューションが用意されています。システム障害やネットワーク障害が発生するとユーザーはデータにアクセスできなくなりますが、適切なバックアップがない状態でメディア障害が発生すると、データが消失してリカバリできなくなる可能性があります。 たとえば、次の機能があります。
関連項目
パーティション化とは、大規模な表や索引を、パーティションというより小さくて管理しやすい部分に分割して、この種の表や索引をサポートするときの主な問題に対処します。パーティション表にアクセスする際、SQL問合せとDML文を変更する必要はありません。ただしパーティションを定義すると、DDL文は表や索引全体ではなく、個々のパーティションへのアクセスやその操作ができるようになります。パーティション化を行うと、このようにしてラージ・データベース・オブジェクトの管理を簡素化できます。また、パーティション化は、アプリケーションに対して完全に透過的です。
透過的アプリケーション・フェイルオーバーにより、アプリケーション・ユーザーは接続に失敗した場合にデータベースに自動的に再接続できます。アクティブなトランザクションはロールバックされますが、元の接続と同じデータベース接続が異なるノードを使用して新規に確立されます。これは、接続がどのように失敗した場合も同じです。
透過的アプリケーション・フェイルオーバーを使用すると、アプリケーションを処理中のインスタンスが1つでも残っているかぎり、クライアントは接続障害に気づきません。データベース管理者は、どのアプリケーションがどのインスタンスで実行されるかを制御し、アプリケーションごとにフェイルオーバー順序を作成します。これはReal Application Clusters（RAC）に最も有効であり、あるノードに障害が発生した場合は、クラスタ内の他のノードにすばやく再接続できます。
通常のクライアント/サーバーによるデータベース操作中は、クライアントとサーバーが通信できるように、クライアントがデータベースへの接続をメンテナンスします。サーバーが障害を起こすと、接続が切断されます。次回にクライアントが接続の使用を試みると、エラーが発行されます。この時点で、ユーザーはデータベースに再度ログインする必要があります。
ただし、透過的アプリケーション・フェイルオーバーを使用すると、Oracleはデータベースへの新規接続を自動的に取得します。これにより、ユーザーは元の接続が失敗しなかった場合と同様に作業を続けることができます。
アクティブなデータベース接続には、複数の要素が関連付けられています。次のような要素があります。
透過的アプリケーション・フェイルオーバーを使用すると、クライアント/サーバーのデータベース接続、ユーザーのデータベース・セッションおよび必要に応じてアクティブな問合せをリストアできます。アクティブなトランザクションやサーバー側パッケージの状態など、アクティブなデータベース接続のその他の要素をリストアするには、アプリケーション・コードで、最後のコミット後に実行した文を再実行できることが必要です。
OCIおよびJDBC（シック）クライアントは、RACの高可用性イベント通知を登録し、イベント発生時に適切な処理を実行できます。これにより、接続フェイルオーバーの応答時間を短縮し、接続プールおよびセッション・プールから古い接続を削除できます。障害検出時間を短縮することで、障害発生時に透過的アプリケーション・フェイルオーバーがより迅速に反応できるようになり、ノードまたはインスタンス障害時に動作しているクライアント・アプリケーションに役立ちます。
クライアントは、Oracle Streams Advanced Queuingの高可用性通知に対して有効化されているデータベース・サービスに接続する必要があります。データベース・サービスは、これらの通知をサポートするためにEnterprise Managerによって変更される場合があります。有効化された後は、クライアントは高可用性イベントの発生時に必ず起動されるコールバックを登録できます。
災害に対するOracleの主要なソリューションは、Oracle Data Guard製品です。
Oracle Data Guardでは、障害および停止にかかわらず、自動的かつ透過的に稼働時間を維持できます。Oracle Data Guardでは、破損、データ障害、人為的エラーおよび災害など、すべての脅威から保護するために、本番データベースのリアルタイム・コピーであるスタンバイ・データベースが最高9つまでメンテナンスされます。本番（プライマリ）データベースに障害が発生した場合は、スタンバイ・データベースの1つにフェイルオーバーして新規のプライマリ・データベースにすることができます。また、現行のプライマリ・データベースとスタンバイ・データベースの間で本番処理をすばやく簡単に移行（スイッチオーバー）できるため、メンテナンスのための予定停止時間を短縮できます。
ファスト・スタート・フェイルオーバーでは、プライマリ・データベースが消失した場合に、複雑な手動手順を実行してフェイルオーバーを起動することなく、指定の同期スタンバイ・データベースに、自動的にすばやく確実にフェイルオーバーできます。これにより、稼働時間を透過的に維持し、システム障害、データ障害およびサイト停止に対する高可用性レベル、ならびに障害時リカバリの堅牢さを高めることができます。
Oracle Data Guard構成は、緩やかに接続されたシステムの集合であり、単一のプライマリ・データベースと最高9つのスタンバイ・データベースで構成されます。スタンバイ・データベースには、フィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベースを混在させることができます。Data Guard構成でのデータベースは、同じデータ・センター内でLANを使用して接続できます。また、最大限の災害保護のために、WANを介して地理的に分散させて、Oracle Net Servicesで接続することもできます。
Data Guard構成は、データベースを問わず配置できます。これは、その使用がアプリケーションに対して透過的であり、スタンバイ・データベースに適用するためにアプリケーション・コードを変更する必要がないためです。また、Data Guardを使用すると、データの保護レベルとアプリケーションのパフォーマンスが受ける影響のバランスを取るように構成をチューニングし、データ保護、可用性またはパフォーマンスを最大限に発揮するように保護モードを構成できます。
アプリケーションのトランザクションがプライマリ・データベースに変更を加えると、変更内容はREDOログにローカルに記録されます。フィジカル・スタンバイ・データベースの場合、変更は管理リカバリ・モードで実行中の各フィジカル・スタンバイ・データベースに適用されます。ロジカル・スタンバイ・データベースの場合、変更はアーカイブREDOログから再生成されたSQLを使用して適用されます。
フィジカル・スタンバイ・データベースは、物理的にプライマリ・データベースと同一です。プライマリ・データベースがオープンされてアクティブになっている間は、フィジカル・スタンバイ・データベースが（ログを適用して）リカバリを実行中であるか、アクセス・レポート用にオープンされています。フィジカル・スタンバイ・データベースは、本番データベースからフィジカル・スタンバイ・サイトにREDOデータが送られている間で、リカバリを実行していないときに、読取り専用で問合せできます。
リカバリ操作では物理ROWIDを使用してブロックごとに変更を適用するため、フィジカル・スタンバイのオン・ディスク・データベース構造は、プライマリ・データベースのブロックベースの構造と同じにする必要があります。索引などのデータベース・スキーマは、同じである必要があります。また、データベースはオープンできません（読取り専用アクセスを除きます）。オープンしていると、フィジカル・スタンバイ・データベースに異なるROWIDが使用され、リカバリを継続できなくなります。
ロジカル・スタンバイ・データベースは、標準的なOracleアーカイブREDOログを使用し、格納されているREDOレコードをSQLトランザクションに変換して、オープンされているスタンバイ・データベースに適用します。変更はエンド・ユーザーによるアクセスと並行して適用できますが、再生成されるSQLトランザクションを介してメンテナンスされる表では、ロジカル・スタンバイ・データベースのユーザーに読取り専用アクセスが許可されます。データベースがオープンしているので、プライマリ・データベースとは物理的に異なります。データベース表には、対応するプライマリ・データベース表とは異なる索引と物理特性を持たせることができますが、スタンバイ・データ・ソースとしてのロールを果たすには、アプリケーション・アクセスの観点から論理的な一貫性を保つ必要があります。
Oracle Data Guard Brokerにより、複雑な作成およびメンテナンス・タスクが自動化され、監視、アラートおよび制御メカニズムが大幅に拡張されます。Data Guard Brokerが使用するバックグラウンド・エージェント・プロセスはOracleデータベース・サーバーと統合され、各Data Guardサイトに関連付けられており、Data Guard構成全体に統一された監視および管理のインフラストラクチャを提供します。Data Guard構成とのやりとりに2つのユーザー・インタフェースが用意されています。一方はコマンドライン・インタフェース（DGMGRL）で、他方はData Guard Managerと呼ばれるGUIです。
Oracle Data Guard ManagerはOracle Enterprise Managerと統合されており、そのウィザードを使用すると構成を簡単に作成、管理および監視できます。この統合により、アラート用イベント・サービス、簡単に設定するための検出サービス、メンテナンスを容易にするジョブ・サービスの提供など、Enterprise Managerの他の機能を利用できます。
RACにより、相互接続を使用してリンクされた複数の独立したサーバーがOracleデータベースへのアクセスを共有でき、障害時に高可用性、スケーラビリティおよび冗長性が提供されます。RACおよびData Guardは、連携することで、システムレベル、サイトレベルおよびデータレベルの保護を提供するため、データの消失なしに高可用性および障害時リカバリを実現できます。
ローカル・サイトとリモート・サイトの使用方法、ノードの使用方法、およびロジカル・スタンバイ・データベースとフィジカル・スタンバイ・データベースの組合せに応じて、RACとData Guardを使用した様々なアーキテクチャが考えられます。
この項では、人為的エラーに対する次のようなOracleのソリューションについて説明します。
バッチ・ジョブが連続して2回実行されるなどの重大なエラーが発生した場合、データベース管理者は、データベース全体を以前の時点まで迅速にリカバリするフラッシュバック操作を要求できます。これにより、バックアップのリストアとPoint-in-Timeリカバリの必要がなくなります。データベース・レベルでのフラッシュバック操作に加えて、表全体のフラッシュバックも可能です。同様に、データベースでは、ユーザーが意図せずに削除した表をリカバリできます。
関連項目
Oracle LogMinerを使用すると、SQLインタフェースを介してREDOログ・ファイルを問い合せることができます。REDOログ・ファイルには、データベースに対するアクティビティの履歴情報が含まれています。Oracle Enterprise Managerには、Oracle LogMiner ViewerのGraphical User Interface（GUI）が組み込まれています。
ユーザー・データまたはデータベース・ディクショナリに対して行われた変更は、すべてOracleのREDOログ・ファイルに記録されます。したがって、REDOログ・ファイルには、リカバリ操作の実行に必要な情報がすべて含まれています。REDOログ・ファイルのデータは、通常はアーカイブ・ファイルに保管されているため、すでに使用可能になっています。LogMinerの全機能を活用するには、補助ロギングを使用可能にする必要があります。
Oracle Internet Directoryを使用すると、X.509証明書により認証されたユーザーなど、ユーザーのセキュリティ属性と権限を管理できます。また、Oracle Internet Directoryでは属性レベルのアクセス制御も規定されます。これにより、特定の属性に対する読取り、書込みまたは更新権限は、社内のセキュリティ管理者など、特定の指名ユーザーに限定されます。ディレクトリの問合せと応答には、認証や他の対話中の保護を強化するためにSSL暗号化を使用できます。その他、データベース・セキュリティ機能には、Virtual Private Database（VPD）、Label Security、監査およびプロキシ認証などがあり、これらのディレクトリベース・ユーザーをエンタープライズ・ユーザーとして構成するときに活用できます。
Oracle Advanced SecurityのUser Migration Utilityは、既存のデータベース・ユーザーをOracle Internet Directoryに移行する作業を支援します。ディレクトリ内でユーザーが作成された後、組織では引き続きWeb環境で新規アプリケーションをビルドでき、Oracle Internet Directoryと同じユーザー識別情報を使用して、ユーザーがこれらのアプリケーションにアクセスできるようにします。
Oracleには、計画停止時間を短縮または削除する機能がいくつか用意されています。 たとえば、次の機能があります。
Oracleは高度な自己管理機能を備えており、日常的なDBAタスクが自動化され、領域、メモリーおよびリソースの管理が簡素化されます。 たとえば、次の機能があります。
データベース管理者は、ヒープ構成表のオンライン再編成など、表の定義に対して様々なオンライン操作を実行できます。これにより、ユーザーにはすべてのアクセス権を付与したままで表を再編成できます。
このオンライン・アーキテクチャには、次の機能が用意されています。
Oracleには、停止時間を最短に、または停止時間なしでデータベース・ソフトウェアのメンテナンスを行うテクノロジが用意されています。データベース・サービスが常に使用可能になるように、Real Application Clustersインスタンスには一度に1つずつパッチを適用できます。
この混合モードでReal Application Clustersシステムを任意の期間稼働させて、本番環境でパッチをテストできます。パッチが正常に適用されていることを確認した後、この手順をクラスタの残りのノードに対して繰り返します。クラスタの全ノードにパッチが適用されると、パッチ・ローリング・アップグレードが完了し、全ノードが同じバージョンのOracleを実行することになります。
|
 Copyright © 2006 Oracle Corporation. All Rights Reserved. |
|