| Oracle® Database高可用性概要 12cリリース1 (12.1) B71280-03 |
|
 前 |
 次 |
この章では、MAAソリューションで使用されるOracle Databaseの機能について説明します。
|
関連項目:
|
Oracle Data Guardは、企業データの高可用性、データ保護および障害時リカバリを保証します。Data Guardは、Oracleデータベースが自然災害やデータ破損などのあらゆる種類の停止に耐えられるよう、1つ以上のスタンバイ・データベースの作成、メンテナンス、管理および監視を行うサービスの包括的なセットを提供します。Data Guardスタンバイ・データベースは本番データベースの正確なレプリカなので、従来のバックアップ、リストア、フラッシュバックおよびクラスタ技術と組み合せて透過的に利用し、可能なかぎり高いレベルのデータ保護とデータ可用性を提供できます。Data GuardはOracle Enterprise Editionに含まれています。
Data Guard構成は、1つのプライマリ・データベースと1つ以上のスタンバイ・データベースからなります。プライマリ・データベースは、単一インスタンスOracleデータベースまたはOracle RACデータベースのいずれかになります。プライマリ・データベースと同様に、スタンバイ・データベースは、単一インスタンスOracleデータベースまたはOracle RACデータベースのいずれかになります。プライマリ・データベースのバックアップ・コピーを使用してプライマリ・データベースからREDOを直接受信するスタンバイ・データベースを最大で30作成できます。オプションで、カスケード・スタンバイを使用して、プライマリがREDOを単一のリモート宛先に転送し、その宛先がREDOを複数のスタンバイ・データベースに転送する、Data Guard構成を作成することができます。これにより、プライマリ・データベースは必要に応じて、30よりも多くのスタンバイ・データベースと効率的に同期することができます。
|
注意: Oracle Active Data Guardは基本Data Guardの拡張で、様々なタイプの処理を本番データベースからオフロードする高度な機能を提供し、データ損失ゼロの保護をどんな距離にでも拡張して、高可用性を強化します。Oracle Active Data GuardはOracle Database Enterprise Editionとは別のライセンスです。Oracle Active Data Guardについては、3.1.1項「Oracle Active Data Guard」で詳しく説明します。 |
スタンバイ・データベースにはいくつかのタイプがあります。Data Guardフィジカル・スタンバイ・データベースはデータ保護および障害時リカバリについてのMAAベスト・プラクティスで、最も一般的に使用されるスタンバイ・データベースのタイプです。フィジカル・スタンバイ・データベースはREDO適用(Oracleメディア・リカバリの拡張)を使用して、本番データベースの正確なフィジカル・レプリカを保持します。MAAベスト・プラクティスを使用して構成する場合、REDO適用は複数のOracle対応検証チェックを使用して、プライマリに影響を与える可能性のある破損がスタンバイに影響を与えることを防ぎます。その他のタイプのData Guardスタンバイ・データベースには、スナップショット・スタンバイ(テストまたはその他の目的で読取り/書込みでオープンするスタンバイ)、ロジカル・スタンバイ(計画停止時間の短縮のために使用)があります。
更新がスタンバイ・データベースに適用される前に、Oracleデータ・ブロックおよびREDO内の構造の物理的および論理的整合性に対する複数のチェックを使用した、すべての変更のOracle対応の継続的な検証。これにより、スタンバイ・データベースが分離され、プライマリ・システムで発生する可能性のあるデータ破損による影響を受けることを防ぎます。
透過的な操作 - データ保護のためのData Guardフィジカル・スタンバイの使用には制約がありません。REDO適用はすべてのデータおよびストレージタイプ、すべてのDDL操作、およびすべてのアプリケーション(カスタムおよびパッケージ・アプリケーション)をサポートし、プライマリとスタンバイ・データベース間の整合性を保証します。
最高のパフォーマンス: 最高のリカバリ・ポイントの目標のための高速REDO転送、最高のリカバリ時間の目標のための高速適用パフォーマンス。
なんらかの理由でプライマリ・データベースに障害が発生した場合の、可用性を維持するためのスタンバイ・データベースへの高速フェイルオーバー。フェイルオーバーはData Guardの構成方法により、手動または自動の操作になります。
フェイルオーバーの発生後、アプリケーション・クライアントが新しいプライマリ・データベースに接続できるようにする、統合されたクライアント通知フレームワーク。
フェイルオーバーの発生後、障害の発生したプライマリ・データベースの自動または自動化された(構成による)再同期化、同期化されたスタンバイ・データベースへの迅速な変換。
すべてのネットワーク構成、可用性およびパフォーマンスSLA、ビジネス要件をサポートする、柔軟なデータ保護レベルの選択。
Data Guard Brokerコマンド・ライン・インタフェースまたはOracle Enterprise Manager Cloud Controlのいずれかを使用して、プライマリおよびそのスタンバイ・データベースのすべてを単一の構成として管理し、管理と監視を簡略化。
Data Guard Broker 12cは次の追加機能により大幅に管理容易性が向上しています。どの時点でも、構成によるリカバリ・ポイントの目標およびリカバリ時間の目標のSLAのサポートを自動的に監視するための、包括的な構成のヘルス・チェック、再開可能スイッチオーバー操作、ストリームライン・ロール・トランジション、カスケード・スタンバイ構成のサポート、転送および適用ラグに対するユーザー構成可能なしきい値。
プライマリ本番データベースから送信されてカスケード・スタンバイ・データベースにより転送される単一のREDOストリームを使用した、複数のリモート宛先への効果的な転送。
スナップショット・スタンバイにより、フィジカル・スタンバイ・データベースをテストおよび本番データのレプリカの読取り/書込みが必要なアクティビティ用に読取り/書込みでオープン可能。スナップショット・スタンバイは受信は続行しますが、プライマリにより生成された更新の適用は行いません。テストが完了すると、読取り/書込みでオープンしている間の変更を最初に破棄し、次にプライマリ・データベースから受信したREDOを適用することで、スナップショット・スタンバイは同期されたフィジカル・スタンバイ・データベースへと変換されて戻されます。プライマリ・データは常に保護されます。スナップショット・スタンバイはOracle Real Application Testingと一緒に使用される場合に特に有用です(スタンバイ・データベース(本番の正確なレプリカ)でのリプレイおよび後続のパフォーマンス分析のためにワークロードが本番データベースで取得されます)。
スタンバイ・データベースを使用してローリング方式でメンテナンスを実行することにより、計画停止時間を短縮。停止時間はData Guardスイッチオーバーの実行に必要な時間だけです。つまりアプリケーションはメンテナンスの実行中も使用可能なままです。(詳細は、3.3.3項「Oracle Active Data GuardおよびOracle GoldenGateを一緒に使用する場合」および表5-7「システムおよびソフトウェア・メンテナンス用Oracle高可用性ソリューション」を参照してください。)
プライマリ・システムとスタンバイ・システムで異なるCPUアーキテクチャまたはオペレーティング・システムが使用されているData Guard構成の柔軟性の向上は、My Oracle Support(http://support.oracle.com/)のノート413484.1に定義されている制限が前提です。
Oracle Database 12cコンテナ・データベース(CDB)の効率的な障害時リカバリ。Data Guardフェイルオーバーおよびスイッチオーバーは、CDBに統合されたデータベース(プラガブル・データベースまたはPDB)の数にかかわらず、CDBレベルで1つのコマンドを使用して実行されます。
Data Guard 12cにより、特定の管理特権であるSYSDGで、Data Guardに対する標準の管理業務を処理できるようになります。この新しい権限は、特定の機能を実行するのに必要な権限のみユーザーに付与され、それ以上は付与されない、最低限の権限の原則に基づいています。SYSDBA権限は以前のリリースでも引き続き動作します。
Oracle Active Data Guardはフィジカル・レプリケーション・プロセスを使用した、Oracleデータベースのリアルタイムのデータ保護および障害時リカバリに対するOracleの戦略的ソリューションです。Oracle Active Data Guardはまた、プライマリ・データベースから受信した変更を適用する間もスタンバイ・システムを読取り専用でオープンできることにより、障害時リカバリ・システムで高い投資利益率を提供します。Oracle Active Data Guardは、Oracle Enterprise Editionに含まれるData Guard機能を大幅に拡張する高度な機能を提供する、別個のライセンス製品です。
Oracle Active Data Guardにより、プライマリ・データベースから受信した変更を適用する間も読取り専用でオープンできるフィジカル・スタンバイ・システムに、プライマリ・データベースから処理をオフロードすることにより、管理者はパフォーマンスを向上できます。Oracle Active Data Guard 12cのオフロード機能は、次のものを含むように強化されました。読取り専用レポート作成およびグローバル一時表および一意のグローバルまたはセッション順序へのDMLを含む非定型問合せ、データの抽出、高速増分バックアップ、REDO転送圧縮、複数のリモート宛先の効果的な処理、およびプライマリ・データベースのパフォーマンスに影響を与えずにデータ損失ゼロの保護をリモート・スタンバイ・データベースへ拡張する機能。Oracle Active Data Guardはまた、自動ブロック修復を実行し、高可用性アップグレードを可能にする(データベース・ローリング・アップグレードをより容易に実装するためのOracle Database 12cでの新しい自動化)ことにより、可用性を向上させます。
|
注意: Oracle Active Data GuardはOracle Database Enterprise Editionのデータベース・オプション・ライセンスとして、別個にライセンスされます。すべてのOracle Active Data Guard機能も、Oracle Enterprise EditionのOracle Golden Gateライセンスに含まれます。これにより顧客は、Oracle Active Data Guardのスタンドアロン・ライセンス、またはすべての高度なOracleレプリケーション機能へのアクセスを取得するためのOracle GoldenGateのライセンスを選択できるようになります。 |
Oracle Active Data Guardは前述のData Guardの利点のすべてと、次の内容を継承します。
プライマリ・データベースのパフォーマンスの向上: 読取り専用アプリケーション、レポート作成および非定型問合せのOracle Active Data Guardスタンバイ・データベースへの本番オフロード。読取り専用データベースと互換性のあるアプリケーションはOracle Active Data Guardスタンバイで実行できます。Oracleは多くのOracle E-Business Suite Reports、PeopleToolsのレポート作成、Oracle Business Intelligence Enterprise Edition (OBIEE)およびOracle TopLinkアプリケーションのOracle Active Data Guardスタンバイ・データベースへのオフロードを可能にする統合も提供します。
Oracle Active Data Guard 12cでは、グローバル一時表へのDMLの新しいサポートおよびスタンバイ・データベースでの順序の使用を提供します。これにより本番データベースからOracle Active Data Guardスタンバイ・データベースへオフロードできる読取り専用アプリケーションの数が大幅に増加します。
複数のOracle Active Data Guardスタンバイ・データベースを使用して、読取りパフォーマンスを容易に高めることのできるユニークな機能は、リーダー・ファームとも呼ばれます。
Oracle Data Pumpまたはその他のソース・データベースから直接読み取る手法を使用した、データの抽出の本番オフロード。
プライマリとスタンバイ・データベースが数百または数千マイルも離れている、同期したデータ損失ゼロの構成で、ネットワーク待機時間からのパフォーマンスの影響の本番オフロード。Oracle Active Data Guard 12c遠隔同期はプライマリ・データベースとは独立したシステムにデプロイされた軽量インスタンス(制御ファイルおよびアーカイブ・ログ・ファイル、しかしリカバリ・ファイルおよびデータ・ファイルではない)を使用します。遠隔同期インスタンスは、アプリケーションが同期転送のパフォーマンスの影響に耐えて最適な保護を提供できる、プライマリ・システムから最も離れた場所に配置するのが理想的です。Data GuardはREDOを遠隔同期インスタンスに同期して転送し、遠隔同期はそのREDOを最終フェイルオーバー・ターゲットであるリモート・スタンバイ・データベースに非同期に転送します。プライマリ・データベースに障害が発生すると、Data Guard構成で使用される同じフェイルオーバー・コマンドまたはOracle Enterprise Manager 12cを使用したマウスのクリック、またはData Guardファスト・スタート・フェイルオーバーを使用した自動フェイルオーバーは、リモート宛先へのデータ損失ゼロのフェイルオーバーを実行します。この透過性は、同期構成でのWANネットワーク待機時間のプライマリ・データベースのパフォーマンスの影響を回避しながら、REDOをプライマリ・データベースから直接受け取っているかのように、データ損失ゼロの保護をリモート・スタンバイ・データベースに拡張します。
遠隔同期を使用した複数のリモート・スタンバイ宛先にサービスするオーバーヘッドの本番オフロード。遠隔同期構成では、プライマリ・データベースは同期または非同期転送を使用して、REDOの単一のストリームを遠隔同期インスタンスへ送信します。遠隔同期インスタンスは、ソース・データベースの増分オーバーヘッドなしで、REDOを29のリモート宛先に非同期で転送できます。
Data Guardの最大可用性では、NOAFFIRMREDO転送属性がサポートされます。REDOがメモリーで受信されるとすぐに、スタンバイ・データベースは受領通知をプライマリ・データベースに返します。スタンバイ・データベースでは、リモート・ファイル・サーバー(RFS)によるスタンバイREDOログ・ファイルへの書込みを待っていません。
この機能により、最大可用性とSYNCREDO転送を使用するData Guard構成でのプライマリ・データベースのパフォーマンスが向上します。高速同期により、最大可用性構成内のプライマリ・データベースが、スタンバイ・データベースでの遅いI/Oによるパフォーマンスの影響から隔離されます。この新しいFAST SYNC機能は、フィジカル・スタンバイ・ターゲットとともに使用することも、遠隔同期構成内で使用することも可能です。
REDO転送圧縮の実行に必要なCPUサイクルの本番オフロード。Data Guard構成がOracle Advanced Compression用にライセンスされている場合、REDO転送圧縮は遠隔同期インスタンスにより実行できます。これはプライマリ・データベースの増分オーバーヘッドなしでバンド幅を保存します。
RMANブロック変更のトラッキングのためにOracle Active Data Guardサポートを使用することで、高速増分バックアップをプライマリ・データベースからスタンバイ・データベースへ移動することによる、本番オフロードおよびバックアップ・パフォーマンスの向上。
プライマリまたはスタンバイのいずれかで検出されたブロック破損を、アプリケーションおよびユーザーに透過的に修復するために、Oracle Active Data Guard自動ブロック修復を使用した高可用性の向上。
Oracle Active Data Guard 12cの新しい機能の高可用性アップグレードにより提供される追加の自動化を使用して(3.1.3.3項「Active Data Guardを使用したローリング・アップグレード」参照)、新しいOracle Databaseパッチ・セットおよびデータベース・リリースへのアップグレードの計画停止時間を短縮することにより、高可用性を向上。
Data Guardには、従来のソリューションよりも優れた次のような多くの利点があります。
データ破損、書込み欠落、データベースおよびサイト障害に対するデータベース・フェイルオーバーは、高速かつ自動で実行され、従来のソリューションを使用した場合は数時間かかるリカバリが、Data Guardでは数秒になります
Oracle Active Data Guard遠隔同期の使用時、Wide Area Network(WAN)経由でデータ損失ゼロ
Active Data Guard遠隔同期を使用したREDO転送圧縮処理のオフロードおよび最大29のリモート宛先へのREDO送信
破損自動修復の機能により、プライマリ・データベースまたはフィジカル・スタンバイ・データベースの物理ブロックの破損を、フィジカル・スタンバイ・データベースまたはプライマリ・データベースの良好なブロックをコピーして自動的に置換
プライマリ・データベースでのデータ破損と書込み欠落に対する最も包括的な保護
ストレージ、Oracle ASM、Oracle RAC、システムの移行と一部のプラットフォームの移行、およびData Guardスイッチオーバーを使用した変更による停止時間の短縮
Data Guardのローリング・アップグレード機能による停止時間の短縮
リアルタイム問合せの適用ラグ機能を使用して、スタンバイ・データベースを読取り専用リソースとして使用するRTOおよびRPOの機能を犠牲にせずに、プライマリ・データベースのアクティビティ(バックアップ、問合せまたはレポート作成など)のオフロードが可能
サイト全体のフェイルオーバー操作の一部としてOracle Database File System (DBFS)またはOracle Automatic Storage Managementクラスタ・ファイル・システム(Oracle ACFS)を使用したデータベース以外のファイルの統合機能(3.15項「データベース以外のファイルに対するOracleレプリケーション・テクノロジ」を参照してください)
サイト障害の後で、インスタンスの再起動、ストレージの再マスタリングまたはアプリケーションの再接続が不要
アプリケーションに対する透過性
アプリケーション・フェイルオーバーに対する透過的な統合サポート(アプリケーション・コンティニュイティおよびトランザクション・ガード)
ネットワーク使用の効率化
Oracle Databaseに常駐するデータの場合、データ損失ゼロ機能が組み込まれているData Guardは、データ保護および障害時リカバリに関して従来のリモート・ミラー化ソリューションよりも効率的かつ安価でより最適化されています。Data Guardには、障害時リカバリとデータ保護のテクノロジを選択する際に、従来のリモート・ミラー化ソリューションよりもData Guardを採用する方が正しいとする、技術上およびビジネス上の理由があります。
Data Guardスタンバイ・データベースを使用してローリング方式でメンテナンスを実行することにより、計画停止時間を短縮できます。スタンバイ・データベースで変更が最初に実装されます。新しいバージョンが本番用に確実に準備できるまで、古いバージョンでプライマリを実行し、新しいバージョンでスタンバイを実行する構成が可能です。次にData Guardスイッチオーバーが実行され、本番が新しいバージョンに遷移します。データベースの停止時間はスイッチオーバーを実行するのに必要な時間のみです。
Data Guardスタンバイを使用してローリング方式でメンテナンスを実行するには、いくつかの方法があります。顧客の要件および好みにより、どの方法を使用するかが決まります。このドキュメントで説明する方法は、次のとおりです。
Oracle Database 10gから、Data Guard REDO適用を使用してクロス・プラットフォームのサポートの柔軟性が向上しました。特定のData Guard構成で、プライマリおよびスタンバイ・データベースは、異なるオペレーティング・システム(WindowsとLinuxなど)、ワード・サイズ(32ビット/64ビット)またはハードウェア・アーキテクチャのシステムで実行できます。REDO適用を使用して、Oracle Automatic Storage Management (ASM)への移行、単一インスタンスOracle DatabasesからOracle RACへの移行、テクノロジ・リフレッシュの実行、またはあるデータ・センターから次のデータ・センターへの移動を実行することもできます。
Oracle Database 11g リリース2 (11.2)から、Standby-First Patchの適用(REDO適用を使用したフィジカル・スタンバイ)は、ローリング方式でOracleパッチを適用および検証する目的で、プライマリ・データベースとそのフィジカル・スタンバイ・データベース間で異なるソフトウェア・パッチ・レベルをサポートします。Standby-First Patchの適用が可能なパッチには次のものがあります。
データベースのパッチ・セット更新(PSU)
データベースのクリティカル・パッチ・アップデート(CPU)
データベースのバンドル・パッチ
Oracle Exadata Database Machineバンドル・パッチ
Exadata Storage Server Softwareパッチ
既存のOracleデータベースのバージョンと互換性のあるあらゆるオペレーティング・システム、システム・ファームウェアまたはシステム変更
Standby-First Patchの適用は、Oracle Database Enterprise Edition 11g リリース2 (11.2)以降の認定ソフトウェア・パッチでサポートされます。
前述の計画メンテナンスの各タイプで、構成はプライマリおよびフィジカル・スタンバイ・データベースから始まります(新しいプラットフォームまたはASM、Oracle RACへの移行の場合、スタンバイは新しいプラットフォームに作成されます)。すべての変更がフィジカル・スタンバイ・データベースで実装されると、REDO適用(フィジカル・レプリケーション)が使用されてスタンバイとプライマリが同期します。Data Guardスイッチオーバーが使用され、本番がスタンバイ(新しい環境)に転送されます。
|
関連項目:
|
データベースの元のバージョンと変更後またはアップグレードされたバージョンを同期するのに、REDO適用(フィジカル・レプリケーション)を使用できない、多くのタイプのメンテナンス・タスクがあります。次のようなタスクがあります。
Standby-First Patchの適用に適格ではないデータベース・パッチまたはアップグレード。これにはデータベース・パッチ・セット(11.2.0.2から11.2.0.3)および新しいOracle Databaseのリリース(11.2.0.3から12.1)が含まれます。
停止時間を必要とするデータベースの物理構造を変更するメンテナンスが実行される必要があります(パーティション化されていない表へのパーティションの追加、Basicfile LOBからSecurefile LOBへの変更、XML-CLOBからBinary XMLへの変更、表のOLTP圧縮への変更など)。
Data Guard SQL Apply (ロジカル・レプリケーション)を使用して、以前のタイプのすべてのメンテナンスを、Data Guardスタンバイ・データベースを使用したローリング方式で実行し、古いバージョンのデータベースと新しいバージョンのデータベースを同期できます。Oracle Database 11g以前、これにはロジカル・スタンバイ・データベースの作成、ロジカル・スタンバイでのメンテナンスの実行、スタンバイとプライマリの再同期、およびスイッチオーバーが必要でした。さらに、フィジカル・スタンバイが障害時リカバリに使用された場合、新しいフィジカル・スタンバイ・データベースは新しいバージョンで本番データベースのバックアップから作成される必要があります。これは複数のTBデータベースのアップグレード時の、多くのロジスティックおよびコスト上の課題を表しています。
Oracle Database 11g以降、データベースのローリング・アップグレードでは、一時ロジカルと呼ばれる、フィジカル・スタンバイ・データベースで始まりフィジカル・スタンバイ・データベースで終わる、新しいプロシージャを使用できます。SQL Applyは、Data Guardが古いバージョンと新しいバージョンで同期している場合のフェーズ中でのみ使用されます。フィジカル・スタンバイがすでに所定の場所にある場合、新しいロジカル・スタンバイ・データベースを作成する必要はありません。メンテナンスが完了した後に、新しいフィジカル・スタンバイ・データベースを、新しいバージョンで本番データベースのバックアップから作成する必要はありません。インプレース・フィジカル・スタンバイを持つData Guard構成のアップグレードの従来のプロセスと同様に、元のプライマリは新しいプライマリ・データベースからのREDOおよびREDO適用を使用してアップグレードまたは変更されます(単一カタログのアップグレードではプライマリおよびスタンバイ・データベースの両方を新しいOracleリリースに移行します)。
一時ロジカル・アップグレードでは、プライマリ・データベースがOracle Database 11g リリース1(11.1)以降で、データベースがSQL Applyの前提条件を満たしていることが必要です。
一時ロジカル・ローリング・アップグレード・プロセスに必要ないくつかの手動の手順を自動化するBourneシェル・スクリプトが用意されています。詳細は、MAAベスト・プラクティス・ペーパー『容易になったデータベースのローリング・アップグレード』(http://www.oracle.com/technetwork/database/features/availability/maa-wp-11g-upgrades-made-easy-131972.pdf )を参照してください。
Oracle Database 12cでは、Oracle Active Data Guardを使用したローリング・アップグレードが導入され、前述の手動一時ロジカル・ローリング・アップグレードで表される方法よりも、より簡単で、自動化された、容易に繰返し可能な、計画停止時間を短縮するための方法が提供されます。Oracle Active Data Guardを使用したローリング・アップグレードでは、手動プロシージャで必要な42以上の手順が、いくつかの使いやすいDBMS_ROLLING PL/SQLパッケージに変換されます。
Oracle Active Data Guardを使用したローリング・アップグレードの手順は次のとおりです。
DBMS_ROLLING.INIT_PLANのコール
アップグレード・プロセスを管理者にガイドするための、構成に固有の指示セットを含むアップグレード・プランを生成
DBMS_ROLLING.SET_PARAMETERのコール
ローリング・アップグレードのパラメータを変更
アップグレードに関連するすべてのデータベースで新しいソフトウェアをインストール
DBMS_ROLLING.START_PLANのコール
アップグレードに関連するプライマリおよびスタンバイ・データベースを構成
スタンバイ・データベースをアップグレードまたは変更
DBMS_ROLLING.SWITCHOVERのコール
スイッチオーバーによる本番の新しいバージョンへの移行
スイッチオーバーは必要な停止時間のみ
可能な場合、新しいバイナリを使用して前のプライマリを再起動
DBMS_ROLLING.FINISH_PLANのコール
Data Guard構成で古いプライマリと追加のスタンバイ・データベースのアップグレードを完了し、新しいプライマリと同期
Oracle Active Data Guardを使用したローリング・アップグレードには次のメリットがあります。
簡単な指定-コンパイル-実行プロトコルを提供
コンパイル手順で構成エラーを検出
実行時エラーを実行中に検出
状態をデータベースに保持
信頼できる、繰返し可能なプロセスが可能
含まれるデータベースの数に関係なく、実行時の手順は一定
元のプライマリ・データベースでエラーを処理
アップグレードされたプライマリに対するデータ保護がいつでも可能
Oracle Active Data Guardを使用するローリング・アップグレードは、Oracle Active Data Guardライセンスと、プライマリ・データベースがOracle Database 12c リリース1(12.1)以降で、データベースがSQL Applyの前提条件を満たしていることが必要です。プライマリ・データベースが以前のOracle Databaseリリースの場合、MAAホワイト・ペーパー『容易になったデータベースのローリング・アップグレード』(http://www.oracle.com/goto/maa)を参照してください。
|
関連項目: 『Oracle Data Guard概要および管理』のDBMS_ROLLINGを使用したローリング・アップグレードの実行に関する項。 |
Oracle GoldenGateはデータ分散およびデータ統合のためのOracleの戦略的ロジカル・レプリケーション・ソリューションです。他のベンダーのレプリケーション・ソリューションとは違い、Oracle GoldenGateはOracle Databaseとより密接に統合されながらも、異機種データベース管理システム間のレプリケーションに最適な、オープンなモジュラー・アーキテクチャも提供します。これらの性質の組合せにより妥協が排されるため、Oracle GoldenGateはOracle Database環境と非Oracle Database環境にまたがる要件に対処するための優先のレプリケーション・ソリューションとなります。
Oracle GoldenGateはリアルタイムのログ・ベースの変更データの取得およびレプリケーション・ソフトウェア・プラットフォームを提供します。このソフトウェアでは、異種のデータベース間で、トランザクション・データのキャプチャ、ルーティング、変換および配信をリアルタイムに行います。
典型的な環境として、取得、ポンプおよび配信プロセスがあります。これらの各プロセスは、Oracle Databaseおよび非Oracleデータベースを含む、ほとんどの一般的なオペレーティング・システムおよびデータベースで実行できます。データのすべてまたは一部をレプリケートすることができ、プロセス内のデータは、異機種環境だけでなく、異なるデータベース・スキーマでも操作できます。Oracle GoldenGateはマルチマスター・レプリケーション、ハブ・アンド・スポーク方式のデプロイメントおよびデータ変換をサポートします。
Oracle GoldenGate 12cはレプリケーション機能とOracle Databaseとの統合が大幅に強化された重要な新しい機能を提供します。新しい機能は次のとおりです。
マルチテナント・アーキテクチャやクラウド環境でのデータ取得と配信のサポートなど、Oracle Database12cが最適化されました。クラウド環境のサポートは、リリース11.2.1から使用可能でした。
Oracle GoldenGate用に作成された軽量のストリーミングAPIを利用しているOracle Databaseへの配信が統合され、パフォーマンスとスケーラビリティが向上しました。単一のReplicat構成内において、元のトランザクションのアトミック性を保持しながら、複数のインバウンド・サーバーの子プロセス(適用サーバーとも言う)により、トランザクションを並行して適用します。この並列度は、Replicatプロセスを構成する際に、ターゲット・システムの数だけ増やすことも、必要に応じて動的に調整することも可能です。この機能は、Oracle 11.2.0.4および12cでのみ使用できます。
調整配信は、複数のReplicatプロセスを管理する複雑さを軽減します。調整配信により、調整イベント(DDL、SQLEXEC文、EVENTACTIONSなど)の適用が管理され、SCNの順序で適用されます。これにより、スケーラビリティとパフォーマンスの向上を必要としているユーザーが、DDL操作のレプリケートや、データに対する特定の問合せまたはチェックを実行できるようになります。
統合キャプチャは、データベースに表を含めることで、表のレプリケートが可能かどうかを判断しやすくして、使用性が向上するよう拡張され、DDL解決機能も、データベース・レベルのトリガーなしでREDOログから直接DDLを読み取れるよう拡張されました。この機能は、統合Extractとともに、Oracle Database 11gリリース11.2.0.4以降およびOracle Database 12cリリース12.1.0.2以降でのみ使用できます。
使用性を向上し、実装を簡素化するために、多数のパラメータが変更されました。DISCARDFILEにデフォルト値が設定されたため、Replicatでこのパラメータを指定する必要がなくなりました。デバッグ、エラー・ロギング、スキーマのワイルドカード検索機能のみでなく、システムを完全にレプリケートできるようデータベース全体を拡張しました。
Oracle Walletおよび資格証明ストアの機能が追加され、ユーザー名とパスワードのセキュリティが向上しました。
取得と配信の両方で、Informixリリース11.5、11.7および12.1がサポートされます。
Oracle GoldenGate 11gリリース2はレプリケーション機能とOracle Databaseとの統合が大幅に強化された重要な新しい機能を提供します。新しい機能は次のとおりです。
統合キャプチャのパフォーマンスの向上 - Oracle GoldenGate 11gリリース2で導入された統合キャプチャが、より高速なパフォーマンスを実現するよう改善されました。この拡張はユーザーに対して透過的であり、構成を変更する必要はありません。
統合Replicat - Oracle用のReplicatを統合モードで使用できるようになり、Oracleターゲット環境でのスケーラビリティが向上しました。統合モードにおいて、Replicatプロセスでは、Oracleデータベース内で使用可能な適用処理機能が使用されます。統合Replicatでは、参照整合性およびデータ定義言語(DDL)の操作が処理され、それらの操作が適切な順序で実行されていることが確認されるため、管理者は、親子関係や、複数の表が関連するDDLまたは単一の表内における構造の変更などに注意を払う必要がありません。
マルチテナント・コンテナ・データベースへの取得および適用 - Oracle GoldenGateで、Oracleマルチテナント・コンテナ・データベース(CDB)からの取得と配信がサポートされるようになりました。
ネイティブDDLキャプチャ - このリリースのOracle GoldenGateには、統合モードでのExtractに対するネイティブDDLキャプチャが導入されています。ネイティブDDLキャプチャを使用することにより、サポートされているOracleバージョンのDDLを取得するために、DDLトリガー(およびサポートされているオブジェクト)を使用する必要がなくなります。ネイティブDDLキャプチャにより、DDLの取得がデータベース・ローミング・サーバーに統合されます。
Oracle GoldenGate論理レプリケーションにより、Oracle GoldenGate構成のすべてのデータベース(ソースおよびターゲット・データベースの両方)を読取り/書込みで開くことができます。この事実とOracle GoldenGateのアドバンスト・レプリケーション機能との組合せにより、停止時間ゼロのメンテナンス、クロス・プラットフォームの移行を使用したデータの連続可用性に対する広範囲の挑戦に対処するための、MAAの主要なコンポーネントになっています。具体的には次のとおりです。
ゼロまたはゼロに近い停止時間でのメンテナンス。この点においてOracle GoldenGateでは、Data Guardで提供される基本機能よりも高い柔軟性が提供されます。Oracle GoldenGateのソースおよびターゲット・データベースは、異なるフィジカルおよびロジカル構造を持つことが可能で、異なるハードウェアおよびオペレーティング・システム・アーキテクチャに存在でき、異なるOracle Databaseリリースに拡張(たとえば9iから12c)、またはOracleと非Oracleシステムの混在が可能です。メンテナンスは本番がソースで実行している間に、まずターゲット・データベースで実行されます。メンテナンスが完了すると、Data Guardスイッチオーバーのように、本番を一度にすべてソースに移動できます。オプションで、双方向レプリケーションを使用して、停止時間ゼロと認識させて、ユーザーを新しいシステムへ徐々に移動できます。いずれの場合も、Oracle GoldenGateレプリケーションは、遷移中、逆方向に元のソース・システム・データベースの同期化を保持することが可能で、これにより、必要な場合、最小限の停止時間でデータの損失なしで、簡単に前のバージョンへの計画フォールバックが実行できます。
ゼロまたはゼロに近い停止時間でのアプリケーションのアップグレード。バックエンド・データベース・オブジェクトを変更するアプリケーション・アップグレードでは、通常、メンテナンスの実行中、大幅な計画停止時間が発生します。Oracle GoldenGateレプリケーションでは、アプリケーションの前のバージョンにより使用されたデータベース・オブジェクトを、アプリケーションの新しいバージョンで変更されたオブジェクトにマップするデータ変換が可能です。これにより、アプリケーションの可用性に影響を与えずに、本番データベースの別のコピーで、データベース・メンテナンスの実行が可能になります。メンテナンスが完了し、Oracle GoldenGateの古いバージョンと新しいバージョンの同期が終了すると、ユーザーはアプリケーションの新しいバージョンにスイッチできます。
Oracle GoldenGateでは、ソース・データベースと同期化されている間も、レプリカ・データベースへの読取り/書込みアクセスが可能です。これは、レポート・アプリケーションが動作のためにデータベースへの読取り/書込みを必要とする場合の、本番データベースのコピーへのレポート作成のオフロードに最も頻繁に使用されます。しかしこれは、アプリケーション層に使用されるテクノロジの性質が、リカバリ時間の目標を満たすために常にDRデータベースへのアクティブな読取り/書込み接続を必要とする、特定の障害時リカバリ環境にも関係します。Oracle GoldenGateがOracle Active Data Guardのかわりに後者のケースで使用される場合、Oracle Active Data Guardスタンバイにより提供される追加のデータ保護、簡略性および透過性が、常に読取り/書込みでオープンされているフェイルオーバー・ターゲットと引換えにされます。
すべてが同じデータを含み、Oracle GoldenGateと同期された複数のデータベースが存在する、マルチマスターおよび双方向レプリケーション・アーキテクチャ。どのデータベースでの更新も他のすべてのデータベースに即座にレプリケートされます。更新の競合は、アプリケーションにより処理されるか、またはOracle GoldenGateを使用して構成された競合ハンドラで処理されるか、あるいは手動で解決されます。これはワークロードのバランシングおよびデータの可用性と操作の簡略性の対比を強調するアーキテクチャです。Oracle GoldenGateの各ソースはまた、最適な障害保護のために、Data Guardスタンバイ・データベースにより保護されます。オプションで、コスト上の考慮事項より、Data Guard物理スタンバイ・データベースの追加のコストをかけずに、各Oracle GoldenGateレプリカを使用してデータの可用性とDR保護の両方を提供できます。
Oracle Active Data GuardおよびOracle GoldenGateはそれぞれOracle Databaseの同期化されたコピーを保持できますが、要件に応じて、1つのテクノロジまたは別のテクノロジ、あるいは同時に両方を使用できる高可用性アーキテクチャになる、ユニークな特徴があります。Oracle Database 12cに関連するユースケースに対するMAAベスト・プラクティス・ガイドラインの例は次のとおりです。
簡易性、データ保護および可用性が重要視される場合、Oracle Active Data Guardを使用します。
Oracle Database全体の最も簡単で高速な一方向レプリケーション。
制約なし: Data Guard REDO適用はすべてのデータ型と記憶域のタイプおよびOracle機能、DDLの透過的レプリケーションをサポートします。
データ保護に最適化された機能: ソースまたはターゲットに発生する可能性のあるサイレントな破損を検出し、破損ブロックを自動的に修復
同期されたスタンバイの読取り専用でのオープンにより、最大ROIのための簡単な読取り専用オフロードが提供
バックアップの透過性: Data Guardのプライマリおよびスタンバイはお互いに物理的に正確なコピーであり、RMANバックアップは完全に代替可能
データベースのパフォーマンスに影響を与えず、どんな距離でもデータ損失なしの保護
Standby-First Patchの適用、データベースのローリング・アップグレード、プラットフォームの移行の選択を使用した計画停止時間およびリスクの最小化
Data Guardスナップショット・スタンバイを使用したテスト用の二重目的のDRシステムによる変更の導入のリスクの減少
統合されたデータベースおよびクライアントの自動フェイルオーバー
構成全体の統合された管理: Data Guard Brokerコマンド・ラインまたはOracle Enterprise Manager Cloud Control
Oracle Active Data Guardで対処されない高度なレプリケーション要件が重要視される場合、Oracle GoldenGateを使用します。
プライマリ・データベースと同期しながら、レプリカ・データベースを読取り/書込みでオープンする必要がある要件
マルチマスターおよび双方向レプリケーション、サブセットのレプリケーション、多対1レプリケーションおよびデータ統合などのデータ・レプリケーション要件。
エンディアン形式のプラットフォーム間またはデータベース全体のメジャー・バージョン間で、データ・レプリケーションが必要な場合。
ゼロまたはゼロに近い停止時間が必要なメンテナンスまたは移行。Oracle GoldenGateを使用して、停止時間なしで、Application 1.0からApplication 2.0へなど、アプリケーションのバージョン間で移行できます。
高速フォールバックの目的で、新しいバージョンから古いバージョンにレプリケートする場合のデータベースのローリング・アップグレードは、うまくいきません。
双方向レプリケーションを使用して、停止時間ゼロを認識させて、ユーザーを新しいシステムへ徐々に移動する場合の、停止時間ゼロの計画メンテナンス。双方向レプリケーションでは異種のデータベースで発生する可能性のある更新の競合を回避または解決する必要があります。
Oracle Active Data GuardおよびOracle GoldenGateは相互に排他的ではありません。次に示すのは、Oracle Active Data GuardとOracle GoldenGateの同時使用を含む、高可用性アーキテクチャのユースケースです。
Oracle Active Data Guardスタンバイは、ミッション・クリティカルなOLTPデータベースに対する障害保護およびデータベースのローリング・アップグレード用に使用されます。同時に、Oracle GoldenGateは、エンタープライズ・データ・ウェアハウスのETL更新に対し、Data Guardプライマリ・データベースから(またはOracle GoldenGate ALOモードを使用してスタンバイ・データベースから)データをレプリケートするのに使用されます。
Oracle GoldenGateサブセットのレプリケーションを使用して、多数のデータ・ストアからデータを抽出、変換および集計する、操作データ・ストア(ODS)を作成します。ODSは企業に多くの収益をもたらす、ミッション・クリティカルなアプリケーション・システムをサポートします。Oracle Active Data Guardスタンバイ・データベースを使用して、ODSを保護し、最適なデータ保護と可用性を提供します。
Oracle GoldenGateの双方向レプリケーションは、数千マイル離れた2つのデータベースを同期させるために使用されます。ユーザー・ワークロードは、Oracle 12cグローバル・データ・サービス(GDS)を使用して、地理、ワークロードおよびサービス・レベルに基づき各データベース間で分散されます。Oracle GoldenGateのコピーは、停止が発生した場合にデータ損失ゼロのフェイルオーバーを可能にする、固有のローカル同期Data Guardスタンバイ・データベースを持ちます。Oracle GoldenGateのキャプチャおよび適用プロセスは、プライマリとスタンバイがお互いに正確で最新のレプリカであるので、フェイルオーバー後の新しいプライマリ・データベースで容易に再起動されます。
障害保護用に使用されているOracle Active Data Guardスタンバイ・データベースは、Data Guardによりサポートされない計画メンテナンスの実行のために、一時的にOracle GoldenGateターゲットに変換されます。たとえば、バックエンド・データベース・オブジェクトの変更を必要とするSiebelアプリケーションのアップグレードで、ユーザーを新しいシステムにスイッチオーバーする前に包括的なテストが必要な場合です。
Oracle Active Data Guardは、停止時間がゼロまたはゼロに近い状態で、データベースのメジャー・バージョンのアップグレード(Oracle 11.2.0.3から12cなど)が必要な場合に、本番環境の保護に使用されます。新しいバージョンのデータベースを使用して、プライマリ/スタンバイ環境がもう1つ作成され、Oracle GoldenGateは、本番環境からコピーの環境へ、一方向または双方向のレプリケーションでデータをレプリケートするために使用されます。Oracle GoldenGateで古い環境と新しい環境の同期が完了すると、本番は新しい環境に切り替わり、古い環境は廃止されます。これによって、構成により停止時間はゼロまたは最小となり、古い環境と新しい環境が完全に分離されることでリスクが軽減され、アップグレード・プロセス中に問題が発生しても、データ保護および可用性SLAへの影響が回避されます。
Recovery Manager (RMAN)は、データベースを効率的にバックアップおよびリカバリするための包括的な基盤を提供します。RMANは、操作の複雑さを排除するとともに、データベースの優れたパフォーマンスおよび可用性をもたらします。
RMANは、リクエストされたバックアップ、リストアまたはリカバリの操作を実行する最も効率的な方法を決定し、Oracle Databaseサーバーでの処理のために、これらの操作を発行します。RMANおよびサーバーは、データベース構造に加えられた変更を自動的に識別し、変更に適応するために必要な操作を動的に調整します。
クロス・プラットフォームのバックアップおよびリストアのサポート(Oracle Database 12cでの新機能)。
RESTORE操作によりデータ・ファイルをデータベース間でネットワークを介して直接コピーできる、ネットワーク対応のRESTORE操作(Oracle Database 12cでの新機能)
RECOVER TABLEコマンドを使用した簡略化された表のリストア(Oracle Database 12cでの新機能)。
個々のプラガブル・データベースのバックアップおよびリカバリを含む、Oracle Multitenantのサポート(Oracle Database 12cの新機能)
バックアップおよびリストア操作での自動チャネル・フェイルオーバー
リストア操作で欠落した、または破損したバックアップが検出された場合に、前回のバックアップへの自動フェイルオーバー
リカバリ中の一時ファイルおよび新規データベースの自動作成
前回のポイント・イン・タイム・リカバリを使用した自動リカバリ(リセットログによるリカバリ)
ブロック・メディア・リカバリでは、データ・ファイルをオンラインに保ったまま、ブロックの破損を修復
ブロック・チェンジ・トラッキングを使用した高速増分バックアップ
イントラファイルおよびインターファイルの並列処理による高速バックアップ操作とリストア操作
増分バックアップがイメージ・コピーにマージされ、最新の状態にリカバリ可能
必要なファイルのみ、バックアップおよびリストアを最適化
保存方針により、関連のバックアップを確実に保存
失敗した場合に、操作のバックアップおよびリストアを再開可能
制御ファイルおよびサーバー・パラメータ・ファイルの自動バックアップを行うことにより、データベース構造の変化や、メディア障害や災害の発生時に、バックアップ・メタデータの使用が可能
既存のバックアップから、またはDUPLICATEコマンドを使用して本番データベースから直接(この場合ステージング領域は不要)、新しいデータベースを簡単に再インスタンス化
|
関連項目: 『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』 |
Oracle Secure Backupは、UNIX、Linux、WindowsおよびNetwork Attached Storage(NAS)の分散環境で実行される異種データ保護を提供する、集中型のテープ・バックアップ管理ソリューションです。ファイル・システムとOracle Databaseのデータを保護することにより、Oracle Secure BackupはIT環境に完全なテープ・バックアップ・ソリューションを提供します。
Oracle Secure BackupはRMANと密接に統合され、RMANのメディア管理レイヤーを提供します。Oracle Secure BackupとRMANは、最適化された統合ポイントを使用して、Oracle Databaseに最速で効率性が最も高いテープ・バックアップ機能を提供します。
バックアップ・ポリシーを使用して、分散サーバーをOracle Secure Backup中央管理サーバーからローカルおよびリモートのテープ・デバイスにバックアップできます。完全自動操作の場合はカレンダーに基づくスケジュールで、迅速な要件の場合はオンデマンドでバックアップされます。高度にスケーラブルなクライアント/サーバー・アーキテクチャにより、Oracle Secure Backupは安全なイントラドメイン通信と双方向サーバー認証のためにSecure Sockets Layer(SSL)を利用して、ローカルおよびリモートのデータ保護を提供します。
Oracle Secure Backupには次のような利点があります。
比較可能なメディア管理製品よりも25-40%高速なOracle Databaseのバックアップと、CPU使用率の最大10%の低下を達成する、最適化されたパフォーマンス
未使用ブロックとUNDOブロックの圧縮
RMANとのテープ・バッファの共有
ポリシーに基づく管理により、バックアップ管理者はバックアップ・ドメインの正確な制御が可能
動的ドライブ共有によるテープ・リソースの使用率の向上
異種ストレージ・エリア・ネットワーク(SAN)のサポートにより、NAS、UNIX、WindowsおよびLinuxでテープ・ドライブとメディアの共有が可能
完全および増分オフサイト・バックアップ・スケジューリングによる、ファイル、ディレクトリ、ファイル・システムまたはRAWパーティション・レベルでのファイル・システム・バックアップ
Oracle Enterprise Managerとの統合による、直感的で使いやすいインタフェースの提供
Oracle Secure Backupのホスト・ベースの暗号化またはハードウェア暗号化(テープ・ドライブ)のいずれかを利用する、ポリシー・ベースの暗号化鍵管理を使用したテープへのバックアップの暗号化
SANおよびSCSI環境における新しいテープ・デバイスと従来の幅広テープ・デバイスのサポート
Network Data Management Protocol(NDMP)のサポートによる、NASファイルの効率性の高いバックアップ
スケーラブルで低コストのライセンス・モデルによる、ITコストの削減と運用面の考慮事項の軽減
Exadata Database Machine環境で最大のバックアップおよびリストアのパフォーマンスのための、インフィニバンド・ネットワーク経由のReliable Datagram Socket over Remote Direct Memory Access (RDS/RDMA)の強化されたデータ・スループット
OSBおよびOracleデータベース・バックグラウンド・プロセスが最適なパフォーマンスのために同じNUMA領域で通信することを保証する、不均一メモリー・アクセス(NUMA)マシンでのOracle対応のバックアップとリストア
|
関連項目: 『Oracle Secure Backup管理者ガイド』 |
Oracle Real Application Clusters(Oracle RAC)とOracle Clusterwareを使用すると、Oracle Databaseはクラスタ化された一連のサーバー全体にパッケージまたはカスタム・アプリケーションを実行できます。この機能により、高いレベルの可用性および最も柔軟的なスケーラビリティが得られます。クラスタ化されたサーバーに障害がある場合でも、Oracle Databaseは残りのサーバー上で稼働し続けます。より高い処理能力が必要なときは、データへのユーザーのアクセスを中断することなく、他のサーバーを追加できます。
Oracle RACを使用すると、インターコネクトでリンクされた複数のインスタンスによるOracleデータベースへのアクセスの共有が可能になります。Oracle RAC環境では、単一の共有データベースに同時にアクセスしている間、Oracle Databaseはクラスタ内の2つ以上のシステム上で稼働します。その結果、複数のハードウェア・システムにまたがる単一データベース・システムとなり、Oracle RACではクラスタ内での障害時に高可用性と冗長性を提供できます。Oracle RACは、読取り専用のデータ・ウェアハウス・システムから更新頻度の高いオンライン・トランザクション処理(OLTP)システムまで、あらゆるタイプのシステムに対応しています。
Oracle Clusterwareは、同じオペレーティング・システムを実行するサーバーにインストールされる場合、これらのサーバーが連係して単一サーバーとして機能できるようにして、ユーザー・アプリケーションとOracleデータベースの可用性を管理するソフトウェアです。また、ノードのメンバーシップ、グループ・サービス、グローバルなリソース管理、高可用性機能といったクラスタ管理に必要な機能もすべて提供します。
高可用性については、Oracleデータベース(単一インスタンスまたはOracle RACデータベース)とユーザー・アプリケーション(OracleおよびOracle以外)をOracle Clusterwareの管理と保護の下に置いて、プロセス障害時にはデータベースとアプリケーションが再起動し、ノード障害後には別のノードへのフェイルオーバーが行われるようにすることができます。
クラスタ管理については、複数の独立したサーバーがまるで単一システムのイメージまたは単一の仮想サーバーであるかのように示されます。この単一の仮想サーバーは、すべての管理操作に対してクラスタ全体で維持されるため、管理者はインストール、構成、バックアップ、アップグレードおよび監視の機能を実行できます。その後、Oracle Clusterwareが、これらの管理機能の実行を、クラスタ内の該当するノードに自動的に分散します。
Oracle Clusterwareは、Oracle RACを使用するための要件です。Oracle RACが動作するほとんどのプラットフォームにおいて、必要なクラスタウェアはOracle Clusterwareのみです。Oracle Databaseでは引き続きサード・パーティのクラスタウェア製品を指定されたプラットフォームでサポートしますが、Oracle Clusterwareを使用すれば、次の主な利点があります。
ベンダー独自開発のクラスタウェアが不要
ローカルまたはリモートのOracle Automatic Storage Management(Oracle Flex ASM)によるディスク管理を提供するOracleから、Oracle DatabaseおよびOracle RACによるデータ管理まで、統合ソフトウェア・スタックを使用
Oracle Flex Clusterと呼ばれる大規模クラスタに構成可能
さらに、OracleサービスなどのOracle Database機能では、Oracle Clusterwareの基本的なメカニズムを使用して、それらの機能を提供します。
Oracle Clusterwareには2つのクラスタウェア・コンポーネントが必要です。1つはノード・メンバーシップ情報を記録する投票ディスク、もう1つはクラスタ構成情報を記録するOracle Cluster Registry(OCR)です。投票ディスクとOCRは共有ストレージに存在する必要があります。Oracle Clusterwareでは、各ノードがプライベート・インターコネクト経由でプライベート・ネットワークに接続されている必要があります。
|
関連項目: 『Oracle Real Application Clusters管理およびデプロイメント・ガイド』 |
Oracle Clusterwareには次のような利点があります。
コンピュータおよびインスタンス障害を許容し、迅速にリカバリします。
Oracle ClusterwareとOracle Databaseの併用により、管理およびサポートを単純に行えます。少数のベンダーとすべてのOracleスタックを使用することで、サード・パーティ・クラスタウェアを使用した場合より優れた統合を得られます。
システム変更およびハードウェア変更のローリング・アップグレードを実行します。たとえば、ローリング方式で、Oracle Clusterwareのアップグレード、パッチ・セットおよび個別パッチを適用できます。
Oracle Database 12cにアップグレードすると、Oracle ClusterwareおよびOracle ASMバイナリがOracle Grid Infrastructureという1つのバイナリとしてインストールされます。Oracle Clusterwareは、Oracle Clusterware 10gおよびOracle Clusterware 11gからローリング方式でアップグレードできますが、Oracle ASMはOracle Database 11gリリース1(11.1)からの場合のみローリング方式でアップグレードできます。
エラーが発生したOracleプロセスを自動的に再開。
仮想IP(VIP)アドレスを自動的に管理。ノードに障害がある場合、そのノードのVIPアドレスは、VIPアドレスが接続を受け入れられる他のノードにフェイルオーバーされます。
障害が発生したノードのリソースを残りのノードで自動的に再開。
Oracleプロセスを次のように制御します。
Oracle RACデータベースの場合、すべてのOracleプロセスはデフォルトでOracle Clusterwareによって制御されます。
単一インスタンスのOracleデータベースの場合、Oracle Clusterwareで制御されるリソース・グループへのOracleプロセスを構成できます。
OracleアプリケーションおよびOracle以外のアプリケーションの場合、Application Programming Interface(API)が提供され、Oracle Clusterwareによるその他のOracleプロセス(再開、または障害や特定のルールへの応答など)を制御できます。
ノードのメンバーシップを管理し、2つ以上のインスタンスがデータベースを制御する際のスプリット・ブレイン・シンドロームを防止。
アプリケーションの停止時間ゼロで、Oracle Clusterwareのローリング・リリース・アップグレードの実行が可能。
|
関連項目: 『Oracle Clusterware管理およびデプロイメント・ガイド』 |
Oracle RACとOracle Clusterwareの併用には、3.6.1項に示したOracle Clusterwareのすべての利点に加え、次のような利点があります。
すべてのOracleソフトウェア・スタックを使用することで、サード・パーティ・クラスタウェアを使用した場合より優れたOracle Databaseの統合およびサポートを提供します。
Oracle Serviceの自動的再配置。さらに、高速アプリケーション通知(FAN)とクライアント構成を追加で実行する場合は、高速かつ自動のインテリジェントな接続とフェイルオーバーを実現するために、アプリケーションが素早く反応できるようなFANイベントの配信。
接続障害を高速に自動検出し、Oracle Universal Connection Pool(Oracle UCP)、高速接続フェイルオーバーおよびFANイベントを使用するJavaアプリケーションの終了済接続を削除します。
Oracle UCP、Oracle Call Interface(OCI)およびOracle Data Provider for .NET(ODP.NET)でランタイム接続ロード・バランシングを使用します。
停止時間またはアプリケーションへの変更なしで、汎用ハードウェアを使用して処理能力を向上できる柔軟性を提供します。
データベースおよびクラスタの機能を統合する包括的な管理性を提供します。
データベース・インスタンス全体にわたるスケーラビリティを提供します。
停止時間またはアプリケーションへの変更なしで、汎用ハードウェアを使用して処理能力を向上できる柔軟性
アプリケーションの停止を、コールド・クラスタ・ソリューションの場合の数分から数時間と比べて、ゼロまたは数秒にすることが可能
結合またはその他のテクノロジを使用せずに、冗長ネットワーク・インタフェースを使用したクラスタでの通信を最適化
Oracle Grid InfrastructureおよびOracle RACによる、ネットワーク・トラフィックを分散し、クラスタ内の最適な通信を保証する冗長インターコネクトの使用。この機能はOracle Database 11gリリース2(11.2.0.2)から使用可能になりました。それまでのリリースでは、結合またはトランキングのようなテクノロジを使用してインターコネクト用の冗長ネットワークを使用していました。
データベースおよびクラスタの機能を統合する包括的な管理性(グリッド・プラグ・アンド・プレイ、およびポリシーに基づくクラスタ管理と容量管理を使用)
ロード・バランシング・アドバイザおよびランタイム接続ロード・バランシングによる、適切なリソース全体での作業のリダイレクトおよび均等な分散
データベース・ワークロードへのリソース割当てをポリシーベースでランタイム管理するためのOracle Quality of Service(QoS)管理(動的状況下でのビジネス・ニーズの順にサービス・レベルが満たされます)。これはデータベースが実行しているサーバー・プールにサービスを割り当てることにより行われます。プールからのリソースを使用して、必要な容量が使用可能になるようにします。
Oracle Enterprise Managementによる、Oracle ASMおよびOracle ACFS、グリッド・プラグ・アンド・プレイ、クラスタ・リソース管理、Oracle ClusterwareとOracle RACのプロビジョニングとパッチ適用のサポート。
Oracle RACに接続しているクライアントへの単一の名前としての、SCAN(単一クライアント・アクセス名)サポート。この名前は、クラスタのノードを追加または削除しても、クラスタの存続期間中は変更されません。
図3-2は、Oracle RAC使用のOracle Databaseアーキテクチャを示しています。この図は、パーティション化された3つのノードからなるデータベースの、Oracle RACを使用したOracle Databaseアーキテクチャを示しています。Oracle RACデータベースは、異なるノード上の3つのインスタンスに接続されています。各インスタンスは、サービス(人事、販売およびコール・センター)に関連付けられています。インスタンスはハートビートを確認することでお互いを監視します。Oracle Net Servicesは、図の最上部にあるアプリケーション/Webサーバー層へのクライアント・アクセスを提供します。
Oracle Real Application Clusters One Node(Oracle RAC One Node)は、クラスタ内の1つのノードで実行されるOracle RACデータベースの単一インスタンスです。この機能により、最小限のオーバーヘッドで多数のデータベースを1つのクラスタに統合し、計画済および計画外の両方の停止から保護することができます。統合されたデータベースはフェイルオーバー保護、アプリケーションのオンライン・ローリング・パッチ適用、オペレーティング・システムおよびOracle Clusterwareのローリングアップグレードという、高可用性の利点を得ます。
Oracle RAC One Nodeでは、オンライン・データベース再配置と呼ばれるOracleテクノロジにより、単一インスタンス・データベースのコールド・フェイルオーバーよりも高い可用性が可能になります。このテクノロジは高可用性とロード・バランシングのためにデータベース・インスタンスと接続を別のクラスタ・ノードへとインテリジェントに移行します。オンライン・データベース再配置はServer Control Utility(SRVCTL)を使用して実行されます。
Oracle RAC One Nodeでは次のことが提供されます。
単一インスタンス・データベース・サービスが常に使用可能
高可用性のための組込みクラスタ・フェイルオーバー
サーバーをまたがるインスタンスのライブ・マイグレーション
単一インスタンス・データベースに対するオンライン・ローリング・パッチ適用およびローリング・アップグレード
単一インスタンスから複数インスタンスOracle RACへのオンライン・アップグレード
データベース・サーバーの優れた統合
拡張されたサーバーの仮想化
完全Oracle RACの開発およびテスト・プラットフォームのコストの低減
Data Guardとともに構成されているOracle RACプライマリおよびスタンバイ・データベースの再配置。この機能はOracle Database 11gリリース2(11.2.0.2)から使用可能になりました。
また、Oracle RAC One Nodeはデータベース記憶域の統合を促進し、データベース環境を標準化し、必要な場合は、完全な複数インスタンスOracle RACデータベースに停止時間または中断なしに移行することができます。
Oracle ASMは、垂直方向に統合されたファイル・システムおよびボリューム・マネージャを直接Oracle Databaseカーネル内に構築し、次の機能を提供します。
データベース・ストレージのプロビジョニングに必要な作業量を大幅に削減
より高いレベルの可用性
特殊なストレージ製品のコスト、インストールおよびメンテナンスを排除
データベース・アプリケーションの固有の機能
最適なパフォーマンスを実現するため、Oracle ASMは、ファイルをすべての使用可能なストレージ間で分散させます。また、データ損失から保護するために、Oracle ASMは、SAME(Stripe and Mirror Everything)の概念を拡大して、ディスク全体のレベルではなくデータベース・ファイル・レベルでのミラー化が可能となるように、SAMEにより柔軟性を持たせます。
さらに重要なことに、Oracle ASMは、ミラー化の設定、ディスクの追加および削除プロセスを簡素化します。数百または数千にもなりうる(大規模なデータ・ウェアハウスの場合)多数のファイルを管理するかわりに、データベース管理者は、Oracle ASMを使用してディスク・グループと呼ばれるさらに大きなオブジェクトを作成および管理します。ディスク・グループは、論理ユニットとして管理されるディスク・セットを識別します。ファイルの名前付け、および基礎となるデータベース・ファイルの配置を自動化することにより、データベース管理者の時間を節約でき、標準的なベスト・プラクティスの適用を保証できます。
Oracle ASMネイティブ・ミラー化メカニズム(2方向または3方向)がストレージ障害から保護します。Oracle ASMミラー化を使用して、障害グループを使用する場合により高いレベルのデータ保護を実現できます。障害グループとは、障害が許容される、共通のリソース(ディスク・コントローラまたはディスク・アレイ全体)を共有するディスク・セットのことです。Oracle ASMの障害グループを定義することで、データの冗長コピーが個別の障害グループにインテリジェントに配置されます。これにより、ストレージのサブシステム内のいずれかのコンポーネントで障害が発生した場合でも、このデータを使用でき、また、透過的に保護されるようになります。
ドライブおよびストレージ・アレイ間でのミラー化とストライプ化
障害が発生したドライブから残りのドライブへの自動再ミラー化
データベースがオンラインのまま、ディスクの追加または削除時に格納されたデータの自動リバランスが可能
Oracle Automatic Storage Managementクラスタ・ファイル・システム(Oracle ACFS)を使用したOracleデータベース・ファイルおよびデータベース以外のファイルのサポート
データベース・ストレージ管理の操作の簡素化が可能
Oracle Cluster Registry(OCR)および投票ディスクの管理
インスタンスのローカル・ディスク上の優先読取り機能による、拡張クラスタのパフォーマンスの向上
大規模データベースのサポート
Oracle ASMローリング・アップグレードのサポート
ミラー・ディスクを使用したロジカル・データ破損の検出および修復のためのOracle ASMディスクのスクラブ・プロセスを使用した可用性と信頼性の向上
ミラーのいずれかに適切なコピーが存在する場合、Oracle ASMの高速ミラー再同期およびブロック破損自動修復の機能を使用した、一時的なディスク障害発生後の高速修復を提供
Oracle ACFSのネットワーク経由でのリモート・サイトへのレプリケーションを可能にすることにより、ファイル・システムの障害時リカバリ機能を提供
Oracle Flex ASMを使用して、サービス中のクライアントに影響を与えることなく、Oracle ASMインスタンスのパッチを適用します。接続されている現在のOracle ASMインスタンスが計画メンテナンスでオフラインになっている間、データベース・インスタンスは、別の場所からOracle ASMメタデータにアクセスするように指定できます。
Oracle ASMディスク再同期化およびリバランス操作の速度と状態の監視および管理
Oracle ASM再同期化の指数制限を使用して再同期化の並列度を制御することにより、複数のディスクを同時にオンラインにし、パフォーマンスをより適切に管理します。セルまたはディスクの障害、および再同期を実行中のインスタンスのエラーの後の高速リカバリ。再同期化を最初から始めるかわりに中断または停止した時点から再開することができるディスク再同期チェックポイントを使用することでこれが可能です。
Oracle Flex ASMを使用したデータベース・インスタンスの別のOracle ASMインスタンスへの自動的な接続計画外停止によりOracle ASMインスタンスに障害が発生した場合、ローカル・データベース・インスタンスは必要なメタデータおよびデータに引き続きアクセスできます。
|
関連項目: ACFSの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。 |
高速リカバリ領域は、Oracle Database内のすべてのリカバリ関連ファイルおよびアクティビティを対象とした一元的な格納場所です。この機能を有効にすると、すべてのRMANバックアップ、アーカイブREDOログ・ファイル、制御ファイルの自動バックアップ、フラッシュバック・ログおよびデータ・ファイルのコピーが自動的に特定のファイルシステムまたはOracle ASMディスク・グループに書き込まれ、このディスク領域はRMANとデータベース・サーバーによって管理されます。
高速リカバリ領域を使用するとテープへの書込みのボトルネックが解消されるため、ディスクへのバックアップ実行が高速化されます。さらに重要なことに、データベースのメディア・リカバリを行う必要がある場合は、データ・ファイルのバックアップがすぐに使用できます。必要なデータ・ファイルおよびアーカイブREDOログ・ファイルをリストアするためのテープおよび空きテープ・デバイスを見つける必要がないため、リストアおよびリカバリの時間が短縮されます。
関連リカバリ・ファイルの格納場所の一元化
リカバリ・ファイルに割り当てられたディスク領域を管理し、データベース管理タスクを簡素化
高速で信頼性の高いディスクベースのバックアップおよびリストア
|
関連項目: 『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』 |
データ・ブロック破損は、業務に多大の悪影響をおよぼし、修復が困難なことがあります(1.4項(「停止時間の原因」)を参照)。破損が発生すると、アプリケーションやデータベースに重大な停止時間が生じる原因になることがあります。悪くすると数時間、数日、場合によっては数週にわたり破損が気づかれず、検出後に、さらに長いアプリケーション停止時間を招くことがあります。あいにく、破損のソースおよび原因はメモリー、ハードウェア、ファームウェア、記憶域、オペレーティング・システム、ソフトウェアまたはユーザー・エラーのどこにでも存在する可能性があるので、データベース内のデータ破損を包括的に防止、検出および修復する手段は存在しません。さらに悪いことには、Oracleデータ・ブロックのセマンティクスやOracleのデータ・ブロックの変更方法を理解していないサード・パーティのソリューションでは、データ・ブロック破損の防止および検出ができません。サード・パーティのリモート・ミラーリング・テクノロジは、データ破損をデータベース・レプリカ(スタンバイ)に伝播する可能性があり、これは二重障害、データ損失および停止時間の長期化につながります。
Oracle MAAには、物理ブロック破損、論理ブロック破損、逸脱した書込みおよび書込みの欠落を含む、あらゆる形のデータ・ブロック破損を防止、検出および修復する包括的な計画があります。これらの追加の保護手段は、最も包括的なOracleデータ・ブロック破損の防止、検出および修復ソリューションを提供します。この計画の詳細は、My Oracle Supportのノート「Data Guard構成における破損の検出、防止および自動修復のベスト・プラクティス」に記載されています。
表3-1に、様々な手動操作チェック、およびランタイムやバックグラウンドの破損チェックに対するブロック破損チェックをまとめます。データベース管理者と作業チームは、RMANバックアップの実行、RMANのCHECK LOGICAL検証、または重要なオブジェクトに対するANALYZE VALIDATE STRUCTUREコマンドの実行など、手動チェックを組み込むことができます。手動チェックは、更新や問合せがあまり行われないデータを検証する際に、特に重要です。
ランタイム・チェックは、問合せや更新が頻繁に行われるデータの破損を、即座にまたはランタイムに検出する点で非常に優れています。ランタイム・チェックにより、破損が回避されたり、自動的に修正されたりするため、より強力にデータを保護し、アプリケーションの可用性をさらに高めることが可能です。Exadataに新しいバックグラウンド・チェックが導入され、アプリケーション・オーバーヘッドなしで、ディスクのスキャンと修正が自動的かつインテリジェントに行われ、物理的に破損したブロックは自動的に修正されます。
表3-1 ブロック破損チェックの概要
| チェック | 機能 | 物理ブロック破損 | 論理ブロック破損 |
|---|---|---|---|
|
手動チェック |
Dbverify、Analyze |
物理的ブロック・チェック |
ブロック内およびオブジェクト間の論理的な一貫性チェック |
|
手動チェック |
RMAN |
バックアップおよびリストア操作中の物理的ブロック・チェック |
ブロック内論理チェック |
|
手動チェック |
ASMの修正 |
物理的ブロック・チェック |
ブロック内の複数の論理チェック |
|
ランタイム・チェック |
Oracle Active Data Guard |
1. 転送および適用中に、物理的ブロック・チェックをスタンバイにおいて継続的に実行 2. 強力なデータベース分離により、データベースの単一点障害を排除 3. ブロック破損の自動修復 4. データベースの自動フェイルオーバー |
1. DB_LOST_WRITE_PROTECTが有効化されている場合、書込み欠落を検出(11.2以降)。11.2.0.4およびData Guard Brokerでは、プライマリ・データベースで書込み欠落が検出された場合に、プライマリを停止可能。 2. スタンバイでDB_BLOCK_CHECKINGが有効化されている場合、ブロック内の追加の論理チェックが可能 |
|
ランタイム・チェック |
データベース |
DB_BLOCK_CHECKSUMにより、インメモリー・データ・ブロックおよびREDOチェックサムを検証 |
DB_BLOCK_CHECKINGにより、インメモリーのブロック内チェックを検証 |
|
ランタイム・チェック |
ASM |
書込み中に、正常なASMエクステント・ブロックのペアが存在する場合、読取りおよび書込みの暗黙的なデータ破損検出と自動修復を実行 |
|
|
ランタイム・チェック |
DIX + T10 DIF |
オペレーティング・システムからHBAコントローラ、ディスク(ファームウェア)に至るまでのチェックサム検証。認定済のLinux、HBAおよびディスクに対する読取りと書込みを検証。 |
|
|
ランタイム・チェック |
ハードウェアおよびストレージ |
Oracle統合が行われていないため、限定的なチェック。チェックサムが最も一般的。 |
Oracle統合が行われていないため、限定的なチェック。チェックサムが最も一般的 |
|
ランタイム・チェック |
Exadata |
書込みに対する包括的なHARDチェック |
書込みに対するHARDチェック |
|
バックグラウンド・チェック |
Exadata |
ハード・ディスクの自動修正および修復。不良セクターの検出および修正。 |
|
関連項目:
|
データ・リカバリ・アドバイザは、永続的な(ディスク上の)データ障害を自動的に診断し、適切な修復オプションを示し、リクエストに応じて修復操作を実行します。
データ・リカバリ・アドバイザを使用して、プライマリ・データベース、ロジカル・スタンバイ・データベース、フィジカル・スタンバイ・データベースおよびスナップショット・スタンバイ・データベースをトラブルシューティングできます。
データ・リカバリ・アドバイザには、次の機能があります。
障害診断
通常、データベース障害の最初の兆候は、エラー・メッセージ、アラーム、トレース・ファイルおよびダンプ、ヘルス・チェックの失敗などです。これらの兆候を評価する作業はたいてい複雑で間違いやすく、時間がかかります。データ・リカバリ・アドバイザを使用すると、データ障害が自動的に診断され、これらの詳細が通知されます。
障害の影響の評価
障害の診断後、修復戦略について検討する前に、障害の範囲を把握し、アプリケーションに与える影響を評価する必要があります。データ・リカバリ・アドバイザを使用すると、障害の影響が自動的に評価され、わかりやすい形式でその結果が表示されます。
修復の生成
障害が正しく診断されたとしても、正しい修復方法の選択は容易ではなく、負担になります。さらに、判断を誤ると、停止時間の増加やデータ損失という点で大きな不利益を被ることになります。データ・リカバリ・アドバイザは、自動的に一連の障害に関する最善の修復方法を判断して提示します。
修復の実行可能性チェック
データ・リカバリ・アドバイザでは、修復オプションが示される前に、特定の環境や提案される修復処理を完了するために必要なメディア・コンポーネントの可用性に関して、ファイルをプライマリまたはスタンバイ・データベースから直接リストアして提案された修復を完了するなどの、これらの修復オプションが検証されます。
修復の自動化
提示された修復オプションを使用すると、この修復オプションが自動的に実行され、修復が成功したかどうかが検証されて、該当する障害が処置済となります。
データの整合性およびデータベースのリカバリ可能性の検証
データ・リカバリ・アドバイザでは、選択すればいつでも、データ、バックアップおよびREDOストリームの整合性を検証できます。
破損の早期検出
状態モニターを使用して、データ・リカバリ・アドバイザによる診断チェックを定期的に実行するようスケジュール設定できます。これにより、トランザクションを実行しているデータベース・プロセスによって破損が検出されてエラーが通知される前に、データ障害を検出できます。早期の警告により、破損による損害を制限できます。
データの検証および修復の統合
データ・リカバリ・アドバイザは、データの検証および修復用の単一のツールです。
|
注意: データ・リカバリ・アドバイザでは、単一インスタンス・データベースのみがサポートされています。Oracle RACデータベースはサポートされていません。データ・リカバリ・アドバイザでサポートされているデータベース構成の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
|
関連項目: 『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』 |
人的エラーに対する最大の保護とは、その発生を防ぐことです。人的エラーの最高の保護方法は、ユーザー・アクセスを、ビジネス機能の実行に必要なデータおよびサービスのみに限定することです。Oracle Databaseでは、データベース・ユーザーの認証によりアプリケーション・データへのアクセスを制御し、管理者が任務の遂行に必要な権限のみをユーザーに与えることができる多種多様なセキュリティ・ツールを提供しています。
さらに、Oracle Databaseのセキュリティ・モデルでは、Oracle Virtual Private Databaseを使用して行レベルにデータ・アクセスを制限し、アクセスする必要がないデータをデータベース・ユーザーから分離することが可能です。
Oracle Databaseには次のようなセキュリティ上の利点があります。
ネットワーク、データベースおよびアプリケーションを使用したエンティティのアイデンティティを検証するための認証制御。データベース間のネットワーク・セッション(REDO転送セッションなど)も認証されます。
データベース・ユーザー・アイデンティティおよびロールにリンクされているアクセスおよびアクションを制限するための認証制御。
オブジェクトへのアクセスを制御し、エンティティの要求がオブジェクトに対するアクセスまたは変更のいずれであろうとオブジェクトを保護。
特定のデータベース・アクティビティに関するデータの監視および収集、不審なアクティビティの調査、ユーザー(またはその他)の不適切なアクティビティの防止、および認証あるいはアクセス制御の実装による問題の検出を行う監査制御。
SYSDBA権限が付与されないクラスのユーザーに、Data Guard構成の管理を委任することができます。
|
関連項目:
|
Oracle Flashbackテクノロジは、Oracle Database機能のグループで、データベース、データベース・オブジェクト、トランザクションまたは行の過去の状態を表示し、データベース、データベース・オブジェクト、トランザクションまたは行を、ポイント・イン・タイム・メディア・リカバリを使用せずに前の状態に戻すことができます。
フラッシュバック機能を使用すると、次のことができます。
過去のある時点でのデータの様子を表示する問合せの実行
データベースに対する変更の詳細履歴を示したメタデータを戻す問合せを実行します。
表または行を前の時点にリカバリします。
トランザクション・データの変更を自動的に追跡およびアーカイブします。
データベースがオンラインである間にトランザクションおよびその依存トランザクションをロールバックします。
表の削除取消
リストア操作なしでのポイント・イン・タイムへのデータベースのリカバリ
フラッシュバック・データベース機能以外に、ほとんどのOracle Flashback機能では、自動UNDO管理(AUM)システムにより、トランザクションに関するメタデータおよび履歴データが取得されます。フラッシュバック機能はUNDOデータに依存します。UNDOデータは、個々のトランザクションの結果のレコードです。たとえば、ユーザーが給与を1000から1100に変更するUPDATE文を実行すると、Oracle DatabaseによってUNDOデータに値1000が格納されます。
UNDOデータは永続的であり、データベース停止時にも失われません。フラッシュバック機能を使用すると、UNDOデータを使用して過去のデータを問い合せたり、論理的な損害をリカバリしたりすることができます。UNDOデータは、フラッシュバック機能以外でも、Oracle Databaseによって次の処理に使用されます。
アクティブなトランザクションのロールバック
データベースまたはプロセス・リカバリを使用した終了済トランザクションのリカバリ
SQL問合せに対する読取り一貫性の提供
Oracle Flashbackは、不注意または悪意でデータを変更し、不正なインストールおよびアップグレードの原因となり、アプリケーションでのロジカル・エラーを招く様々なヒューマン・エラーまたはオペレータによるエラーにより損なわれたデータに対処して巻き戻すことができます。これらの問題は次の各フェーズで対処され、フラッシュバック・トランザクション、フラッシュバック・ドロップ、表のフラッシュバック、データベースのフラッシュバックなどの機能を使用します。
フェーズ1: 通常はアプリケーションにより実行されるロジカル・エラーの検出
フェーズ2: フラッシュバック問合せ、フラッシュバック・バージョン問合せ、フラッシュバック・トランザクション問合せおよびDBMS_FLASHBACKパッケージなどの機能を使用した調査。
フェーズ3: エラー・リカバリ。
Oracle Flashback Query (フラッシュバック問合せ)では、自動UNDO管理システムを利用してトランザクションのメタデータおよび履歴データを取得することで、過去に存在したデータを表示できます。UNDOデータは永続的で、データベースの異常や停止の際にも失われません。フラッシュバック問合せの独自の機能により、表の以前のバージョンの問合せが可能になり、誤った操作からリカバリするための強力なメカニズムも提供されます。
フラッシュバック問合せの用途は次のとおりです。
失われたデータをリカバリしたり、コミット済の不適切な変更を取り消す場合。たとえば、削除または更新された行を、コミット後でもただちに修復できます。
現行のデータと過去のある時点の対応するデータとを比較します。たとえば、前日のデータの変更を示す日次レポートを使用すると、表データの個々の行を比較したり、一連の行の共通部分または和集合を検索したりできます。
特定の日の勘定残高を確認するなど、ある時点におけるトランザクション・データの状態をチェックします。
特定のタイプの一時データを格納する必要をなくすことで、アプリケーションの設計を簡素化します。フラッシュバック問合せを使用すると、過去のデータをデータベースから直接取得できます。
レポート生成ツールなどのパッケージ・アプリケーションを過去のデータに適用します。
アプリケーションのセルフサービス・エラー修正を実現し、ユーザーが自分のエラーの取消しおよび修正を行えるようにします。
|
関連項目: Oracle Database開発ガイド |
Oracle Flashback Version QueryはSQLの拡張機能で、特定の表から特定の期間に存在した行のバージョンを取得するために使用できます。Oracle Flashback Version Queryでは、指定期間に存在した行のバージョンごとに1行が返されます。どの表についても、COMMIT文が実行されるたびに行のバージョンが新たに作成されます。
Oracle Flashback Version Queryは、データベース管理者が問題の原因特定の分析を実行するために使用できる強力なツールです。さらに、アプリケーション開発者はOracle Flashback Version Queryを使用して、監査目的のカスタム・アプリケーションを作成できます。
|
関連項目: Oracle Database開発ガイド |
Oracle Flashback Transactionは、トランザクションとその依存トランザクションをバックアウトします。DBMS_FLASHBACK.TRANSACTION_BACKOUT()プロシージャは、データベースがオンラインのまま、トランザクションとその依存トランザクションをロール・バックします。このリカバリ操作ではUNDOデータを使用して、影響を受けたデータを元の状態に戻す補正トランザクションを作成および実行します。DBA_FLASHBACK_TRANSACTION_STATEビューに問い合せることで、トランザクションが依存ルールを使用してバックアウトされたか、次のいずれかで強制的に取り消されたかを確認できます。
競合していない行のバックアウト
UNDO SQLの適用
Oracle Flashback Transactionでは、特定のトランザクション、またはトランザクションのセットとその依存トランザクションを迅速にバックアウトすることにより、論理リカバリ時の可用性が向上します。データベースがオンラインのまま、1つのコマンドを使用してトランザクションをバックアウトします。
|
関連項目:
|
Oracle Flashback Transaction Queryは、データベースに加えられたすべての変更をトランザクション・レベルで表示するためのメカニズムを提供します。Oracle Flashback Version Queryと併用した場合、人的エラーまたはアプリケーションのエラーからリカバリする高速で効率的な手段となります。Oracle Flashback Transaction Queryでは、行を変更したデータベース・ユーザーが返されるため、データベースの問題のオンライン診断を実行する能力が強化されます。また、トランザクションの分析および監査も実行されます。
|
関連項目: Oracle Database開発ガイド |
Oracle Flashback Tableを使用すると、過去のある時点の状態に表をリカバリできます。人的エラーまたはアプリケーションのエラーによって変更された1つの表または一連の表をリカバリするための高速なオンライン・ソリューションを提供します。ほとんどの場合、Oracle Flashback Tableを使用することで、管理者がより複雑なポイント・イン・タイム・リカバリ操作を実行する必要性は軽減されます。元の表のデータは、Oracle Flashback Tableを使用すると表を元の状態に戻せるため失われません。
|
関連項目: 『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』 |
オブジェクトの誤った削除は、データベース・ユーザーにも、データベース管理者にも問題です。削除された表、索引、制約またはトリガーをリカバリする簡単な方法はありませんが、Oracle Flashback Dropでは、オブジェクトを削除する際の安全策が提供されます。表を削除すると、その表は自動的にごみ箱に入ります。ごみ箱は、すべての削除済オブジェクトが入っている仮想コンテナです。削除した表のデータは、引き続き問い合せることができます。
|
関連項目: 『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』 |
Oracle Flashbackのリカバリ操作がデータベースで実行されるとき、DBAは、適切な時間内に(システム変更番号(SCN)またはタイムスタンプで識別)、後でフラッシュバック可能なポイントを決定する必要があります。Oracle Flashbackのリストア・ポイントとは、フラッシュバック・データベース、フラッシュバック表およびOracle Recovery Manager(RMAN)操作で使用されるSCNまたはトランザクション時間に置き換えるためにユーザーが定義できるラベルです。さらに、データベースは、前回のデータベースのリカバリを通じてフラッシュバックでき、保証されたリストア・ポイントを使用して、OPEN RESETLOGSコマンドと同様に開くことができます。保証されたリストア・ポイントを使用して、データベースの巻戻しに必要なUNDOが保存されるようにすることで、データベースのバッチ・ジョブ、アップグレードまたはパッチなどの主なデータベース変更を素早く元に戻すことができます。
リストア・ポイント機能を使用すると、次の利点があります。
一貫性のある状態、つまり失敗した計画操作(バッチ・ジョブ、Oracleソフトウェア・アップグレードまたはアプリケーション・アップグレードの失敗など)より前の適切なポイントに素早くリストアすることが可能
スナップショット・スタンバイ・データベースをプライマリ・データベースと再同期させる機能
テスト・データベースまたはクローン化されたデータベースを元の状態に戻す迅速なメカニズム
|
関連項目: 『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』 |
Oracle Flashback Databaseは高速巻戻しボタンのようなもので、データベースを過去の時点にすばやく巻き戻します。バックアップやアーカイブ・ログを使用したリストアやロール・フォワードに時間をかける必要がありません。データベースのサイズが大きくなるほど、Oracle Flashback Databaseを使用する高速なポイント・イン・タイム・リカバリの利点も大きくなります。
Oracle Flashback Databaseを有効にすると、次の利点があります。
ポイント・イン・タイム・リカバリで論理破損(管理エラーを原因とする破損など)を高速に修復。
Oracleリストア・ポイントと組み合わせた反復テストに便利。リストア・ポイントの設定、データベースの変更の実装、影響を評価するためのワークロードのテスト実行が可能。Oracle Flashback Databaseを使用して、変更を破棄して元の起点に戻り、別の変更を行ってから、同じワークロードでもう一度テスト実行することで、正当な基盤に基づいて異なる構成変更の影響を比較することができます。
Data GuardはOracle Flashback Databaseを使用して、障害の発生したプライマリ・データベースを、(フェイルオーバー後に)新しいスタンバイとしてすばやく再インスタンス化します(障害の発生したプライマリをバックアップからリストアする必要はありません)。
マルチテナント環境では、コンテナ・データベース・レベルでフラッシュバック・データベースが実行されます。すべてのPDBが一緒にフラッシュバックされます。
|
関連項目:
|
自動的な破損ブロック修復の試行後、ブロック・メディア・リカバリ機能で、フラッシュバック・ログからデータ・ブロックの最新コピーを必要に応じて取得して、リカバリ時間を短縮できます。自動ブロック修復を使用すると、検出されたプライマリ・データベースの破損ブロックをフィジカル・スタンバイ・データベースの良好なブロックを使用してただちに自動修復できます。
その上、インスタンスのリカバリで発生した破損ブロックによってインスタンスのリカバリが失敗することはありません。このようなブロックは破損として自動的にマークされ、V$DATABASE_BLOCK_CORRUPTION表のRMANの破損リストに追加されます。その後、RMANのRECOVER BLOCKコマンドを発行して関連ブロックを修正できます。また、フィジカル・スタンバイ・データベースが使用可能な場合には、RMAN RECOVER BLOCKコマンドはフィジカル・スタンバイ・データベースからブロックをリストアします。
|
関連項目:
|
Oracle Data Pumpテクノロジを使用すると、データおよびメタデータをデータベース間で非常に高速に移動できます。Data Pumpは、次の計画メンテナンス・アクティビティを実行するために使用されます。
異なるプラットフォームへのデータベース移行
プラガブル・データベースへのデータベース移行
データベース・アップグレード
この計画メンテナンス用テクノロジの使用法の詳細は、5.4項「システムおよびソフトウェア・メンテナンス用Oracle高可用性ソリューション」を参照してください。
前述の計画メンテナンス・アクティビティを可能にするData Pump機能は次のとおりです。
データベース全体を異なるデータベース・インスタンスに移動するフル・トランスポータブル・エクスポート/インポート
データベース間で一連の表領域を移動するトランスポータブル表領域
表3-2は、データベース以外のファイルに対するOracleレプリケーション・テクノロジの説明です。
表3-2 データベース以外のファイルに対するOracleレプリケーション・テクノロジ
| テクノロジ | 推奨される使用方法 | コメント |
|---|---|---|
|
|
Exadata Database Machineシステムまたはデータベースおよびデータベース以外のシステム間で完全な同期が必要な場合に推奨 |
|
|
|
Oracle ASM、Oracle ClusterwareおよびOracle Enterprise Managerテクノロジと統合された単一ノードおよびクラスタ全体のファイルシステム・ソリューションの提供を推奨 |
|
|
Oracle Solaris ZFS Storage Applianceレプリケーション |
データベース以外のファイルに対する障害時リカバリ保護、特にOracle Fusion Middlewareのデータベース外に保存されたクリティカル・ファイルに推奨します。 |
|
Oracle Database File System(DBFS)は、ファイルを格納するデータベースの利点と、リレーショナル・データを効率的に管理するデータベースの強度を活用して、データベースに格納されたファイルに対する標準のファイルシステム・インタフェースを実装します。このインタフェースを使用すると、BLOBおよびCLOBプログラム・インタフェースを使用するために特別に記述されたプログラムに制限されずに、データベースにファイルを格納できるようになります。これで、ファイルに作用する任意のオペレーティング・システム(OS)プログラムを使用して、データベース内のファイルに透過的にアクセスできるようになります。たとえば、ETL(抽出、変換およびロード)ツールは、ステージング・ファイルを透過的にデータベースに格納します。
Oracle DBFSには次のような利点があります。
フルスタックの統合リカバリおよびフェイルオーバー: ファイル・システムをデータベース構造に格納することにより、データベース・オブジェクトとファイル・システム・データの両方のポイント・イン・タイム・リカバリの容易な実行が可能です。
障害時リカバリ・システムの投資利益率(ROI): DBFSに含まれるファイルへのすべての変更も、OracleデータベースのREDOログ・ストリーム経由で記録され、Data Guardフィジカル・スタンバイ・データベースに渡すことができます。Oracle Active Data Guardテクノロジを使用して、DBFSファイル・システムは、ソースとしてフィジカル・スタンバイ・データベースを使用して読取り専用でマウントできます。プライマリでの変更はスタンバイ・データベースに伝播され、スタンバイに適用されると表示できます。
ファイル・システム・バックアップ: DBFSはデータベースにデータベース・オブジェクトとして格納されるので、標準RMANバックアップおよびリカバリ機能をファイル・システム・データに適用できます。データベースまたはデータベース内オブジェクト上で実行できるバックアップ、リストアまたはリカバリ操作は、DBFSファイルシステムに対して実行することもできます。
Oracle ASMクラスタ・ファイル・システム(ACFS)は、マルチプラットフォームのスケーラブル・ファイルシステムであり、Oracle Automatic Storage Management(Oracle ASM)機能を拡張して、Oracle Databaseの外部で保持されているカスタマ・ファイルをサポートするストレージ管理テクノロジです。Oracle ACFSでは、実行可能ファイル、データベース・トレース・ファイル、データベース・アラート・ログ、アプリケーション・レポート、BFILE、構成ファイルなど、様々なデータベース・ファイルおよびアプリケーション・ファイルがサポートされます。他にも、ビデオ、オーディオ、テキスト、イメージ、設計図、その他の汎用アプリケーションのファイル・データがサポートされます。
Oracle ACFSでは次のOracle ASM機能を利用できます。
Oracle ACFSの動的なファイル・システムのサイズ変更
Oracle ASMディスク・グループ・ストレージへの直接アクセスによるフォーマンスの最大化
I/Oの並列性向上によるOracle ASMディスク・グループ・ストレージ全体でのOracle ACFSの分散の平均化
Oracle ASMミラー化保護メカニズムによるデータの信頼性の確保
Oracle ACFSの追加機能はOracle ACFSレプリケーションで、データベースに対するData Guardと同様、これによりネットワーク経由でのOracle ACFSファイルシステムのリモート・サイトへのレプリケーションが可能になり、ファイルシステムに対する障害時リカバリ機能が提供されます。Oracle ACFSレプリケーションはプライマリ・ファイルシステムのディスクに書き込まれた変更を取得し、その変更をレプリケーション・ログと呼ばれるファイルに記録します。このログは、関連するスタンバイ・ファイルシステムをホストするサイトに転送され、そこでバックグラウンド・プロセスがログを読み取り、ログに記録された変更をスタンバイ・ファイルシステムへ適用します。レプリケーション・ログに記録された変更がスタンバイ・ファイルシステムに正常に適用された後、レプリケーション・ログはプライマリおよびスタンバイ・ファイルシステムをホストしているサイトから削除されます。
Oracle Solaris ZFS Storage Applianceシリーズは、プロジェクトのスナップショット・ベースのレプリケーションをサポートし、次のユースケースに対し、スケジュールされてまたは連続で、ソース・アプライアンスから任意の数のターゲット・アプライアンスへ手動で分配します。
障害回復: レプリケーションを使用して障害時リカバリのためにアプライアンスをミラーリングできます。プライマリ・アプライアンス(またはデータ・センター全体)のサービスに影響を与える障害イベント時に、管理者は障害時リカバリ・サイトでサービスをアクティブ化し、最新のレプリケートされたデータを使用して引き継ぎます。プライマリ・サイトがリストアされると、障害時リカバリ・サイトがサービス中に変更されたデータは、プライマリ・サイトに移行して戻され、通常のサービスがリストアされます。このようなシナリオは、障害が発生する前に完全にテストすることができます。
データ破損: レプリケーションを使用して、ターゲット・アプライアンスのクライアントが通常はソース・アプライアンスに直接到達できない、またはそのような設定では待機時間が非常に長くなるような状況で、データ(仮想マシン・イメージまたはメディア)を世界中のリモート・システムに分散できます。1つの例ではこのローカル・キャッシングのスキーマを使用して、読取り専用データ(ドキュメントなど)の待機時間を改善します。
ディスク・ツー・ディスク・バックアップ: レプリケーションをテープ・アックアップが実行可能でない環境に対するバックアップ・ソリューションとして使用できます。たとえば、使用可能なバンド幅が不足しているため、またはリカバリの待機時間が長すぎるために、テープ・バックアップが実行可能でない場合があります。
データ移行: レプリケーションを使用して、ハードウェアのアップグレード時または記憶域のリバランス時に、Oracle Solaris ZFS Storageアプライアンス間でデータおよび構成を移行できます。シャドウ移行はこの目的でも使用できます。
Oracle Solaris ZFS Storage Applianceのアーキテクチャによっても、これはOracle Fusion Middlewareの障害時リカバリに対しData Guardを補完するための理想的なプラットフォームになります。Oracle Fusion Middlewareにはデータベース外に保管された多数の重要なファイルがあります。これらのバイナリ、構成データ、メタデータ、ログなども、Oracle Fusion Middlewareの可用性を確保するためにデータ保護が必要です。これらに対し、ZFS Storage Applianceの組込みレプリケーション機能を使用してこのデータをリモートの障害時リカバリ・サイトに移動します。
Oracle Solaris ZFS Storage ApplianceをOracle Fusion Middlewareと使用する場合の利点には次のものがあります。
Oracle Fusion Middlewareのリモート・レプリケーションの活用
DRサイトのROIを向上させるデータベースのクローンおよびスナップショットを迅速に作成する機能
高可用性アーキテクチャでは、アプリケーション層が生き残っているインスタンスまたはデータベースに透過的にフェイルオーバーして必要なサービスを通知することが必要です。これにより、ノード障害、インスタンス障害、データ破損またはデータベース障害時に、アプリケーションが通常どおり使用可能であることが保証されるか、または影響を最小限に抑えることができます。透過的なクライアント・フェイルオーバーにより、アプリケーションは別の使用可能なOracle RACインスタンスまたは別のデータベースにフェイルオーバーできます(Data Guardロール・トランジションまたはOracle GoldenGateの場合など)。
クライアント・フェイルオーバーには、障害の通知、接続のクリーンアップ、自動再接続、および別のOracle RACインスタンスまたはデータベースに存在するデータベース・サービスの再試行が含まれ、問合せの再試行も含まれる可能性があります。
高いレベルで、次のコンポーネントを使用してシームレスなクライアント・フェイルオーバーを提供します。
サービス
企業のグリッド構想を可能にするために、Oracle Databaseでは、サービスと呼ばれる強力な自動ワークロード管理機能が導入されています。サービスは、Oracleデータベースで定義できるエンティティで、これを使用してデータベース・ワークロードをグループ化し、サービスの提供を割り当てられている最適なインスタンスに作業をルーティングし、計画済および計画外のアクションの高可用性を実現できます。
高可用性フレームワーク
Oracle Databaseがコンポーネントを実行状態に維持できるOracle RACコンポーネント。
高速アプリケーション通知(FAN)
FANは、UPまたはDOWNイベントなどのサービス・ステータスの変更を含む、構成レベルおよびサービス・レベルの情報を他のプロセスに通知するためにOracle RACが使用する高可用性通知メカニズムです。また、FANには、ロード・アドバイザ通知もあります。Oracleクライアント・ドライバおよびOracle接続プールは、FANイベントに応答し、ただちに処理します。FANのUPイベントおよびDOWNイベントは、インスタンス、サービスおよびノードに適用できます。
トランザクション・ガード
トランザクション・ガードは、計画外停止および重複送信の場合に、トランザクションの実行を1回以下にするためのプロトコルおよびAPIを提供するツールです。
アプリケーション・コンティニュイティ
アプリケーション・コンティニュイティは、リカバリ可能なエラーが発生した場合に、多くのシステム、通信、記憶域の停止およびハードウェア障害をマスクして、処理中の要求をリプレイする汎用インフラストラクチャを提供します。既存のリカバリ・テクノロジとは異なり、この機能では、アプリケーション下でトランザクションおよび非トランザクション・セッション状態をリカバリしようとするため、停止はアプリケーションにとって実行の遅延のように見えます。
接続ロード・バランシング
コネクション・ロード・バランシングは、要求されたデータベース・サービスを提供するすべてのインスタンスで、受信する接続を均等に分散するOracle Net Servicesの機能です。
ランタイム接続ロード・バランシングを使用すると、アプリケーションは、ロード・バランシング・アドバイザ・イベントを使用して、ユーザーにより適切なサービスを提供できます。Oracle JDBC、Oracle Universal Connection Pool for Java、OCIセッション・プール、ODP.NETおよびOracle WebLogic Server Active GridLink for Oracle RACクライアントは、ロード・バランシング・アドバイザリ・イベントを利用するために自動的に統合されます。ロード・バランシング・アドバイザは、サービスに対してインスタンスで提供されている現在のサービス・レベルをクライアントに通知します
高速接続フェイルオーバー
高速接続フェイルオーバーは、FANイベントをサブスクライブすることによって、高速な接続のフェイルオーバーを提供する、Oracleクライアントの機能です。
透過的アプリケーション・フェイルオーバー(TAF)
透過アプリケーション・フェイルオーバーは、高可用性環境を対象としたランタイム・フェイルオーバーであり、アプリケーションからサービスへの接続のフェイルオーバーおよび再確立を意味します。TAFにより、クライアント・アプリケーションは接続障害の発生時にデータベースに自動的に再接続でき、実行中だったSELECT文を再開することも可能です。この再接続は、Oracle Call Interface(OCI)ライブラリ内から自動的に実行されます。
単一クライアント・アクセス名(SCAN)
SCANはOracle RACに接続しているクライアントに単一の名前を提供し、この名前は、クラスタのノードを追加または削除しても、クラスタの存続期間中は変更されません。SCANに接続しているクライアントでは、Thin JDBC URLやEZConnectなどの単一の接続文字列を使用でき、ロード・バランシングおよびクライアントの接続フェイルオーバーが実現されます。
グローバル・データ・サービス
グローバル・データ・サービス(GDS)は新しいOracle Databaseの機能で、サービスの概念を、単一インスタンス、Oracle RAC、Oracle Active Data GuardおよびOracle GoldenGateの組合せを含む、グローバルにレプリケートされた構成に拡張します。これにより、サービスはこのグローバルにレプリケートされた構成内のどこにでもデプロイでき、ロード・バランシング、高可用性、データベース・アフィニティなどをサポートします。
接続時フェイルオーバー
Oracle Netでは、それぞれ独自の特性を備えた複数のアドレス・リストを持つ接続記述子もサポートされます。接続時フェイルオーバーを使用すると、あるアドレスへの接続失敗時に、新しい接続試行を別のアドレスにフェイルオーバーすることができます。
|
関連項目:
|
高レベルで、MAA環境での自動クライアント・フェイルオーバーには、データベース・サービスの使用可能リソースへの再配置、障害が発生したことのクライアントへの通知、TCPタイムアウトからそれらの潜在的なブレーク、データベース・サービスがアクティブな使用可能リソースへのアプリケーション接続のリダイレクトが含まれます。特定のクライアントまたはアプリケーションの構成およびベスト・プラクティスについては、My Oracle Supportのノート1617163.1「クライアントおよびアプリケーションのフェイルオーバー検証マトリックス」を参照してください。
アプリケーション接続のフェイルオーバーの処理に使用される、この章の導入部で説明したコンポーネントは、MAA環境の構成により異なります。
表3-3 接続のクライアント・フェイルオーバー処理
| MAA構成 | サービスの再配置 | アプリケーション通知 | セッションのフェイルオーバーおよびリカバリ脚注1 |
|---|---|---|---|
|
Data Guard使用の単一インスタンス |
|
アプリケーション・レイヤーを実行しているホストでのオペレーティング・システムの効率的なTCPタイムアウトの構成 |
OCIクライアントに対する透過的Oracleフェイルオーバー(TAF)の構成。TAFを使用しない場合、OCI、JDBC ThinまたはODP用にアプリケーションにトランザクション・ガードを含めることができます。 |
|
Oracle RAC DatabaseまたはOracle RAC One Node |
|
高速アプリケーション通知の構成 |
OCIクライアントに対する透過的Oracleフェイルオーバー(TAF)の構成。Thin JDBCクライアントのためのアプリケーション・コンティニュイティの構成。 これらを使用しない場合、OCI、JDBC ThinまたはODP用にアプリケーションにトランザクション・ガードを含めることができます。(TAFおよびACにはトランザクション・ガードが含まれます) |
|
Data Guard使用のOracle RAC Database |
|
高速アプリケーション通知の構成 |
OCIクライアントに対する透過的Oracleフェイルオーバー(TAF)の構成。JDBCシン・クライアントのためのアプリケーション・コンティニュイティの構成。 これらを使用しない場合、OCI、JDBC ThinまたはODP用にアプリケーションにトランザクション・ガードを含めることができます。(TAFおよびACにはトランザクション・ガードが含まれます) |
|
レプリケート・データベース |
|
アプリケーション・レイヤーを実行しているホストでのオペレーティング・システムの効率的なTCPタイムアウトの構成 |
BASICのみを使用したOCIクライアントに対する透過的Oracleフェイルオーバー(TAF)の構成。 |
脚注1 クライアントがJDBC、UCPまたはAGLである場合、アプリケーション・コンティニュイティは、レプリケートされたデータベースを除いて、これらすべての構成のオプションでもあります。
次の項では、サービスの再配置とアプリケーション通知の詳細を説明します。
|
関連項目:
|
サービス名とは、クライアント接続に使用するサービスの論理表現です。クライアントは、リスナーに接続するときにサービスへの接続をリクエストします。データベース・インスタンスは、起動時にインスタンス自体をリスナーに登録し、1つ以上のサービスとして名前で指定できるようになります。リスナーとして知られているように、単一サービスはOracle RACまたはData Guard環境の1つまたは複数のデータベース・インスタンスを識別できます。各データベース・インスタンスは、1つ以上のサービスをリスナーに登録できます。
アプリケーションはプライマリ特有のサービス名、つまり、プライマリ・データベースでのみアクティブなユーザー作成サービスを使用してデータベースに接続する必要があります。Data Guardのフェイルオーバーのイベントで、このサービスは現在プライマリ・ロールを保持しているいずれかのデータベースに移行されます。これはON_STARTUPシステム・イベントに基づき実行されるトリガーを作成することによりインストールされたOracle Clusterwareのない単一インスタンス環境で実行できます。このトリガーはV$DATABASEビューのDATABASE_ROLE値をチェックし、値がPRIMARYの場合、ユーザー作成サービスを開始します。
サービスを定義すると、リソース・プロファイルは自動的に作成されます。リソース・ファイルには、Oracle Clusterwareによるサービスの管理方法と、PREFERREDインスタンスが停止した場合にサービスがフェイルオーバーされるインスタンスが定義されています。また、リソース・プロファイルでは、インスタンスおよびデータベースに対するサービスの依存性も定義します。この依存性の情報によって、データベースが停止した場合に、インスタンスおよびサービスが自動的に正しい順序で停止されます。
管理者管理データベースに対してサービスを定義する場合は、SRVCTLに-preferredパラメータを使用して、そのサービスを通常サポートするインスタンスを定義します。このようなインスタンスを、優先インスタンスといいます。サービスの優先インスタンスが失敗した場合に備えて、-availableパラメータを指定してSRVCTLを使用し、サービスをサポートするその他のインスタンスを定義することもできます。このようなインスタンスを、使用可能インスタンスといいます。
優先インスタンスを指定する場合は、サービスが通常実行されるインスタンスの数を指定します。これは、サービスの最大カーディナリティです。Oracle Clusterwareは、サービスを構成したインスタンス数でサービスが実行されることを確認しようとします。その後は、インスタンス障害またはサービスの計画的な再配置のために、使用可能インスタンスでサービスが実行される場合があります。
インスタンスが失敗した場合、リストに複数のインスタンスがあると、Oracle Clusterwareによってサービスがどの使用可能インスタンスに再配置されるかは制御できません。ただし、計画済操作時は、サービスを現在提供していない、優先リストまたは使用可能リスト内のインスタンスにサービスを手動で転送できます。
ご使用のOracle RAC環境でData Guardを構成してある場合は、SRVCTLに-lパラメータを使用して、各サービスにロールを定義できます。サービスにロールを指定すると、Oracle Clusterwareは、データベース・ロールがそのサービスに指定したロールに一致した場合にのみ自動的にサービスを起動します。有効なロールは、PRIMARY、PHYSICAL_STANDBY、LOGICAL_STANDBYおよびSNAPSHOT_STANDBYで、1つのサービスに複数のロールを指定できます。
クラスタ内の複数のデータベースが同じサービス名を提供すると、Oracle RACは、該当するすべてのデータベースにわたってそのサービスへの接続を均等に分散します。これはData Guardのスタンバイ・データベースおよびアクティブ・データベースに役に立ちますが、サービスへのクライアント接続を特定のデータベースに割り当てる必要がある場合、サービス名はクラスタ内で一意である(他のデータベースによって提供されない)必要があります。
|
関連項目: データベース・ロールの詳細は、『Oracle Data Guard概要および管理』を参照してください。 |
グローバル・データ・サービス・フレームワークはグローバル・サービス向けのソフトウェア・インフラストラクチャです。このフレームワークはデータベース・クラウドの構成、メンテナンスおよび監視を自動化および集中化し、グローバル・サービスのロード・バランシングおよびフェイルオーバーを可能にします。このフレームワークでは、これらの仮想化リソースを最小限の管理オーバーヘッドで管理し、追加のクライアント要求を処理するために迅速にクラウドを有効化します。
Global Data Servicesフレームワークは、次の既存のOracle Databaseのテクノロジを中心に構築されます。
Oracle Active Data Guard
読取り専用データベースの高パフォーマンス・ファームを可能にします。
Data Guard Broker
プライマリ・データベースと最大30のスタンバイ・データベースを含むData Guard構成の作成、管理および監視を可能にします。
Oracle GoldenGate
複数のデータベース間のレプリケーション更新を可能にします。
FANを使用して、Oracle RAC、Data Guardおよびグローバル・データ・サービスに構築された連続した動的データベース・サービスは、アプリケーションおよび中間層サーバーに拡張されています。データベース・サービスの状態が変わると(起動、停止または再起動なしなど)、新しいステータスがFANイベントを介して、関係のあるサブスクライバにポストされます。Oracleドライバおよびアプリケーションは、これらのイベントを使用して、障害を非常にすばやく検出し、障害後の接続プールを均等に分散し、障害の発生したコンポーネントが修復されると接続プールを再度分散します。たとえば、インスタンスのサービスが起動されると、そのリソースに作業をルーティングするためにFANイベントが即時に使用されます。インスタンスまたはモードのサービスが失敗すると、リカバリするアプリケーションを中断するために、FANイベントが即時に使用されます。
データベース接続で高可用性の問題を解決するには、サービスの状態が変わるとすぐに、Oracle ClusterwareおよびData Guard BrokerでFANイベントをポストし、さらにサーバー側のコールアウトを実行します。イベント・ペイロードにはOracle RACでのサービスのステータスを説明する関連情報が含まれます。FANイベントを受信すると同時に、アプリケーションでは、障害が発生したインスタンスまたはノードと通信中のセッションを終了し、操作の再開を待つセッションに通知し、補助のリソースが使用可能になると、着信する作業を再編成できます。処理すべきセッションを識別するために、Oracle Databaseを使用するどのセッションにも、一意の接続署名があります。接続署名は、FANペイロードと一致します。
計画停止の場合、構成されたFANで接続プールを使用します。OCI、UCP、ICC、WebLogic Server Active Grid LinkまたはODP.Netです。FAN計画イベントの場合、リクエスト境界で作業を排出します。すぐにFANイベントが計画停止のために受信され、そのサービスまたはインスタンスのプールからアイドル接続が削除され、アクティブ(借りた)接続は、プールに返されるときに解放のマークが付けられます。これにより、ユーザーを妨げることなく、計画停止のために作業が効果的にドレインされます。アプリケーションを中断せずに、計画メンテナンス操作を正常に実行する手順は、My Oracle Supportのノート1593712.1を参照してください。
FANは、ランタイム接続のロード・バランシング、Web親和性およびデータ依存型ルーティングについてのアドバイザをポストする場合にも使用されます。
|
関連項目:
|
Oracle RACデータベースへの接続に使用される多くの一般的なクライアント・アプリケーション環境は、FANと統合されました。そのため、FANを使用する最も簡単な方法は、Oracle統合クライアントを使用することです。
FANとの統合によって、Oracle統合クライアントはOracle RACクラスタの最新のステータスをより迅速に認識します。これによって、クライアント接続が使用できなくなったインスタンスやサービスを待機したり接続試行することがなくなります。インスタンスが起動すると、Oracle RACでは、最近起動されたインスタンスへの接続を接続プールで作成し、このインスタンスで提供される追加リソースを接続プールで使用できるように、FANを使用して接続プールに通知します。
FANと統合されたOracleクライアント・ドライバでは次のことが適用されます。
終了した接続を削除すると同時に、サービスがインスタンスでDOWNとして宣言され、ノードも同時にDOWNとして宣言されます。
サービスが再起動を繰り返し試行する間クライアントを待機させるかわりに、NOT RESTARTING状態がOracle Databaseで検出されるとすぐにエラーをクライアントにレポートします。
FANと統合されたOracle接続プールでは、次の処理を実行できます。
サービスの起動時に、Oracle RACのすべてのインスタンス間で接続を均等に分散します。この方法は、接続プールで定義されているセッションを、サービスがサポートされている最初のOracle RACインスタンスに割り当てるよりも有効です。
ロード・バランシング・アドバイザのイベントを使用して、実行時の作業要求を均等に分散します。
|
関連項目: すべてのOracleクライアントでFANを有効化する方法の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。 |
アプリケーション・レイヤーを実行しているホストでオペレーティング・システムの効率的なTCPタイムアウトを構成します。OS TCPタイムアウトは、データベース・レイヤーがフェイルオーバーするのにかかる時間およびデータベース・サービスが開始するのにかかる時間に設定される必要があります。TCPタイムアウトを適切に構成する方法については、オペレーティング・システムのマニュアルを参照してください。
例外のイベントに適切に応答するように、アプリケーション内の再接続ロジックを構成します。たとえば、接続プールからのセッションが切断となる例外(ORA-3113エラーなど)を受信すると、アプリケーションはそのセッションへの再接続を自動的に試みます。再接続の試行は、データベース・レイヤーをフェイルオーバーするのにかかる時間継続し、アプリケーション・サービスをオンラインにするように構成する必要があります。
トランザクションのフェイルオーバーおよび保護テクノロジには、トランザクション・ガードとアプリケーション・コンティニュイティがあります。
トランザクション・ガードは、アプリケーションで、計画済および計画外の停止に続くトランザクションに、信頼できる既知の結果を提供する汎用ツールです。アプリケーションでは論理トランザクションIDという新しい概念を使用して、停止に続くデータベース・セッション内でオープンになっている最終トランザクションの結果が判断されます。トランザクション・ガードを使用しないと、アプリケーションが停止の後に操作を実行しようとして、トランザクションが重複してコミットされ論理破損が発生する可能性があります。
最後の送信がコミットされたか、近いうちにコミットされるか、または完了まで実行されていないかを識別できない場合、アプリケーションがリプレイを試みることにより、すでに永続化されている変更の再発行が試みられる可能性があるため、トランザクションの送信が重複し、他の形式の論理的破損が発生する可能性があります。
トランザクション・ガードを使用しないと、トランザクションが開始され、コミットが発行された場合、クライアントに返されるコミット・メッセージに継続性がありません。クライアントは、トランザクションがコミットされたかどうかわからないままになります。トランザクションは、非トランザクション状態が不正確な場合、またはそのトランザクションがすでにコミットされている場合は、有効に再送信できません。保障されたコミットや完了情報がないと、再送信により、トランザクションが複数回適用され、不適切な状態になる可能性があります。
|
関連項目:
|
高可用性アーキテクチャでは、アプリケーション層が生き残っているインスタンスまたはデータベースに透過的にフェイルオーバーして必要なサービスを通知する機能が必要です。これにより、ノード障害、インスタンス障害、データ破損またはデータベース障害時に、アプリケーションが通常どおり使用可能であることが保証されるか、または影響を最小限に抑えることができます。Javaのアプリケーション・コンティニュイティでは、別の使用可能なOracle RACインスタンスで、または別のデータベースに対して(Data Guardロール遷移の場合など)、リクエストをリプレイすることで、リカバリ可能な停止をマスキングしようとします。
アプリケーション・コンティニュイティには次のものが含まれます。
FAN: 障害の通知
接続のクリーンアップ
別のOracle RACインスタンスまたはデータベースに存在するデータベース・サービスの自動再接続および再試行
進行中のリクエストのリプレイ
データベース・セッションの停止のマスキングはアプリケーション開発にとって複雑なタスクのため、結果的にエラーおよびタイムアウトが頻繁にユーザーに公開されます。アプリケーション・コンティニュイティは、リカバリ可能な停止(計画外および計画)に続いてデータベース・セッションをリカバリすることで、ユーザーおよびアプリケーションから停止をマスキングしようとします。アプリケーション・コンティニュイティはこのリカバリをアプリケーション直下で実行するため、アプリケーションにとっては、その停止が遅延された実行のように見えます。リカバリを成功させるには、アプリケーション・コンティニュイティによりクライアントに対してリストアされたデータやメッセージが、アプリケーションで表示され、決定が下された可能性のあるものと同じであることが必要です。
アプリケーション・コンティニュイティは、通常、基本となるソフトウェア、フォアグラウンド、ハードウェア、通信、ネットワークまたは記憶域の層に関連する、リカバリ可能な停止に対して起動されます。アプリケーション・コンティニュイティは計画外停止および計画停止の両方を処理するときのユーザーの操作性を向上させるために使用されます。
Oracle Database 12cリリース1では、Java用のアプリケーション・コンティニュイティは、次のものとの一般的使用が可能です。
JDBC-Thin Oracleドライバ
JDBCユニバーサル接続プール
WebLogic Server Active Grid Link
|
関連項目:
|
グローバル・データ・サービスにより、管理者は共通のサービスを提供するレプリケートされたデータベース全体でクライアント・ワークロードを自動的および透過的に管理できます。データベース・サービスは1つまたは複数のデータベース・インスタンスの名前付の表現です。サービスにより、データベース・ワークロードをグループ化し、特定の作業リクエストを適切なインスタンスへルーティングできます。グローバル・サービスはデータ・レプリケーションにより同期化された複数のデータベースにより提供されます。
グローバル・データ・サービスでは、共有サービスを提供する一連のレプリケート・データベースに動的ロード・バランシング、フェイルオーバーおよびサービスの集中管理を提供します。データベースのセットには、Oracle RACとOracle Data Guardを介して相互に関連するクラスタ以外のOracleデータベース、Oracle Multitenantの元で統合されたデータベース、Oracle GoldenGateまたはその他のレプリケーション技術を含めることができます。
グローバル・データ・サービスの利点は次のとおりです。
グローバルに分散されたマルチ・データベース構成を含む、グローバル・リソースの集中管理が可能
グローバルなスケーラビリティ、可用性、実行時ロード・バランシングの提供
シームレスなフェイルオーバーのサポート
GDS構成へのデータベースの動的な追加、およびグローバル・サービスの動的な移行が可能
最適なリソース使用率が可能
グローバル・サービス管理フレームワークはグローバル・サービス向けのソフトウェア・インフラストラクチャです。このフレームワークはGDS構成の構成、メンテナンスおよび監視を自動化および集中化し、サービスのロード・バランシングおよびフェイルオーバーを可能にします。このフレームワークでは、これらの仮想化リソースを最小限の管理オーバーヘッドで管理し、追加のクライアント要求を処理するために構成を有効化します。
グローバル・サービス管理のフレームワークは、次の既存のOracle Databaseテクノロジを中心に構築されます。
Oracle Real Application Clusters(Oracle RAC)
1つのクラスタでの動的ロード・バランシングおよびワークロード管理が可能になります。
Oracle Active Data Guard
読取り専用データベースの高いパフォーマンスのファームを可能にします。
Data Guard Broker
プライマリ・データベースと最大30のスタンバイ・データベースを含むData Guard構成の作成、管理および監視を可能にします。
Oracle GoldenGate
複数のデータベース間のレプリケーション更新を可能にします。
|
関連項目: 『Oracle Database Global Data Services概要および管理ガイド』 |
Oracle Multitenantは、Oracle Database 12c以降の最適なデータベース統合方法です。マルチテナント・アーキテクチャでは、これまでの統合方法に付きものであったトレードオフはなくし、それぞれの一番よい特性が結合されています。
Oracle MultitenantはOracle Database 12cの新しいオプションで、統合やプロビジョニング、アップグレードなどを簡素化することにより、ITコストの削減を支援します。この新しいアーキテクチャでは、コンテナ・データベースに多数のプラガブル・データベースを保持できます。アプリケーションでは、これらのプラガブル・データベースはスタンドアロン・データベースとして認識され、プラガブル・データベースにアクセスするためにアプリケーションを変更する必要はありません。複数のデータベースをプラガブル・データベースとして1つのコンテナ・データベースに統合することにより、複数のデータベースを1つのデータベースとして管理できるようになります。ビジネスで必要な場合には、分離してプラガブル・データベースを操作する柔軟性もあります。
Oracle Multitenantは、Oracle Real Application Clusters、Oracle Data GuardおよびOracle Golden Gateなど、その他の高可用性機能に完全に準拠しています。
Oracle Multitenantを使用する利点
統合密度の高さ - 1つのコンテナ・データベースに、多数のプラガブル・データベースを格納できます。これらのプラガブル・データベースでは、バックグラウンド・プロセスとメモリー構造が共有され、それぞれの単一データベースのオーバーヘッドが取り除かれたり、低減したりするため、単一データベースより多くのプラガブル・データベースを実行できます。
高速なプロビジョニングおよびクローニング - プラガブル・データベースは、あるコンテナ・データベースから切断して、別のコンテナ・データベースに接続できます。また、プラガブル・データベースを、同じコンテナまたは別のコンテナにクローニングすることも可能です。DBaaSまたはSaaS環境では、クローニングにより、ゴールド・イメージやシード・データベースを作成できます。このプラガブル・データベースをクローニングすれば、新規顧客用にデータベース環境を簡単に設定できます。
パッチ適用およびアップグレードの新オプション - コンテナ・データベースをアップグレードまたはパッチ適用する場合、そのコンテナ内のすべてのプラガブル・データベースもアップグレードまたはパッチ適用されます。分離する必要がある場合は、プラガブル・データベースを切断して、より新しいバージョンのコンテナ・データベースに接続できます。
データベースのバックアップおよびリカバリ - 複数のデータベースをプラガブル・データベースとして統合することで、バックアップや障害時リカバリなどの操作がコンテナ・レベルで実行されます。Oracle Multitenantでも、同じコンテナ・データベース内の、実行されているその他のプラガブル・データベースに影響を与えずに、個々のプラガブル・データベースを柔軟にバックアップおよびリストアできます。
Oracle Data Guardを使用した操作 - コンテナ・データベース・レベルでは、Data Guard構成が維持されます。Data Guardのロール・トランジション(フェイルオーバーかスイッチオーバーのいずれか)が実行されると、すべてのプラガブル・データベースが新しいプライマリ・データベースに移行されます。単一データベースの場合には必要になりますが、プラガブル・データベースごとに複数のData Guard構成を作成したり管理したりする必要はありません。Data Guard Standby-First PatchやData Guard一時ロジカル・ローリング・アップグレードなどの既存ツールを使用して停止時間を短くすることが可能で、コンテナ・レベルで実行されるため、すべてのプラガブル・データベースを一度の操作でメンテナンスできます。
Oracle Golden Gateを使用した操作 - Oracle Multitenantには、Oracle Golden Gateで提供されているすべての機能があります。Golden Gateにも、プラガブル・データベース・レベルで操作する柔軟性があるため、コンテナ・データベース内のプラガブル・データベースのサブセットにレプリケーションを実行できます。Golden Gateを使用して、コンテナ・データベース・レベルまたは個々のプラガブル・データベース・レベルで、停止時間が最小限またはゼロのアップグレードを実行できます。
リソース管理 - Oracle Resource Managerで単一データベース間のリソース使用率を制御できるのと同じように、コンテナ内の個々のプラガブル・データベースのリソース使用率も制御できます。これにより、1つのプラガブル・データベースが、割り当てられている量を超えてシステム・リソースにアクセスすることはありません。
Oracle Flashback Databaseの操作 - 高速のポイント・イン・タイム・リカバリが必要な場合は、Oracle Multitenantの初期リリースを使用すると、CDBレベルでフラッシュバック・データベースを使用できます。今後のリリースのOracle Multitenantでは、その他のPDBの可用性に影響を与えずに、個々のPDBでフラッシュバック・データベースを使用できるようにする予定です。
Oracle RestartはOracle 11gリリース2(11.2)の新機能で、単一インスタンスの(クラスタ化されていない)Oracle Databaseとそのコンポーネントの可用性を強化します。Oracle Restartは、単一インスタンス環境でのみ使用されます。Oracle Real Application Clusters(Oracle RAC)環境では、Oracle Clusterwareによってコンポーネントを自動再起動する機能が提供されます。
Oracle Restartをインストールすると、ハードウェアまたはソフトウェア障害の後、あるいはデータベースのホスト・コンピュータが再起動するときは必ず、データベース、リスナー、およびその他のOracleコンポーネントは自動的に再起動します。また、Oracleコンポーネントが、コンポーネントの依存性に応じて、確実に正しい順序で再起動します。
Oracle Restartでは、Oracle Restartと統合されているコンポーネント(SQL*Plus、リスナー制御ユーティリティ(LSNRCTL)、ASMCMDおよびOracle Data Guardなど)の状態を定期的に監視します。コンポーネントのヘルス・チェックに失敗すると、Oracle Restartはそのコンポーネントを停止し、再起動します。
Oracle Restartは、Oracle Databaseホームとは別にインストールするOracle Grid Infrastructureホームから実行されます。
統合されたクライアント・フェイルオーバー・アプリケーションは、Oracle Clusterwareにより管理されているロール・ベースのサービスや高速アプリケーション通知イベントに依存して、アプリケーションに障害の警告を行います。単一インスタンス・データベースで、統合されたクライアント・フェイルオーバーを実現するには、Oracle Restartが必要です。
|
関連項目:
|
Oracle Site Guardは障害時リカバリ・ソリューションで、管理者は、サイトの完全なスイッチオーバーやフェイルオーバーを自動化できるようになります。
Oracle Site Guardは、Oracle Fusion Middleware、Oracle Fusion ApplicationsおよびOracleデータベースの調整されたフェイルオーバーを編成して自動化します。また、拡張して、別のデータ・センターのソフトウェア・コンポーネントを組み込むことも可能です。
Oracle Site Guardは、プライマリ環境とスタンバイ環境を同期し、ミッション・クリティカルなデータを保護する基礎となるレプリケーション・メカニズムと統合できます。Oracleデータベース用のOracle Data GuardやOracle Sun ZFSのサポートが組み込まれています。また、Oracle Site Guardは、他のストレージ・レプリケーション・テクノロジをサポートすることも可能です。
|
関連項目: Oracle Enterprise Manager Oracle® Site Guard管理者ガイド |
