1. 高可用性概要
  2. 可用性を最大化するための機能

3 可用性を最大化するための機能

MAAソリューションで使用される次のOracle Database高可用性機能について理解します。

  • Oracle Data Guard
    Oracle Data Guardは、高可用性、データ保護、企業データの障害時リカバリを保証します。
  • Oracle GoldenGate
    Oracle GoldenGateはデータ分散およびデータ統合のためのOracleの戦略的ロジカル・レプリケーション・ソリューションです。
  • ベスト・プラクティス: Oracle Active Data GuardおよびOracle GoldenGate
    Oracle Active Data GuardおよびOracle GoldenGateはそれぞれOracle Databaseの同期化されたコピーを保持できますが、要件に応じて、1つのテクノロジまたは別のテクノロジ、あるいは同時に両方を使用できる高可用性アーキテクチャになる、ユニークな特徴があります。
  • Recovery Manager
    Recovery Manager (RMAN)は、データベースを効率的にバックアップおよびリカバリするための包括的な基盤を提供します。RMANは、操作の複雑さを排除するとともに、データベースの優れたパフォーマンスおよび可用性をもたらします。
  • Oracle Real Application ClustersおよびOracle Clusterware
    Oracle RACとOracle Clusterwareを使用すると、Oracle Databaseはクラスタ化された一連のサーバー全体にパッケージまたはカスタム・アプリケーションを実行できます。
  • Oracle RAC One Node
    Oracle Real Application Clusters One Node (Oracle RAC One Node)は、クラスタ内の1つのノードで実行されるOracle RACデータベースのシングル・インスタンスです。
  • Oracle Automatic Storage Management
    Oracle ASMは、垂直方向に統合されたファイル・システムおよびボリューム・マネージャを直接Oracle Databaseカーネル内に提供します。
  • 高速リカバリ領域
    高速リカバリ領域は、Oracle Database内のすべてのリカバリ関連ファイルおよびアクティビティを対象とした一元的な格納場所です。
  • 破損の予防、検出および修復
  • データ・リカバリ・アドバイザ
    データ・リカバリ・アドバイザは、永続的な(ディスク上の)データ障害を自動的に診断し、適切な修復オプションを示し、リクエストに応じて修復操作を実行します。
  • Oracle Flashbackテクノロジ
    Oracle Flashbackテクノロジは、Oracle Database機能のグループで、データベース、データベース・オブジェクト、トランザクションまたは行の過去の状態を表示し、データベース、データベース・オブジェクト、トランザクションまたは行を、ポイント・イン・タイム・メディア・リカバリを使用せずに前の状態に戻すことができます。
  • Oracle Data Pumpとデータ転送
  • データベース以外のファイルに対するOracleレプリケーション・テクノロジ
    Oracle ASMクラスタ・ファイル・システム、Oracle Database File SystemおよびOracle Solaris ZFS Storage Applianceレプリケーションは、データベース以外のファイル用のOracleレプリケーション・テクノロジです。
  • Oracle Multitenant
    Oracle Multitenantはデータベースの統合に最適な方法です。マルチテナント・アーキテクチャでは、これまでの統合方法に付きものであったトレードオフはなくし、それぞれの一番よい特性が結合されています。
  • Oracle Sharding
    Oracle Shardingはアプリケーションに対する拡張性および可用性の機能で、シャード・データベースで実行されるように明示的に設計されています。
  • Oracle Restart
    Oracle Restartは、単一インスタンスの(クラスタ化されていない) Oracleデータベースおよびそのコンポーネントの可用性を向上させます。
  • Oracle Site Guard
  • オンライン再編成および再定義
    可用性および管理性を強化する1つの方法として、データの再編成操作中、データベースへのアクセス権をユーザーに与えます。
  • Zero Data Loss Recovery Appliance
    クラウド規模のZero Data Loss Recovery Appliance (通常、リカバリ・アプライアンスと呼ばれる)は、エンタープライズ内のすべてのOracleデータベースでデータ損失とバックアップ・オーバーヘッドを劇的に削減するように設計されたエンジニアド・システムです。
  • フリート・パッチ適用およびプロビジョニング
    フリート・パッチ適用およびプロビジョニングでは、領域効率がよいソフトウェアのリポジトリ(より正確には「ゴールド・イメージ」)が維持されます。これは、任意の数のターゲット・マシンにプロビジョニングできる標準化されたソフトウェア・ホームです。
  • アプリケーションの継続的なサービスの有効化
    データベース層の計画的メンテナンス、計画外停止および負荷の不均衡がユーザーから認識されない場合に、アプリケーションの継続的なサービスが実現します。
  • その他の高可用性機能について
    前述の高可用性のためのOracle Database機能に加えて、次のリソースにも注目してください。

Oracle Data Guard

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については、「Oracle Active Data Guard」で詳しく説明します。

スタンバイ・データベースにはいくつかのタイプがあります。Data Guardフィジカル・スタンバイ・データベースはデータ保護および障害時リカバリについてのMAAベスト・プラクティスで、最も一般的に使用されるスタンバイ・データベースのタイプです。フィジカル・スタンバイ・データベースはREDO適用(Oracleメディア・リカバリの拡張)を使用して、本番データベースの正確なフィジカル・レプリカを保持します。MAAベスト・プラクティスを使用して構成する場合、REDO適用は複数のOracle対応検証チェックを使用して、プライマリに影響を与える可能性のある破損がスタンバイに影響を与えることを防ぎます。その他のタイプのData Guardスタンバイ・データベースには、スナップショット・スタンバイ(テストまたはその他の目的で読取り/書込みでオープンするスタンバイ)、ロジカル・スタンバイ(計画停止時間の短縮のために使用)があります。

Data Guard使用の利点

  • 更新がスタンバイ・データベースに適用される前に、Oracleデータ・ブロックおよびREDO内の構造の物理的および論理的整合性に対する複数のチェックを使用した、すべての変更のOracle対応の継続的な検証。これにより、スタンバイ・データベースが分離され、プライマリ・システムで発生する可能性のあるデータ破損による影響を受けることを防ぎます。

  • 透過的な操作 - データ保護のためのData Guardフィジカル・スタンバイの使用には制約がありません。REDO適用はすべてのデータおよびストレージタイプ、すべてのDDL操作、およびすべてのアプリケーション(カスタムおよびパッケージ・アプリケーション)をサポートし、プライマリとスタンバイ・データベース間の整合性を保証します。

  • 最高のパフォーマンス: 最高のリカバリ・ポイントの目標のための高速REDO転送、最高のリカバリ時間の目標のための高速適用パフォーマンス。マルチインスタンスREDO適用により、REDO適用にOracle RACのスケーラビリティが提供され、単一のデータベース・サーバーのボトルネックが排除されます。REDO適用は、基本的にOracle RACクラスタで使用可能なCPU、I/Oおよびネットワークまでスケールアップされます。8ノードRAC Exadataでは、3500 MB/秒(12 TB/時)のRedo適用レートが確認されています。

  • なんらかの理由でプライマリ・データベースに障害が発生した場合の、可用性を維持するためのスタンバイ・データベースへの高速フェイルオーバー。フェイルオーバーはData Guardの構成方法により、手動または自動の操作になります。

  • フェイルオーバーの発生後、アプリケーション・クライアントが新しいプライマリ・データベースに接続できるようにする、統合されたクライアント通知フレームワーク。

  • フェイルオーバーの発生後、障害の発生したプライマリ・データベースの自動または自動化された(構成による)再同期化、同期化されたスタンバイ・データベースへの迅速な変換。

  • すべてのネットワーク構成、可用性およびパフォーマンスSLA、ビジネス要件をサポートする、柔軟なデータ保護レベルの選択。

  • Data Guard Brokerコマンド・ライン・インタフェースまたはOracle Enterprise Manager Cloud Controlのいずれかを使用して、プライマリおよびそのスタンバイ・データベースのすべてを単一の構成として管理し、管理と監視を簡略化。

  • Data Guard Brokerは次の追加機能により大幅に管理容易性が向上しています。どの時点でも、構成によるリカバリ・ポイントの目標およびリカバリ時間の目標のSLAのサポートを自動的に監視するための、包括的な構成のヘルス・チェック、再開可能スイッチオーバー操作、合理化されたロール・トランジション、カスケード・スタンバイ構成のサポート、転送および適用ラグに対するユーザー構成可能なしきい値。

  • プライマリ本番データベースから送信されてカスケード・スタンバイ・データベースにより転送される単一のREDOストリームを使用した、複数のリモート宛先への効果的な転送。

  • スナップショット・スタンバイにより、フィジカル・スタンバイ・データベースをテストおよび本番データのレプリカの読取り/書込みが必要なアクティビティ用に読取り/書込みでオープン可能。スナップショット・スタンバイは受信は続行しますが、プライマリにより生成された更新の適用は行いません。テストが完了すると、読取り/書込みでオープンしている間の変更を最初に破棄し、次にプライマリ・データベースから受信したREDOを適用することで、スナップショット・スタンバイは同期されたフィジカル・スタンバイ・データベースへと変換されて戻されます。プライマリ・データは常に保護されます。スナップショット・スタンバイはOracle Real Application Testingと一緒に使用される場合特に有用です(スタンバイ・データベース(本番の正確なレプリカ)でのリプレイおよび後続のパフォーマンス分析のためにワークロードが本番データベースで取得されます)。

  • スタンバイ・データベースを使用してローリング方式でメンテナンスを実行することにより、計画停止時間を短縮。停止時間はData Guardスイッチオーバーの実行に必要な時間だけです。つまりアプリケーションはメンテナンスの実行中も使用可能なままです。(詳細は、Oracle Active Data GuardおよびOracle GoldenGateを一緒に使用する場合およびシステムおよびソフトウェア・メンテナンス用Oracle高可用性ソリューションを参照してください。)

  • プライマリ・システムとスタンバイ・システムで異なるCPUアーキテクチャまたはオペレーティング・システムが使用されているData Guard構成の柔軟性の向上は、My Oracle Supportのノート413484.1に定義されている制限が前提です。

  • コンテナ・データベース(CDB)の効率的な障害時リカバリ。Data Guardフェイルオーバーおよびスイッチオーバーは、CDBに統合されたプラガブル・データベース(PDB)の数にかかわらず、CDBレベルで1つのコマンドを使用して実行されます。

  • 特定の管理特権であるSYSDGで、Data Guardに対する標準の管理業務を処理できるようになります。この新しい権限は、特定の機能を実行するのに必要な権限のみユーザーに付与され、それ以上は付与されない、最低限の権限の原則に基づいています。SYSDBA権限は以前のリリースでも引き続き動作します。

  • Active Data Guard環境のスタンバイ・データベースで、Oracle Databaseインメモリー列ストアがサポートされます。

  • Data Guard構成でデータ・ウェアハウスのパフォーマンスおよび可用性をさらに向上させるには、次の情報を追跡します 
    NOLOGGING
    操作。これにより、次の新しいRMANコマンドで修復できます 
    RECOVER DATABASE
          NOLOGGING
    .
  • 新しいパラメータを使用して、複数のSYNCトランスポート宛先がプライマリ・データベースに与える影響を改善します 
    DATA_GUARD_SYNC_LATENCY
    このパラメータは、少なくとも1つの同期スタンバイがREDOの受信を確認した後、後続の宛先を切断するまで、プライマリ・データベースが待機すべき最大時間(秒単位)を定義します。

  • Data Guard Brokerは、代替の宛先の管理を拡張するのみでなく、プライマリとは異なるエンディアンの宛先をサポートすることで管理性を改善します。

  • Data Guardは、次を含む複数の機能により、保護およびリカバリ時間目標(RTO)とリカバリ・ポイント目標(RPO)を改善します。

    • マルチインスタンスREDO適用(MIRA)は、Oracle RACインスタンスでスケーラブルなREDO適用パフォーマンスを実現し、本番環境のOLTPやバッチ・ワークロードが高い場合でもRTOを削減します。

    • プライマリ・データベースとスタンバイ・データベースのブロックを比較し(新しい 
      DBMS_DBCOMP
      パッケージを使用)、書込み欠落を効率的に解決できるように識別します。

    • Fast Start Failover (FSFO)は、最大保護モードのサポートによる高可用ゼロ・データ損失構成の堅牢性を備えると同時に、構成の高可用性のために複数のオブザーバーと複数のフェイルオーバーの柔軟性を提供します。FSFOは、プライマリで書込み欠落を検出してスタンバイに自動的にフェイルオーバーするよう設定することもできます。

    • 非同期構成での保管失敗後のデータ損失なしフェイルオーバーおよびアプリケーション・コンティニュイティに対するData Guard BrokerサポートによりRPOが改善されて、Data Guardロール・トランジション時のユーザー・エクスペリエンスが向上します。

  • Oracle Data Guard Brokerは、プライマリ宛先が使用できない場合の代替アーカイブ先管理の拡張に加えて、プライマリとは異なるendianessの宛先をサポートして管理性を改善します。

  • Oracle Data Guardデータベース比較ツールでは、Oracle Data Guardプライマリ・データベースとそのフィジカル・スタンバイ・データベースに格納されたデータ・ブロックを比較します。DBVERIFYユーティリティなどの他のツールでは検出できないディスク・エラー(書込み欠落など)を検出するには、このツールを使用します(Oracle Database 12cリリース2の新機能)。

  • Oracle Data Guard Brokerは、ファスト・スタート・フェイルオーバー構成で複数の自動フェイルオーバー・ターゲットをサポートします。複数のフェイルオーバー・ターゲットを指定すると、必要なときに自動フェイルオーバーに適したスタンバイが常に存在する可能性が大幅に向上します(Oracle Database 12cリリース2の新機能)。

