| Oracle Database高可用性概要 11gリリース1（11.1） E05748-03 |
|
 戻る |
 次へ |
Oracle Databaseは、可用性を高め、計画停止時間と計画外停止時間のいずれもゼロまたは最小限に抑える高可用性ソリューションの統合スイートを提供します。これらのソリューションは、企業が24時間年中無休でビジネスの継続性を維持する場合に役立ちます。一方で、Oracle高可用性ソリューションは、プライマリ・システムおよびセカンダリ・システムでのシステム使用効率を高め、パフォーマンス、スケーラビリティおよび管理性全体の向上を支援するソリューションを提供することにより、停止時間の短縮にとどまらない機能を実現します。
この章の次の項では、ビジネスおよびアプリケーションに対するOracle高可用性機能の主な影響について説明します。
オラクル社では、次のような高可用性機能を提供しています。
また、「計画外停止時間用Oracle高可用性ソリューションおよびリカバリ時間」の項では、各種の計画外停止時間に対応する主な高可用性ソリューションと、各ソリューションのリカバリ時間の概要について説明します。
|
関連項目:
|
オラクル社では、システム・フォルトとデータベース障害からの高速で予測可能なリカバリを提供しています。Oracle Databaseに含まれているファスト・スタート・リカバリ・テクノロジは、セルフチューニングされるチェックポイント処理を使用して、起動時にデータベースのリカバリ時間を自動的に制限します。これにより、リカバリ時間を高速で予測可能なものにし、サービス・レベルの目標の達成能力を向上させます。Oracleのファスト・スタート・リカバリ機能によって、負荷の多いデータベースのリカバリ時間を数十分から数秒に短縮できます。
ファスト・スタート・リカバリ機能には次のものがあります。
インスタンス障害、データベース障害およびコンピュータ障害からの、予測可能で、制限的なリカバリ
希望のリカバリ時間目標を維持するためのセルフチューニングであるデータベース・チェックポイント
|
関連項目: 『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』 |
Oracle Real Application Clusters（Oracle RAC）とOracle Clusterwareを使用すると、Oracle Databaseは一連のクラスタ化されたサーバーにまたがってパッケージまたはカスタム・アプリケーションを実行できます。この機能により、高いレベルの可用性および最も柔軟的なスケーラビリティが得られます。クラスタ化されたサーバーに障害がある場合でも、Oracle Databaseは残りのサーバー上で稼働を継続します。より高い処理能力が必要なときは、データへのユーザーのアクセスを中断することなく、他のサーバーを追加できます。
Oracle RACを使用すると、インターコネクトでリンクされた複数のインスタンスによるOracleデータベースへのアクセスの共有が可能になります。Oracle RAC環境では、単一の共有データベースに同時にアクセスしている間、Oracle Databaseはクラスタ内の2つ以上のシステム上で稼働します。その結果、複数のハードウェア・システムにまたがる単一データベース・システムとなり、Oracle RACではクラスタ内での障害時に高可用性と冗長性を提供できます。Oracle RACは、読取り専用のデータ・ウェアハウス（DSS）・システムから更新頻度の高いオンライン・トランザクション処理（OLTP）システムまで、あらゆるタイプのシステムに対応しています。
Oracle Clusterwareは、同じオペレーティング・システムを実行するサーバーにインストールされる場合、これらのサーバーが連携して単一サーバーとして機能できるようにして、ユーザー・アプリケーションとOracleデータベースの可用性を管理するソフトウェアです。また、ノードのメンバーシップ、グループ・サービス、グローバルなリソース管理、高可用性機能といったクラスタ管理に必要な機能もすべて提供します。
高可用性については、Oracleデータベース（単一インスタンスまたはOracle RACデータベース）とユーザー・アプリケーション（OracleおよびOracle以外）をプロセス障害時に再起動するか、またはノード障害後に別のノードへのフェイルオーバーが発生するようにOracle Clusterwareで管理および保護できます。
クラスタ管理については、単一システムのイメージまたは単一の仮想サーバーのように動作する複数の独立したサーバーが提供されます。この単一の仮想サーバーは、すべての管理操作に対してクラスタにまたがって維持されるため、管理者はインストール、構成、バックアップ、アップグレードおよび監視の各機能を一回実行できます。その後、Oracle Clusterwareは、これらの管理機能の実行を、クラスタ内の該当ノードに自動的に分散します。
Oracle ClusterwareはOracle RACを使用する際に必要で、Oracle RACが動作するほとんどのプラットフォームに必要な唯一のクラスタウェアです。Oracle Databaseでは選択したサード・パーティのクラスタウェア製品を指定のプラットフォームで引き続きサポートしますが、Oracle Clusterwareを使用すれば、ベンダーが独自に開発したクラスタウェアは不要になり、Oracle ASMによるディスク管理がOracle DatabaseおよびOracle RACによるデータ管理に提供されるOracle統合ソフトウェア・スタックを使用できます。さらに、OracleサービスなどのOracle Database機能では、Oracle Clusterwareの基本的なメカニズムを使用して、その機能を提供します。
Oracle Clusterwareには2つのクラスタウェア・コンポーネントが必要です。1つはノード・メンバーシップ情報を記録する投票ディスク、もう1つはクラスタ構成情報を記録するOracle Cluster Registry（OCR）です。投票ディスクとOCRは共有ストレージに存在する必要があります。Oracle Clusterwareでは、各ノードがプライベート・インターコネクト経由でプライベート・ネットワークに接続されている必要があります。
Oracle RACとOracle Clusterwareには次のような利点があります。
コンピュータおよびインスタンスの障害からの許容および迅速なリカバリが可能
ローリング方式による、Oracle Clusterwareのアップグレード、パッチ・セットおよび個別パッチの適用が可能
たとえば、Oracle ClusterwareをOracle 10gからOracle 11gにアップグレードし、Oracle ClusterwareにOracle 10.2.0.3から10.2.0.4のパッチを適用し、Oracle ClusterwareにOracle 10.2.0.2バンドル1からOracle 10.2.0.2バンドル2のパッチを適用します。
システム変更およびハードウェア変更のローリング・アップグレード
一部の個別パッチのローリング・パッチ・アップグレード
サービスの再配置、および高速アプリケーション通知（FAN）とクライアント構成を追加で実行する場合は、高速かつ自動のインテリジェントな接続とフェイルオーバーを実現するためにアプリケーションが素早く反応できるようなFANイベントの配信
接続障害の高速自動検出と、Oracle Universal Connection Pool（UCP）、高速接続フェイルオーバーおよびFANイベントを使用するJavaアプリケーションの終了済接続の削除
Oracle UCPランタイム接続ロード・バランシングを使用する作業リクエスト・バランシング
Oracle UCP、OCIおよびODP.NETを使用した実行時の接続ロード・バランシング
ロード・バランシングのアドバイス
停止時間またはアプリケーションへの変更なしで、汎用ハードウェアを使用して処理能力を向上できる柔軟性
データベースおよびクラスタの機能を統合する包括的な管理性
データベース・インスタンスにまたがるスケーラビリティ
Oracle Clusterwareには次のような利点があります。
エラーが発生したOracleプロセスを自動的に再開
ノード障害時のクラスタの別ノードにおけるOracle仮想IP（VIP）の自動管理とフェイルオーバー
障害が発生したノードのリソースを残りのノードで自動的に再開
Oracle RACデータベースの場合、すべてのOracleプロセスはデフォルトでOracle Clusterwareによって制御され、Oracle単一インスタンス・データベースの場合、Oracle Clusterwareで制御されるリソース・グループへのOracleプロセスの構成が可能
OracleアプリケーションおよびOracle以外のアプリケーションの場合、Oracle ClusterwareではApplication Programming Interface（API）が提供され、Oracle Clusterwareによるその他のOracleプロセスの制御（再開、または障害や特定のルールへの応答など）が可能
ノードのメンバーシップを管理し、2つ以上のインスタンスがデータベースを制御する際のスプリット・ブレイン・シンドロームを防止
アプリケーションの停止時間ゼロで、Oracle Clusterwareのローリング・リリース・アップグレードを実行が可能
|
関連項目: 『Oracle Real Application Clusters管理およびデプロイメント・ガイド』および『Oracle Clusterware管理およびデプロイメント・ガイド』 |
Oracle Data Guardは、企業データの高可用性、データ保護および障害時リカバリを保証します。Oracle Data Guardは、Oracleデータベースが災害およびデータ破損に耐えられるよう、1つ以上のスタンバイ・データベースの作成、メンテナンス、管理および監視を行うサービスの包括的なセットを提供します。Oracle Data Guardでは、スタンバイ・データベースがトランザクション的に一貫したプライマリ（本番）データベースのコピーとしてメンテナンスされます。計画停止または計画外停止によりプライマリ・データベースが使用できなくなった場合は、任意のスタンバイ・データベースをプライマリ・ロールに切り替えて、停止に伴う停止時間を最小限に抑えることができます。Oracle Data Guardを従来のバックアップ、リストアおよびクラスタ技術とともに使用すると、高度なデータ保護およびデータ可用性が提供されます。Oracle Data Guardでは、管理者は、オプションで、リソース集中型バックアップ操作およびレポート作成操作をスタンバイ・システムにオフロードすることによって、プライマリ・データベースのパフォーマンスを向上できます。
Oracle Data Guard構成は、1つのプライマリ・データベースと1つ以上のスタンバイ・データベースからなります。プライマリ・データベースのバックアップ・コピーを使用して、最大9つのスタンバイ・データベースの作成およびOracle Data Guard構成への統合が可能です。スタンバイ・データベースが作成されると、Oracle Data Guardは、このスタンバイ・データベースにプライマリ・データベースからREDOデータを送信および適用して、自動的に各スタンバイ・データベースのメンテナンスを行います。
プライマリ・データベースと同様に、スタンバイ・データベースは、単一インスタンスOracleデータベースまたはOracle RACデータベースのいずれかになります。
スタンバイ・データベースは、フィジカル・スタンバイ・データベース、スナップショット・スタンバイ・データベースまたはロジカル・スタンバイ・データベースのいずれかになります。Oracle Data Guard構成にはこのようなスタンバイ・データベースの種類の組合せを含めることができます。
フィジカル・スタンバイ・データベースは、プライマリ・データベースの物理的に同一なコピーを提供します。このコピーにはプライマリ・データベースと同一のデータ・ファイルがあります。索引などのデータベース・スキーマは同じです。また、フィジカル・スタンバイ・データベースは、REDO Applyによってプライマリ・データベースと同期化され、プライマリ・データベースから受信したREDOデータをリカバリし、フィジカル・スタンバイ・データベースに適用します。
フィジカル・スタンバイ・データベースは、障害時リカバリ以外のビジネス目的にも使用できます。Oracle Database 11gリリース1以降では、スタンバイ・データベースにREDOデータを適用している間に、フィジカル・スタンバイ・データベースを読取り専用アクセス用に開くことができます。Oracle Active Data Guardオプション脚注1と呼ばれるこのモードを使用すると、ユーザーは問合せのためにいつでも最新のフィジカル・スタンバイ・データベースにアクセスできます。詳細は、2.3.4.1項「フィジカル・スタンバイ・データベースのOracle Active Data Guardオプション」を参照してください。
また、フィジカル・スタンバイ・データベースを次のように変換することもできます。
ロジカル・スタンバイに一時的に変換できます。これは、一時的なロジカル・スタンバイ・データベースと呼ばれ、ローリング・アップグレードを実行します。
スナップショット・スタンバイ・データベースに一時的に変換できます。これは、クローンまたはテスト・データベースとして使用されます。
詳細は、4.1.5.2項「複数のスタンバイ・データベース・アーキテクチャの概要」を参照してください。
|
関連項目:
|
スナップショット・スタンバイ・データベースは、フィジカル・スタンバイ・データベースから作成する更新可能なスタンバイ・データベースです。スナップショット・スタンバイ・データベースは、プライマリ・データベースから受信されるREDOデータを受信してアーカイブしますが、スタンバイが読取り/書込みアクセス用に開いているときにプライマリ・データベースのREDOデータを適用しません。したがって、通常、スナップショット・スタンバイは時間が経過するにつれてプライマリ・データベースから分岐します。また、スナップショット・スタンバイ・データベースのローカルな更新が原因でさらに分岐します。
プライマリ・データベースのREDOデータは、スナップショット・スタンバイ・データベースをフィジカル・スタンバイ・データベースに戻して、スナップショット・スタンバイ・データベースへのローカルな更新がすべて破棄されるまで適用されません。1つのコマンドでスナップショット・スタンバイをフィジカル・スタンバイ・データベースに戻すことができます。このとき、スナップショット・スタンバイ状態に加えられた変更が破棄され、アーカイブされたREDOデータを使用してフィジカル・スタンバイ・データベースとプライマリ・データベースがREDO Applyによって自動的に再同期化されます。
ロジカル・スタンバイ・データベースには、プライマリ・データベースと同じ論理的な情報が含まれますが、データの物理的な組織と構造は異なります。ロジカル・スタンバイ・データベースは、SQL Applyによってプライマリ・データベースと同期化されます。SQL Applyは、プライマリ・データベースから受信したREDOデータをSQL文に変換し、スタンバイ・データベースでそのSQL文を実行します。
ロジカル・スタンバイ・データベースの主な利点は、レポート作成のワークロードを最適化する重要な補助構造を作成できることです（プライマリ・データベースのトランザクションのレスポンス時間に対する抑制効果をもたらす構造など）。ロジカル・スタンバイ・データベースでは、次の操作を行うことができます。
そのデータを、パーティション化が異なり、異なる索引が多くあり、オンデマンド・リフレッシュ・マテリアライズド・ビューが作成および管理される別の記憶域タイプに物理的に再編成できます。
データ・キューブや他のOLAPデータ・ビューの作成に使用できます。
障害時リカバリ要件を満たす以外のビジネス目的でも使用でき、ユーザーは、問合せとレポート作成目的でロジカル・スタンバイ・データベースに常にアクセスできます。
ほぼ停止時間ゼロでOracle Databaseソフトウェアおよびパッチ・セットをアップグレードをするために使用できます。
そのため、データ保護、レポート作成、およびデータベースのアップグレード目的でロジカル・スタンバイ・データベースを同時に使用することができます。
Oracle Data Guardには次のような利点があります。
リアルタイムでトランザクション的に一貫したデータベースのコピーが保持されるため、計画外の停止時間および災害からの保護が実現
コンピュータ障害、人的エラー、データ破損、書込み欠落およびサイト障害からのデータ保護および迅速な修復
すべてのネットワーク構成とビジネス要件をサポートする、柔軟性の高いデータ保護レベルを備えた自動フェイルオーバー
様々な強化機能による、REDO適用、REDO転送およびロール移行の高速化
システム変更、一部のプラットフォームの移行、ハードウェアおよびシステムのアップグレード、Oracleパッチ・セットとデータベースのアップグレードの計画停止時間の短縮（表2-1「停止タイプと計画外停止時間用Oracle高可用性ソリューション」も参照）
システム・パフォーマンス要件に対し、データ可用性のバランスを取るための複数レベルのデータ保護およびパフォーマンス
フィジカル・スタンバイ・データベース（Active Data Guardオプションを含む）とロジカル・スタンバイ・データベースのサポートにより、問合せ機能およびレポート作成機能をプライマリ・データベースからスタンバイ・データベースに転送し、システム・リソースの使用効率の向上を実現（ロジカル・スタンバイ・データベースは、読取り/書込みアクセス用に開いているスタンバイ・データベースへのアクセスを必要とするすべてのアクティビティに対して高い柔軟性を提供）「フィジカル・スタンバイ・データベースの利点」、「ロジカル・スタンバイ・データベースの利点」および2.3.4.1項「フィジカル・スタンバイ・データベースのOracle Active Data Guardオプション」も参照してください。
レポート作成またはテスト（クローニング）を目的とするスナップショット・スタンバイ・データベースのサポート、およびレポート作成またはテスト完了後のプライマリ・データベースとの自動再同期化「スナップショット・スタンバイ・データベースの利点」も参照してください。
計画および計画外の停止時間を最小限に抑えるため、管理された自動的なロールの移行ならびにアプリケーション通知
フェイルオーバーに続く、障害が発生したプライマリ・データベースの自動再同期化
管理を簡素化するため、すべてのシステムを単一の構成として管理
プライマリ・システムとスタンバイ・システムで異なるCPUアーキテクチャ、オペレーティング・システム（WindowsとLinuxなど）、オペレーティング・システム・バイナリ（32ビットと64ビット）、Oracleデータベース・バイナリ（32ビットと64ビット）が使用されているData Guard構成の柔軟性の向上（サポート・ノート413484.1に定義されている制限が前提）
フィジカル・スタンバイ・データベースの利点
プライマリ・データベースのブロック単位での物理的なコピーが保証されます。
リアルタイムのレポート作成用にREDO Applyをアクティブにしている間に、読取り専用問合せ用に開くことができます（2.3.4.1項「フィジカル・スタンバイ・データベースのOracle Active Data Guardオプション」で説明するOracle Active Data Guardオプションが必要）。
ロールの移行において、スタンバイ・データベースが古いプライマリ・データベースの正確なレプリカであることが保証されます。
プライマリ・データベースからのバックアップをオフロードするのに使用できます。
非常に高性能で、ワークロードのプロファイルに対して完全に透過的です。
データ型の制限がありません。
多くの計画メンテナンス・イベントの停止時間を最小限に抑えるのに役立ちます。
スナップショット・スタンバイ・データベースの利点
フィジカル・スタンバイ・データベースのすべての属性を継承します。
読取り/書込みアクセス用に開いて、プライマリ・データベースに関係なくトランザクションを処理することができます。
プライマリ・データベースを読取り/書込みのI/O用に開いている間、プライマリ・データベースを保護します。
単一のコマンドを発行するだけで、スナップショット・スタンバイを同期化されたフィジカル・スタンバイ・データベースに戻すことができます。
特にOracle Real Application Testingと組み合せたときに理想的なテスト・システムを提供します。
ロジカル・スタンバイ・データベースの利点
プライマリ・データベースのトランザクション単位での論理的なコピーを提供します。
追加オブジェクトの作成、オブジェクトの変更が可能です。
特定のオブジェクトへの適用をスキップすることができます。
リアルタイムのレポート作成をサポートします。
読取り/書込みのI/O用に開きます（SQL Applyによってメンテナンスされている表内のデータは変更できません）。
ワークロードに応じてパフォーマンスが変化します。
ソフトウェア・アップグレードのための停止時間を最小限に抑えます。
Oracle Streamsは柔軟性の高い強力なデータベース機能であり、きめ細かなレプリケーション、マルチマスター・レプリケーション、多対1のレプリケーション、データ変換、ハブ・アンド・スポーク・レプリケーションおよびメッセージ・キューイングを実装します。
Oracle Streamsは、情報共有を目的として設計されています。Streamsを使用すると、高度にカスタマイズされたレプリケーション戦略で、ターゲット・データベースにレプリケートされたデータの様々な用途を満たすことができます。これらの機能により、Oracle Streamsは、高可用性および障害時リカバリ要件に対応して新しいデータベース・リリースとパッチ・セットへのアップグレード時に、計画停止時間を最小限に抑えるための有用なテクノロジになります。Oracle Data Guardは、障害の発生時にプライマリ・ロールを引き継ぐことができる同期化されたコピーを維持するために、データベース全体の単純な一方向レプリケーションを明示的に行う目的で設計されています。Oracle Data GuardのREDO Apply（フィジカル・スタンバイ）は、データ型やアプリケーションにとらわれない、高レベルのパフォーマンスへの拡張が可能な障害時リカバリ・ソリューションとして、簡素化の概念を示す最適な例です。Oracle Data Guardには、バックアップ、問合せおよびレポートを実行するプライマリ・データベースのオーバーヘッドをスタンバイ・データベースでオフロードできる機能もありますが、これらの機能はOracle Data Guardのプライマリ・ミッションを補助するものであり、高可用性と障害時リカバリにおいて投資効果を高める目的で提供されています。Oracle Data Guard構成から追加の値を取得するために、Oracle Data Guard SQL Apply（ロジカル・スタンバイ・データベース）を使用して、新しいデータベース・リリースとパッチ・セットへのアップグレードに際しての計画停止時間を最小限に抑えることができます。
Streamsのメッセージ機能と情報フロー
Oracle Streamsでは情報を共有できます。Oracle Streamsを使用すると、共有情報の各単位はメッセージと呼ばれ、これらのメッセージをストリームで共有できます。ストリームは、データベース内またはデータベース間で情報を伝播できます。
たとえば、図2-1は、すべてのサイトがレプリケーション環境に参加している他のすべてのサイトと直接接続されているOracle Streamsのマルチマスター構成を示しています。マルチマスター構成により、すべてのサイト間でデータをほぼリアルタイム方式でレプリケートできます。
また、プライマリやハブで加えられた変更がリモートまたはスポークにほぼリアルタイム方式で伝播されるOracle Streams 1-N（ハブ・アンド・スポーク構成）の例もあります。
双方向レプリケーションを行う場合にハブ・アンド・スポーク構成を構成できますが、図2-2に示すように、1つの場所（ハブ）に対する更新を制限することをお薦めします。問合せ集中型環境では、更新がハブに制限されている間に、高速ローカル・アクセスによって負荷のバランスを複数の場所で調整することもできます。スポークにレポート作成をオフロードすることで、ハブまたはプライマリのOLTPのパフォーマンスが向上します。このタイプの構成は、レプリケーション環境のすべての場所を結ぶ接続を確立したり、競合する解決戦略を実装したりする必要がないため、マルチマスター・レプリケーションよりも実装が簡単です。
ストリームは、指定の情報を指定の宛先にルーティングします。その結果、メッセージの取得と管理、および他のデータベースやアプリケーションとのメッセージの共有に関して、従来のソリューションよりも優れた機能と柔軟性が提供されます。Oracle Streamsには、分散するエンタープライズとアプリケーションの構築および操作に必要な機能、データ・ウェアハウスおよび高可用性ソリューションが備わっています。Oracle Streamsの機能はすべて同時に使用できます。ビジネス要件が変更になる場合、既存の機能を損わずにOracle Streamsの新しい機能を実装できます。
Oracle Streamsの構成では、取得、ステージング（伝播）および消費（適用）の3つのフェーズがあります。Oracle Streamsを使用して、データ・ストリームに入れる情報、ストリームが流れる方法、データベース間でのストリームのルーティング方法、ストリーム内のメッセージが各データベースに達したときの処理、およびストリームの終了方法を制御します。Oracle Streamsの特定の機能を構成することで、特定の要件に対処できます。Oracle Streamsでは、仕様に基づいてデータベースでメッセージの取得、ステージングおよび管理を自動的に行うことができます。メッセージには、データ操作言語（DML）の変更やデータ定義言語（DDL）の変更などが含まれますが、これらに限定するものではありません。また、ユーザー定義のメッセージをストリームに挿入して、Streamsが他のデータベースやアプリケーションに情報を自動的に伝播することもできます。メッセージが宛先に達すると、Streamsは仕様に基づいてこれらを消費できます。
次の図は、Oracle Streamsの情報フローを示しています。
Oracle Streamsを使用して、本番データベースのローカルまたはリモート・コピーを作成できます。人的エラーまたは大災害が発生した場合、このコピーを使用して処理を再開できます。Oracle Streamsを使用すると、柔軟性のある高可用性環境を構成できます。Oracle Streamsの機能を使用することにより、データベースのアップグレード操作やメンテナンス操作時のデータベースの停止時間がごくわずか、またはゼロになります。メンテナンス操作には、別のプラットフォームへのデータベースの移行、別のキャラクタ・セットへのデータベースの移行、ユーザー作成アプリケーションへのアップグレードをサポートするデータベース・スキーマ・オブジェクトの変更、およびOracleソフトウェア・パッチの適用などがあります。
図2-4は、Oracle Streamsのアドバンスト・キューイングによってメッセージのエンキューとデキューを明示的に行うアプリケーションを示しています。Oracle Streamsのアドバンスト・キューイングは、異なるメッセージ・システムを使用するビジネス・パートナまたは顧客と情報を共有する方法です。エンキューが行われると、メッセージは必要に応じて変換および伝播され、非データベース指向のメッセージ・システムであるビジネス・パートナのアプリケーションにデキューされます。
Oracle Streamsを使用する利点
Oracle Streamsには次のような利点があります。
データベースの完全または部分的なリモート・コピーの保持によるデータ保護
データベースのアップグレード、または別のプラットフォームあるいはキャラクタ・セットへのデータベースの移行、アプリケーションへのアップグレードをサポートするためのデータベース・オブジェクトの変更、およびOracleソフトウェア・パッチの適用などのメンテナンス操作中の停止時間をゼロまたは最小限に抑えます。
データベース・オブジェクトに加えられたDMLおよびDDLの変更を取得し、これらの変更を1つ以上の他のデータベースにレプリケートすることによるデータのレプリケーション。2つのデータベースが、レプリケートされたデータベース・オブジェクトとデータを正確に共有する双方向レプリケーション環境が実現します。
メッセージのエンキューまたはイベントの取得、メッセージおよびイベントのキューへの伝播、メッセージまたはイベントのデキューと適用あるいは操作によるイベント管理および通知（図2-4を参照）
構成内のデータベースにまたがった異種プラットフォームのサポート
レプリカを区別するためのキャラクタ・セットの使用
きめ細かなデータ共有制御が可能
|
注意: Oracle Streamsでは実装の初期投資がある程度必要になりますが、Streamsで得られる柔軟性の高さを考慮すれば、その価値は十分にあります。 |
|
関連項目: 『Oracle Streams概要および管理』 |
フラッシュバック・テクノロジは、過去の様々な時点におけるデータのビューを切り替えるための一連の機能を提供します。フラッシュバック機能を使用すると、スキーマ・オブジェクトの過去のバージョンや履歴データを問い合せることができます。また、変更分析の実行、データベースをオンラインにしたまま論理的破損からリカバリするセルフサービス修復も可能になります。
フラッシュバック・テクノロジは、人的エラーの分析および修復を素早く行うためのSQLインタフェースを提供します。フラッシュバック・テクノロジでは、誤った顧客オーダーの削除など、局部的な損傷のきめ細かな分析および修復が行われます。フラッシュバック・テクノロジを使用すると、より広範な損傷の修正も可能になります。しかも、修正は迅速に行われるため、停止時間が長期化することはありません。フラッシュバック・テクノロジはOracle Databaseに特有のものであり、行、トランザクション、表、表領域、データベースなどのあらゆるレベルでのリカバリをサポートしています。
ほとんどのフラッシュバック機能ではUNDOデータが使用され、フラッシュバック・データベースやブロック・メディア・リカバリなどの機能ではフラッシュバック・ログが使用されます。
フラッシュバック・データ・アーカイブ: 表領域に格納されるアーカイブ。レコードの存続期間中に表のすべてのレコードに対して行われたトランザクションの変更が含まれます。アーカイブされたデータは、UNDO表領域で提供される保存期間よりも長く保存できます。
フラッシュバック・ログ: フラッシュバック操作の実行に使用されるOracle生成ログ。データベースは、フラッシュ・リカバリ領域にのみフラッシュバック・ログを書き込むことができます。フラッシュバック・ログは連続して書き込まれ、アーカイブされません。このログをディスクにバックアップすることはできません。
次に、フラッシュバック機能について説明します。
Oracle Flashback Queryでは、自動UNDO管理システムを利用してトランザクションのメタデータおよび履歴データを取得することで、過去に存在したデータを表示できます。UNDOデータは永続的で、データベースの異常や停止の際にも失われません。フラッシュバック問合せの独自の機能により、表の以前のバージョンの問合せが可能になり、誤った操作からリカバリするための強力なメカニズムも提供されます。
フラッシュバック問合せの用途を次に示します。
失われたデータのリカバリや、誤ったコミット済の変更の取消しを行います。たとえば、削除または更新された行を、コミット後でもただちに修復できます。
現行のデータと過去のある時点の対応するデータとを比較します。たとえば、前日のデータの変更を示す日次レポートを使用すると、表データの個々の行を比較したり、一連の行の共通部分または和集合を検索することができます。
特定の日の勘定残高を確認するなど、ある時点におけるトランザクション・データの状態をチェックします。
特定のタイプの一時データを格納する必要をなくすことで、アプリケーションの設計を簡素化します。フラッシュバック問合せを使用すると、過去のデータをデータベースから直接取得できます。
レポート生成ツールなどのパッケージ・アプリケーションを過去のデータに適用します。
アプリケーションのセルフサービス・エラー修正を実現し、ユーザーが自分のエラーの取消しおよび修正を行えるようにします。
|
関連項目: 『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』 |
Oracle Flashback Versions Query
Oracle Flashback Versions QueryはSQLの拡張機能で、特定の表から特定の期間に存在した行のバージョンを取得するために使用できます。Oracle Flashback Versions Queryでは、特定の期間に存在した行の各バージョンに対して行が1つ返されます。どの表についても、COMMIT文が実行されるたびに行のバージョンが新たに作成されます。
フラッシュバック・バージョン問合せは、DBAが分析を実行して問題の原因を特定できる強力なツールです。さらに、アプリケーション開発者はフラッシュバック・バージョン問合せを使用して、監査目的のカスタム・アプリケーションを構築できます。
|
関連項目: 『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』 |
Oracle Flashback Transaction
Oracle Flashback Transactionは、Oracle Database 11gリリース1の新機能であり、トランザクションとその依存トランザクションを簡単に取り消すことができます。DBMS_FLASHBACK.TRANSACTION_BACKOUT()プロシージャは、データベースがオンラインのまま、トランザクションとその依存トランザクションをロール・バックします。このリカバリ操作ではUNDOデータを使用して、影響を受けたデータを元の状態に戻す補正トランザクションを作成および実行します。DBA_FLASHBACK_TRANSACTION_STATEビューを問い合せて、トランザクションが依存ルールを使用して取り消されたか、または次のいずれかによって強制的に取り消されたかについて、トランザクションの現在の状態を確認できます。
競合していない行の取消し
UNDO SQLの適用
Oracle Flashback Transactionでは、データベースがオンラインのまま、特定のトランザクション、またはトランザクションのセットとその依存トランザクションを1つのコマンドで簡単かつ迅速に取り消すことにより、論理リカバリ時の可用性が向上します。
|
関連項目: 『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』 |
Oracle Flashback Transaction Query
Oracle Flashback Transaction Queryは、データベースに加えられたすべての変更をトランザクション・レベルで表示するためのメカニズムを提供します。フラッシュバック・バージョン問合せと併用した場合、人的エラーまたはアプリケーションのエラーからリカバリする高速で効率的な手段となります。フラッシュバック・トランザクション問合せでは、行を変更したデータベース・ユーザーが戻されるため、データベースの問題のオンライン診断を実行する能力が強化されます。また、トランザクションの分析および監査も実行されます。
|
関連項目: 『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』 |
Oracle Flashback Table
Oracle Flashback Tableを使用すると、過去のある時点の状態に表をリカバリできます。フラッシュバック表は、人的エラーまたはアプリケーションのエラーによって変更された1つの表または一連の表をリカバリするための高速なオンライン・ソリューションを提供します。ほとんどの場合、フラッシュバック表を使用することで、管理者がより複雑なポイント・イン・タイム・リカバリ操作を実行する必要性は軽減されます。表のフラッシュバック後も元の表のデータは失われないため、後で元の状態に戻すことができます。
|
関連項目: 『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』 |
Oracle Flashback Drop
オブジェクトの誤った削除は、データベース・ユーザーにも、データベース管理者にも同様に問題です。削除された表、索引、制約またはトリガーをリカバリする簡単な方法はありませんが、Oracle Flashback Dropでは、オブジェクトを削除する際の安全策が提供されます。表を削除すると、その表は自動的にごみ箱に入ります。ごみ箱は、すべての削除済オブジェクトが入っている仮想コンテナです。削除した表のデータは、引き続き問い合せることができます。
|
関連項目: 『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』 |
Oracle Flashbackのリストア・ポイント
Oracle Flashbackのリカバリ操作がデータベースで実行されるとき、DBAは、適切な時間内に（システム変更番号（SCN）またはタイムスタンプで識別）、後でフラッシュバック可能なポイントを決定する必要があります。Oracle Flashbackのリストア・ポイントとは、フラッシュバック・データベース、フラッシュバック表およびRecovery Manager（RMAN）操作で使用されるSCNまたはトランザクション時間を代入するユーザー定義可能なラベルです。さらに、データベースでは、前回のデータベースのリカバリを通じてフラッシュバックでき、保証されたリストア・ポイントでリセットログをオープンできます。保証されたリストア・ポイントを使用して、データベースの巻戻しに必要なUNDOが保存されるようにすることで、データベースのバッチ・ジョブ、アップグレードまたはパッチなどの主なデータベース変更を素早く元に戻すことができます。
Oracle Flashbackのリストア・ポイント機能を使用すると、次の利点があります。
一貫性のある状態、つまり失敗した計画操作（バッチ・ジョブ、Oracleソフトウェア・アップグレードまたはアプリケーション・アップグレードの失敗など）より前の適切なポイントに素早くリストアすることが可能。
スナップショット・スタンバイと本番データベースとの再同期化が可能。
テスト・データベースまたはクローン化されたデータベースを元の状態に戻す迅速なメカニズムを提供。
|
関連項目: 『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』 |
Oracle Flashback Database
Oracle Flashback Databaseは、データベースのポイント・イン・タイム・リカバリよりも効率的な代替策を提供します。Oracle Flashback Databaseを使用すると、現行のデータ・ファイルを過去の内容に戻すことができます。つまり、データ・ファイルのバックアップからデータをリストアして、データベースのポイント・イン・タイム・リカバリを実行する場合とほぼ同じです。ただし、フラッシュバック・データベースではデータ・ファイルのリストアとほとんどのREDOデータの適用が省略されます。
Oracle Flashback Databaseを有効にすると、次の利点があります。
データベース全体に影響を与える人的エラー修正時のバックアップのリストア時間を排除
人的エラーは素早く元に戻すことができるため、リアルタイム適用を使用してスタンバイ・データベースとプライマリ・データベースとの同期化が可能
データベースのフェイルオーバー後、スタンバイ・データベースの迅速な再インスタンス化が可能
|
関連項目:
|
Oracle Databaseリリース11.1以降では、ブロック・リカバリでフラッシュバック・ログからデータ・ブロックの最新コピーをオプションで取得してリカバリ時間を短縮できます。その上、インスタンスのリカバリで発生した破損ブロックによってインスタンスのリカバリが失敗することはありません。このようなブロックは破損として自動的にマークされ、V$DATABASE_BLOCK_CORRUPTION表のRMANの破損リストに追加されます。その後、RMANのRECOVER BLOCKコマンドを発行して関連ブロックを修正できます。
|
関連項目: 『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』 |
表領域に格納されるアーカイブで、レコードの存続期間中に表のすべてのレコードに対して行われたトランザクションの変更が含まれます。アーカイブされたデータは、UNDO表領域で提供される保存期間よりも長く保存できます。
|
関連項目: 『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』 |
自動ストレージ管理（ASM）は、垂直方向に統合されたファイル・システムおよびボリューム・マネージャを直接Oracleカーネル内に構築し、次の機能を提供します。
データベース・ストレージのプロビジョニングに必要な作業量が大幅に削減
より高いレベルの可用性
特殊なストレージ製品のコスト、インストールおよびメンテナンスを排除
データベース・アプリケーションの固有の機能
最適なパフォーマンスを実現するため、ASMは、ファイルをすべての使用可能なストレージ間で分散させます。また、データ損失から保護するために、ASMは、SAME（Stripe and Mirror Everything）の概念を拡大して、ディスク全体のレベルではなくデータベース・ファイル・レベルでのミラー化が可能となるように、SAMEにより柔軟性を持たせます。
さらに重要なことに、ASMは、ミラー化の設定、ディスクの追加および削除プロセスを簡素化します。数百または数千にもなりうる（大規模なデータ・ウェアハウスの場合）多数のファイルを管理するかわりに、DBAは、ASMを使用してディスク・グループと呼ばれるさらに大きなオブジェクトを作成および管理します。ディスク・グループは、論理ユニットとして管理されるディスク・セットを識別します。ファイルの名前付け、および基礎となるデータベース・ファイルの配置を自動化することにより、データベース管理者の時間を節約でき、標準的なベスト・プラクティスの適用を保証できます。
ASM固有のミラー化メカニズム（双方向または3方向）は、ストレージ障害から保護するためのオプションです。ASMミラー化を使用して、障害グループを使用する場合により高いレベルのデータ保護を実現できます。障害グループとは、障害が許容される、共通のリソース（ディスク・コントローラまたはディスク・アレイ全体）を共有するディスク・セットのことです。ASMの障害グループを定義することで、データの冗長コピーが個別の障害グループにインテリジェントに配置されます。これにより、ストレージのサブシステム内のいずれかのコンポーネントで障害が発生した場合でも、このデータを使用でき、また、透過的に保護されるようになります。
ASMには次のような利点があります。
ドライブおよびストレージ・アレイ間でのミラー化とストライプ化が可能
障害が発生したドライブから残りのドライブへの自動再ミラー化
データベースがオンラインのまま、ディスクの追加または削除時に格納されたデータの自動リバランスが可能
データベース・ストレージ管理の操作の簡素化が可能
ローカル読取り機能による、拡張クラスタのパフォーマンスの向上
大規模データベースのサポート
ASMローリング・アップグレードのサポート
チューニングおよびセキュリティのきめ細かな粒度のサポート
|
関連項目: 『Oracle Databaseストレージ管理者ガイド』 |
Recovery Manager（RMAN）は、データベースのバックアップや、さらに重要なデータベースのリカバリを管理するためのOracleのユーティリティです。RMANは、操作の複雑さを排除するとともに、データベースの優れたパフォーマンスおよび可用性をもたらします。
RMANは、リクエストされたバックアップ、リストアまたはリカバリの操作を実行する最も効率的な方法を決定し、Oracle Databaseサーバーでの処理のために、これらの操作を発行します。RMANおよびサーバーは、データベース構造に加えられた変更を自動的に識別し、変更に適応するために必要な操作を動的に調整します。
Recovery Managerには次のような利点があります。
バックアップおよびリストア操作での自動チャネル・フェイルオーバー
リストア操作で欠落した、または破損したバックアップが検出された場合に、前回のバックアップへの自動フェイルオーバー
リカバリ中の一時ファイルおよび新規データベースの自動作成
前回のポイント・イン・タイム・リカバリを使用した自動リカバリ（リセットログによるリカバリ）
ブロック・メディア・リカバリでは、データ・ファイルをオンラインに保ったまま、ブロックの破損を修復
ブロック・チェンジ・トラッキングを使用した高速増分バックアップ
イントラファイルおよびインターファイルの並列処理による高速バックアップ操作とリストア操作
仮想プライベート・カタログによるセキュリティの強化
ネットワークでデータベースを作成する場合の、ステージング領域の削除による領域消費の削減
増分バックアップをイメージ・コピーにバックグラウンドでマージし、最新のリカバリ可能性を提供
必要なファイルのみ、バックアップおよびリストアを最適化
保存方針により、関連のバックアップを確実に保存
前回失敗した操作のバックアップおよびリストアを再開可能
制御ファイルおよびサーバー・パラメータ・ファイルの自動バックアップを行うことにより、データベース構造の変化や、メディア障害や災害の発生時に、バックアップ・メタデータの使用が可能
オンライン・バックアップの際に、データベースをホット・バックアップ・モードに切り替える必要なし
|
関連項目: 『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』 |
Oracle Secure Backupは、UNIX、Linux、WindowsおよびNetwork Attached Storage（NAS）の分散環境で実行される異種データ保護を提供する、集中型のテープ・バックアップ管理ソリューションです。ファイル・システムとOracleデータベースのデータを保護することにより、Oracle Secure BackupはIT環境に完全なテープ・バックアップ・ソリューションを提供します。
Oracle Secure BackupはRMANと緊密に統合されてRMANのメディア管理層を提供し、Oracle9i以降のリリースをサポートしています。Oracle Secure BackupとRMANは、最適化された統合ポイントを使用して、Oracleデータベースに最速で効率性が最も高いテープ・バックアップ機能を提供します。
バックアップ・ポリシーを使用して、分散サーバーをOracle Secure Backup中央管理サーバーからローカルおよびリモートのテープ・デバイスにバックアップできます。完全自動操作の場合はカレンダーに基づくスケジュールで、迅速な要件の場合はオンデマンドでバックアップされます。高度にスケーラブルなクライアント/サーバー・アーキテクチャにより、Oracle Secure Backupは安全なイントラドメイン通信と双方向サーバー認証のためにSSLを利用して、ローカルおよびリモートのデータ保護を提供します。
次に、Oracle Secure Backupの主な利点について説明します。
現在使用されているブロックのみをバックアップして、バックアップ・パフォーマンスを10%〜25%向上させることで、Oracleデータベースのテープ・バックアップを最適化。
ポリシーに基づく管理により、バックアップ管理者はバックアップ・ドメインの正確な制御が可能。
動的ドライブ共有によるテープ・リソースの使用率の向上。
異種ストレージ・エリア・ネットワーク（SAN）のサポートにより、NAS、UNIX、WindowsおよびLinuxでテープ・ドライブとメディアの共有が可能。
完全および増分オフサイト・バックアップ・スケジューリングによる、ファイル、ディレクトリ、ファイル・システムまたは行パーティション・レベルでのファイル・システム・バックアップ。
Oracle Enterprise Managerとの統合による、直感的で使いやすいインタフェースの提供。
テープへのバックアップの暗号化。
SANおよびSCSI環境における新しいテープ・デバイスと従来のテープ・デバイスの幅広いテープ・デバイス・サポート。
Network Data Management Protocol（NDMP）のサポートによる、NASファイラの効率性の高いバックアップ。
スケーラブルで低コストのライセンス・モデルによる、ITコストの削減と運用面の考慮事項の軽減。
|
関連項目: 『Oracle Secure Backup管理者ガイド』 |
Oracle Database 11gの新機能であるデータ・リカバリ・アドバイザは、永続的な（ディスク上の）データ障害を自動的に診断し、適切な修復オプションを示し、要求に応じて修復操作を実行します。
|
注意: 最初のリリースのデータ・リカバリ・アドバイザではOracle RACがサポートされていません。また、Data Guard構成でプライマリ・データベースを管理する際にデータ・リカバリ・アドバイザを使用できますが、データ・リカバリ・アドバイザを使用してフィジカル・スタンバイ・データベースのトラブルシューティングを行うことはできません。データ・リカバリ・アドバイザは、Enterprise Manager 11g Grid Controlを使用する場合、修復方法を提示する際にスタンバイ・データベースの存在のみを考慮します。 |
データ・リカバリ・アドバイザには、次の機能があります。
障害診断
通常、データベース障害の最初の兆候は、エラー・メッセージ、アラーム、トレース・ファイルおよびダンプ、ヘルス・チェックの失敗などです。これらの兆候を評価する作業はたいてい複雑で間違いやすく、時間がかかります。データ・リカバリ・アドバイザを使用すると、データ障害が自動的に診断され、これらの詳細が通知されます。
障害の影響の評価
障害の診断後、修復戦略について検討する前に、障害の範囲を把握し、アプリケーションに与える影響を評価する必要があります。データ・リカバリ・アドバイザを使用すると、障害の影響が自動的に評価され、わかりやすい形式でその結果が表示されます。
修復の生成
通常、データ・リカバリ・アドバイザには使用可能な修復オプションは複数あり、リカバリ時間と潜在的なデータ損失のどちらを採用するか妥協が必要になります。障害が複数ある場合は、最適な修復の順序も確認する必要があります。状況によっては、修復作業を統合した方がよい場合もあります。データ・リカバリ・アドバイザは、これらすべての作業に対応しており、最善の修復オプションが自動的に確認されます。
修復の実行可能性チェック
データ・リカバリ・アドバイザでは、修復オプションが示される前に、特定の環境や提案される修復処理を完了するために必要なメディア・コンポーネントの可用性に関して、これらの修復オプションが検証されます。高速で行われる実行可能性チェックは、必要なバックアップを使用できるかどうかを検証します。これらのバックアップの実際の内容は修復中に検証されます。
修復の自動化
提示された修復オプションを使用すると、この修復オプションが自動的に実行され、修復が成功したかどうかが検証されて、該当の障害が処置済となります。
データの整合性およびデータベースのリカバリ可能性の検証
データ・リカバリ・アドバイザでは、選択すればいつでも、データ、バックアップおよびREDOストリームの整合性を検証できます。
破損の早期検出
状態モニターを使用して、データ・リカバリ・アドバイザによる診断チェックを定期的に実行するようスケジュール設定できます。これにより、トランザクションを実行しているデータベース・プロセスによって破損が検出されてエラーが通知される前に、データ障害を検出、分析および修復できます。早期の警告により、破損による損害を制限できます。
データの検証および修復の統合
データ・リカバリ・アドバイザは、データの検証および修復用の単一のツールです。
|
関連項目: 『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』のデータ・リカバリ・アドバイザを使用した障害の診断および修復に関する記述を参照してください。 |
フラッシュ・リカバリ領域とは、Oracle Database内のすべてのリカバリ関連ファイルおよびアクティビティを対象とした一元的な格納場所です。この機能を有効にすると、すべてのRMANバックアップ、アーカイブREDOログ、制御ファイルの自動バックアップおよびデータ・ファイルのコピーが自動的に特定のファイル・システムまたはストレージ管理ディスク・グループに書き込まれ、このディスク領域はRMANとデータベース・サーバーによって管理されます。
フラッシュ・リカバリ領域を使用するとテープへの書込みのボトルネックが解消されるため、ディスクへのバックアップ実行が高速化されます。さらに重要なことに、データベースのメディア・リカバリを行う必要がある場合は、データ・ファイルのバックアップがすぐに使用できます。必要なデータ・ファイルおよびアーカイブREDOログをリストアするためのテープおよび空きテープ・デバイスを見つける必要がないため、リストアおよびリカバリの時間が短縮されます。
フラッシュ・リカバリ領域には、次の利点があります。
関連リカバリ・ファイルの格納場所の一元化
リカバリ・ファイルに割り当てられたディスク領域を管理し、データベース管理タスクを簡素化
高速で信頼性の高いディスクベースのバックアップおよびリストア
フラッシュ・リカバリ領域全体のバックアップとリストアが可能
フラッシュ・リカバリ領域への障害の許容が可能
|
関連項目: 『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』 |
人的エラーに対する最大の保護とは、その発生を防ぐことです。人的エラーの最高の保護方法は、ユーザー・アクセスを、真にビジネス機能を実行する必要があるデータおよびサービスに限定することです。オラクル社では、データベース・ユーザーの認証によりアプリケーション・データへのアクセスを制御し、管理者が、任務の遂行に必要な権限のみをユーザーに与えることができる多種多様なセキュリティ・ツールを提供しています。
さらに、Oracle Databaseのセキュリティ・モデルでは、仮想プライベート・データベースを使用して行レベルにデータ・アクセスを制限し、アクセスする必要がないデータをデータベース・ユーザーから分離することが可能です。
Oracleセキュリティ機能には、次の利点があります。
ネットワーク、データベースおよびアプリケーションを使用したエンティティのアイデンティティを検証するための認証制御。データベース間のネットワーク・セッション（REDO転送セッションなど）も認証されます。
データベース・ユーザー・アイデンティティおよびロールにリンクされているアクセスおよびアクションを制限するための認証制御。
オブジェクトへのアクセスを制御し、エンティティがオブジェクトへのアクセスか変更を求めるかに関係なく保護を提供。
特定のデータベース・アクティビティに関するデータの監視および収集、不審なアクティビティの調査、不適切なアクティビティからのユーザー（またはその他）の削除、および認証あるいはアクセス制御の実装による問題の検出を行う監査制御。
プロファイルを使用したセキュリティ・ポリシー管理。
データベースおよびバックアップ内に存在する、またはデータベース間で転送されるデータの暗号化。
|
関連項目: 『Oracle Databaseセキュリティ・ガイド』および『Oracle Data Guard概要および管理』 |
Oracleログ・ファイルには、Oracleデータベースのアクティビティおよび履歴に関する有益な情報が含まれています。また、ログ・ファイルには、データベースのリカバリの実行に必要なすべてのデータが含まれており、データベース内のデータおよびメタデータに加えられたあらゆる変更も記録されます。
LogMinerは、SQLを使用したREDOログ・ファイルの読取り、分析および解析を可能にする完全リレーショナル・ツールです。LogMinerを使用したログ・ファイルの分析は、次の用途に使用できます。
データへの変更の追跡または監査
チューニングおよび容量計画用に追加情報を提供
複雑なアプリケーションのデバッグ用の重要情報の取得
削除されたデータのリカバリ
論理障害のトラブルシューティングと解決に役立つ、ブラウザベースの簡素化を提供
LogMiner機能には次のものがあります。
アプリケーション・レベルで発生したエラーなど、データベースの論理的破損が発生した可能性のある時期を特定
トランザクション・レベルでのきめの細かいリカバリを実行するために必要な処置を決定
傾向分析を通じたパフォーマンス・チューニングおよび容量計画の提供
監査後処理の実行
|
関連項目: 『Oracle Databaseユーティリティ』 |
Hardware Assisted Resilient Data（HARD）Initiativeとは、データ破損がディスクに書き込まれないようにする、Oracleとハードウェア・ベンダー間のイニシアティブです。データ破損はごくまれですが、実際に発生した場合には、データベース、さらにはビジネスに壊滅的な影響を与える可能性があります。
HARD Initiativeの下、オラクル社は破損を早期に検出して破損データがディスクに書き込まれるのを防ぐことのできるオペレーティング・システムおよびストレージのコンポーネントを構築すべく、精選されたシステム・ベンダーおよびストレージ・ベンダーと協業しています。鍵となるアプローチは、ストレージ・サブシステムでOracleブロックの内容を検証するブロック・チェックです。
HARD準拠のストレージにあるデータ・ファイルとログ・ファイルが保護されます。また、ベンダー提供のインタフェースを使用して、ストレージでHARD検証機能を有効にする必要があります。Oracleによってストレージにデータが書き込まれると、ストレージ・システムでデータが検証されます。データが破損していると考えられる場合、エラーが発生し、書込みが拒否されるか、または許容され、ストレージによってエラーが内部ログ内に記録されます。
ストレージ・ベンダーは、一部またはすべてのチェックを選択して実装できます。また、各ベンダーの実装はそれぞれ異なり、制御インタフェースは様々な機能を持ちます。
|
関連項目: ベンダーと実装の最新情報については、http://www.oracle.com/technology/deploy/availability/htdocs/HARD.htmlのHARD Initiativeのページを参照してください。 |
Oracle Database 11g以前では、RMANで検出されたブロックの破損はV$DATABASE_BLOCK_CORRUPTIONで記録されていました。Oracle Database 11gでは、RMANなどのデータベースのコンポーネントとユーティリティで破損ブロックを検出でき、このビューで記録できます。Oracle Databaseは、（たとえば、ブロック・メディア・リカバリまたはデータ・ファイル・リカバリを使用して）破損ブロックが検出または修復されると、このビューを自動的に更新します。この利点は、ブロック破損の検出に要する時間が短縮されることです。
さらに、DB_ULTRA_SAFE初期化パラメータを使用して、データベースで適切なデータ保護ブロック・チェック・レベルを自動的に構成できます。パフォーマンスの影響は、アプリケーションや使用可能なシステム・リソースによって異なりますが、その影響は1%から10%まで様々です。
DB_ULTRA_SAFE初期化パラメータは次の操作を実行します。
DB_BLOCK_CHECKING、DB_BLOCK_CHECKSUMおよびDB_LOST_WRITE_PROTECTなど、関連する他の初期化パラメータの設定を制御します。
ASMで連続的なミラー書込みを実行する必要がある場合など、Oracle Databaseの他のデータ保護動作を制御します。
これらの機能により、データ破損をすぐに検出できるため、Oracleデータベースに重要な高可用性の利点が提供されます。
|
関連項目: これらのビューと初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。 |
オラクル社では、あらゆるタイプの計画外障害に対して停止時間を防止、許容および短縮するための高可用性ソリューションを提供しています。
計画外停止時間用の各種Oracle高可用性ソリューション、および各ソリューションで達成可能なリカバリ時間について、表2-1で説明します。この表は、2.1.1項〜2.1.14項で説明した機能を使用して、計画外停止時間の様々な原因に対処する方法を示しています。また、各Oracle高可用性アーキテクチャでのあらゆるタイプの計画外停止時間に対する達成可能なリカバリ時間の概要は、表4-4を参照してください。
表2-1 計画外停止時間の停止タイプとOracle高可用性ソリューション
| 停止範囲 | Oracleソリューション | 利点 |
|---|---|---|
|
サイトの障害 |
|
|
|
サイトの障害 |
|
|
|
サイトの障害 |
|
|
|
コンピュータ障害 |
Oracle Real Application ClustersおよびOracle Clusterware |
|
|
コンピュータ障害 |
|
|
|
コンピュータ障害 |
|
|
|
コンピュータ障害 |
|
|
|
ストレージ障害 |
|
|
|
ストレージ障害 |
|
|
|
ストレージ障害 |
|
|
|
ストレージ障害 |
|
|
|
データ破損 |
Hardware Assisted Resilient Data（HARD）Initiative |
|
|
データ破損 |
|
|
|
データ破損 |
|
|
|
データ破損 |
|
|
|
データ破損 |
|
|
|
人的エラー |
|
|
|
人的エラー |
|
|
|
人的エラー |
|
|
|
書込み欠落 |
Oracle Data Guard、Recovery Managerおよび
|
|
|
書込み欠落 |
Hardware Assisted Resilient Data（HARD）Initiative |
|
|
停止または低速化 |
Oracle DatabaseおよびOracle Enterprise Manager |
|
計画停止時間は、計画外停止時間と同様、業務に悪影響を及ぼします。これは、特に、複数のタイムゾーンのユーザーをサポートする必要がある、または顧客に24時間年中無休でインターネット・アクセスを提供する必要があるグローバル企業に当てはまります。
以前は、周期的なメンテナンスを実行する場合や、新しいデプロイメントに移行する場合に計画停止時間が必要になりました。パッチ適用またはシステムの再構成などの周期的なメンテナンスは、データベース、アプリケーション、オペレーティング・システム、ミドルウェアまたはネットワークの更新の際に必要となる場合があります。新規デプロイメントには、ハードウェア、データベース、アプリケーション、オペレーティング・システム、ミドルウェアまたはネットワークの主要アップグレードまたは新規導入などがあります。
オラクル社では、システム変更とデータベース変更、データ変更およびアプリケーション変更の計画停止時間を短縮またはゼロにするために、次の高可用性ソリューションを提供しています。
システム変更とデータベース変更については、「動的リソース・プロビジョニング」を参照
データ変更については、「オンライン再編成および再定義」を参照
アプリケーション変更については、「アプリケーションのオンライン・メンテナンスおよびオンライン・アップグレード」を参照
この項では、次のトピックに基づき動的リソース・プロビジョニングについて説明します。
オラクル社では、サービスを中断することなく、ハードウェアの需要に応えるための変更の採用が可能となるように、データベースの動的再構成のサポートを継続的に拡大しています。Oracle Databaseは、ハードウェアおよびデータベース構成への様々な変更に対して動的に対応します。
SMPサーバーへのプロセッサの追加およびSMPサーバーからの削除
Oracle RAC環境でのノードとインスタンスの追加および削除
自動共有メモリー管理を使用した、共有メモリーの割当ての動的な拡張と縮小、およびオンラインでのメモリーのチューニング
データベース・アクティビティに影響しない、自動ストレージ管理（ASM）を使用したオンラインによるデータベース・ディスクの追加および削除
データベース・アクティビティに影響しない、ASMを使用したオンラインによるストレージ・アレイの追加および削除
ASMを使用したデータベース・ストレージにまたがるI/Oロードの自動リバランス
ストレージ構成が変更するたびに自動的にデータベース・ストレージのリバランスを行う、ASMを使用したディスクの追加または削除時のオンラインによるデータ・ファイルの移動
セッション中にパラメータの値を変更する場合はSQL*PlusのALTER SESSION文を使用し、インスタンスの期間中にそのインスタンスのすべてのセッションでパラメータの値を変更する場合はALTER SYSTEM文を使用することにより、インスタンスを停止せずにほぼすべての初期化パラメータを変更
これらの機能により、エンタープライズ・グリッド・コンピューティングの基本要件であるシステム変更およびキャパシティ・オンデマンド・プロビジョニングがコストなしで実現されます。
Oracle Database 11gから、MEMORY_TARGETおよびMEMORY_MAX_TARGETという2つのメモリー管理初期化パラメータにより、システム・グローバル領域（SGA）、プログラム・グローバル領域（PGA）、およびOracle Databaseの実行に必要な他のメモリーを自動管理できます。
|
注意: MEMORY_MAX_TARGETは、MEMORY_TARGETの動的な最大値です。これらの初期化パラメータがデフォルト値（0）のままである場合、Oracle Databaseでは、メモリーは自動的にチューニングされません。1つのパラメータをゼロ以外の値に設定し、もう一方のパラメータを設定しない場合、Oracle Databaseでは両パラメータがゼロ以外の値に内部的に設定されます。 |
Oracle Databaseでは非集中型ポリシーを使用して、SGAおよびPGAの各サブコンポーネントのメモリーを解放して取得します。また、メモリーのグラニュルをあまり必要としないコンポーネントから、より必要とするコンポーネントに転送するようオペレーティング・システムに要求することにより、メモリーを自動的にチューニングします。メモリー転送の粒度は、現在の空きメモリーと、サービスに支障のない基本レベルを維持するためにオペレーティング・システムが必要とするメモリー量によって決まります。
|
注意: MEMORY_TARGETおよびMEMORY_MAX_TARGET初期化パラメータを使用する自動メモリー管理は、Linux、Windows、Solaris、HP-UXおよびAIXでサポートされます。サポートされるすべてのプラットフォームの詳細は、『Oracle Database概要』および『Oracle Database管理者ガイド』を参照してください。 |
ASMは、データ・ファイル、制御ファイルおよびログ・ファイルのレイアウトを自動化ならびに簡素化します。データベース・ファイルは、使用可能なすべてのディスクにまたがって自動的に分散されます。ディスクまたはストレージ・アレイの追加と削除など、ストレージ構成に変更があった場合に、データベース・ストレージのリバランスが行われます。ASMは、データベース・ファイルのミラー化を通じて冗長性を提供するとともに、使用可能なすべてのディスクにまたがってデータベース・ファイルを自動的にストライプ化することにより最適なパフォーマンスを提供します。
|
関連項目: ASMの詳細は、『Oracle Database概要』および『Oracle Databaseストレージ管理者ガイド』を参照してください。 |
オラクル社では、あらゆるタイプの計画メンテナンスに対して停止時間を防止、許容および短縮するための高可用性ソリューションを提供しています。計画停止時間用の各種Oracle高可用性ソリューション、および各ソリューションで達成可能な停止時間ならびに既知の考慮事項について、表2-2で説明します。どのような場合でも、ローリング・アップグレードを実行する前に広範囲なテストを行うことをお薦めします。
表2-2 計画停止時間用Oracle高可用性ソリューション
| メンテナンス・タイプ | 推奨されるOracleソリューション | ソリューションの説明 | 停止時間 |
|---|---|---|---|
|
オペレーティング・システムおよびハードウェアのアップグレード |
Oracle Real Application ClustersおよびOracle Clusterware |
|
停止時間ゼロ |
|
Oracle個別パッチ |
Oracle Real Application Clusters（Oracle RAC） |
|
停止時間ゼロ脚注1 |
|
デバッグ用オンライン・パッチと個別パッチ（アップグレードの範囲が少ない場合） |
オンライン・パッチの適用 |
|
停止時間ゼロ |
|
Oracle Clusterwareのアップグレードおよびパッチ |
Cluster Ready Services（CRS） |
|
停止時間ゼロ |
|
ASMのアップグレード |
|
|
停止時間ゼロ |
|
ストレージの移行脚注2 |
|
|
停止時間ゼロ |
|
ASMへの移行、またはOracle RACへの単一インスタンス・データベースの移行 |
|
|
数秒〜数分 |
|
パッチ・セットおよびデータベースのアップグレード |
SQL Applyとロジカル・スタンバイ・データベースを使用するOracle Data Guard |
|
数秒〜数分 |
|
WindowsとLinux間でのプラットフォームの移行 |
|
|
数秒〜数分 |
|
同じエンディアン形式のプラットフォーム間でのプラットフォームの移行 |
トランスポータブル表領域 |
|
数分〜数時間 |
|
異なるエンディアン形式のプラットフォーム間でのプラットフォームの移行 |
トランスポータブル表領域 |
|
数分〜数時間 |
|
アプリケーションのアップグレード |
アプリケーションのオンライン・メンテナンスおよびオンライン・アップグレード |
|
脚注1 ローリング・アップグレードの実行で適用できないパッチは、パッチ適用による可用性の影響が少ないOpatchユーティリティのMINIMIZE_DOWNTIMEオプションで適用できます。
脚注2 従来型のストレージから低コストのストレージへの移行などの例があります。
|
関連項目:
|
システムとハードウェアのアップグレード時の停止時間を回避するには、Oracle RACを使用するソリューションをお薦めします。
Oracle RACを使用してアップグレードを実行できない場合、Oracle Data Guardとフィジカル・スタンバイ・データベースを使用するソリューションをお薦めします。詳細は2.2.2.2項を参照してください。
Oracle RACソリューションの説明
次の手順を実行します。
アプリケーション・サービスを停止します。
停止すると、FANを使用している場合、ターゲット・インスタンスとの接続が切断され、暗黙的にリダイレクトされます。
IMMEDIATEオプションを指定してターゲット・インスタンスを停止します。
Oracle Clusterwareを停止して無効にします。
Oracle Clusterwareを無効にすると、自動起動しなくなります。
メンテナンスを実行します。
Oracle Clusterwareを有効にして、起動します。
この手順により、データベース・インスタンスが暗黙的に起動されます。
アプリケーション・サービスを起動します。
この手順により、FANを使用している場合、ターゲット・インスタンスへの接続が回復し、暗黙的にリダイレクトされます。
次のノードですべての手順を繰り返します。
追加の考慮事項
次の事項を検証します。
計画メンテナンスがオペレーティング・システムの観点からローリング形式で行うことができるかどうかを確認します。
データベースとクラスタウェアのバージョンが、新規システムおよびハードウェアの変更で動作保証されているかどうかを確認します。
|
関連項目: 使用するオペレーティング・システム別のOracle Real Application Clustersのインストレーション・ガイドを参照してください。 |
Oracle Data Guardとフィジカル・スタンバイ・データベースは、Oracle RACローリング・アップグレードを使用してアップグレードできないシステムとクラスタのアップグレードを実行する場合に推奨されるソリューションです。Oracle Data Guardは、ASM、Oracle RACおよび64ビット・システムへの移行、WindowsとLinux間での移行、あるいは同じプロセッサ・アーキテクチャのプラットフォームへの移行にも推奨されます。次に例を示します。
システムの制限によりOracle RACのローリング・アップグレードを使用してアップグレードできないシステム・アップグレードには、Oracle Data Guardを使用します。
ASMへの移行、クラスタ化されていない環境からOracle RACへの移行、同じエンディアン形式の別のプラットフォームへの移行、または同じプロセッサ・アーキテクチャの別のプラットフォームへの移行を行う場合、Oracle Data Guardを使用します。
通常、フィジカル・スタンバイ・データベースを最初にアップグレードしてから、フィジカル・スタンバイ・データベースに対してData Guardスイッチオーバーを次のように実行します。
システムをアップグレードするか、またはフィジカル・スタンバイ・データベース・システムをターゲット環境に変更します。
たとえば、ASMを使用して、スタンバイ・データベースを単一インスタンス・データベースからOracle RACデータベースに変換できます。プライマリ・データベースへの影響はありません。次に、スタンバイ・データベースを再起動し、これがターゲット環境に合っているかどうかを確認して、REDO Applyによるスタンバイ・データベースへのREDOデータの適用が終わるまで待機します。
Data Guardスイッチオーバーを実行します（数秒〜数分が最適）。
元のプライマリ・データベースを停止します（これでスタンバイ・データベースになる）。
アップグレードするか、元のプライマリ・データベースへのシステム変更を行います。
スタンバイ・データベースとしてアップグレードしたデータベースを再起動し、リカバリでデータベースを自動的に同期化します。
オプションで、Data Guardスイッチオーバーを実行して、スタンバイ・データベースをプライマリ・データベース・ロールに戻します。
追加の考慮事項
スイッチオーバーを高速化するには、スイッチオーバー操作の前に、スタンバイ・データベースでリアルタイム適用が使用され、できれば、データベースが必ず同期化されるように構成します。
Oracle RACのローリング・アップグレードまたはオンラインでパッチの適用ができない場合は、この方法を使用します。詳細は、『Oracle Data Guard概要および管理』を参照してください。
Oracle Databaseパッチ・セットの適用またはOracle Databaseのアップグレードを同時に行う場合、32ビットから64ビットへの変換は自動的に行われます。オペレーティング・システムのみをアップグレードする場合、サポート・ノート414043.1に記述されているアップグレード後の手順を追加で行う必要があります。アップグレードの詳細は『Oracle Databaseアップグレード・ガイド』を参照してください。
Oracleデータベースの個別パッチを適用する際に停止時間を回避するには、Oracle RACを使用します。Oracle RACを使用すれば、新規パッチの約90％は適用できます。Oracle RACを使用してパッチを適用できない場合、Oracle Data Guardとフィジカル・スタンバイ・データベースを使用します。詳細は2.2.2.2項を参照してください。
ソリューションの説明
通常、データベース・ソフトウェアへのOracle個別パッチは、ソフトウェアの問題に対する既知の修正を実装するため、または診断パッチを適用して問題に関する情報を収集するために適用します。パッチの適用は、スケジュール・メンテナンス停止の際に行うように計画します。
オラクル社では、opatchコマンドライン・ユーティリティを使用して、データベースの停止時間がゼロまたは最小限のOracle RACを使用したローリング・パッチのアップグレードを行う機能を提供しています。
Oracle RACによるローリング・アップグレードでは、計画停止の間、Oracle RACインストールのインスタンスを、1つを除いてすべて使用できます。その結果、計画停止に必要なアプリケーション停止時間に対する影響はさらに減少します。Oracleのopatchユーティリティを使用すると、インストール済のOracle RACの異なるインスタンスに対してパッチを連続的に適用できます。
追加の考慮事項
ローリング・アップグレードの実行は、ローリング・アップグレード用に認可されているパッチの場合のみ可能です。一般に、ローリング・アップグレードでインストール可能なパッチは次のとおりです。
データベースの内容（データ・ディクショナリなど）に影響を与えないパッチ
Oracle RACのノード間通信に関連しないパッチ
SQL*Plus、Oracleユーティリティ、開発ライブラリ、Oracle Netなどのクライアント側ツールに関連したパッチ
データ・ファイル・ヘッダー、制御ファイル、カーネル・モジュールの共通ヘッダー定義などの共有データベース・リソースを変更しないパッチ
Oracle RACを使用してパッチ・セットのローリング・アップグレードを実行しないでください。
|
関連項目: 使用するオペレーティング・システム別のOracle Real Application Clustersのインストレーション・ガイドを参照してください。 |
オンライン・パッチを使用できる場合、停止時間を回避するには、オンライン・パッチを適用するソリューションをお薦めします。
ソリューションの説明
オンライン・パッチは、インスタンスがオンラインのままで適用できる特殊な個別パッチです。
オラクル社では、opatchコマンドライン・ユーティリティを使用してOracleデータベースでオンライン・パッチ適用を実行できる機能を提供しています。
追加の考慮事項
オラクル社では、変更されるコードの範囲が少ない場合やコードがそれほど複雑ではない場合（診断パッチや不具合の修正が少ない場合など）、オンライン・パッチを提供します。
オラクル社では、パッチによってシステム・グローバル領域（SGA）の共有メモリー構造や他の重要な内部コード構造が変更されない場合、オンライン・パッチを提供します。
オンライン・パッチを適用すると、各Oracleプロセスではパッチの適用時にプログラム・グローバル領域（PGA）のメモリーを多く使用するため、システムのメモリー消費が増加します。オンライン・パッチを適用する前に、メモリー要件を考慮してください。各オンライン・パッチは一意のものであり、メモリー要件はパッチごとに異なります。通常、ベスト・プラクティスとして、最初にテスト・システムにパッチを適用します。また、テスト・システムに適用することで、本番システムへのオンライン・パッチの影響を評価し、追加するメモリー使用量を見積もることができます。
|
関連項目: オンライン・パッチの適用とOPatchの詳細は『Oracle Universal InstallerおよびOpatchユーザーズ・ガイド』、ローリング・アップグレードとローリング・パッチの概要については『Oracle Databaseアップグレード・ガイド』を参照してください。 |
Oracle Clusterwareをアップグレードする際の停止時間を回避するには、Cluster Ready Services（CRS）ソフトウェアを使用してOracle Clusterwareのローリング・アップグレードを実行するソリューションをお薦めします。
ソリューションの説明
Oracle Clusterwareへのアップグレードはすべて、ローリング方式で実行できます。
|
関連項目: 使用するオペレーティング・システム別のOracle Clusterwareのインストレーション・ガイド |
ASMをアップグレードするには、ローリング方式によるアップグレードの実行をお薦めします。
ソリューションの説明
Oracle Database 11g（およびこれ以降のリリース）でのアップグレードはすべて、ローリング方式で実行できます。
|
関連項目: 『Oracle Databaseストレージ管理者ガイド』 |
ストレージの移行を実行するには、ASMを使用するソリューションをお薦めします。
ソリューションの説明
ASMを使用して、すべてのディスクを1つのストレージ・アレイに追加した後、別のアレイからすべてのディスクを削除できます。ASMは、データベースが稼働したままの状態で、自動的にデータのリバランスを行い、新規ストレージに移行します。
追加の考慮事項
ソース・ストレージ・アレイを削除する前に、リバランスが完了したかどうか確認してください。
|
関連項目: 『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』のASMデータ移行の実行に関する章 |
パッチ・セットおよびデータベースのアップグレードを最小の停止時間で実行するには、SQL Applyを使用するOracle Data Guardのソリューションをお薦めします。このソリューションについては2.2.2.8.1項で説明します。ソース・データベースがSQL Applyでサポートされていないデータ型を使用している場合、拡張データ型サポート（EDS）を使用することで、対応する拡張データ型をさらにいくつか増やすことができます。
ソース・データベースが、SQL Applyのローリング・アップグレードでサポートされていないソフトウェア・バージョンを使用している場合（Oracle Databaseリリース10.1.0.3より前のリリース）、およびEDSを使用してもSQL Applyのデータ型の競合を十分に解決できない場合、Database Upgrade Assistant（DBUA）脚注2またはトランスポータブル表領域の使用を検討します。DBUAには、アップグレード・プロセスの手順を示すグラフィカル・ユーザー・インタフェース（GUI）・ユーティリティが備わっており、データベースのアップグレードの方法としては最も簡単で推奨できる方法です。ただし、DBUAでデータベースのアップグレードにかかる時間が定義されたメンテナンス・ウィンドウの期間に納まらない場合は、1時間未満でデータベース・アップグレードを実行するために、トランスポータブル表領域の使用を検討してください。
SQL Applyを使用できず、メンテナンス・ウィンドウで停止時間を1時間未満にする必要がある場合、およびアップグレードされるデータベースに単純なスキーマや、トランスポート・プロセスの一部として転送する必要のないデータ・ファイル（データ・ファイルが所定の場所で使用される場合など）が少ない場合には、トランスポータブル表領域を使用します。トランスポータブル表領域ソリューションについては2.2.2.8.2項で説明します。
最後に、Oracle Streamsは、データベース・アップグレードを実行する際の最も柔軟な方法と、追加のデータ型サポートを提供するソリューションです。このソリューションについては2.2.2.8.3項で説明します。
|
関連項目: 詳細と、ユーザーの構成に適したデータベース・アップグレード方法の選択に役立つ情報は、『Oracle Database高可用性ベスト・プラクティス』を参照してください。 |
次の手順を実行してSQL Applyを使用するData Guardを利用し、Oracleデータベースをアップグレードします。
ロジカル・スタンバイ・データベースを新規リリースにアップグレードして、変更を評価します。
SQL ApplyによってREDOデータがすべてロジカル・スタンバイ・データベースに適用されたかどうかを確認します。
アプリケーションを切断します。
Data Guardスイッチオーバーを実行します。
アプリケーションを新規プライマリ・データベースに再接続します。
元のプライマリ・データベースを停止します（これでロジカル・スタンバイ・データベースになる）。
新しいスタンバイ・データベースでデータベース・ソフトウェアのアップグレード手順を実行します。
スタンバイ・データベースを再起動し、リカバリが同期化されるようにします。
オプションとして、Data Guardスイッチオーバーを実行して元のデータベースに戻ります。
追加の考慮事項
SQL Applyによるローリング・アップグレードは、Oracle Databaseリリース10.1.0.3以上の場合のみサポートされます。詳細は、『Oracle Data Guard概要および管理』のSQL Applyを使用したOracle Databaseのアップグレードに関する章を参照してください。
SQL Applyにはいくつかのデータ型制限があります（制限のリストは、『Oracle Data Guard概念および管理』を参照）。データ型の制限がある場合は、拡張データ型サポート（EDS）の実装を検討してください。
EDSによりSQL Applyで、1つのデータベースから別のデータベースに、本来サポートされていないいくつかのデータ型を含む表への変更をレプリケートできます。Oracle Database 10gリリース2（10.2.0.4）パッチ・セット3から、SQL Applyでは、EDSの基礎となるロジカル・スタンバイ・データベースでトリガーを起動させる機能がサポートされています。EDSの概要は、次のWebサイトで入手可能なMAAホワイト・ペーパー「Extended Datatype Support」を参照してください。
http://www.oracle.com/technology/deploy/availability/pdf/maa_edtsoverview.pdf
本来SQL Applyではサポートされていないデータ型をサポートするためのEDSを使用する例は、サポート・ノート559353.1を参照してください。
Oracle RACによるローリング・アップグレードができず、データ型の制限がない場合は、Oracle Data Guardが最適なアプローチです。
|
関連項目: http://www.oracle.com/technology/deploy/availability/htdocs/maa.htmから入手可能なMAAホワイト・ペーパー「Rolling Database Upgrades Using Data Guard SQL Apply」 |
データ型の競合のためにData Guard SQL Applyを使用できず、テストの結果、DBUAでのアップグレードが稼働時間の要件を満たせないことがわかる場合、トランスポータブル表領域を使用したデータベースのアップグレードを検討してください。次の高度な手順では、トランスポータブル表領域機能を利用して、Oracleデータベースをアップグレードします。
ターゲット・システムにOracle Databaseソフトウェアをインストールし、ソース・データベースで最初の手順を実行し、トランスポート・プロセスの準備をします。
ソースおよびターゲット・データベースを準備します。
ソース・データベースから情報を収集します。
Database Configuration Assistant（DBCA）でターゲット・データベースを作成します。
データ・ポンプ使用のためと、トランスポートされる表領域を受け入れるために、ターゲット・データベースの準備をします。
トランスポートを実行します。
ユーザーを切断し、ソース・データベースへのアクセスを制限することで、ソース・データベースのトランスポートの準備をし、すべてのユーザー表領域をREAD ONLYにして、ソース・データベースから順序の開始値を取得します。
REDO Applyを停止し、スタンバイ・データベースを停止します。
ユーザー表領域をトランスポートします。
ターゲット・データベースが完全であり機能することを確認した上でバックアップします。
|
関連項目: http://www.oracle.com/technology/deploy/availability/htdocs/maa.htmから入手可能なMAAホワイト・ペーパー「Database Upgrade Using Transportable Tablespaces」 |
追加の考慮事項
トランスポータブル表領域機能は、単純なスキーマを持ち、トランスポート・プロセスの一部としてデータ・ファイルを転送する必要がない（データ・ファイルが所定の場所で使用される場合など）データベースに対して、1時間未満でデータベース・アップグレードを実行するためのオプションです。次のWebサイトにあるMAAホワイト・ペーパー「Database Upgrade using Transportable Tablespaces」を参照してください。
http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm
トランスポータブル表領域を使用すると、以前のリリースのソフトウェアが稼働するデータベースから、現行リリースのソフトウェアが稼働する空のターゲット・データベースに、すべてのユーザー表領域を移動することにより、データベースのアップグレード時間が短縮されます。トランスポータブル表領域を持つ表領域データ・ファイルは、データ・ファイルをターゲット・データベースにコピーし、オブジェクト・メタデータをターゲット・データベースにインポートすることで、データベースに接続されます。
Streamsは機能面でData GuardのSQL Applyと似ていますが、SQL Applyでサポートされないデータ型がデータベースに含まれる場合に対応する柔軟性があります。SQL Applyと同様に、Streamsでは拡張データ型サポート（EDS）を利用して、本来サポートされていないいくつかのデータ型を含む表に対する変更を、1つのデータベースから別のデータベースにレプリケートすることができます。
次の高度な手順では、データベース・アップグレードの実行方法について説明します。
アップグレード・プロセスを開始する前に、ユーザー定義型を持つデータベースでデータベース・アップグレードを実行する方法について『Oracle Streams概要および管理』を参照してください。
複製データベースを作成します。（最新のフィジカル・スタンバイ・データベースとしてレプリカを開始することが理想的です。）
データベースをアクティブにして、後続バージョンにアップグレードします。
Oracle Streamsレプリケーションを有効にします。
レプリカのアップグレード中に、ソース・データベースは先行して引き続き稼働しています。レプリカが遅れを取り戻したら、スイッチオーバーを実行します。
|
関連項目: Oracle Streamsによるデータベースのオンライン・アップグレードの詳細は『Oracle Streams概要および管理』を参照してください。 |
同じエンディアン形式のプラットフォーム間でプラットフォームの移行を実行する場合、次のアプローチを検討します。
LinuxおよびWindowsプラットフォーム間で移行を実行するには、Oracle Data Guard（フィジカル・スタンバイ・データベース）のソリューションをお薦めします。このソリューションについては、2.2.2.2項で説明します。
クロス・プラットフォームのフィジカル・スタンバイ・データベースが移行対象のプラットフォームの組合せに使用できない場合、トランスポータブル・データベースを使用します。このソリューションについては、2.2.2.9.1項「トランスポータブル・データベースを使用したプラットフォーム移行のソリューションの説明」で説明します。
トランスポータブル・データベースで移行を迅速に実行できない場合、Oracle Streamsを使用します。このソリューションについては、2.2.2.9.2項「Oracle Streamsを使用したプラットフォーム移行のソリューションの説明」で説明します。
クロス・プラットフォームのフィジカル・スタンバイ・データベースまたはロジカル・スタンバイ・データベースが、該当するプラットフォームの組合せに対してサポートされていない場合のみ、プラットフォーム移行にトランスポータブル・データベースを使用してください。脚注3
たとえば、Windows x86-64からLinux x86-64に移動する場合、トランスポータブル・データベースではなく、クロス・プラットフォームのスタンバイ・データベースを使用するのが適しています。停止時間が少なく（スイッチオーバーに要する時間のみ）、新しいプラットフォームでスタンバイ・データベースを一定期間実行して、すべてが計画どおりに機能するかどうかを確認できます。
高度な手順（ターゲット・システムの変換を含む）は次のとおりです。
読取り専用モードでソース・データベースを設定
RMANのCONVERT DATABASEコマンドを実行
ターゲット・システムにファイルを移動
RMAN生成スクリプトを実行して、UNDOが含まれるデータ・ファイルをターゲット・プラットフォームの形式に変換
RMAN生成スクリプトを実行して、移行を完了
トランスポータブル・データベースを使用する場合、プラットフォームの移行に必要な停止時間は、次の操作に要する時間によって異なります。
読取り専用モードでソース・データベースを設定
UNDOが含まれるデータ・ファイルを新しいプラットフォームの形式に変換（UNDOが含まれていないデータ・ファイルは変換不要）
ソース・システムからターゲット・システムにすべてのデータ・ファイルを転送
ストレージ・インフラストラクチャを使用すると、物理的にファイルを移動しなくてもターゲット・システムでデータ・ファイルを使用できるため、この時間を大幅に短縮できます。
SQLスクリプトutlirp.sqlおよびutlrp.sqlを使用して、すべてのPL/SQLを無効化および再コンパイル
|
関連項目: http://www.oracle.com/technology/deploy/availability/htdocs/maa.htmから入手可能なホワイト・ペーパー「Platform Migration using Transportable Database」 |
Oracle Streamsは、複数のマスターでの更新を可能にし、別のデータベース・リリースのある異種プラットフォームに対するサポートを提供します。したがって、Oracle Streamsは、データベースのアップグレードおよびプラットフォームの移行に最も高速なアプローチを提供することになります。
Oracle Streamsには、アドバンスト・キューおよびオブジェクト・タイプなど、データ型の制限があります。しかし、ソース・データベースにシャドウ表を作成することで、制限に対処できる場合があります。サポートされたデータ型を指定した表に変更を取得して伝播するために、サポートされていないデータ型を指定した表にトリガーを作成できます。この変更は、Streamsを通じてターゲット・データベースにレプリケートされます。ターゲット・データベースの元の表に変更を適用するために、適用メカニズムをカスタマイズできます。
Oracle Streamsは、より柔軟性の高いアーキテクチャとなるように設計されているため、実装する場合には、テスト、設定および構成に管理投資を追加する必要があります。
次の高度な手順では、Oracle Streamsを使用したプラットフォーム移行の実行方法について説明します。
ソース・データベースでStreams環境を設定します。
新しいターゲット・バージョンを使用して、またはターゲット・プラットフォームでレプリカ・データベース（ターゲット・データベース）を作成します。
ターゲット・データベースでStreams環境を設定します。
Streamsを使用すると、ソース・データベースに加えられた変更をすべてターゲット・データベースに伝播して、ターゲット・データベースとソース・データベースを完全に同期化することができます。
ユーザーをターゲット・データベースに接続して、ソース・データベースを停止します。
Streams構成を削除します。
|
関連項目: 『Oracle Streams概要および管理』 |
異なるエンディアン形式のプラットフォームでプラットフォーム移行を実行する場合、次のアプローチを検討します。
異なるエンディアン形式のプラットフォーム間でプラットフォーム移行を実行するには、トランスポータブル表領域のソリューションをお薦めします。このソリューションでは、停止時間が大幅に短縮されます。詳細は「トランスポータブル表領域のソリューションの説明」を参照してください。
Oracle Data Pumpは、すべてのアプローチの中で最も単純な方法です。Oracle Data Pumpの使用方法の詳細は『Oracle Databaseユーティリティ』を参照してください。
計画停止時間が数秒の可能性がある場合、2.2.2.9.2項「Oracle Streamsを使用したプラットフォーム移行のソリューションの説明」で説明するようにOracle Streamsの使用を検討してください。
トランスポータブル表領域のソリューションの説明
トランスポータブル表領域によって、別のエンディアン形式を使用する新しいプラットフォームにデータベースを移行するには、次の高度な手順が必要です。
ターゲット・プラットフォームで、新しい空のデータベースを作成します。
トランスポート操作に必要なオブジェクトを、ソース・データベースからターゲット・データベースにインポートします。
すべてのユーザー表領域のトランスポータブルなメタデータをソース・データベースからエクスポートします。
ユーザー表領域のデータ・ファイルをターゲット・システムに転送します。
RMANを使用して、データ・ファイルをターゲット・システムのエンディアン形式に変換します。
すべてのユーザー表領域のトランスポータブルなメタデータをターゲット・データベースにインポートします。
残りの（トランスポート操作で移動されなかった）データベース・オブジェクトとメタデータをソース・データベースからターゲット・データベースにインポートします。
ターゲット・データベースが移行時に新しい場所（新しいデータ・センターなど）に移動する場合は、ターゲット・データベースと共存している最初のプライマリ・データベースからフィジカル・スタンバイ・データベースを作成します。Data Guardスイッチオーバー後、ファイル転送時間が停止時間の一部となることなく、表領域をソースからターゲットにトランスポートします。
追加の考慮事項
トランスポータブル表領域には、キャラクタ・セット、不透明型およびシステム表領域オブジェクトに関して制限があります。前述の各ソリューションと異なり、手順は自動化されません。
次の事項がすべて当てはまる場合、トランスポータブル表領域を使用してプラットフォーム移行を実行します。
ソース・プラットフォームとターゲット・プラットフォームのエンディアン形式が異なる。
完全なデータ・ポンプ・エクスポートおよびインポートの実行に必要な時間がメンテナンス・ウィンドウの期間に納まらない。
|
関連項目: http://www.oracle.com/technology/deploy/availability/htdocs/maa.htmから入手可能なホワイト・ペーパー「Oracle Database 10g Release 2 Best Practices: Platform Migration using Transportable Tablespaces」 |
可用性および管理性を強化する1つの方法として、データの再編成操作中、データベースへの通常のアクセス権をユーザーに与えます。Oracle Databaseのオンライン再編成および再定義機能により、管理者は、データベースへの通常のアクセス権をユーザーに与えたまま、表の物理属性を変更したり、データおよび表構造の両方を変換したりするなど多くの柔軟性が得られます。この機能によって、データの可用性、問合せのパフォーマンス、レスポンス時間およびディスク領域の使用率が向上します。これらは、すべてミッションクリティカルな環境において重要で、アプリケーションのアップグレード・プロセスをより簡単、安全かつ高速なものにします。
このオンライン・アーキテクチャには次のような利点があります。
オンラインの表編成および再定義:
表の物理属性をオンラインで変更します（新しい場所への表の移動、表のパーティショニング、1つの構成（ヒープ構成など）から別の構成（索引構成など）への表の変換など）。
名前、型、サイズなどの多くの論理属性を変更します。列を追加、削除またはマージできます。ただし、表の主キーは変更できません。
オンライン索引操作:
索引をオンラインで作成し、それらを同時に分析します。論理ROWIDの物理的推測コンポーネント（索引構成表の2次索引およびマッピング表で使用）のオンライン修復も使用できます。
索引構成表および2次索引をオンラインで再編成して、再編成のメンテナンス・ウィンドウを排除できます。2次索引は、ブロック・ヒント（物理的推測）の効率的な使用をサポートします。索引編成表で2次索引に格納される論理ROWIDの無効な物理的推測のオンライン修復も実行できます。
2次索引を再構築せずに索引構成表または表パーティションを再編成できるため、再編成のメンテナンス期間が短縮されます。
パーティション化された表をオンラインで移動できます。
アドバンスト・キュー、クラスタ表、マテリアライズド・ビューおよび抽象データ型（オブジェクト）をオンラインで再編成できます。
デフォルト値による高速なADD COLUMN操作（すべての行をデフォルト値に更新する必要はありません）。
不可視の索引によって、アプリケーションの移行とテストの実行が高速化されます。
明示的なヒントで移行の速度を上げ、終了したらヒントを削除します。
新しく作成された索引の早まった使用を防止します。
必要に応じて、索引を見えるようにしてDROP INDEXの影響をテストするため、索引の再構築は必要ありません。
DMLを中断せずに、索引をオンラインで作成します（DMLの排他ロックは不要です）。
オンライン再定義が論理的にオブジェクトに影響を与えない場合（列が表に追加される場合やプロシージャがパッケージに追加される場合など）、依存オブジェクトの再コンパイルは行いません。
オンラインで表のDDL操作を簡単にできます（中断ではなく、アクティブなDML操作を待つオプションがあります）。
マテリアライズド・ビューやマテリアライズド・ビュー・ログがある表の再定義をサポートします。
表の物理属性を変更したり、データと表構造の両方を変換したりする機能は、Oracle8i以降で利用できます。表2-3は、データ再編成の機能を総合的に表した表です。
表2-3 リリース別の新しいデータ再編成の機能
| アクション | Oracle 9i | Oracle Database 10gリリース1 | Oracle Database 10gリリース2 | Oracle Database 11g |
|---|---|---|---|---|
|
パッケージ |
表記憶域パラメータの変更 異なる表領域への表の移動 パラレル問合せのサポートの追加 パーティション化サポートの追加または削除 断片化を回避するための表の再作成 表から索引構成表または索引構成表から表への変更 列の追加または削除 関数を使用した列の変換 |
権限、制約およびトリガーのクローニング LONGからLOBへの変換一意キーを使用した再編成 表の順序の基準となる列の指定 |
単一のパーティションの再編成 アドバンスト・キューおよびクラスタ表 ADTを含んだ表 統計の保存およびクローニング チェック制約およびNOT NULL制約のクローニング ネストした表の依存オブジェクトのコピー |
マテリアライズド・ビュー・ログまたはマテリアライズド・ビューがある表 再定義が論理的にオブジェクトに影響を与えない場合、依存オブジェクトの再コンパイルは行われません。 |
|
未使用領域の再利用 |
適用なし |
次の文で ALTER TABLEALTER INDEXALTER MATERIALIZED VIEWALTER MATERIALIZED VIEW LOG |
適用なし |
適用なし |
|
索引のオンライン作成 |
|
適用なし |
適用なし |
DMLロックのない索引のオンライン作成により、ワークロードに依存することなく透過的に作成可能 |
|
索引のオンライン結合 |
|
適用なし |
適用なし |
適用なし |
|
索引構成表のオンライン移動 |
|
適用なし |
適用なし |
適用なし |
|
関連項目: 『Oracle Database管理者ガイド』 |
トランスポータブル・テクノロジでは、トランスポータブル・データベースとトランスポータブル表領域が提供されます。
トランスポータブル・データベースは、データベース全体（ユーザー・データとOracleディクショナリ）を同じエンディアン形式の新しいプラットフォームに移動する場合に使用されます。トランスポータブル・データベースでは、すべてのユーザー・データをソース・データベースからアンロードしてターゲット・データベースにロードする時間のかかる方法を使用せずに、新しいプラットフォームに最小限の停止時間で移行できます。
トランスポータブル表領域は、あるデータベースのサブセットを別のデータベースに移動します。エンディアン形式が異なるプラットフォーム間でも可能です。
トランスポータブル表領域のクロス・プラットフォーム機能を使用すると、データベース内のすべてのユーザー・データを、異なるエンディアン形式の新しいプラットフォームに移行できます。この方法でトランスポータブル表領域を使用すれば、すべてのユーザー・データをソース・データベースからアンロードしてターゲット・データベースにロードする時間のかかる方法を使用せずに、新しいプラットフォームに最小限の停止時間で移行できます。
トランスポータブル表領域を使用すれば、データベースには単純なスキーマがあり、トランスポート・プロセス中にデータ・ファイルをコピーする必要がない場合（データ・ファイルが所定の場所で使用されている場合など）、データベースのアップグレードのための停止時間を短縮できます。
|
関連項目: 別のデータベースに表領域を移動またはコピーする方法の詳細（プラットフォーム間の表領域のトランスポートの詳細を含む）は『Oracle Database管理者ガイド』を参照してください。 |
次の項では、アプリケーションのデータベース・オブジェクトの変更に必要なアプリケーションの停止時間を大幅に短縮する（またはゼロにする）ことができる機能について説明します。
高速ローリング・アップグレードにOracle Streamsを使用することを検討してください。ただし、Oracle Streamsではデータベースの停止時間がほとんどないか、またはゼロでアップグレードできますが、このソリューションを構成するには、運用面での投資がある程度必要になることに注意してください。詳細は、2.1.4項「Oracle Streams」および『Oracle Streams概要および管理』を参照してください。
データ定義言語（DDL）コマンドには、内部構造で排他ロックが必要です。DDLコマンドが発行されると、これらのロックは使用できず、DDLが何秒か後に成功する場合もありますが、文がすぐに失敗します。WAITオプション（新しいデフォルト）でDDLを指定すると、この問題が解決されます。待機時間をインスタンス全体（初期化パラメータ・ファイル）で指定し、セッション・レベルで待機時間を変更します。
WAITオプションでDDLコマンドを指定すると、すぐにエラーが発生するのではなく、コマンドが成功するまでの猶予期間を定義する柔軟性が得られるため、このようなエラーに対処するアプリケーション・ロジックが追加で必要になります。
|
関連項目: 『Oracle Database管理者ガイド』 |
状態（ENABLEおよびDISABLE）と順序付け（FOLLOWS）はトリガーの起動を制御するためのトリガーです。このような状態が追加されたことで、トリガーの管理制御が向上しています。CREATE TRIGGER文を無効な状態で使用すれば、有効にする前にコンパイルが成功したかどうかを検証できます。また、トリガーの順序をFOLLOWS句で制御できます。
|
関連項目: 『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』 |
列のデフォルト値は、NOT NULLとして指定された列のデータ・ディクショナリで管理されます。
DEFAULT値とNOT NULL制約を指定して新しい列を追加する場合、デフォルト値を既存のすべてのレコードに格納する必要がなくなります。この拡張は、既存のデータ量に関係なく何秒かでスキーマ変更を行えるだけでなく、領域を消費することもありません。
|
関連項目: 『Oracle Database管理者ガイド』 |
Oracle Database 11g以前のリリースでは、メタデータはオブジェクト全体の粒度でオブジェクト間の相互依存を記録します。たとえば、PL/SQLの単位PはPL/SQLの単位Qに依存するか、そのビューVは表Tに依存します。このような場合、論理的な要件がなければ、依存オブジェクトは場合によって無効になっていました。たとえば、ビューVが表Tの列C1、C2およびC3にのみ依存し、新しい列C99が追加される場合、ビューVの有効性は論理的に影響を受けません。それにもかかわらず、以前のリリースでは、Vは列C99が加えられたことによって無効になっていました。
Oracle Database 11gから、依存メタデータはきめ細かな粒度レベルで記録されるため、C99が追加されたことでビューVが無効になることはありません。同様に、プロシージャPがパッケージPKGの要素E1およびE2にのみ依存して、要素E99がPKGに追加される場合も、プロシージャPは無効になりません。（Oracle Database 10gでは、PKGに要素E99が加えられると、プロシージャPは無効になります。）
依存されるオブジェクトの変更に対して依存オブジェクトが必然的に無効になることが少なくなったことで、アプリケーションの可用性が向上します。この利点は、開発環境において、および稼働中のアプリケーションを解析またはアップグレードする場合に効果があります。Oracle Databaseのパッチ・セットを適用する場合にこの利点が得られます。これは、互換性を保つためにスキーマ・オブジェクトの変更が必要になり、必然的な無効化が行われないためです。
|
関連項目: 『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』 |
不可視の索引は、索引を使用できなくするか、または索引を削除する場合の代替方法です。不可視の索引はDML操作に対して維持されますが、ヒントで索引を明示的に指定しないかぎり、オプティマイザで使用されません。
アプリケーション全体をオフラインにできなくても、通常、アプリケーションを変更する必要があります。不可視の索引を使用すると、アプリケーション全体に影響を与えることなく、アプリケーションの特定の操作やモジュールに対して一時的な索引構造を利用できます。さらに、不可視の索引を使用して、索引をすぐに削除せずに削除のテストを行うことができるため、本番環境でテスト用の猶予期間が有効になります。
|
関連項目: 『Oracle Database管理者ガイド』 |
グリッド・コンピューティングとスタンバイ・データベース機能を使用すると、既存のシステム・インフラストラクチャを利用して拡張することができます。プライマリ・データベースの場合、すべてのハードウェア・リソースがパフォーマンスとスケーラビリティに利用されます。セカンダリまたは障害時リカバリ・システムの場合、システム・リソースとデータベース・リソースをActive Data Guardオプションとともに、スタンバイ・データベース・ロールで本番目的に使用できます。Oracle Database 11gでは、Oracle Data GuardはIT操作とアプリケーション・ビジネスにとって不可欠な要素になります。
この項の内容は次のとおりです。
グリッド・コンピューティングとは、あらゆる企業のコンピューティング・ニーズに応えるため、多数のサーバーおよびストレージを柔軟性のあるオンデマンド・コンピューティング・リソース内に効果的にプールするコンピューティング・アーキテクチャです。
Oracle Databaseには、パフォーマンス、スケーラビリティ、セキュリティ、管理性、機能性またはシステム可用性を犠牲にせずに、コスト面におけるグリッド・エンタープライズ・コンピューティングの利点が取り込まれています。
データベース・サーバーとストレージ・グリッドを使用すると、スタンバイ・データベースおよびテスト・ハブを構築して、システム・リソースのプールを利用できます。システム・リソースは、様々な優先度に応じて動的に割り当てたり、割当てを解除したりすることができます。たとえば、本番データベースがスタンバイ・ハブのいずれかのスタンバイ・データベースにフェイルオーバーした場合、テスト・リソースが一時的に不足している間、そのスタンバイ・データベースがより多くのシステム・リソースとストレージ・リソースを取得します。グリッド・テクノロジでは、ビジネス要件を犠牲にすることなく、高レベルの使用率と低TCOを実現できます。
図2-6に、グリッド・エンタープライズ・コンピューティング環境内のデータベース・サーバー・グリッドおよびデータベース・ストレージ・グリッドを示します。
低コストのおよび信頼性のあるブレード・サーバーの可用性、小規模のマルチ・プロセッサ・サーバーおよびLinuxなどの安価なオープン・ソース・オペレーティング・システムによって、可用性、スケーラビリティ、柔軟性および管理性が非常に高いデータベース・サーバー・グリッドの構築が可能になりました。
Oracle RACは、複数の低コストのサーバーにまたがりながら、アプリケーション上には単一で一元的なデータベース・システムとして表示される単一のデータベースを提供することによって、データベース・サーバー・グリッドを有効にするテクノロジです。Oracle RACによって、グリッド内の動的プロビジョニング・リソースおよびサービスに柔軟性が与えられ、コンピューティング・ニーズの変化に対応し、容量への需要増加に合せてグリッドにシステムを追加できます。さらに、Oracle RACは、データベースを実行している残りのシステムのいずれかで、障害が発生したノードの処理を自動的にリカバリし、クライアントの再接続を行い、障害が発生したシステムの影響を受けている負荷の再分散をすることによって、システム障害から保護します。
低コストのATAディスクベース・ストレージ・アレイおよびストレージ・ネットワークの可用性により、Oracle Databaseでデータベース・ストレージ・グリッドを非常に低コストで使用できるようになりました。データベース管理者は、ASMインタフェースを使用して、ASMがすべてのサーバーおよびストレージ・プラットフォームにまたがって管理するデータベース・ストレージ・グリッド内のディスクを指定します。ASMは、ディスク領域をパーティション化し、ストレージ・アレイ全体でデータ記憶域を均一に分散します。さらに、ストレージ・アレイがデータベース・ストレージ・グリッドに追加または削除される際、ASMは自動的にデータ記憶域を再分散します。
Oracle Database 11g以降では、スタンバイ・データベースは、障害時リカバリを提供する他、動的なITおよびアプリケーション要件に使用できます。Oracle Data GuardのActive Data Guardオプションを使用すると、障害時リカバリ・ソリューションを提供する以外に、通常操作時に他の有用な作業にフィジカル・スタンバイ・データベースを使用できます。
次の項では、他のビジネス目的でフィジカル・スタンバイ・データベースを利用できるOracle Data Guardの機能について説明します。
REDO Apply（フィジカル・スタンバイ・データベース）は、相対的に簡単なことと、高パフォーマンスおよび高度なデータ保護のために、障害時リカバリの一般的なソリューションになっています。Oracle Database 11g以降では、REDO Applyがアクティブなときに、フィジカル・スタンバイ・データベースを読取り専用アクセス用に開くことができます。したがって、Active Data Guardを使用すれば、データ保護を犠牲にしたり、フェイルオーバーが必要な場合のリカバリ時間を延長したりせずに、最新のフィジカル・スタンバイ・データベースに対して問合せやレポート作成を実行できます。そのため、スタンバイ・ロールでもすべてのフィジカル・スタンバイ・データベースで本番使用をサポートできます。
Active Data Guardオプションを有効にするには、読取り専用モードでデータベースを開き、ALTER DATABASE RECOVER MANAGED STANDBY文を発行します。プライマリ・データベースとフィジカル・スタンバイ・データベースの両方で、COMPATIBLEパラメータを11.0.0に設定する必要があります。この機能は、アプリケーションに対して完全に透過的に使用されます。
Oracle Active Data Guardオプションは、次の理由から最高の高可用性ソリューションを提供します。
プライマリ・データベースとスタンバイ・データベースでOracle RACをサポートします。
Active Data Guardは、単一インスタンスおよびOracle RACのフィジカル・スタンバイ・データベースの両方で機能します。REDO Applyは1つのOracle RACインスタンスでのみ実行できますが、他のすべてのインスタンスは読取り専用モードで実行できます。
プライマリ・データベースの最新状態にきわめて近い一貫した結果を、トランザクションにより返します。
遅延設定や適用頻度に応じて、スタンバイ・データベースをプライマリ・データベースよりも何秒か遅らせることができます。問合せは、常にトランザクションでは一貫しており、そのときの最後にコミットしたトランザクションの一貫したビューを示します。
スタンバイ・データベースが読取り専用で開いているときに、プライマリ・データベースで生成されたREDOがスタンバイ・データベースにすでに適用され、スタンバイ・データベースがプライマリ・データベース・ロールをすぐに引き継ぐことができるため、高速なスイッチオーバーまたはフェイルオーバーが可能です。
プライマリ・データベースに障害が発生した場合、ファスト・スタート・フェイルオーバーを使用して、自動ファスト・フェイルオーバーが可能になります。
|
注意: Active Data Guardが有効な実行中のフィジカル・スタンバイ・データベースをトランザクションが変更しようとすると、そのトランザクションはエラーで失敗します。 |
|
関連項目: Active Data Guardの使用の詳細は『Oracle Data Guard概要および管理』を参照してください。 |
Oracle Database 11g以降では、フィジカル・スタンバイ・データベース（Active Data Guardオプションを使用）とロジカル・スタンバイ・データベースを使用してリーダー・ファームをデプロイできます。このような構成の例を図2-7に示します。この図は、プライマリ・データベースに障害が発生した場合、Data Guardのファスト・スタート・フェイルオーバーを使用してフェイルオーバーが自動的に行われることを示しています。ファスト・スタート・フェイルオーバーが行われると、リーダー・ファームのすべてのスタンバイ・データベースは、新しいプライマリ・データベースを自動的に認識することに注意してください。
Data Guard構成では複数のスタンバイ・データベースをサポートできるため、ユーザーはこの機能を使用して、基本的なシステムおよびストレージ・アーキテクチャのサポート可能範囲を超えて、最も要求の厳しいWebアプリケーションの読取りパフォーマンスを向上できます。これにより、I/Oが駆動要因となるグリッド・アーキテクチャを使用して拡張を行う比較的低コストの方法が可能になります。
この概念は単純です。つまり、1つのプライマリ・データベースが読取り/書込みのトランザクションをサポートし、複数のスタンバイ・データベースがWebユーザーに読取り専用アクセスを提供します。このようなアプローチでは、スタンバイ・データベースが追加されるにつれて、読取りパフォーマンスが直線的に拡張されます。また、1つのスタンバイ・データベースに影響を及ぼす問題が構成内の他のスタンバイ・データベースから分離されるため、フォルトを孤立させる効果的な方法でもあります。
フィジカル・スタンバイ・データベースのリーダー・ファームを作成する利点には次のようなものがあります。
フォルトの孤立化
フィジカル・スタンバイ・データベースとREDO Applyによる高パフォーマンス
REDO Applyを使用した、DDLとデータ型のシームレス・サポート
プライマリ・データベースの変更を含めて、すべてのリーダー・データベースを最新の状態に維持
データ損失をゼロまたは最小に抑えた、自動フェイルオーバー機能
グリッド・コントロールによる一元的な構成としての管理
1つのライター・データベースとn個のリーダー・データベースを使用した拡張
ローリング・アップグレード機能
図2-7は、Oracle Data Guard、フィジカル・スタンバイ・データベースおよびActive Data Guardを使用して、ビジネスの迅速な成長に必要な柔軟性を提供し、その一方で障害時リカバリも提供する適切な使用例を示しています。この構成では、プライマリ・データベースはREDOデータを複数のスタンバイ・データベースに転送し、そのうちの1つは、データ損失をゼロまたは最小に抑えた自動フェイルオーバーを行うファスト・スタート・フェイルオーバー用に有効化されています。
図2-7のData Guard構成で、ファスト・スタート・フェイルオーバーがトリガーされるとします。
自動フェイルオーバーは目的のスタンバイ・データベースに対して行われます。
すべてのスタンバイ・データベースは新しいプライマリ・データベースからデータを受け入れます。
スイッチオーバーを適宜実行して、すべてのデータベースを元のロールに戻すことができます。
複雑な環境では、構成の変更、システムのアップグレードおよび新しいアプリケーションのロールアウトの調整が要求されます。Oracle Database 11gの管理性は、高可用性アーキテクチャにおける操作の自動化と簡素化を大幅に改善し、Oracleデータベースによる自己管理を見据えた重要な機能となっています。
この項の内容は次のとおりです。
Oracle Databaseには、データベースが自己学習し、この情報を使用してワークロードの変動に対応したり、潜在的な問題を自動的に修正したりすることができる高度な自己管理インフラストラクチャがあります。自己管理インフラストラクチャには次のようなものがあります。
自動ワークロード・リポジトリ
自動ワークロード・リポジトリ（AWR）は、問題の検出やセルフチューニングのためにOracle Databaseが使用するパフォーマンス統計を含む組込みリポジトリです。Oracle Databaseでは重要な統計とワークロード情報のスナップショットを定期的に作成し、AWRに格納します。スナップショットに含まれるデータは、自動データベース診断モニター（ADDM）で分析されます。AWRの詳細は『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。
自動メンテナンス・タスク
AWRに格納された情報を分析することにより、データベースは日常的なメンテナンス・タスクを実行する必要があるかどうかを確認できます。自動メンテナンス・タスク・インフラストラクチャ（AutoTaskと呼ばれる）を使用すると、Oracle Databaseはこのような操作を自動的にスケジュール設定することができます。AutoTaskでは、メンテナンス期間と呼ばれるOracle Scheduler期間のセットで自動メンテナンス・タスクを実行するようにスケジュール設定します。メンテナンス期間は、Oracle Scheduler期間グループMAINTENANCE_WINDOW_GROUPのメンバーである期間です。詳細は、『Oracle Database管理者ガイド』および『Oracle Database 2日でデータベース管理者』を参照してください。
フォルト診断インフラストラクチャ
Oracle Databaseには、問題の防止、検出、診断および解決を行う高度なフォルト診断インフラストラクチャがあります。対象となる問題は、データベース・コードの不具合、メタデータの破損およびユーザー・データの破損から生じる重要なエラーです。次のような機能があります。
自動診断リポジトリ（ADR）は、トレース、アラート・ログ、状態モニターのレポートといったデータベース診断データ用のファイルベースのリポジトリです。複数のインスタンスや製品にまたがる一元化されたディレクトリ構造を持っています。
データベース管理者が、重大なエラーに関連するすべての診断データ（トレース、状態チェック・レポート、SQLテスト・ケースなど）を自動で簡単に収集し、そのデータをOracleサポートへの転送に適したZIPファイルにまとめるために使用できるインシデント・パッケージ・サービス。
これらのコンポーネントの詳細は『Oracle Database管理者ガイド』を参照してください。
問題が自動的に解決されず、管理者に通知する必要がある場合（領域不足など）、Oracle Databaseはサーバー生成アラートを提供します。Oracle Databaseは自らを監視し、アラートを送信して問題をユーザーに通知し、報告された問題の解決方法に関する提案を行います。これにより、問題が素早く解決され、潜在的な障害の防止に役立ちます。
Oracle Databaseには、データベースの様々なサブシステムに対する複数のアドバイザがあり、対応するサブコンポーネントの操作をさらに最適化できる方法を自動的に決定します。たとえば、SQLチューニング・アドバイザとSQLアクセス・アドバイザは、SQL文をより速く実行するための提案を行います。メモリー・アドバイザは、試行錯誤による方法を使用せず、様々なメモリー・コンポーネントのサイズ調整に役立ちます。セグメント・アドバイザは、領域関連の問題（消費済領域の再利用の提案や成長傾向の分析など）に対処し、UNDOアドバイザはUNDO表領域のサイズ設定を正しく行います。アドバイザの使用の詳細は『Oracle Database 2日でデータベース管理者』を参照してください。
Oracle Database 11gでは、データベースやSQLの変更による影響を分析できるように、変更前後のワークロードの自動取得とリプレイ機能が導入されています。
データベース・リプレイ機能では、本番システムの実際のデータベース・ワークロードを取得して、それをテスト・システムでリプレイすることにより、実際のテストを実行できます。また、潜在的な問題（エラーの発生やパフォーマンスの分岐など）やその問題を修正する推奨方法を示す分析とレポート作成も提供されます。
SQLパフォーマンスの低下は、データベースのアップグレード、初期化パラメータの変更、および索引の追加や削除などのシステム変更において常に懸念事項になります。SQLパフォーマンス・アナライザ機能では、SQL文のパフォーマンスに対する変更の影響を評価する簡単な方法を提供して、変更前後のレスポンス時間を比較および対比することにより、この懸念事項を軽減します。SQパフォーマンス・アナライザを使用すると、本番データベースなどのソース・システムからSQLワークロードを取得して、変更が適用されたテスト・システムでこのワークロードをリプレイできます。
|
関連項目: 『Oracle Databaseパフォーマンス・チューニング・ガイド』 |
日常的なタスクや繰返しタスクの実行に必要な人的作業を減らすことで、サービスの安定性、信頼性および可用性が向上します。これは、管理者が多くのシステムをできるかぎり効率的に管理する必要がある場合に特に重要です。
Oracle Enterprise Manager Grid Controlは、管理者がOracleテクノロジ・スタック全体（ビジネス・アプリケーション、アプリケーション・サーバー、データベース、E-Business Suite）、およびOracle以外のコンポーネントにまたがって完全な監視を行うことができるHTMLベースのインタフェースです。高速アプリケーション通知のコンポーネントが使用できない、またはパフォーマンスの問題が発生した場合、Grid Controlには自動生成されたアラートが表示されるので、管理者は適切なリカバリ処置を行えます。
Grid Controlのコンポーネントには、次のものがあります。
Oracle Management Service（OMS）
OMSは、Grid Controlのインタフェースを提供するJ2EE Webアプリケーションのセットで、すべての管理エージェントと連携して監視情報を処理し、管理リポジトリを永続的なデータ・ストアとして使用します。
各監視対象ホストにデプロイされているプロセスで、ホスト上のすべてのターゲットを監視し、その情報をOMSに送信し、ホストおよびターゲットのメンテナンスを行います。
Oracle Database内のスキーマで、Grid Controlによって管理される管理者、ターゲットおよびアプリケーションに関するあらゆる情報が含まれます。
Grid Control、OMSおよびOracle Management Agent間の通信は、HTTPを通じて行われます。ファイアウォールで保護されている環境内の層と層の間における安全な通信を可能にするため、SSLも有効化されます。管理エージェントは、収集された監視データをOMSにアップロードし、OMSは、管理リポジトリにデータをロードします。ターゲット状態に変更（可用性状態の変更など）があると、Grid Controlにアラートが生成されます。
Grid Controlを使用して、管理者は次の操作を行うことができます。
アーキテクチャ・コンポーネントの監視、および障害発生時のアラートの受信
データベース・クラスタ内のノードの数、および現在のステータスなど全体的なシステム・ステータスの表示
すべてのインスタンスに関して発せられたアラートの表示
クラスタ全体のデータベースごとにアラート生成に対するしきい値の設定
すべてのインスタンスにまたがるパフォーマンス・メトリックの監視
バックアップおよびリカバリなど、データベース・クラスタ全体の操作の実行
クラスタ・データベースの監視のインターコネクト
|
関連項目:
|
脚注の凡例
脚注1: Oracle Active Data Guardオプションは、リアルタイム問合せスタンバイと呼ばれることがあります。