親トピック: 可用性を最大化するための機能

Oracle Active Data Guard

Oracle Active Data Guardはフィジカル・レプリケーション・プロセスを使用した、Oracleデータベースのリアルタイムのデータ保護および障害時リカバリに対するOracleの戦略的ソリューションです。

Oracle Active Data Guardはまた、プライマリ・データベースから受信した変更を適用する間もスタンバイ・システムを読取り専用でオープンできることにより、障害時リカバリ・システムで高い投資利益率を提供します。Oracle Active Data Guardは、Oracle Enterprise Editionに含まれるData Guard機能を大幅に拡張する高度な機能を提供する、別個のライセンス製品です。

図3-1 Oracle Active Data Guardアーキテクチャ

図3-1の説明が続きます
「図3-1 Oracle Active Data Guardアーキテクチャ」の説明

Oracle Active Data Guardにより、プライマリ・データベースから受信した変更を適用する間も読取り専用でオープンできるフィジカル・スタンバイ・システムに、プライマリ・データベースから処理をオフロードすることにより、管理者はパフォーマンスを向上できます。Oracle Active Data Guardのオフロード機能には、次のものが含まれています。読取り専用レポート作成およびグローバル一時表および一意のグローバルまたはセッション順序へのDMLを含む非定型問合せ、データの抽出、高速増分バックアップ、REDO転送圧縮、複数のリモート宛先の効果的な処理、およびプライマリ・データベースのパフォーマンスに影響を与えずにデータ損失ゼロの保護をリモート・スタンバイ・データベースへ拡張する機能。また、Oracle Active Data Guardは、自動ブロック修復を実行し、高可用性アップグレードの自動化を有効にすることによって、高可用性を向上させます。

注意:

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の利点

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スタンバイ・データベースへのオフロードを可能にする統合も提供します。

  • DMLグローバル一時表およびスタンバイ・データベースでの順序の使用により、本番データベースからOracle Active Data Guardスタンバイ・データベースにオフロードできる読取り専用アプリケーションの数が大幅に増加します。

  • 複数のOracle Active Data Guardスタンバイ・データベースを使用して、読取りパフォーマンスを容易に高めることのできるユニークな機能は、リーダー・ファームとも呼ばれます。

  • Oracle Data Pumpまたはその他のソース・データベースから直接読み取る手法を使用した、データの抽出の本番オフロード。

  • プライマリとスタンバイ・データベースが数百または数千マイルも離れている、同期したデータ損失ゼロの構成で、ネットワーク待機時間からのパフォーマンスの影響の本番オフロード。遠隔同期はプライマリ・データベースとは独立したシステムにデプロイされた軽量インスタンス(制御ファイルおよびアーカイブ・ログ・ファイルはあるが、リカバリ・ファイルおよびデータ・ファイルはない)を使用します。遠隔同期インスタンスは、アプリケーションが同期転送のパフォーマンスの影響に耐えて最適な保護を提供できる、プライマリ・システムから最も離れた場所に配置するのが理想的です。Data GuardはREDOを遠隔同期インスタンスに同期して転送し、遠隔同期はそのREDOを最終フェイルオーバー・ターゲットであるリモート・スタンバイ・データベースに非同期に転送します。プライマリ・データベースに障害が発生すると、Data Guard構成で使用される同じフェイルオーバー・コマンドまたはOracle Enterprise Manager Cloud Controlを使用したマウス・クリック、あるいはData Guard Fast-Start Failoverを使用した自動フェイルオーバーにより、リモート宛先へのゼロデータ損失フェイルオーバーが実行されます。この透過性は、同期構成でのWANネットワーク待機時間のプライマリ・データベースのパフォーマンスの影響を回避しながら、REDOをプライマリ・データベースから直接受け取っているかのように、データ損失ゼロの保護をリモート・スタンバイ・データベースに拡張します。

  • 遠隔同期を使用した複数のリモート・スタンバイ宛先にサービスするオーバーヘッドの本番オフロード。遠隔同期構成では、プライマリ・データベースは同期または非同期転送を使用して、REDOの単一のストリームを遠隔同期インスタンスへ送信します。遠隔同期インスタンスは、ソース・データベースの増分オーバーヘッドなしで、REDOを29のリモート宛先に非同期で転送できます。

  • Data Guardの最大可用性では、次の使用がサポートされます 
    NOAFFIRM
    REDO転送属性。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 Databaseパッチ・セットおよびデータベース・リリースへのアップグレードの計画停止時間を短縮することにより、高可用性を向上。

  • ロールの変更によりActive Data Guardスタンバイで接続を維持することで、レポート作成が容易になり、ユーザー・エクスペリエンスが向上。データベース・ロールがプライマリ・データベースに変更され、再開している間接続は一時接続するため、ユーザー・エクスペリエンスが向上します。

  • Oracle Enterprise Manager診断ツールをActive Data Guardとともに使用してパフォーマンス・データをキャプチャし、自動ワークロード・リポジトリに送信できると同時に、SQLチューニング・アドバイザを使用してプライマリ・データベースのSQL文のチューニングをスタンバイ・データベースにオフロード可能。

  • Oracle Database In-Memoryオプションに対するActive Data Guardのサポートにより、レポート作成をスタンバイ・データベースにオフロードできると同時に、スタンバイ・データベースのワークロード用に調整された列ストアなどのIn-Memoryオプションを利用可能。

親トピック: Oracle Data Guard

従来のソリューションより優れているOracle Data Guardの利点

Oracle Data Guardには、従来のソリューションよりも優れた多くの利点があります。

  • データ破損、書込み欠落、データベースおよびサイト障害に対するデータベース・フェイルオーバーは、高速かつ自動で実行され、従来のソリューションを使用した場合は数時間かかるリカバリが、Data Guardでは数秒になります

  • Oracle Active Data Guard遠隔同期の使用時、ワイド・エリア・ネットワーク経由でデータ損失ゼロ

  • Active Data Guard遠隔同期を使用したREDO転送圧縮処理のオフロードおよび最大29のリモート宛先へのREDO送信

  • 破損自動修復の機能により、プライマリ・データベースまたはフィジカル・スタンバイ・データベースの物理ブロックの破損を、フィジカル・スタンバイ・データベースまたはプライマリ・データベースの良好なブロックをコピーして自動的に置換

  • プライマリ・データベースでのデータ破損と書込み欠落に対する最も包括的な保護

  • ストレージ、Oracle ASM、Oracle RAC、システムの移行と一部のプラットフォームの移行、およびData Guardスイッチオーバーを使用した変更による停止時間の短縮

  • Data Guardのローリング・アップグレード機能による、データベースのアップグレードのための停止時間の短縮

  • Database In-Memory列のサポートを含め、リアルタイム問合せの適用ラグ機能を使用して、スタンバイ・データベースを読取り専用リソースとして使用するRTOおよびRPOの機能を犠牲にせずに、プライマリ・データベースのアクティビティ(バックアップ、問合せまたはレポート作成など)のオフロードが可能

  • サイト全体のフェイルオーバー操作の一部としてOracle Database File System (DBFS)またはOracle Automatic Storage Managementクラスタ・ファイル・システム(Oracle ACFS)を使用したデータベース以外のファイルの統合機能(「データベース以外のファイルに対するOracleレプリケーション・テクノロジ」を参照してください)

  • サイト障害の後で、インスタンスの再起動、ストレージの再マスタリングまたはアプリケーションの再接続が不要

  • アプリケーションに対する透過性

  • アプリケーション・フェイルオーバーに対する透過的な統合サポート(アプリケーション・コンティニュイティおよびトランザクション・ガード)

  • ネットワーク使用の効率化

  • Database In-Memoryのサポート

  • アプリケーション全体のRTOを短縮する統合されたサービスとクライアント・フェイルオーバー

  • Oracle RAC、RMAN、Oracle GoldenGate、Enterprise Manager、ヘルス・チェック(orachk)、DBCA、フリート・パッチ適用およびプロビジョニングなどの既存のOracleテクノロジで拡張および統合されるData Guard認識

Oracle Databaseに常駐するデータの場合、データ損失ゼロ機能が組み込まれているData Guardは、データ保護および障害時リカバリに関して従来のリモート・ミラー化ソリューションよりも効率的かつ安価でより最適化されています。Data Guardには、障害時リカバリとデータ保護のテクノロジを選択する際に、従来のリモート・ミラー化ソリューションよりもData Guardを採用する方が正しいとする、技術上およびビジネス上の理由があります。

親トピック: Oracle Data Guard

Data Guardおよび計画メンテナンス

Data Guardスタンバイ・データベースを使用してローリング方式でメンテナンスを実行することにより、計画停止時間を短縮できます。スタンバイ・データベースで変更が最初に実装されます。新しいバージョンが本番用に確実に準備できるまで、古いバージョンでプライマリを実行し、新しいバージョンでスタンバイを実行する構成が可能です。Data Guardスイッチオーバーを実行して、本番を新しいバージョンに移行させたり、同じ変更をローリング方式で本番に適用することができます。可能性のあるデータベースの停止時間は、スイッチオーバーを実行するのに必要な時間のみです。

Data Guardスタンバイを使用してローリング方式でメンテナンスを実行するには、いくつかの方法があります。顧客の要件および好みにより、どの方法を使用するかが決まります。

親トピック: Oracle Data Guard

Data Guard REDO適用およびStandby-First Patchの適用

Oracle Database 10gから、Data Guard REDO適用を使用してクロス・プラットフォームのサポートの柔軟性が向上しました。

特定のData Guard構成で、プライマリおよびスタンバイ・データベースは、異なるオペレーティング・システム(WindowsとLinuxなど)、ワード・サイズ(32ビット/64ビット)、異なるストレージ、異なるExadataハードウェアとソフトウェア・バージョンまたは異なるハードウェア・アーキテクチャのシステムで実行できます。REDO適用を使用して、Oracle Automatic Storage Management (ASM)への移行、単一インスタンスOracle DatabasesからOracle RACへの移行、テクノロジ・リフレッシュの実行、またはあるデータ・センターから次のデータ・センターへの移動を実行することもできます。

Oracle Database 11gリリース2 (11.2)から、Standby-First Patchの適用(REDO適用を使用したフィジカル・スタンバイ)は、ローリング方式でOracleパッチを適用および検証する目的で、プライマリ・データベースとそのフィジカル・スタンバイ・データベース間で異なるデータベース・ソフトウェア・パッチ・レベルをサポートします。Standby-First Patchの適用が可能なパッチには次のものがあります。

  • データベースのリリース更新(RU)またはリリース更新のリビジョン(RUR)

  • データベースのパッチ・セット更新(PSU)

  • データベースのクリティカル・パッチ・アップデート(CPU)

  • データベースのバンドル・パッチ

Standby-First Patchの適用は、Oracle Database Enterprise Edition 11gリリース2 (11.2)以降の認定データベース・ソフトウェア・パッチでサポートされます。

前述の計画メンテナンスの各タイプで、構成はプライマリおよびフィジカル・スタンバイ・データベースから始まります(新しいプラットフォームまたはASM、Oracle RACへの移行の場合、スタンバイは新しいプラットフォームに作成されます)。すべての変更がフィジカル・スタンバイ・データベースで実装されると、REDO適用(フィジカル・レプリケーション)が使用されてスタンバイとプライマリが同期します。Data Guardスイッチオーバーが使用され、本番がスタンバイ(新しい環境)に転送されます。

関連項目:

Data Guard構成でサポートされる混在プラットフォームの組合せの詳細は、My Oracle Supportのノート 413484.1を参照してください。

Standby First Patchの適用の詳細は、My Oracle Supportのノート1265700.1、ターゲット・パッチがStandby-First Patchとして認定されているかどうか判断するには、各パッチのREADMEを参照してください。

親トピック: Data Guardおよび計画メンテナンス

Data Guard一時ロジカル・ローリング・アップグレード

データベースの元のバージョンと変更後またはアップグレードされたバージョンを同期するのに、REDO適用(フィジカル・レプリケーション)を使用できない、多くのタイプのメンテナンス・タスクがあります。次のようなタスクがあります。

  • Standby-First Patchの適用に適格ではないデータベース・パッチまたはアップグレード。これにはデータベース・パッチ・セット(11.2.0.2から11.2.0.4)および新しいOracle Databaseのリリースへのアップグレード(12.2から18c)が含まれます。

  • 停止時間を必要とするデータベースの物理構造を変更するメンテナンスが実行される必要があります(パーティション化されていない表へのパーティションの追加、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シェル・スクリプトが用意されています。

Oracle Database Vaultを使用するデータベースは、Oracle Data Guardデータベース・ローリング・アップグレードを使用して新しいOracle Databaseリリースおよびパッチ・セットにアップグレードできます(一時ロジカル・スタンバイのみ)。

関連項目:

Oracle MAAホワイト・ペーパー『Oracle Databaseローリング・アップグレード: Data Guardフィジカル・スタンバイ・データベースの使用』(http://www.oracle.com/goto/maa)

親トピック: Data Guardおよび計画メンテナンス

Oracle Active Data Guardを使用したローリング・アップグレード

Oracle Active Data Guardを使用したデータベースのローリング・アップグレードでは、手動の一時ロジカル・ローリング・アップグレードで表される方法よりも、より簡単で、自動化された、容易に繰返し可能な、計画停止時間を短縮するための方法が提供されます。

Oracle Active Data Guardを使用したローリング・アップグレードでは、手動プロシージャで必要な42以上のステップが、いくつかの使いやすいDBMS_ROLLING PL/SQLパッケージに変換されます。DBMS_ROLLING PL/SQLパッケージを使用して実行するローリング・アップグレードが、マルチテナント・コンテナ・データベース(CDB)でサポートされます。

Oracle Active Data Guardを使用したローリング・アップグレードでは、次の操作が行われます。

  • アップグレード・プロセスをガイドするための、構成に固有の指示セットを含むアップグレード・プランを生成

  • ローリング・アップグレードのパラメータを変更

  • アップグレードに関連するプライマリおよびスタンバイ・データベースを構成

  • 本番データベースから新しいバージョンへのスイッチオーバーの実行。スイッチオーバーは必要な停止時間のみ

  • Data Guard構成で古いプライマリと追加のスタンバイ・データベースのアップグレードを完了し、新しいプライマリと同期

Oracle Active Data Guardを使用したローリング・アップグレードには、次の利点もあります。

  • 簡単な指定-コンパイル-実行プロトコルを提供

    • コンパイル・ステップで構成エラーを検出

    • 実行時エラーを実行中に検出

  • 状態をデータベースに保持

    • 信頼できる、繰返し可能なプロセスが可能

  • 含まれるデータベースの数に関係なく、実行時のステップは一定

  • 元のプライマリ・データベースでエラーを処理

  • アップグレードされたプライマリに対するデータ保護がいつでも可能

関連項目:

Oracle MAAホワイト・ペーパー『Oracle Databaseローリング・アップグレード: Data Guardフィジカル・スタンバイ・データベースの使用』(http://www.oracle.com/goto/maa)

『Oracle Data Guard概要および管理』

親トピック: Data Guardおよび計画メンテナンス

Oracle GoldenGate

Oracle GoldenGateはデータ分散およびデータ統合のためのOracleの戦略的ロジカル・レプリケーション・ソリューションです。

Oracle GoldenGateはリアルタイムのログ・ベースの変更データの取得およびレプリケーション・ソフトウェア・プラットフォームを提供します。このソフトウェアでは、異種のデータベース間で、トランザクション・データのキャプチャ、ルーティング、変換および配信をリアルタイムに行います。

他のベンダーのレプリケーション・ソリューションとは違い、Oracle GoldenGateはOracle Databaseとより密接に統合されながらも、異機種データベース管理システム間のレプリケーションに最適な、オープンなモジュラー・アーキテクチャも提供します。これらの性質の組合せにより妥協が排されるため、Oracle GoldenGateはOracle Database環境と非Oracle Database環境にまたがる要件に対処するための優先の論理レプリケーション・ソリューションとなります。

典型的な環境として、取得、ポンプおよび配信プロセスがあります。これらの各プロセスは、Oracle Databaseを含む、ほとんどの一般的なオペレーティング・システムおよびデータベースで実行できます。データのすべてまたは一部をレプリケートできます。またこれらのどのプロセス内のデータも異種機間環境だけでなく、異なるデータベース・スキーマ、表名または表構造で操作できます。Oracle GoldenGateは、事前設定された競合検出と解決ハンドラにより双方向のレプリケーションをサポートし、データ競合を解決を支援します。

Oracle GoldenGate論理レプリケーションにより、Oracle GoldenGate構成のすべてのデータベース(ソースおよびターゲット・データベースの両方)を読取り/書込みで開くことができます。これにより、停止時間ゼロのメンテナンス、クロス・プラットフォームの移行を使用したデータの連続可用性に対する広範囲の挑戦に対処するための、MAAの主要なコンポーネントになっています。具体的には次のとおりです。

  • ゼロまたはゼロに近い停止時間でのメンテナンス。このアーキテクチャにおいて、Oracle GoldenGateでは、Data Guardで提供される基本機能よりも高い柔軟性が提供されます。Oracle GoldenGateのソースおよびターゲット・データベースは、異なるフィジカルおよびロジカル構造を持つことが可能で、異なるハードウェアおよびオペレーティング・システム・アーキテクチャに存在でき、Oracle Databaseリリースが大きく異なっていること(12.1と18cなど)、またはOracleと非Oracleシステムの混在が可能です。これにより、24x7サーバーの近代化が可能になり、データベースの可用性に影響を与えずに新しいOracle機能を実装できます。メンテナンスは本番がソースで実行している間に、まずターゲット・データベースで実行されます。メンテナンスが完了すると、Data Guardスイッチオーバーのように、本番を一度にすべてソースに移動できます。オプションで、双方向レプリケーションを使用して、停止時間ゼロと認識させて、ユーザーを新しいシステムへ徐々に移動できます。いずれの場合も、Oracle GoldenGateレプリケーションは、遷移中、逆方向に元のソース・システム・データベースの同期化を保持することが可能で、これにより、必要な場合、最小限の停止時間でデータの損失なしで、簡単に前のバージョンへの計画フォールバックが実行できます。

  • Data Guardソリューションが適用できない場合にゼロまたはゼロに近い停止時間での移行。プラットフォームまたはデータベースの移行は、古いシステムと新しいシステム間でのデータ同期方法としてOracle GoldenGateを使用して実行できます。データベースが別のホストでインスタンス化されると、Oracle GoldenGateは本番データベースから変更をレプリケートするよう構成されます。保証付きリストア・ポイントを移行したデータベースに作成して、ユーザー・テストの後、データベースをフラッシュ・バックできるようにします。また、Oracle GoldenGateは、スナップショット・スタンバイ・データベースと同様に、新しいデータベースにアプリケーション・ユーザーを移行する前に、本番データベースからの未処理のデータ変更を適用できます。必要に応じて、双方向のレプリケーションを移行したデータベースから本番データベースに戻して構成し、フォールバック・ソリューションとして使用することもできます。

  • ゼロまたはゼロに近い停止時間でのアプリケーションのアップグレード。バックエンド・データベース・オブジェクトを変更するアプリケーション・アップグレードでは、通常、メンテナンスの実行中、大幅な計画停止時間が発生します。Oracle GoldenGateレプリケーションでは、アプリケーションの前のバージョンにより使用されたデータベース・オブジェクトを、アプリケーションの新しいバージョンで変更されたオブジェクトにマップするデータ変換が可能です。これにより、アプリケーションの可用性に影響を与えずに、本番データベースの別のコピーで、データベース・メンテナンスの実行が可能になります。メンテナンスが完了し、Oracle GoldenGateの古いバージョンと新しいバージョンの同期が終了すると、ユーザーはアプリケーションの新しいバージョンにスイッチできます。

  • ソース・データベースと同期化されている間のレプリカ・データベースへの読取り/書込みアクセス。これは、レポート・アプリケーションが動作のためにデータベースへの読取り/書込みを必要とする場合の、本番データベースのコピーへのレポート作成のオフロードに最も頻繁に使用されます。これは、アプリケーション層に使用されるテクノロジの性質が、リカバリ時間の目標を満たすために常にDRデータベースへのアクティブな読取り/書込み接続を必要とする、障害時リカバリ環境にも関係します。

  • アクティブ-アクティブ・レプリケーション。Oracle GoldenGateは、アクティブ-アクティブのマルチ・ディメンショナル構成をサポートします。この構成では、いずれかのシステムのアプリケーション・ユーザーによって変更できる同じデータ・セットを持つシステムが2つ以上存在します。Oracle GoldenGateは、トランザクション・データの変更を各データベースから他のデータベースへレプリケートして、すべてのデータ・セットを最新の状態に維持します。

  • データベース・インスタンスで障害が発生した場合、または適切なメンテナンス操作中に、Oracle Real Application Clusters (RAC)ノード間をシームレスに移動。この機能はOracle GoldenGateに高可用性を提供し、Oracle GoldenGateが現在実行されているノードに影響を与えずに、クラスタ内の1つ以上のノードでOracle GoldenGateソフトウェアにパッチを適用したり、アップグレードできます。その後、事前に決定した時間で、Oracle GoldenGateをアップグレードするいずれかのノードに切り替えることができます。構成情報はOracle RACクラスタで共有されるため、Oracle GoldenGateを再構成することなく切替えが実行されます。

関連項目:

Oracle GoldenGateのドキュメント

Oracle MAAのOracle GoldenGateのホワイト・ペーパー(http://www.oracle.com/goto/maa)

親トピック: 可用性を最大化するための機能

ベスト・プラクティス: Oracle Active Data GuardおよびOracle GoldenGate

Oracle Active Data GuardおよびOracle GoldenGateはそれぞれOracle Databaseの同期化されたコピーを保持できますが、要件に応じて、1つのテクノロジまたは別のテクノロジ、あるいは同時に両方を使用できる高可用性アーキテクチャになる、ユニークな特徴があります。

MAAベスト・プラクティスのガイドラインの例を次に示します。

親トピック: 可用性を最大化するための機能

Oracle Active Data Guardを使用する場合

簡易性、データ保護および可用性が重要視される場合は、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

Oracle GoldenGateを使用する場合

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および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つのデータベースを同期させるために使用されます。ユーザー・ワークロードは、グローバル・データ・サービス(GDS)を使用して、地理、ワークロードおよびサービス・レベルに基づき各データベース間で分散されます。Oracle GoldenGateのコピーは、停止が発生した場合にデータ損失ゼロのフェイルオーバーを可能にする、固有のローカル同期Data Guardスタンバイ・データベースを持ちます。Oracle GoldenGateのキャプチャおよび適用プロセスは、プライマリとスタンバイがお互いに正確で最新のレプリカであるので、フェイルオーバー後の新しいプライマリ・データベースで容易に再起動されます。

  • 障害保護用に使用されているOracle Active Data Guardスタンバイ・データベースは、Data Guardによりサポートされない計画メンテナンスの実行のために、一時的にOracle GoldenGateターゲットに変換されます。たとえば、バックエンド・データベース・オブジェクトの変更を必要とするSiebelアプリケーションのアップグレードで、ユーザーを新しいシステムにスイッチオーバーする前に包括的なテストが必要な場合です。

  • Oracle Active Data Guardは、停止時間がゼロまたはゼロに近い状態で、データベースのメジャー・バージョンのアップグレード(Oracle 18cから19cなど)が必要な場合に、本番環境の保護に使用されます。新しいバージョンのデータベースを使用して、プライマリ/スタンバイ環境がもう1つ作成され、Oracle GoldenGateは、本番環境からコピーの環境へ、一方向または双方向のレプリケーションでデータをレプリケートするために使用されます。Oracle GoldenGateで古い環境と新しい環境の同期が完了すると、本番は新しい環境に切り替わり、古い環境は廃止されます。これによって、構成により停止時間はゼロまたは最小となり、古い環境と新しい環境が完全に分離されることでリスクが軽減され、アップグレード・プロセス中に問題が発生しても、データ保護および可用性SLAへの影響が回避されます。

関連項目:

Oracle MAAベスト・プラクティス・ホワイト・ペーパー『Oracle Data GuardおよびOracle GoldenGateによる透過的なロール・トランジション』(http://www.oracle.com/goto/maa)

親トピック: ベスト・プラクティス: Oracle Active Data GuardおよびOracle GoldenGate

Recovery Manager

Recovery Manager (RMAN)は、データベースを効率的にバックアップおよびリカバリするための包括的な基盤を提供します。RMANは、操作の複雑さを排除するとともに、データベースの優れたパフォーマンスおよび可用性をもたらします。

RMANは、リクエストされたバックアップ、リストアまたはリカバリの操作を実行する最も効率的な方法を決定し、Oracle Databaseサーバーでの処理のために、これらの操作を発行します。RMANおよびサーバーは、データベース構造に加えられた変更を自動的に識別し、変更に適応するために必要な操作を動的に調整します。

RMANは、リカバリ・アプライアンス、ローカル・ディスク(ZFSストレージ)、テープ、クラウド・オブジェクト・ストアからバックアップおよびリストアする標準インターフェイスです。

RMANには次のような利点があります。

  • Oracle Shardingのサポート - すべての独立したデータベース(シャード)に対するRMANのサポート

  • スパース・データベースの拡張機能 - 次に対してバックアップおよびリストアを実行できます 
    SPARSE
    バックアップ・セットまたはイメージ・コピー(あるいはその両方)
  • ネットワーク経由のスタンバイ・データベースの修復での 
    NONLOGGED
    操作 - スタンバイでの検証および修復用の新しい構文 - 
    VALIDATE/RECOVER .. NONLOGGED BLOCK;
  • RMAN DUPLICATE
    機能。プライマリおよびバックアップからの遠隔同期の作成をサポートするために機能拡張されました
  • RMAN DUPLICATE
    暗号化バックアップの使用 - RMANは、次を使用した暗号化バックアップに基づく非自動ログイン・ウォレットがサポートするように機能拡張されます。新しい 
    SET
    コマンド - 中断されることなくクローニングを実行できます

  • ネットワーク経由でのクロス・プラットフォームのバックアップおよびリストアのサポート

  • ネットワーク対応のリストアにより、次が可能になります 
    RESTORE
    操作により、データベースから別のデータベースにネットワーク経由でデータ・ファイルを直接コピー
  • 次を使用した簡略化された表のリストア 
    RECOVER TABLE
    コマンド

  • 個々のプラガブル・データベースのバックアップとリストアを含む、Oracle Multitenantのサポート

  • 個々のPDBのバックアップとリストアを含む、クロスプラットフォームのOracle Multitenantのサポート

  • バックアップおよびリストア操作での自動チャネル・フェイルオーバー

  • リストア操作で欠落した、または破損したバックアップが検出された場合に、前回のバックアップへの自動フェイルオーバー

  • リカバリ中の一時ファイルおよび新規データベースの自動作成

  • 前回のポイント・イン・タイム・リカバリを使用した自動リカバリ(リセットログによるリカバリ)

  • ブロック・メディア・リカバリでは、データ・ファイルをオンラインに保ったまま、ブロックの破損を修復

  • ブロック・チェンジ・トラッキングを使用した高速増分バックアップ

  • イントラファイルおよびインターファイルの並列処理による高速バックアップ操作とリストア操作

  • 仮想プライベート・リカバリ・カタログによるセキュリティの強化

  • 増分バックアップがイメージ・コピーにマージされ、最新の状態にリカバリ可能

  • 必要なファイルのみ、バックアップおよびリストアを最適化

  • 保存方針により、関連のバックアップを確実に保存

  • 失敗した場合に、操作のバックアップおよびリストアを再開可能

  • 制御ファイルおよびサーバー・パラメータ・ファイルの自動バックアップを行うことにより、データベース構造の変化や、メディア障害や災害の発生時に、バックアップ・メタデータの使用が可能

  • 既存のバックアップから、または次を使用して本番データベースから直接(この場合ステージング領域は不要)、新しいデータベースを簡単に再インスタンス化 
    DUPLICATE
    コマンド。

関連項目:

『Oracle Databaseバックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』

親トピック: 可用性を最大化するための機能

Oracle Real Application ClustersおよびOracle Clusterware

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 Clusterware使用の利点

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 Real Application ClustersおよびOracle Clusterware

Oracle Real Application ClustersおよびOracle Clusterware使用の利点

Oracle RACとOracle Clusterwareの併用には、Oracle Clusterwareのすべての利点に加え、次のような利点があります。

  • すべてのOracleソフトウェア・スタックを使用することで、サード・パーティ・クラスタウェアを使用した場合より優れたOracle Databaseの統合およびサポートを提供します。

  • Oracle Serviceの自動的再配置。さらに、高速アプリケーション通知(FAN)とクライアント構成を追加で実行する場合は、高速かつ自動のインテリジェントな接続とフェイルオーバーを実現するために、アプリケーションが素早く反応できるようなFANイベントの配信。

  • 接続障害を高速に自動検出し、Oracle Universal Connection Pool(Oracle UCP)、高速接続フェイルオーバーおよびFANイベントを使用するJavaアプリケーションの終了済接続を削除します。

  • Oracle UCPランタイム接続ロード・バランシングを使用して作業リクエストを均等に分散します。

  • Oracle UCP、Oracle Call Interface(OCI)およびOracle Data Provider for .NET(ODP.NET)でランタイム接続ロード・バランシングを使用します。

  • ロード・バランシング・アドバイザを使用して、使用可能なすべてのインスタンスに作業を分散します。

  • Oracle Clusterwareが特定のデータベースに対するCPU要件と制限を認識するようデータベースを構成できます。Oracle Clusterwareはこの情報を使用して、CPU数、メモリー量またはその両方が十分備わっているサーバーにのみデータベース・リソースを配置します。

  • 停止時間またはアプリケーションへの変更なしで、汎用ハードウェアを使用して処理能力を向上できる柔軟性を提供します。

  • データベースおよびクラスタの機能を統合する包括的な管理性を提供します。

  • データベース・インスタンス全体にわたるスケーラビリティを提供します。

  • プールされていない接続の高速接続フェイルオーバーを実装します。

親トピック: Oracle Real Application ClustersおよびOracle Clusterware

従来のコールド・クラスタ・ソリューションより優れているOracle RACの利点

Oracle RACには、従来のコールド・クラスタ・ソリューションよりも多くの利点があり、次のような利点があります。

  • データベース・インスタンス全体にわたるスケーラビリティ

  • 停止時間またはアプリケーションへの変更なしで、汎用ハードウェアを使用して処理能力を向上できる柔軟性

  • コンピュータおよびインスタンスの障害の許容および障害からの迅速なリカバリが可能(秒単位)

  • アプリケーションの低下を、コールド・クラスタ・ソリューションの場合の数分から数時間と比べて、ゼロまたは数秒にすることが可能

  • 結合またはその他のテクノロジを使用せずに、冗長ネットワーク・インタフェースを使用したクラスタでの通信を最適化

    Oracle Grid InfrastructureおよびOracle RACによる、ネットワーク・トラフィックを分散し、クラスタ内の最適な通信を保証する冗長インターコネクトの使用。この機能は、Oracle Database 11gリリース2(11.2.0.2)以上で使用できます。それまでのリリースでは、結合またはトランキングのようなテクノロジを使用してインターコネクト用の冗長ネットワークを使用していました。

  • システム変更およびハードウェア変更のローリング・アップグレード

  • 個別パッチ、セキュリティ・パッチ、CPUおよびクラスタ・ソフトウェアのローリング・パッチ・アップグレード

  • 高速、自動およびインテリジェントな接続とサービスの再配置ならびにフェイルオーバー

  • データベースおよびクラスタの機能を統合する包括的な管理性(グリッド・プラグ・アンド・プレイ、およびポリシーに基づくクラスタ管理と容量管理を使用)

  • ロード・バランシング・アドバイザおよびランタイム接続ロード・バランシングによる、適切なリソース全体での作業のリダイレクトおよび均等な分散

  • データベース・ワークロードへのリソース割当てをポリシーベースでランタイム管理するためのOracle Quality of Service(QoS)管理(動的状況下でのビジネス・ニーズの順にサービス・レベルが満たされます)。これはデータベースが実行しているサーバー・プールにサービスを割り当てることにより行われます。プールからのリソースを使用して、必要な容量が使用可能になるようにします。

  • Oracle Enterprise Managementによる、Oracle ASMおよびOracle ACFS、グリッド・プラグ・アンド・プレイ、クラスタ・リソース管理、Oracle ClusterwareとOracle RACのプロビジョニングとパッチ適用のサポート。

  • Oracle RACに接続しているクライアントへの単一の名前としての、SCAN(単一クライアント・アクセス名)サポート。この名前は、クラスタのノードを追加または削除しても、クラスタの存続期間中は変更されません。

次の図は、Oracle RACアーキテクチャを使用したOracle Databaseを示しています。この図は、パーティション化された3つのノードからなるデータベースの、Oracle RACを使用したOracle Databaseアーキテクチャを示しています。Oracle RACデータベースは、異なるノード上の3つのインスタンスに接続されています。各インスタンスは、サービス(人事、販売およびコール・センター)に関連付けられています。インスタンスはハートビートを確認することでお互いを監視します。Oracle Net Servicesは、図の最上部にあるアプリケーション/Webサーバー層へのクライアント・アクセスを提供します。

図3-2 Oracle RAC使用のOracle Databaseアーキテクチャ

図3-2の説明が続きます
「図3-2 Oracle RAC使用のOracle Databaseアーキテクチャ」の説明

注意:

Oracleリリース11.2以降では、Oracle Clusterware (コールド・クラスタ・フェイルオーバー)を使用するよりも、より完全で、機能豊富なソリューションであるOracle RAC One NodeまたはOracle RACをお薦めします。

関連項目:

Oracle RAC管理およびデプロイメント・ガイド

Oracle Clusterware管理およびデプロイメント・ガイド

親トピック: Oracle Real Application ClustersおよびOracle Clusterware

Oracle RAC One Node

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 Automatic Storage Management。

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 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インスタンスに障害が発生した場合、ローカル・データベース・インスタンスは必要なメタデータおよびデータに引き続きアクセスできます。

  • フレックス・ディスクグループを使用して、同じディスクグループを使用する複数のデータベースでの高可用性のメリットに優先順位をつけます。主なHAの利点には、ファイル・エクステントの冗長性、指数制限のリバランス、優先順位のリバランスなどがあります。フレックス・ディスクグループを使用して、データベースごとに前述の機能の異なる値を設定できます。その結果、1つのディスクグループ内の複数のデータベースで優先順位を付けることができます。

  • フレックス・ディスクグループを使用して、1つのディスクグループを共有する複数のデータベースにquoto_groupsを実装し、領域管理と保護に利用できます。

  • フレックス・ディスクグループを使用して、ASM分割ミラー機能でポイント・イン・タイム・データベース・クローンを作成します。

  • ストレッチ・クラスタで優先読取りを使用し、読取りを1つのサイトに関連付けてパフォーマンスを改善します。

関連項目:

Oracle Automatic Storage Management管理者ガイド

親トピック: 可用性を最大化するための機能

高速リカバリ領域

高速リカバリ領域は、Oracle Database内のすべてのリカバリ関連ファイルおよびアクティビティを対象とした一元的な格納場所です。

この機能を有効にすると、すべてのRMANバックアップ、アーカイブREDOログ・ファイル、制御ファイルの自動バックアップ、フラッシュバック・ログおよびデータ・ファイルのコピーが自動的に特定のファイルシステムまたはOracle ASMディスク・グループに書き込まれ、このディスク領域はRMANとデータベース・サーバーによって管理されます。

高速リカバリ領域を使用するとテープへの書込みのボトルネックが解消されるため、ディスクへのバックアップ実行が高速化されます。さらに重要なことに、データベースのメディア・リカバリを行う必要がある場合は、データ・ファイルのバックアップがすぐに使用できます。必要なデータ・ファイルおよびアーカイブREDOログ・ファイルをリストアするためのテープおよび空きテープ・デバイスを見つける必要がないため、リストアおよびリカバリの時間が短縮されます。

高速リカバリ領域には、次の利点があります。

  • 関連リカバリ・ファイルの格納場所の一元化

  • リカバリ・ファイルに割り当てられたディスク領域を管理し、データベース管理タスクを簡素化

  • 高速で信頼性の高いディスクベースのバックアップおよびリストア

関連項目:

『Oracle Databaseバックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』

親トピック: 可用性を最大化するための機能

破損の予防、検出および修復

データ・ブロックの破損は、非常に破壊的で修復が困難な場合があります。破損は、発生した場合に重大なアプリケーションやデータベースの停止時間およびデータ損失が発生することがあり、さらに数時間、数日および数週間検出されなかった場合は、検出時にアプリケーションの停止時間がより長くなります。残念ながら、データベース内のデータ破損を包括的に回避、検出および修復する1つの方法はありません。破損の発生源および原因は、メモリー、ハードウェア、ファームウェア、ストレージ、オペレーティング・システム、ソフトウェア、ユーザー・エラーなどの多岐に渡るからです。さらに悪いことには、Oracleデータ・ブロックのセマンティクスやOracleのデータ・ブロックの変更方法を理解していないサード・パーティのソリューションでは、データ・ブロック破損の防止および検出ができません。サード・パーティのリモート・ミラーリング・テクノロジは、データ破損をデータベース・レプリカ(スタンバイ)に伝播する可能性があり、これは二重障害、データ損失および停止時間の長期化につながります。サード・パーティのバックアップおよびリストア・ソリューションでは、リストアまたは検証操作が実行されるまで破損したバックアップまたは無効なセクターを検出できないため、リストア時間が長くなり、データが失われる可能性があります。

Oracle MAAには、物理ブロック破損、論理ブロック破損、逸脱した書込みおよび書込みの欠落を含む、あらゆる形のデータ・ブロック破損を防止、検出および修復する包括的な計画があります。これらの追加の保護手段は、最も包括的なOracleデータ・ブロック破損の防止、検出および修復ソリューションを提供します。この計画の詳細は、My Oracle Supportのノート「Data Guard構成における破損の検出、防止および自動修復のベスト・プラクティス」(Doc ID 1302539.1)に記載されています。

様々な手動操作チェック、およびランタイムやバックグラウンドの破損チェックに対するブロック破損チェックを次にまとめます。データベース管理者と作業チームは、Oracle Recovery Manager (RMAN)バックアップの実行、RMANのCHECK LOGICAL検証、または重要なオブジェクトに対するANALYZE VALIDATE STRUCTUREコマンドの実行など、手動チェックを組み込むことができます。手動チェックは、更新や問合せがあまり行われないデータを検証する際に、特に重要です。

ランタイム・チェックは、問合せや更新が頻繁に行われるデータの破損を、即座にまたはランタイムに検出する点で非常に優れています。ランタイム・チェックにより、破損が回避されたり、自動的に修正されたりするため、より強力にデータを保護し、アプリケーションの可用性をさらに高めることが可能です。Exadataに新しいバックグラウンド・チェックが導入され、アプリケーション・オーバーヘッドなしで、ディスクのスキャンと修正が自動的かつインテリジェントに行われ、物理的に破損したブロックは自動的に修正されます。

表3-1 ブロック破損チェックの概要

チェック 機能 物理ブロック破損 論理ブロック破損

手動チェック

Dbverify、Analyze

物理的ブロック・チェック

ブロック内およびオブジェクト間の論理的な一貫性チェック

手動チェック

RMAN

バックアップおよびリストア操作中の物理的ブロック・チェック

ブロック内論理チェック

手動チェック

ASMの修正

物理的ブロック・チェック

ブロック内の複数の論理チェック

ランタイム・チェック

Oracle Active Data Guard

1. 転送および適用中に、物理的ブロック・チェックをスタンバイにおいて継続的に実行

2. 強力なデータベース分離により、データベースの単一点障害を排除

3. Oracle Database 12cリリース2のファイル・ブロック・ヘッダーを含む、ブロック破損の自動修正

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により、インメモリーのブロック内チェックを検証

Oracle Database 18c以降では、シャドウ消失書込み保護を有効にすると、追跡対象のデータ・ファイルのシステム変更番号(SCN)がOracleで追跡され、書込み欠落が早期に検出されます。書込み欠落が検出されると、エラーが即時に返されます。

この表の後にあるシャドウ消失書込み保護についての説明を参照してください。

ランタイム・チェック

ASMおよびASMソフトウェアのミラー化

(Exadata、SuperclusterおよびZero Data Loss Recovery Applianceに固有)

書込み中に、正常なASMエクステント・ブロックのペアが存在する場合、読取りおよび書込みの暗黙的なデータ破損検出と自動修復を実行

.

ランタイム・チェック

DIX + T10 DIF

オペレーティング・システムからHBAコントローラ、ディスク(ファームウェア)に至るまでのチェックサム検証。認定済のLinux、HBAおよびディスクに対する読取りと書込みを検証。

.

ランタイム・チェック

ハードウェアおよびストレージ

Oracle統合が行われていないため、限定的なチェック。チェックサムが最も一般的。

Oracle統合が行われていないため、限定的なチェック。チェックサムが最も一般的

ランタイム・チェック

Exadata

書込みに対する包括的なHARDチェック

書込みに対するHARDチェック

バックグラウンド・チェック

Exadata

ハード・ディスクの自動修正および修復。不良セクターの検出および修正。

.

シャドウ消失書込み保護

Oracle Database 18cの新機能のシャドウ消失書込み保護では、データが大きく破損する前に書込みが失われたことを検出します。Oracle Data Guardスタンバイ・データベースを必要とせずに、データベース、表領域またはデータファイルのシャドウ消失書込み保護を有効化できます。シャドウ消失書込み保護は、消失書込みを迅速に検出して即時に対応し、データベースでデータ破損が原因で発生する可能性のあるデータ損失を最小限に抑えます。

関連項目:

これらのビューと初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

My Oracle Supportノート1302539.1

親トピック: 可用性を最大化するための機能

データ・リカバリ・アドバイザ

データ・リカバリ・アドバイザは、永続的な(ディスク上の)データ障害を自動的に診断し、適切な修復オプションを示し、リクエストに応じて修復操作を実行します。

データ・リカバリ・アドバイザを使用して、プライマリ・データベース、ロジカル・スタンバイ・データベース、フィジカル・スタンバイ・データベースおよびスナップショット・スタンバイ・データベースをトラブルシューティングできます。

データ・リカバリ・アドバイザには、次の機能があります。

  • 障害診断

    通常、データベース障害の最初の兆候は、エラー・メッセージ、アラーム、トレース・ファイルおよびダンプ、ヘルス・チェックの失敗などです。これらの兆候を評価する作業はたいてい複雑で間違いやすく、時間がかかります。データ・リカバリ・アドバイザを使用すると、データ障害が自動的に診断され、これらの詳細が通知されます。

  • 障害の影響の評価

    障害の診断後、修復戦略について検討する前に、障害の範囲を把握し、アプリケーションに与える影響を評価する必要があります。データ・リカバリ・アドバイザを使用すると、障害の影響が自動的に評価され、わかりやすい形式でその結果が表示されます。

  • 修復の生成

    障害が正しく診断されたとしても、正しい修復方法の選択は容易ではなく、負担になります。さらに、判断を誤ると、停止時間の増加やデータ損失という点で大きな不利益を被ることになります。データ・リカバリ・アドバイザは、自動的に一連の障害に関する最善の修復方法を判断して提示します。

  • 修復の実行可能性チェック

    データ・リカバリ・アドバイザでは、修復オプションが示される前に、特定の環境や提案される修復処理を完了するために必要なメディア・コンポーネントの可用性に関して、ファイルをプライマリまたはスタンバイ・データベースから直接リストアして提案された修復を完了するなどの、これらの修復オプションが検証されます。

  • 修復の自動化

    提示された修復オプションを使用すると、この修復オプションが自動的に実行され、修復が成功したかどうかが検証されて、該当する障害が処置済となります。

  • データの整合性およびデータベースのリカバリ可能性の検証

    データ・リカバリ・アドバイザでは、選択すればいつでも、データ、バックアップおよびREDOストリームの整合性を検証できます。

  • 破損の早期検出

    状態モニターを使用して、データ・リカバリ・アドバイザによる診断チェックを定期的に実行するようスケジュール設定できます。これにより、トランザクションを実行しているデータベース・プロセスによって破損が検出されてエラーが通知される前に、データ障害を検出できます。早期の警告により、破損による損害を制限できます。

  • データの検証および修復の統合

    データ・リカバリ・アドバイザは、データの検証および修復用の単一のツールです。

注意:

データ・リカバリ・アドバイザでは、単一インスタンス・データベースのみがサポートされています。Oracle RACデータベースはサポートされていません。

関連項目:

データ・リカバリ・アドバイザでサポートされているデータベース構成の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

親トピック: 可用性を最大化するための機能

Oracle Flashbackテクノロジ

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は、不注意または悪意でデータを変更し、不正なインストールおよびアップグレードの原因となり、アプリケーションでのロジカル・エラーを招く様々な人的エラーまたはオペレータによるエラーにより損なわれたデータに対処して巻き戻すことができます。これらの問題では、フラッシュバック・トランザクション、フラッシュバック・ドロップ、表のフラッシュバック、データベースのフラッシュバックなどの機能が使用されます。

  • Oracle Flashback Query
    Oracle Flashback Query (フラッシュバック問合せ)では、自動UNDO管理システムを利用してトランザクションのメタデータおよび履歴データを取得することで、過去に存在したデータを表示できます。
  • Oracle Flashback Version Query
    Oracle Flashback Version QueryはSQLの拡張機能で、特定の表から特定の期間に存在した行のバージョンを取得するために使用できます。
  • Oracle Flashback Transaction
    Oracle Flashback Transactionは、トランザクションとその依存トランザクションをバックアウトします。
  • Oracle Flashback Transaction Query
    Oracle Flashback Transaction Queryは、データベースに加えられたすべての変更をトランザクション・レベルで表示するためのメカニズムを提供します。
  • Oracle Flashback Table
    Oracle Flashback Tableを使用すると、過去のある時点の状態に表をリカバリできます。
  • Oracle Flashback Drop
    削除された表、索引、制約またはトリガーをリカバリする簡単な方法はありませんが、Oracle Flashback Dropでは、オブジェクトを削除する際の安全策が提供されます。
  • リストア・ポイント
    Oracle Flashbackのリカバリ操作をデータベースで実行するとき、後でデータをフラッシュバックできるポイント(システム変更番号(SCN)またはタイムスタンプで識別)を決定する必要があります。
  • Oracle Flashback Database
    Oracle Flashback Databaseは高速巻戻しボタンのようなもので、データベースを過去の時点にすばやく巻き戻します。バックアップやアーカイブ・ログを使用したリストアやロール・フォワードに時間をかける必要がありません。
  • Flashback Pluggable Database
    前のSCNまでPDBを巻き戻すことができます。SQLまたはRecovery Managerから使用可能なFLASHBACK PLUGGABLE DATABASEコマンドは、非CDBでのFLASHBACK DATABASEに類似しています。
  • フラッシュバック・ログまたはフィジカル・スタンバイ・データベースを使用したブロック・メディア・リカバリ
    自動的な破損ブロック修復の試行後、ブロック・メディア・リカバリ機能で、フラッシュバック・ログからデータ・ブロックの最新コピーを必要に応じて取得して、リカバリ時間を短縮できます。
  • フラッシュバック・データ・アーカイブ
    フラッシュバック・データ・アーカイブは表領域に格納され、レコードの存続期間中に表のすべてのレコードに対して行われたトランザクションの変更が含まれます。

関連項目:

Oracle Database開発ガイド

Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイドのフラッシュバックおよびデータベースのポイント・イン・タイム・リカバリの実行、フラッシュバック・データベースおよびリストア・ポイントの使用およびブロック・メディア・リカバリの実行

Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス

『Oracle Database Recovery Managerリファレンス』

親トピック: 可用性を最大化するための機能

Oracle Flashback Query

Oracle Flashback Query (フラッシュバック問合せ)では、自動UNDO管理システムを利用してトランザクションのメタデータおよび履歴データを取得することで、過去に存在したデータを表示できます。

UNDOデータは永続的で、データベースの異常や停止の際にも失われません。フラッシュバック問合せの独自の機能により、表の以前のバージョンの問合せが可能になり、誤った操作からリカバリするための強力なメカニズムも提供されます。

フラッシュバック問合せの用途は次のとおりです。

  • 失われたデータのリカバリや、誤ったコミット済の変更の取消しを行います。たとえば、削除または更新された行を、コミット後でもただちに修復できます。

  • 現行のデータと過去のある時点の対応するデータとを比較します。たとえば、前日のデータの変更を示す日次レポートを使用すると、表データの個々の行を比較したり、一連の行の共通部分または和集合を検索したりできます。

  • 特定の日の勘定残高を確認するなど、ある時点におけるトランザクション・データの状態をチェックします。

  • 特定のタイプの一時データを格納する必要をなくすことで、アプリケーションの設計を簡素化します。フラッシュバック問合せを使用すると、過去のデータをデータベースから直接取得できます。

  • レポート生成ツールなどのパッケージ・アプリケーションを過去のデータに適用します。

  • アプリケーションのセルフサービス・エラー修正を実現し、ユーザーが自分のエラーの取消しおよび修正を行えるようにします。

親トピック: Oracle Flashbackテクノロジ

Oracle Flashback Version Query

Oracle Flashback Version QueryはSQLの拡張機能で、特定の表から特定の期間に存在した行のバージョンを取得するために使用できます。

Oracle Flashback Version Queryでは、指定期間に存在した行のバージョンごとに1行が返されます。どの表でも、毎回次のタイミングで新しい行のバージョンが作成されます 
COMMIT
文の実行時。

Oracle Flashback Version Queryは、データベース管理者が問題の原因特定の分析を実行するために使用できる強力なツールです。さらに、アプリケーション開発者はOracle Flashback Version Queryを使用して、監査目的のカスタム・アプリケーションを作成できます。

親トピック: Oracle Flashbackテクノロジ

Oracle Flashback Transaction

Oracle Flashback Transactionは、トランザクションとその依存トランザクションをバックアウトします。

DBMS_FLASHBACK.TRANSACTION_BACKOUT()
プロシージャは、データベースがオンラインのまま、トランザクションとその依存トランザクションをロール・バックします。このリカバリ操作ではUNDOデータを使用して、影響を受けたデータを元の状態に戻す補正トランザクションを作成および実行します。次の問合せができます 
DBA_FLASHBACK_TRANSACTION_STATE
ビュー: トランザクションが依存性ルールを使用してバックアウトされたか、次のいずれかを実行することによって強制的に破棄されたかを確認できます。

  • 競合していない行のバックアウト

  • UNDO SQLの適用

Oracle Flashback Transactionでは、特定のトランザクション、またはトランザクションのセットとその依存トランザクションを迅速にバックアウトすることにより、論理リカバリ時の可用性が向上します。データベースがオンラインのまま、1つのコマンドを使用してトランザクションをバックアウトします。

親トピック: Oracle Flashbackテクノロジ

Oracle Flashback Transaction Query

Oracle Flashback Transaction Queryは、データベースに加えられたすべての変更をトランザクション・レベルで表示するためのメカニズムを提供します。

Oracle Flashback Version Queryと併用した場合、人的エラーまたはアプリケーションのエラーからリカバリする高速で効率的な手段となります。Oracle Flashback Transaction Queryでは、行を変更したデータベース・ユーザーが返されるため、データベースの問題のオンライン診断を実行する能力が強化されます。また、トランザクションの分析および監査も実行されます。

親トピック: Oracle Flashbackテクノロジ

Oracle Flashback Table

Oracle Flashback Tableを使用すると、過去のある時点の状態に表をリカバリできます。

人的エラーまたはアプリケーションのエラーによって変更された1つの表または一連の表をリカバリするための高速なオンライン・ソリューションを提供します。ほとんどの場合、Oracle Flashback Tableを使用することで、管理者がより複雑なポイント・イン・タイム・リカバリ操作を実行する必要性は軽減されます。元の表のデータは、Oracle Flashback Tableを使用すると表を元の状態に戻せるため失われません。

親トピック: Oracle Flashbackテクノロジ

Oracle Flashback Drop

削除された表、索引、制約またはトリガーをリカバリする簡単な方法はありませんが、Oracle Flashback Dropでは、オブジェクトを削除する際の安全策が提供されます。

表を削除すると、その表は自動的にごみ箱に入ります。ごみ箱は、すべての削除済オブジェクトが入っている仮想コンテナです。削除した表のデータは、引き続き問い合せることができます。

親トピック: Oracle Flashbackテクノロジ

リストア・ポイント

Oracle Flashbackのリカバリ操作をデータベースで実行するとき、後でデータをフラッシュバックできるポイント(システム変更番号(SCN)またはタイムスタンプで識別)を決定する必要があります。

Oracle Flashbackのリストア・ポイントとは、フラッシュバック・データベース、フラッシュバック表およびOracle Recovery Manager(RMAN)操作で使用されるSCNまたはトランザクション時間に置き換えるためにユーザーが定義できるラベルです。さらに、データベースは、前回のデータベース・リカバリによりフラッシュバックでき、次を使用してオープンできます。 
OPEN RESETLOGS
コマンド(保証されたリストア・ポイントを使用)。保証されたリストア・ポイントを使用して、データベースの巻戻しに必要なUNDOが保存されるようにすることで、データベースのバッチ・ジョブ、アップグレードまたはパッチなどの主なデータベース変更を素早く元に戻すことができます。

リストア・ポイント機能を使用すると、次の利点があります。

  • 一貫性のある状態、つまり失敗した計画操作(バッチ・ジョブ、Oracleソフトウェア・アップグレードまたはアプリケーション・アップグレードの失敗など)より前の適切なポイントに素早くリストアすることが可能

  • スナップショット・スタンバイ・データベースをプライマリ・データベースと再同期させる機能

  • テスト・データベースまたはクローン化されたデータベースを元の状態に戻す迅速なメカニズム

親トピック: Oracle Flashbackテクノロジ

Oracle Flashback Database

Oracle Flashback Databaseは高速巻戻しボタンのようなもので、データベースを過去の時点にすばやく巻き戻します。バックアップやアーカイブ・ログを使用したリストアやロール・フォワードに時間をかける必要がありません。

データベースのサイズが大きくなるほど、Oracle Flashback Databaseを使用する高速なポイント・イン・タイム・リカバリの利点も大きくなります。

Oracle Flashback Databaseを有効にすると、次の利点があります。

  • ポイント・イン・タイム・リカバリで論理破損(管理エラーを原因とする破損など)を高速に修復。

  • Oracleリストア・ポイントと組み合わせた反復テストに便利。リストア・ポイントの設定、データベースの変更の実装、影響を評価するためのワークロードのテスト実行が可能。Oracle Flashback Databaseを使用して、変更を破棄して元の起点に戻り、別の変更を行ってから、同じワークロードでもう一度テスト実行することで、正当な基盤に基づいて異なる構成変更の影響を比較することができます。

  • Data GuardはOracle Flashback Databaseを使用して、障害の発生したプライマリ・データベースを、(フェイルオーバー後に)新しいスタンバイとしてすばやく再インスタンス化します(障害の発生したプライマリをバックアップからリストアする必要はありません)。

  • Flashback DatabaseはCDBレベルまたはPDBレベルで動作します。

親トピック: Oracle Flashbackテクノロジ

プラガブル・データベースのフラッシュバック

PDBを前のSCNまで巻き戻しできます。SQLまたはRecovery Managerから使用可能なFLASHBACK PLUGGABLE DATABASEコマンドは、非CDBでのFLASHBACK DATABASEに類似しています。

フラッシュバックPDBはデータ破損、広範囲のユーザー・エラー、およびREDO破損から個々のPDBを保護します。操作ではCDB内の他のPDBのデータは巻き戻しされません。

次を使用して 
CREATE RESTORE POINT ... FOR PLUGGABLE
        DATABASE
PDBのリストア・ポイントを作成できます。これは、指定されたPDB内でのみ使用できます。CDBリストア・ポイントと同様に、PDBリストア・ポイントも通常または保証付きのいずれかです。保証付きリストア・ポイントは、制御ファイルからエージ・アウトされず、明示的に削除する必要があります。ルートに接続していて、次を指定しない場合、 
FOR PLUGGABLE
        DATABASE
句。すべてのPDBで使用できるCDBリストア・ポイントが作成されます。

特殊なPDBリストア・ポイントのタイプはクリーン・リストア・ポイントで、これはPDBが閉じている場合のみ作成できます。共有UNDOを使用するPDBの場合、クリーン・リストア・ポイントまでのPDBの巻き戻しは他の操作よりも高速に行われます。これは、バックアップのリストアまたは一時データベース・インスタンスの作成が不要なためです。

親トピック: Oracle Flashbackテクノロジ

フラッシュバック・ログまたはフィジカル・スタンバイ・データベースを使用したブロック・メディア・リカバリ

自動的な破損ブロック修復の試行後、ブロック・メディア・リカバリ機能で、フラッシュバック・ログからデータ・ブロックの最新コピーを必要に応じて取得して、リカバリ時間を短縮できます。

自動ブロック修復を使用すると、検出されたプライマリ・データベースの破損ブロックをフィジカル・スタンバイ・データベースの良好なブロックを使用してただちに自動修復できます。

その上、インスタンスのリカバリで発生した破損ブロックによってインスタンスのリカバリが失敗することはありません。そのブロックは自動的に破損とマークされ、次のRMAN破損リストに追加されます 
V$DATABASE_BLOCK_CORRUPTION
表。その後、RMANの次を発行します 
RECOVER BLOCK
コマンド。これにより、関連するブロックを修正できます。また、RMANの 
RECOVER BLOCK
コマンドは、フィジカル・スタンバイ・データベース(使用できる場合)からブロックをリストアします。

親トピック: Oracle Flashbackテクノロジ

フラッシュバック・データ・アーカイブ

フラッシュバック・データ・アーカイブは表領域に格納され、レコードの存続期間中に表のすべてのレコードに対して行われたトランザクションの変更が含まれます。

アーカイブされたデータは、UNDO表領域で提供される保存期間よりも長く保存でき、分析および修復のために非常に古いデータを取得するために使用されます。

親トピック: Oracle Flashbackテクノロジ

Oracle Data Pumpとデータ転送

Oracle Data Pumpテクノロジを使用すると、データおよびメタデータをデータベース間で非常に高速に移動できます。Data Pumpは、次の計画メンテナンス・アクティビティを実行するために使用されます。

  • 異なるプラットフォームへのデータベース移行

  • プラガブル・データベースへのデータベース移行

  • データベース・アップグレード

前述の計画メンテナンス・アクティビティを可能にするData Pump機能は次のとおりです。

  • データベース全体を異なるデータベース・インスタンスに移動するフル・トランスポータブル・エクスポート/インポート

  • データベース間で一連の表領域を移動するトランスポータブル表領域

関連項目:

データのトランスポート

親トピック: 可用性を最大化するための機能

データベース以外のファイルに対するOracleレプリケーション・テクノロジ

Oracle ASMクラスタ・ファイル・システム、Oracle Database File SystemおよびOracle Solaris ZFS Storage Applianceレプリケーションは、データベース以外のファイル用のOracleレプリケーション・テクノロジです。

表3-2 データベース以外のファイルに対するOracleレプリケーション・テクノロジ

テクノロジ 推奨される使用方法 コメント

Oracle ASMクラスタ・ファイル・システム

Oracle ASM、Oracle ClusterwareおよびOracle Enterprise Managerテクノロジと統合された単一ノードおよびクラスタ全体のファイルシステム・ソリューションの提供を推奨Data GuardまたはOracle GoldenGateとの結合時に、疎結合されたフル・スタック・レプリケーション・ソリューションを提供します。

Oracle ACFSでは、Oracle ASMインスタンスおよびディスク・グループのステータス更新やディスク・グループのリバランスなどのOracle ASMの状態遷移に関与するために、Oracle ASMインスタンスとの通信を確立し、維持します。

実行可能ファイル、データベース・トレース・ファイル、データベース・アラート・ログ、アプリケーション・レポート、BFILE、構成ファイルなど、様々なデータベース・ファイルおよびアプリケーション・ファイルがサポートされます。他にも、ビデオ、オーディオ、テキスト、イメージ、設計図、その他の汎用アプリケーションのファイル・データがサポートされます。

ポイント・イン・タイム・リカバリの発生時にデータベースの変更とファイル・システムの変更間で時間整合性をほぼ提供可能

NFSやCIFSなどの標準NASファイル・アクセス・プロトコルを使用してリモート・クライアントからアクセスおよびエクスポートできます。

Oracle Database File System,

データベースとデータベース以外のシステム間で強化された同期を提供する場合に推奨

データベースの変更とファイル・システムの変更間で完全に一貫性を保持するためにデータベースとの統合が可能

データベースに保存され、Oracle Active Data Guardと使用して障害時リカバリと読取り専用アクセスの両方を提供できるすべてのデータ

Oracleデータベースのすべての機能を利用可能

Oracle Solaris ZFS Storage Applianceレプリケーション

データベース以外のファイルに対する障害時リカバリ保護、特にOracle Fusion Middlewareのデータベース外に保存されたクリティカル・ファイルに推奨します。

Oracle Fusion Middlewareバイナリ構成を含む、データベース以外のすべてのオブジェクトのレプリケート

ポイント・イン・タイム・リカバリの発生時にデータベースの変更とファイル・システムの変更間で時間整合性をほぼ提供可能
  • Oracle ASMクラスタ・ファイル・システム
    Oracle ASMクラスタ・ファイル・システム(ACFS)は、マルチプラットフォームのスケーラブル・ファイルシステムであり、Oracle Automatic Storage Management (Oracle ASM)機能を拡張して、Oracle Databaseの外部で保持されているカスタマ・ファイルをサポートするストレージ管理テクノロジです。
  • Oracle Database File System
    Oracle Database File System (DBFS)は、ファイルを格納するデータベースの機能と、リレーショナル・データを効率的に管理するデータベースの強みを活用して、データベースに格納されたファイルに対する標準のファイルシステム・インタフェースを実装します。
  • Oracle Solaris ZFS Storage Applianceレプリケーション
    Oracle Solaris ZFS Storage Applianceシリーズでは、ソース・アプライアンスから任意の数のターゲット・アプライアンスに、手動で、スケジュールに従って、あるいは連続して、プロジェクトとシェアをスナップショットベースでレプリケートできます。

親トピック: 可用性を最大化するための機能

Oracle ASMクラスタ・ファイル・システム

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レプリケーションは、データベースに対するData Guardと同様、これによりネットワーク経由でのOracle ACFSファイルシステムのリモート・サイトへのレプリケーションが可能になり、ファイルシステムに対する障害時リカバリ機能が提供されます。Oracle ACFSレプリケーションはプライマリ・ファイルシステムのディスクに書き込まれた変更を取得し、その変更をレプリケーション・ログと呼ばれるファイルに記録します。このログは、関連するスタンバイ・ファイルシステムをホストするサイトに転送され、そこでバックグラウンド・プロセスがログを読み取り、ログに記録された変更をスタンバイ・ファイルシステムへ適用します。レプリケーション・ログに記録された変更がスタンバイ・ファイルシステムに正常に適用された後、レプリケーション・ログはプライマリおよびスタンバイ・ファイルシステムをホストしているサイトから削除されます。

Oracle ACFSの追加機能では、一般ファイルおよびアプリケーション・ファイルのスナップショット・ベースのレプリケーションが可能で、障害時リカバリおよびテスト/開発環境のためのHAソリューションが提供されます。ACFSに格納されたOracle Databaseでは、Oracle MultitenantおよびACFSスナップショット・テクノロジを利用して、プラガブル・データベースのスナップショット・クローンを迅速かつ効率的に作成できます。

Oracle Data GuardとOracle ACFSを結合し、スタンバイ・データベースでデータベースを保護するData Guardと、スタンバイ・ホストにファイル・システムの変更をレプリケートするOracle ACFSにより、フル・スタック高可用性ソリューションを提供できます。計画済停止の場合、データベースはデータ損失なしで特定の時点との一貫性を維持します。

関連項目:

Oracle ACFS ASMクラスタ・ファイル・システム: 概要および使用方法

Oracle MAAホワイト・ペーパー『フル・スタック・ロール・トランジション-Oracle ACFSおよびOracle Data Guard』(http://www.oracle.com/goto/maa)

親トピック: データベース以外のファイルに対するOracleレプリケーション・テクノロジ

Oracle Database File System,

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ファイルシステムに対して実行することもできます。

関連項目:

データベース・ファイルシステム(DBFS)

親トピック: データベース以外のファイルに対するOracleレプリケーション・テクノロジ

Oracle Solaris ZFS Storage Applianceレプリケーション

Oracle Solaris ZFS Storage Applianceシリーズでは、ソース・アプライアンスから任意の数のターゲット・アプライアンスに、手動で、スケジュールに従って、あるいは連続して、プロジェクトとシェアをスナップショットベースでレプリケートできます。

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 ZFS Storage Applianceソフトウェア

親トピック: データベース以外のファイルに対するOracleレプリケーション・テクノロジ

Oracle Multitenant

Oracle Multitenantはデータベースの統合に最適な方法です。マルチテナント・アーキテクチャでは、これまでの統合方法に付きものであったトレードオフはなくし、それぞれの一番よい特性が結合されています。

Oracle Multitenantは統合やプロビジョニング、アップグレードなどを簡素化することにより、ITコストの削減を支援します。この新しいアーキテクチャでは、コンテナ・データベース(CDB)に多数のプラガブル・データベース(PDB)を保持できます。アプリケーションでは、これらのPDBはスタンドアロン・データベースとして認識され、PDBにアクセスするためにアプリケーションを変更する必要はありません。複数のデータベースをPDBとして1つのCDBに統合することにより、複数のデータベースを1つのデータベースとして管理できるようになります。ビジネスで必要な場合には、分離してPDBを操作する柔軟性もあります。

Oracle Multitenantは、非コンテナ・データベース(非CDB)と同様に、Oracle Real Application Clusters、Oracle Data Guard、Oracle GoldenGateなどの高可用性機能と互換し、それらの機能を直接利用できるため、どのOracle MAA参照アーキテクチャでも使用できます。同じ高可用性要件を持つPDBを同じCDBにグループ化すると、それらすべてのPDBとそのアプリケーションは同じテクノロジと構成で管理および保護されます。

Oracle Multitenantを使用する利点

  • 統合密度の高さ - 1つのCDBに、多数のPDBを格納できます。これらのPDBはバックグランド・プロセスとメモリー構造体を共有し、非CDBよりも多くのPDBを実行できます。これは、各非CDBのオーバーヘッドが削除または削減されるためです。CDBには最大4095個のPDBを格納できます。また、各PDBでは、同じCDB内の他のPDBと異なる文字セットを使用することもできます。この場合、CDBルートの文字セットはPDBのすべての文字セットのスーパーセットになります。ロジカル・スタンバイ・データベースは、この文字セットの混在もサポートして、一時ロジカル・スタンバイ・データベースを使用してローリング・アップグレード実行できます。

  • クローン、リフレッシュ可能なクローン、PDBの再配置を含むオンラインのプロビジョン操作 - PDBを1つのCDBから切断して別のCDBに接続できます。PDBを同じCDBまたは別のCDBにクローニングすることも可能です。DBaaSまたはSaaS環境では、クローニングにより、ゴールド・イメージやシード・データベースを作成できます。このPDBをクローニングすれば、新規顧客用にデータベース環境を簡単に設定できます。

    • 停止時間がゼロに近いPDB再配置 – この機能では、クローン機能を使用してPDBを別のCDBに再配置する停止時間を大幅に短縮します。再配置が行われている間、ソースのPDBは開いたまま機能し続けます。アプリケーションの停止は非常に短時間に短縮され、ソースのPDBは一貫性のある状態になり、宛先のPDBは同期されてオンラインになります。この機能は別の新機能であるリスナー・リダイレクトも利用します。これにより、アプリケーションで同じ接続記述子を維持し、再配置後も宛先PDBに接続できます。

    • オンラインのプロビジョニングとクローニング – ソースのPDBを読取り専用モードにする必要なく、PDBのクローンを作成できます。ソースのPDBは読取り/書込みモードのままにすることができ、クローン操作中もアプリケーションにアクセスできます。

    • リフレッシュ可能なPDBのクローン – PDBのクローンは、設定された間隔で自動的にまたは手動でソースPDBへの変更を適用してリフレッシュするのと同じ方法で作成できます。リフレッシュ可能なクローンの場合は、読取り専用モードで維持する必要があります。クローンは読取り/書込みで開くことで通常のPDBに変換できます。リフレッシュ可能なクローンは、Exadataストレージ・スナップショットのテスト・マスターとして使用するのに最適です。

  • パッチ適用およびアップグレードの新オプション - CBDをアップグレードまたはパッチ適用すると、そのコンテナのPDBもアップグレードまたはパッチ適用されます。分離が必要な場合は、PDBを切断し、後のバージョンでCDBに接続できます。

  • データベースのバックアップとリカバリ - 複数のデータベースをPDBとして統合することで、バックアップと障害リカバリなどの操作をコンテナ・レベルで実行できます。Oracle Multitenantでも、同じCDB内の、実行されているその他のPDBに影響を与えずに、個々のPDBを柔軟にバックアップおよびリストアできます。

  • Oracle Data Guardを使用した操作 - CDBレベルでは、Data Guard構成が維持されます。Data Guardのロール・トランジション(フェイルオーバーかスイッチオーバーのいずれか)が実行されると、すべてのPDBが新しいプライマリ・データベースに移行されます。単一データベースの場合には必要になりますが、PDBごとに複数のData Guard構成を作成したり管理したりする必要はありません。Data Guard Standby-First PatchやData Guard一時ロジカル・ローリング・アップグレードなどの既存ツールを使用して停止時間を短くすることが可能で、コンテナ・レベルで実行されるため、すべてのPDBを一度の操作でメンテナンスできます。

    • Data Guard BrokerでのPDBの移行 – Data Guard Brokerが拡張されて、PDBをプライマリ・データベースまたはスタンバイ・データベースのCDBから別のCDBに自動的に移行できるようになりました。これは、PDBを同じバージョンで実行中の別のCDBまた上位バージョンで実行中CDBのいずれかに直接移行してアップグレード・プロセスを開始するために使用できます。この自動化を使用すると、スタンバイ・データベースでPDBファイルを使用して同じバージョンの別のCDBに接続し、単一のPDBフェイルオーバーに影響を与えることもできます。

    • サブセット・スタンバイ - Oracle Multitenantのユーザーは、スタンバイ・データベースへのレプリケーション用のCDBでPDBのサブセットを指定できます。これにより、どのスタンバイ・データベースにどのPDBを含めるか細かく指定できます。

  • Oracle GoldenGateを使用した操作 - Oracle Multitenantには、Oracle GoldenGateで提供されているすべての機能があります。GoldenGateは、PDBレベルで柔軟に操作することができ、レプリケーションをCDB内のPDBのサブセットに対して実行できます。GoldenGateを使用して、CDBレベルまたは個々のPDBレベルで、停止時間が最小限またはゼロのアップグレードを実行できます。

  • リソース管理 - Oracle Resource Managerで単一データベース間のリソース使用率を制御できるのと同じように、コンテナ内の個々のPDBのリソース使用率も制御できます。これにより、1つのPDBが、割り当てられている量を超えてシステム・リソースにアクセスすることはありません。PDBの制限で、SGA、バッファ・キャッシュ、共有プールおよびPGAメモリーの保証された最小値および最大値を指定できます。

  • Oracle Flashback Databaseの操作 - 高速のポイント・イン・タイム・リカバリが必要な場合は、Oracle Multitenantの初期リリースを使用すると、CDBレベルでFlashback Databaseを使用できます。Oracle Multitenantでは、その他のPDBの可用性に影響を与えずに、個々のPDBでFlashback Databaseを使用できます。Flashback DatabaseはCDBレベルで実行でき、コンテナ内のすべてのPDBがフラッシュバックされます。プラガブル・データベースのフラッシュバック機能を使用して、個々のPDBをフラッシュバックできます。個々のPDBをフラッシュバックする場合、他のすべてのPDBは影響を受けません。

  • Data Guard Broker PDBの移行またはフェイルオーバー - マルチテナントのブローカ構成では、本番PDBをコンテナ・データベースから同じシステムにある別のコンテナ・データベースに移動する必要がある場合があります。また、本番PDBで障害が発生したが、コンテナ・データベースおよび他のすべてのPDBが通常どおりに機能している場合、Data Guardスタンバイ・データベースから新しい本番コンテナ・データベースにPDBをフェイルオーバーする必要がある場合があります。新しいData Guard BrokerコマンドMIGRATE PLUGGABLE DATABASEを使用すると、単一PDBを別のコンテナ・データベースに移動したり、単一PDBをData Guardスタンバイから新しい本番コンテナ・データベースにフェイオーバーする操作を簡単に実行できます(Oracle Database 12cリリース2の新機能)。

関連項目:

Oracle Multitenant管理者ガイド

Oracle Databaseの統合のベスト・プラクティス: MAA参照アーキテクチャを含む実装のためのガイド

親トピック: 可用性を最大化するための機能

Oracle Sharding

Oracle Shardingはアプリケーションに対する拡張性および可用性の機能で、シャード・データベースで実行されるように明示的に設計されています。

Oracle Shardingを使用すると、ハードウェアやソフトウェアを共有しないOracleデータベースのプール間でデータを配布およびレプリケーションできます。データベースのプールは1つの論理データベースとしてアプリケーションに示されます。プールにデータベース(シャード)を追加するだけで、任意のレベル、任意のプラットフォームにアプリケーション(データ、トランザクションおよびユーザー)を柔軟にスケーリングできます。最大1000個のシャードまでのスケール・アップがサポートされています。

Oracle Shardingは、スケーラビリティに対して同様のアプローチを使用するカスタムのデプロイメントに比べ、より優れたランタイム・パフォーマンスとよりシンプルなライフサイクル管理を提供します。リレーショナル・スキーマ、SQL、およびその他のプログラム・インタフェース、複雑なデータ型のサポート、オンライン・スキーマの変更、マルチコア・スケーラビリティ、高度なセキュリティ、圧縮、高可用性、ACIDプロパティ、読取り一貫性、JSONを使用した開発者の俊敏性などを含むエンタープライズDBMSの利点も提供します。

関連項目:

Oracle Shardingの使用

親トピック: 可用性を最大化するための機能

Oracle Restart

Oracle Restartは、単一インスタンスの(クラスタ化されていない) Oracleデータベースおよびそのコンポーネントの可用性を向上します。

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 Restart機能のインストールおよび構成の詳細は、『Oracle Database管理者ガイド』を参照してください。

親トピック: 可用性を最大化するための機能

Oracle Site Guard

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管理者ガイド

親トピック: 可用性を最大化するための機能

オンライン再編成および再定義

可用性および管理性を強化する1つの方法として、データの再編成操作中、データベースへの通常のアクセス権をユーザーに与えます。

Oracle Databaseのオンライン再編成および再定義機能により、管理者は、データベースへの通常のアクセス権をユーザーに与えたまま、表の物理属性を変更したり、データおよび表構造の両方を変換したりするなど多くの柔軟性が得られます。この機能によって、データの可用性、問合せのパフォーマンス、レスポンス時間およびディスク領域の使用率が向上します。これらは、すべてミッションクリティカルな環境において重要で、アプリケーションのアップグレード・プロセスをより簡単、安全かつ高速なものにします。

Oracle Databaseのオンライン・メンテナンス機能を使用すると、アプリケーションのデータベース・オブジェクトに変更を加えるために必要なアプリケーションの停止時間が大幅に短縮(または排除)されます。

関連項目:

Oracle Database管理者ガイドのオンラインでの表の再定義を参照してください

親トピック: 可用性を最大化するための機能

Zero Data Loss Recovery Appliance。

クラウド規模のZero Data Loss Recovery Appliance (通常、リカバリ・アプライアンスと呼ばれる)は、エンタープライズ内のすべてのOracleデータベースでデータ損失とバックアップ・オーバーヘッドを劇的に削減するエンジニアド・システムです。

Recovery Manager (RMAN)と統合したリカバリ・アプライアンスによって、クラウド規模の耐障害性の高いハードウェアと記憶域を使用し、多数のデータベースに対応する、集中管理された永久的増分バックアップ計画が実現します。リカバリ・アプライアンスでは、継続してバックアップのリカバリ可能性が検証されます。

リカバリ・アプライアンスは、次の理由からMAA推奨バックアップおよびリカバリ・アプライアンスです。

  • リカバリ・アプライアンスから復元する場合のデータ損失の排除

  • 最小限のバックアップ・オーバーヘッド

  • エンドツーエンド・データ保護の可視性の向上

  • クラウド規模の保護

  • Oracle Sharding層を含むすべてのMAA参照アーキテクチャとの適切な統合

関連項目:

Zero Data Loss Recovery Applianceドキュメント

親トピック: 可用性を最大化するための機能

フリート・パッチ適用およびプロビジョニング

フリート・パッチ適用およびプロビジョニングでは、領域効率がよいソフトウェアのリポジトリ(より正確には「ゴールド・イメージ」)が維持されます。これは、任意の数のターゲット・マシンにプロビジョニングできる標準化されたソフトウェア・ホームです。

任意の数のホームを特定のゴールド・イメージからプロビジョニングでき、フリート・パッチ適用およびプロビジョニングによって系統情報が保持されるため、デプロイされたソフトウェアの出所が常に認識されます。ゴールド・イメージはシリーズに編成できるため、リリースの展開を追跡するグループを作成できます。様々な調整されたソリューション(特定のアプリケーションのOracle Databaseパッチ・バンドルなど)が異なるシリーズにグループ化されます。通知システムは、特定のシリーズで新しいイメージが使用可能になると関係者に通知します。フリート・パッチ適用およびプロビジョニングは、Oracle Grid Infrastructureの機能です。フリート・パッチ適用およびプロビジョニング・サーバーを構成するコンポーネントは、Oracle Grid Infrastructureによって自動的に管理されます。

フリート・パッチ適用およびプロビジョニングを使用して、データベース、クラスタウェア、ミドルウェアおよびカスタム・ソフトウェアをプロビジョニングできます。フリート・パッチ適用およびプロビジョニングには、Oracle Grid InfrastructureおよびOracle Databaseのデプロイメントを作成、構成、パッチ適用およびアップグレードする追加機能があります。これらの機能によって、メンテナンスが簡単になり、リスクと影響が軽減され、変更をバックアウトする必要がある場合にロールバックのオプションが提供されます。追加機能としては、ベース・マシンへのクラスタおよびデータベースのプロビジョニング、クラスタおよびOracle RACデータベースの拡張と縮小による簡単なオンデマンドの容量調整があります。これらの操作はすべて、1つのコマンドで実行されます。他の方法を使用した場合に必要となる多数の手動のステップが、このコマンドに置き換えられています。すべてのコマンドとその結果は、監査ログに記録されます。すべてのワークフローは、任意の環境に固有の要件をサポートするためにカスタマイズできます。

フリート・パッチ適用およびプロビジョニングの主な利点は、次のとおりです。

  • 標準化を有効にして施行します
  • プロビジョニング、パッチ適用およびアップグレードが簡略化されます
  • メンテナンスの影響およびリスクが最小限に抑えられます
  • 自動化が進み、タッチ・ポイントが減少します
  • 大規模なデプロイメントがサポートされます

関連項目:

Oracle Clusterware管理およびデプロイメント・ガイドのフリート・パッチ適用およびプロビジョニングとメンテナンス

Oracleフリート・パッチ適用およびプロビジョニング(FPP)の紹介と技術的概要

親トピック: 可用性を最大化するための機能

アプリケーションの継続的なサービスの有効化

データベース層の計画的メンテナンス、計画外停止および負荷の不均衡がユーザーから認識されない場合に、アプリケーションの継続的なサービスが実現します。

アプリケーションのベスト・プラクティス、簡単な構成変更、およびMAAベスト・プラクティスを使用してデプロイされるOracle Databaseの組合せによって、アプリケーションを継続的に使用できるようになります。

アプリケーションの継続的なサービスの詳細は、次の各トピックを参照してください。

  • 継続的なアプリケーション・サービス
    Oracleでは、計画されたイベント、計画外停止およびロードの不均衡時に、アプリケーションを使用可能な状態にしておくために選択できる一連の機能を提供しています。
  • エディションベースの再定義
    計画的なアプリケーション変更には、データ、スキーマおよびプログラムの変更が含まれる場合があります。これらの変更は、主にパフォーマンス、管理性、および機能性を向上させる目的で行われます。例として、アプリケーションのアップグレードがあります。

親トピック: 可用性を最大化するための機能

継続的なアプリケーション・サービス

Oracleでは、計画されたイベント、計画外停止およびロードの不均衡時に、アプリケーションを使用可能な状態にしておくために選択できる一連の機能を提供しています。

これらの機能は、サービスの中断からアプリケーションを保護する保険のポリシーと考えることができます。最善の機能は、アプリケーションに対して完全に透過的で、アプリケーション開発者がインフラストラクチャではなく機能の構築に集中できる機能であり、将来アプリケーションが変更された場合にアプリケーションを継続的に保護する機能です。

  • 計画メンテナンスのためのセッションの排出とリバランス

    計画メンテナンスが開始されると、インスタンス、PDBまたはデータベースから排出する必要のあるセッションは、排出対象としてマークされます。アイドル・セッションは徐々に解放されます。アクティブ・セッションは、そのセッションで実行されている作業が完了すると排出されます。セッションの排出は、高速アプリケーション通知(FAN)用に構成されたOracleの接続プールおよび中間層で幅広く使用されています。Oracle Database 18c以降では、PDBおよびインスタンスが停止または再配置された場合に、データベース自体がセッションを排出します。排出は常に、計画メンテナンスをユーザーが認識しないようにするための最適なソリューションです。割り当てられた時間内に作業が排出されない場合のフェイルオーバー・ソリューション(アプリケーション・コンティニュイティなど)は、フォールバックです

  • 透過的アプリケーション・フェイルオーバー

    透過的アプリケーション・フェイルオーバー(TAF)は、Oracle8iまで遡る機能です。インスタンス障害の後に、TAFは新しいセッションを作成し、障害が発生する前の時点に戻して問合せをリプレイできます。Oracle Database 12cリリース2以降では、TAFは問合せをリプレイする前に初期セッション・ステートをリストアできます。

  • アプリケーション・コンティニュイティ

    Javaベースのthinアプリケーションの場合はOracle Database 12cリリース1以降、およびOCIやODP.NETベースのアプリケーションの場合はOracle Database 12cリリース2 (12.2.0.1)以降では、アプリケーション・コンティニュイティ(AC)によって、ユーザーが停止を認識しないようにされます。アプリケーション・コンティニュイティは、セッション状態およびトランザクション状態を含む既知のポイントからセッションをリカバリすることによって、セッションを再作成します。アプリケーション・コンティニュイティは、処理中のすべての作業を再作成します。フェイルオーバーが発生した場合、アプリケーションは実行時間がわずかに遅延しますがそのまま続行されます。アプリケーション・コンティニュイティの標準モードは、OLTPスタイルのプールされたアプリケーション用です。

  • 透過的アプリケーション・コンティニュイティ

    Oracle Database 18c以降では、透過的アプリケーション・コンティニュイティ(TAC)で、リカバリ可能な停止の後にデータベース・セッションがリカバリできるように、透過的にセッションおよびトランザクションの状態を追跡および記録します。アプリケーションの知識やアプリケーション・コードの変更を必要とせずにこれが実行され、透過的アプリケーション・コンティニュイティがアプリケーションで有効になります。アプリケーションの透過性とフェイルオーバーは、アプリケーションがユーザー・コールを発行するときのセッション状態の使用状況を取得して分類する状態追跡情報を使用することによって実現されます。

関連項目:

MAAホワイト・ペーパー Oracle Databaseを使用するアプリケーションのためのMAA

『Oracle Real Application Clusters管理およびデプロイメント・ガイド』のアプリケーション・コンティニュイティの確保を参照してください

親トピック: アプリケーションの継続的なサービスの有効化

エディションベースの再定義

計画的なアプリケーション変更には、データ、スキーマおよびプログラムの変更が含まれる場合があります。これらの変更は、主にパフォーマンス、管理性、および機能性を向上させる目的で行われます。例として、アプリケーションのアップグレードがあります。

エディションベースの再定義(EBR)を使用すると、アプリケーションの使用中にそのデータベース・コンポーネントをアップグレードでき、停止時間を最小化あるいは排除することができます。アプリケーションを使用中にアップグレードするには、アプリケーションのデータベース・コンポーネントを構成するデータベース・オブジェクトをコピーし、コピーしたオブジェクトを個別に再定義する必要があります。アプリケーションのユーザーは、この変更による影響を受けず、変更されていないアプリケーションを引き続き実行できます。変更が正しいことを確認できたら、アップグレードしたアプリケーションをすべてのユーザーが使用できるようにします。

関連項目:

Oracle Database開発ガイドのエディションベースの再定義の使用

親トピック: アプリケーションの継続的なサービスの有効化

その他の高可用性機能について

前述の高可用性のためのOracle Database機能に加えて、次のリソースにも注目してください。

親トピック: 可用性を最大化するための機能