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

この章では、MAAソリューションで使用されるOracle Databaseの機能について説明します。

• Oracle Data Guard

• Oracle GoldenGate

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

• Recovery Manager

• Oracle Secure Backup

• Oracle Restart

• Oracle Real Application ClustersおよびOracle Clusterware

• Oracle RAC One Node

• Oracle自動ストレージ管理

• 高速リカバリ領域

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

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

• 状態オブジェクトの隔離

• Oracleセキュリティ機能

• Oracle Flashbackテクノロジ

• Oracle Data Pumpとデータ転送

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

• クライアントとアプリケーションのフェイルオーバー

• Oracle Multitenant

• Oracle Site Guard

• Zero Data Loss Recovery Appliance。

この章の内容は次のとおりです。

• Oracle Data Guard
  
• Oracle GoldenGate
  Oracle GoldenGateはデータ分散およびデータ統合のためのOracleの戦略的ロジカル・レプリケーション・ソリューションです。
• ベスト・プラクティス: Oracle Active Data GuardおよびOracle GoldenGate
  
• Recovery Manager
  
• Oracle Secure Backup
  Oracle Secure Backupは、UNIX、Linux、WindowsおよびNetwork Attached Storage(NAS)の分散環境でディスクとテープ・ターゲットをサポートし、異機種間データ保護を提供する、集中型のバックアップ管理ソリューションです。
• Oracle Real Application ClustersおよびOracle Clusterware
  
• Oracle RAC One Node
  
• Oracle Automatic Storage Management。
  
• 高速リカバリ領域
  
• 破損の予防、検出および修復
  
• データ・リカバリ・アドバイザ
  
• State Object Quarantine
  状態オブジェクトの隔離により、無効なオブジェクトが存在する場合でも、データベース・インスタンスは継続して機能できます。
• Oracleセキュリティ機能
  
• Oracle Flashbackテクノロジ
  
• Oracle Data Pumpとデータ転送
  
• データベース以外のファイルに対するOracleレプリケーション・テクノロジ
  
• クライアントとアプリケーションのフェイルオーバー
  
• Oracle Multitenant
  Oracle Multitenantは、Oracle Database 12c以降の最適なデータベース統合方法です。マルチテナント・アーキテクチャでは、これまでの統合方法に付きものであったトレードオフはなくし、それぞれの一番よい特性が結合されています。
• Oracle Sharding
  Oracle Shardingはカスタム設計されたOLTPアプリケーションに対する拡張性および可用性の機能で、シャード・データベースで実行されるように明示的に設計されています。
• Oracle Restart
  
• Oracle Site Guard
  
• Zero Data Loss Recovery Appliance。
  

関連項目:

• 『Oracle Database概要』の高可用性の概要

• 『Oracle Database新機能ガイド』の新しい高可用性機能の一覧

3.1 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転送、最高のリカバリ時間の目標のための高速適用パフォーマンス。Oracle Database 12cリリース2では、マルチインスタンス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 12cは次の追加機能により大幅に管理容易性が向上しています。どの時点でも、構成によるリカバリ・ポイントの目標およびリカバリ時間の目標のSLAのサポートを自動的に監視するための、包括的な構成のヘルス・チェック、再開可能スイッチオーバー操作、ストリームライン・ロール・トランジション、カスケード・スタンバイ構成のサポート、転送および適用ラグに対するユーザー構成可能なしきい値。

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

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

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

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

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

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

• Active Data Guard環境のスタンバイ・データベースで、Oracle Databaseインメモリー列ストアがサポートされるようになりました(Oracle 12cリリース2の新機能)。

• 新しいRMANコマンドRECOVER DATABASE NOLOGGINGで修復できるようNOLOGGING操作からの情報をトラッキングしてData Guard構成でのデータ・ウェアハウスのパフォーマンスと可用性をさらに改善します(Oracle 12cリリース2の新機能)。

• 新しいパラメータDATA_GUARD_SYNC_LATENCYを使用して、複数のSYNCトランスポート宛先がプライマリ・データベースに与える影響を改善します。このパラメータは、少なくとも1つの同期スタンバイがREDOの受信を確認した後、後続の宛先を切断するまで、プライマリ・データベースが待機する必要のある最大時間(秒単位)を定義します(Oracle 12cリリース2の新機能)。

• Data Guard Brokerは、代替の宛先の管理を拡張するのみでなく、プライマリとは異なるEndianessの宛先をサポートすることで管理性を改善します(Oracle 12cリリース2の新機能)。

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

  • マルチインスタンス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 Active Data Guard
  
• 従来のソリューションより優れているData Guardの利点
  
• Data Guardおよび計画メンテナンス
  

3.1.1 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 Oracle Active 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の利点

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 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 Active Data Guard 12cの新しい機能の高可用性アップグレードにより提供される追加の自動化を使用して、新しいOracle Databaseパッチ・セットおよびデータベース・リリースへのアップグレードの計画停止時間を短縮することにより、高可用性を向上。

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

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

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

関連項目:

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

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

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

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

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

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

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

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

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

• Data Guardのローリング・アップグレード機能による停止時間の短縮

• Oracle Database 12c リリース2の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を採用する方が正しいとする、技術上およびビジネス上の理由があります。

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

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

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

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

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

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

この章の内容は次のとおりです。

• Data Guard REDO適用およびStandby-First Patchの適用
  
• Data Guard一時ロジカル・ローリング・アップグレード
  
• Oracle Active Data Guardを使用したローリング・アップグレード
  

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

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スイッチオーバーが使用され、本番がスタンバイ(新しい環境)に転送されます。

関連項目:

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

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

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

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

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

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

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

Oracle Database 12cでは、Oracle Active Data Guardを使用したローリング・アップグレードが導入され、前述の手動一時ロジカル・ローリング・アップグレードで表される方法よりも、より簡単で、自動化された、容易に繰返し可能な、計画停止時間を短縮するための方法が提供されます。Oracle Active Data Guardを使用したローリング・アップグレードでは、手動プロシージャで必要な42以上の手順が、いくつかの使いやすいDBMS_ROLLING PL/SQLパッケージに変換されます。DBMS_ROLLING PL/SQLパッケージを使用して実行するローリング・アップグレードが、マルチテナント・コンテナ・データベース(CDB)でサポートされます。

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リリースにある場合、Data Guardスタンバイ・データベースを使用します。

関連項目:

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

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

3.2 Oracle GoldenGate

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

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

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

この章の内容は次のとおりです。

• Oracle GoldenGate 12c
  
• Oracle GoldenGateおよび最大可用性アーキテクチャ
  Oracle GoldenGate論理レプリケーションにより、Oracle GoldenGate構成のすべてのデータベース(ソースおよびターゲット・データベースの両方)を読取り/書込みで開くことができます。
• Oracle GoldenGate with Oracle Real Application Clusters
  Oracle Real Application Clusters (RAC)を使用している場合、データベース・インスタンス障害の発生時や適用可能なメンテナンス操作中にOracle RACノード間をシームレスに移動するようにOracle GoldenGateを構成できます。

3.2.1 Oracle GoldenGate 12c

Oracle GoldenGate 12cリリース2はレプリケーション機能とOracle Databaseとの統合が大幅に強化された重要な新しい機能を提供します。新しい機能は次のとおりです。

• エンドツーエンドのレプリケーション・ラグでエンドツーエンドのレプリケーション・ラグ・ビューが示されるため、継続的に更新する必要のある表を手動で実装する必要はありません。このレプリケーション構成を簡素化し、次のような追加の機能を提供する新しいコマンドが用意されています。

  • ソースからターゲットへの単方向ラグ

  • 受信と送信両方のラグを提供するアクティブ-アクティブ・レプリケーション設定時の双方向ラグ

  • エンドツーエンドのラグ情報を表示するGG_LAGデータベース・ビュー

• ポンプによる自動リモート証跡ファイルのリカバリは、ターゲット・システムが前の時点に復元されたときに自動的に処理されます。この機能では、ソースの証跡データが使用可能な場合に不足しているターゲット証跡データを自動的に再生成し、変更データを適用するときに重複トランザクションを適切にスキップして、ターゲット証跡ファイルが誤って削除または破損されるほとんどのケースも処理します。

• GoldenGateプロセスがXAGENABLEによりOracle Grid Infrastructureエージェント(XAG)で管理されている場合は、引き続きGGSCIを使用してマネージャを開始および停止できます。

• Extractがダウンストリーム・デプロイメントで構成されていて、このデプロイメントではダウンストリーム・データベースでマイニングされるソース・データベースからREDOが出荷されている場合、ソース・データベースを使用せずに、アクティブ・スタンバイ・データベースから必要なデータをフェッチできます。ExtractでREDOデータから更新操作を再構築できない場合、またはFETCHCOLS句がTABLEパラメータの一部として指定されている場合、フェッチが実行されます。

• Extractの新しいパラメータTRANLOGOPTIONS HANDLEDLFAILOVERは、Oracle Data Guardスタンバイに適用されているREDOデータからの抽出のみ許可します。統合されたExtractが接続されているOracle GoldenGateソース・データベースが、データ損失の可能性のある(ASYNC REDOトランスポートを使用するData Guard最大パフォーマンス・モード)アクティブ・スタンバイ・データベースで保護されている場合、Extractがスタンバイ・データベースに適用されていないREDOデータを抽出しないようにすることが重要です。この操作を実行すると、Oracle GoldenGateターゲット・データベースにソース・データベースにはないデータが含まれるため、データ損失フェイルオーバーが行われた場合に論理データの不一致が生じます。

関連項目:

レプリケーション・ラグのモニタリングの詳細は、『Oracle GoldenGateの管理for Windows and UNIX』を参照してください。

XAGENABLEの詳細は、『Oracle Fusion Middleware Oracle GoldenGateリファレンスfor Windows and UNIX』を参照してください。

FETCHUSERIDおよびFETCHUSEDIDALIASの詳細は、『Oracle Fusion Middleware Oracle GoldenGateリファレンスfor Windows and UNIX』を参照してください。

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

3.2.2 Oracle GoldenGateおよび最大可用性アーキテクチャ

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

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

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

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

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

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

関連項目:

Oracle GoldenGateのドキュメント

3.2.3 Oracle Real Application ClustersでのOracle GoldenGate

Oracle Real Application Clusters (RAC)を使用している場合、データベース・インスタンス障害の発生時や適用可能なメンテナンス操作中にOracle RACノード間をシームレスに移動するようにOracle GoldenGateを構成できます。

この機能はOracle GoldenGateに高可用性を提供し、Oracle GoldenGateが現在実行されているノードに影響を与えずに、クラスタ内の1つ以上のノードでOracle GoldenGateソフトウェアにパッチを適用したり、アップグレードできます。その後、事前に決定した時間で、Oracle GoldenGateをアップグレードするいずれかのノードに切り替えることができます。構成情報はOracle RACクラスタで共有されるため、Oracle GoldenGateを再構成することなく切替えが実行されます。

関連項目:

Oracle MAAホワイト・ペーパー『Oracle GoldenGate Oracle Real Application Clusters構成の使用』(http://www.oracle.com/goto/maa)

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

Oracle Active Data GuardおよびOracle GoldenGateはそれぞれOracle Databaseの同期化されたコピーを保持できますが、要件に応じて、1つのテクノロジまたは別のテクノロジ、あるいは同時に両方を使用できる高可用性アーキテクチャになる、ユニークな特徴があります。Oracle Database 12cに関連するユースケースに対するMAAベスト・プラクティス・ガイドラインの例は次のとおりです。

この章の内容は次のとおりです。

• Oracle Active Data Guardを使用する場合
  
• Oracle GoldenGateを使用する場合
  
• Oracle Active Data GuardおよびOracle GoldenGateを一緒に使用する場合
  

3.3.1 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

3.3.2 Oracle GoldenGateを使用する場合

Oracle Active Data Guardで対処されない高度なレプリケーション要件が重要視される場合、Oracle GoldenGateを使用します。

• プライマリ・データベースと同期しながら、レプリカ・データベースを読取り/書込みでオープンする必要がある要件

• マルチマスターおよび双方向レプリケーション、サブセットのレプリケーション、多対1レプリケーションおよびデータ統合などのデータ・レプリケーション要件。

• エンディアン形式のプラットフォーム間またはデータベース全体のメジャー・バージョン間で、データ・レプリケーションが必要な場合。

• ゼロまたはゼロに近い停止時間が必要なメンテナンスまたは移行。Oracle GoldenGateを使用して、停止時間なしで、Application 1.0からApplication 2.0へなど、アプリケーションのバージョン間で移行できます。

• 高速フォールバックの目的で、新しいバージョンから古いバージョンにレプリケートする場合のデータベースのローリング・アップグレードは、うまくいきません。

• 双方向レプリケーションを使用して、停止時間ゼロを認識させて、ユーザーを新しいシステムへ徐々に移動する場合の、停止時間ゼロの計画メンテナンス。双方向レプリケーションでは異種のデータベースで発生する可能性のある更新の競合を回避または解決する必要があります。

3.3.3 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つのデータベースを同期させるために使用されます。ユーザー・ワークロードは、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への影響が回避されます。

関連項目:

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

3.4 Recovery Manager

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

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

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

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

• Oracle Shardingのサポート - すべての独立データベース(シャード)に対するRMANのサポート(Oracle Database 12cリリース2の新機能)

• 疎データベースに対する拡張機能 - バックアップとリストアをSPARSEバックアップ設定またはイメージ・コピーで操作可能(Oracle Database 12cリリース2の新機能)

• NONLOGGEDのネットワーク・スタンバイ・データベース修復操作の終了 - スタンバイでの検証と修復用の新しい構文 - VALIDATE/RECOVER .. NONLOGGED BLOCK; (Oracle Database 12cリリース2の新機能)

• RMAN DUPLICATE機能の拡張により、プライマリおよびバックアップからのFar Syncの作成をサポート(Oracle Database 12cリリース2の新機能)

• 暗号化バックアップを使用したRMAN DUPLICATE - 新しいSETコマンドを使用した暗号化バックアップに基づくRMAN拡張サポート非自動ログイン・ウォレット - 中断なしのクローニングが可能(Oracle Database 12cリリース2の新機能)

• ネットワークでのクロス・プラットフォームのバックアップおよびリストアのサポート(Oracle Database 12cリリース2の新機能)。

• RESTORE操作によりデータ・ファイルをデータベース間でネットワークを介して直接コピーできる、ネットワーク対応のリストア操作

• RECOVER TABLEコマンドによる表リストアの簡略化

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

• 個々のPDBのバックアップおよびリカバリを含む、クロス・プラットフォームOracle Multitenantのサポート(Oracle Database 12cリリース2の新機能)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

関連項目:

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

3.5 Oracle Secure Backup

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

3.6 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 Real Application ClustersおよびOracle Clusterware使用の利点
  
• 従来のコールド・クラスタ・ソリューションより優れているOracle RACの利点
  

関連項目:

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

3.6.1 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 Clusterware管理およびデプロイメント・ガイド

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

Oracle RACとOracle Clusterwareの併用には、「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数、メモリー量またはその両方が十分備わっているサーバーにのみデータベース・リソースを配置します。

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

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

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

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

3.6.3 従来のコールド・クラスタ・ソリューションより優れている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(単一クライアント・アクセス名)サポート。この名前は、クラスタのノードを追加または削除しても、クラスタの存続期間中は変更されません。

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

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

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

注意:

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

3.7 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データベースに停止時間または中断なしに移行することができます。

3.8 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つのサイトに関連付けてパフォーマンスを改善します。

関連項目:

ACFSの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

3.9 高速リカバリ領域

高速リカバリ領域は、Oracle Database内のすべてのリカバリ関連ファイルおよびアクティビティを対象とした一元的な格納場所です。この機能を有効にすると、すべてのRMANバックアップ、アーカイブREDOログ・ファイル、制御ファイルの自動バックアップ、フラッシュバック・ログおよびデータ・ファイルのコピーが自動的に特定のファイルシステムまたはOracle ASMディスク・グループに書き込まれ、このディスク領域はRMANとデータベース・サーバーによって管理されます。

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

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

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

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

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

関連項目:

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

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

データ・ブロックの破損は、非常に破壊的で修復が困難な場合があります。破損が発生すると、アプリケーションやデータベースに重大な停止時間やデータ損失が生じる原因になることがあります。悪くすると数時間、数日、場合によっては数週にわたり破損が気づかれず、検出後に、さらに長いアプリケーション停止時間を招くことがあります。あいにく、破損のソースおよび原因はメモリー、ハードウェア、ファームウェア、記憶域、オペレーティング・システム、ソフトウェアまたはユーザー・エラーのどこにでも存在する可能性があるので、データベース内のデータ破損を包括的に防止、検出および修復する手段は存在しません。さらに悪いことには、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	バックアップおよびリストア操作中の物理的ブロック・チェック	ブロック内論理チェック
手動チェック	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により、インメモリーのブロック内チェックを検証
ランタイム・チェック	ASM	書込み中に、正常なASMエクステント・ブロックのペアが存在する場合、読取りおよび書込みの暗黙的なデータ破損検出と自動修復を実行
ランタイム・チェック	DIX + T10 DIF	オペレーティング・システムからHBAコントローラ、ディスク(ファームウェア)に至るまでのチェックサム検証。認定済のLinux、HBAおよびディスクに対する読取りと書込みを検証。
ランタイム・チェック	ハードウェアおよびストレージ	Oracle統合が行われていないため、限定的なチェック。チェックサムが最も一般的。	Oracle統合が行われていないため、限定的なチェック。チェックサムが最も一般的
ランタイム・チェック	Exadata	書込みに対する包括的なHARDチェック	書込みに対するHARDチェック
バックグラウンド・チェック	Exadata	ハード・ディスクの自動修正および修復。不良セクターの検出および修正。

関連項目:

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

データ破損の防止、検出および修復の詳細は、『Oracle Database高可用性ベスト・プラクティス』を参照してください。

My Oracle Supportノート1302539.1

停止時間の原因

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

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

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

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

• 障害診断

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

• 障害の影響の評価

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

• 修復の生成

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

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

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

• 修復の自動化

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

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

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

• 破損の早期検出

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

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

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

注意:

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

関連項目:

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

3.12 状態オブジェクトの隔離

状態オブジェクトの隔離により、無効なオブジェクトが存在する場合でも、データベース・インスタンスは継続して機能できます。

状態オブジェクトはSGAのプロセス、セッションおよびトランザクションなどのデータベース・リソースのステータスに関するメタデータが含まれるセッションレベル構造です。プロセスまたはセッションが終了した場合、PMONは状態オブジェクトを使用して保持リソースをオペレーティング・システムに解放します。

PMONは場合によって、破損してリカバリ不可能な状態オブジェクトを隔離できるため、データベース・インスタンスがただちに強制終了されることはありません。PMONは隔離されたオブジェクトで、クリーンアップの実行をできるかぎり続行します。V$QUARANTINEビューにはオブジェクトのタイプ、消費されたメモリー量、隔離の原因であるOracleエラーなどに関するメタデータが含まれます。

これにより、他のデータベースに影響しないようにメモリー内でリソースを分離または隔離してCDBまたは非CDBデータベース全体とアプリケーションの可用性を確保し、インスタンスまたはデータベースの中断を防ぐことができます。影響は、データベースおよびアプリケーション全体ではなく、1つのセッションに制限できます。ライブラリ・キャッシュまたは行キャッシュのメモリー・オブジェクトなどSGA内の破損したメモリー構造体にアクセスすると、ORA-600エラーまたはORA-7445が発生し、データベースやインスタンスがクラッシュする可能性があります。状態オブジェクト隔離により、セッションはエラーとなり、破損したリソースは隔離されて、重大なバックグラウンド・プロセスを含む他のプロセスは影響を受けません。

3.13 Oracleセキュリティ機能

人的エラーに対する最大の保護とは、その発生を防ぐことです。人的エラーの最高の保護方法は、ユーザー・アクセスを、ビジネス機能の実行に必要なデータおよびサービスのみに限定することです。Oracle Databaseでは、データベース・ユーザーの認証によりアプリケーション・データへのアクセスを制御し、管理者が任務の遂行に必要な権限のみをユーザーに与えることができる多種多様なセキュリティ・ツールを提供しています。

さらに、Oracle Databaseのセキュリティ・モデルでは、Oracle Virtual Private Databaseを使用して行レベルにデータ・アクセスを制限し、アクセスする必要がないデータをデータベース・ユーザーから分離することが可能です。

Oracle Databaseには次のようなセキュリティ上の利点があります。

• ネットワーク、データベースおよびアプリケーションを使用したエンティティのアイデンティティを検証するための認証制御。データベース間のネットワーク・セッション(REDO転送セッションなど)も認証されます。

• データベース・ユーザー・アイデンティティおよびロールにリンクされているアクセスおよびアクションを制限するための認証制御。

• オブジェクトへのアクセスを制御し、エンティティの要求がオブジェクトに対するアクセスまたは変更のいずれであろうとオブジェクトを保護。

• 特定のデータベース・アクティビティに関するデータの監視および収集、不審なアクティビティの調査、ユーザー(またはその他)の不適切なアクティビティの防止、および認証あるいはアクセス制御の実装による問題の検出を行う監査制御。

• プロファイルを使用したセキュリティ・ポリシー管理。

• データベースおよびバックアップ内に存在する、またはデータベース間で転送されるデータの暗号化。

• SYSDBA権限が付与されないクラスのユーザーに、Data Guard構成の管理を委任することができます。

• 透過的データ暗号化で保存データを保護すると、TDEへのオンライン変換を簡単に実行できます。

関連項目:

• 『Oracle Databaseセキュリティ・ガイド』

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

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

フェーズ1: 通常はアプリケーションにより実行されるロジカル・エラーの検出

フェーズ2: フラッシュバック問合せ、フラッシュバック・バージョン問合せ、フラッシュバック・トランザクション問合せおよびDBMS_FLASHBACKパッケージなどの機能を使用した調査。

フェーズ3: エラー・リカバリ。

この章の内容は次のとおりです。

• Oracle Flashback Query
  
• Oracle Flashback Version Query
  
• Oracle Flashback Transaction
  
• Oracle Flashback Transaction Query
  
• Oracle Flashback Table
  
• Oracle Flashback Drop
  
• リストア・ポイント
  
• Flashback Pluggable Database
  前のSCNまでPDBを巻き戻すことができます。SQLまたはRecovery Managerから使用可能なFLASHBACK PLUGGABLE DATABASEコマンドは、非CDBでのFLASHBACK DATABASEに類似しています。
• フラッシュバック・ログまたはフィジカル・スタンバイ・データベースを使用したブロック・メディア・リカバリ
  
• フラッシュバック・データ・アーカイブ
  

3.14.1 Oracle Flashback Query

Oracle Flashback Query (フラッシュバック問合せ)では、自動UNDO管理システムを利用してトランザクションのメタデータおよび履歴データを取得することで、過去に存在したデータを表示できます。UNDOデータは永続的で、データベースの異常や停止の際にも失われません。フラッシュバック問合せの独自の機能により、表の以前のバージョンの問合せが可能になり、誤った操作からリカバリするための強力なメカニズムも提供されます。

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

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

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

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

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

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

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

関連項目:

Oracle Database開発ガイド

3.14.2 Oracle Flashback Version Query

Oracle Flashback Version QueryはSQLの拡張機能で、特定の表から特定の期間に存在した行のバージョンを取得するために使用できます。Oracle Flashback Version Queryでは、指定期間に存在した行のバージョンごとに1行が返されます。どの表についても、COMMIT文が実行されるたびに行のバージョンが新たに作成されます。

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

関連項目:

Oracle Database開発ガイド

3.14.3 Oracle Flashback Transaction

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

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

• UNDO SQLの適用

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

関連項目:

• Oracle Database開発ガイド

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

3.14.4 Oracle Flashback Transaction Query

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

関連項目:

Oracle Database開発ガイド

3.14.5 Oracle Flashback Table

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

関連項目:

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

3.14.6 Oracle Flashback Drop

オブジェクトの誤った削除は、データベース・ユーザーにも、データベース管理者にも問題です。削除された表、索引、制約またはトリガーをリカバリする簡単な方法はありませんが、Oracle Flashback Dropでは、オブジェクトを削除する際の安全策が提供されます。表を削除すると、その表は自動的にごみ箱に入ります。ごみ箱は、すべての削除済オブジェクトが入っている仮想コンテナです。削除した表のデータは、引き続き問い合せることができます。

関連項目:

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

3.14.7 リストア・ポイント

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

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

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

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

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

この章の内容は次のとおりです。

• Oracle Flashback Database
  

関連項目:

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

3.14.7.1 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 Databaseバックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』

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

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

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

Oracle Database 12cリリース2 (12.2)よりも前のリリースでは、ルートへの接続時のみ、リストア・ポイント(SCNの別名)を作成できました。現在は、CREATE RESTORE POINT ... FOR PLUGGABLE DATABASEを使用してPDBリストア・ポイント(指定されたPDB内のみで使用可能)を作成できます。CDBリストア・ポイントと同様に、PDBリストア・ポイントも通常または保証付きのいずれかです。保証付きリストア・ポイントは、制御ファイルからエージ・アウトされず、明示的に削除する必要があります。ルートに接続しており、FOR PLUGGABLE DATABASE句を指定しない場合は、すべてのPDBで使用可能なCDBリストア・ポイントを作成します。

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

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

自動的な破損ブロック修復の試行後、ブロック・メディア・リカバリ機能で、フラッシュバック・ログからデータ・ブロックの最新コピーを必要に応じて取得して、リカバリ時間を短縮できます。自動ブロック修復を使用すると、検出されたプライマリ・データベースの破損ブロックをフィジカル・スタンバイ・データベースの良好なブロックを使用してただちに自動修復できます。

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

関連項目:

ブロック・メディア修復の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

RMAN RECOVER BLOCKコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

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

フラッシュバック・データ・アーカイブは表領域に格納され、レコードの存続期間中に表のすべてのレコードに対して行われたトランザクションの変更が含まれます。アーカイブされたデータは、UNDO表領域で提供される保存期間よりも長く保存でき、分析および修復のために非常に古いデータを取得するために使用されます。

関連項目:

Oracle Database開発ガイド

3.15 Oracle Data Pumpとデータ転送

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

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

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

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

この計画メンテナンス用テクノロジの使用方法の詳細は、「システムおよびソフトウェア・メンテナンス用Oracle高可用性ソリューション」を参照してください。

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

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

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

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

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

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

テクノロジ	推奨される使用方法	コメント
Oracle Database File System,	データベースとデータベース以外のシステム間で強化された同期を提供する場合に推奨	データベースの変更とファイル・システムの変更間で完全に一貫性を保持するためにデータベースとの統合が可能 データベースに保存され、Oracle Active Data Guardと使用して障害時リカバリと読取り専用アクセスの両方を提供できるすべてのデータ 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 Solaris ZFS Storage Applianceレプリケーション	データベース以外のファイルに対する障害時リカバリ保護、特にOracle Fusion Middlewareのデータベース外に保存されたクリティカル・ファイルに推奨します。	Oracle Fusion Middlewareバイナリ構成を含む、データベース以外のすべてのオブジェクトのレプリケート ポイント・イン・タイム・リカバリの発生時にデータベースの変更とファイル・システムの変更間で時間整合性をほぼ提供可能

この章の内容は次のとおりです。

• Oracle Database File System,
  
• Oracle ASMクラスタ・ファイル・システム
  
• Oracle Solaris ZFS Storage Applianceレプリケーション
  

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

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

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

関連項目:

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

3.16.3 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を向上させるデータベースのクローンおよびスナップショットを迅速に作成する機能

3.17 クライアントとアプリケーションのフェイルオーバー

高可用性アーキテクチャでは、アプリケーション層が生き残っているインスタンスまたはデータベースに透過的にフェイルオーバーして必要なサービスを通知することが必要です。これにより、ノード障害、インスタンス障害、データ破損またはデータベース障害時に、アプリケーションが通常どおり使用可能であることが保証されるか、または影響を最小限に抑えることができます。透過的なクライアント・フェイルオーバーにより、アプリケーションは別の使用可能な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)

  透過アプリケーション・フェイルオーバーは、高可用性環境を対象としたランタイム・フェイルオーバーであり、アプリケーションからサービスへの接続のフェイルオーバーおよび再確立を意味します。これにより、クライアント・アプリケーションは接続障害の発生時にデータベースに自動的に再接続でき、実行中だった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では、それぞれ独自の特性を備えた複数のアドレス・リストを持つ接続記述子もサポートされます。接続時フェイルオーバーを使用すると、あるアドレスへの接続失敗時に、新しい接続試行を別のアドレスにフェイルオーバーすることができます。

この章の内容は次のとおりです。

• 接続のクライアント・フェイルオーバー処理
  
• トランザクション・フェイルオーバーおよび保護
  
• グローバル・データ・サービスを使用したOracle Database
  

関連項目:

データベースのトランザクション処理の方法の詳細は、『Oracle Database概要』を参照してください。

動的データベース・サービスの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

Oracle Database Global Data Services概念および管理ガイド

3.17.1 接続のクライアント・フェイルオーバー処理

高レベルで、MAA環境での自動クライアント・フェイルオーバーには、データベース・サービスの使用可能リソースへの再配置、障害が発生したことのクライアントへの通知、TCPタイムアウトからそれらの潜在的なブレーク、データベース・サービスがアクティブな使用可能リソースへのアプリケーション接続のリダイレクトが含まれます。特定のクライアントまたはアプリケーションの構成およびベスト・プラクティスについては、My Oracle Supportのノート1617163.1「クライアントおよびアプリケーションのフェイルオーバー検証マトリックス」を参照してください。

アプリケーション接続のフェイルオーバーの処理に使用される、この章の導入部で説明したコンポーネントは、MAA環境の構成により異なります。

表3-3 接続のクライアント・フェイルオーバー処理

MAA構成	サービスの再配置	アプリケーション通知	セッション・フェイルオーバーおよびリカバリ(1)
Data Guard使用の単一インスタンス	DB_ROLE_CHANGEシステム・イベントで記述されたトリガーを使用したData Guardフェイルオーバー後のサービスの開始 グローバル・データ・サービスの使用	アプリケーション・レイヤーを実行しているホストでのオペレーティング・システムの効率的なTCPタイムアウトの構成	OCIクライアントに対する透過的Oracleフェイルオーバー(TAF)の構成。TAFを使用しない場合、OCI、JDBC ThinまたはODP用にアプリケーションにトランザクション・ガードを含めることができます。
Oracle RAC DatabaseまたはOracle RAC One Node	Oracle Clusterwareにより管理されたサービスの使用	高速アプリケーション通知の構成	OCIクライアントに対する透過的Oracleフェイルオーバー(TAF)の構成。Thin JDBCクライアントのためのアプリケーション・コンティニュイティの構成。 これらを使用しない場合、OCI、JDBC ThinまたはODP用にアプリケーションにトランザクション・ガードを含めることができます。(TAFおよびACにはトランザクション・ガードが含まれます)
Data Guard使用のOracle RAC Database	各クラスタ内のサービス・フェイルオーバーのためのOracle Clusterwareにより管理されたサービスの使用 サイト間のサービス・フェイルオーバーのためのOracle Clusterwareにより管理されたロール・ベースのサービスの使用	高速アプリケーション通知の構成	OCIクライアントに対する透過的Oracleフェイルオーバー(TAF)の構成。JDBCシン・クライアントのためのアプリケーション・コンティニュイティの構成。 これらを使用しない場合、OCI、JDBC ThinまたはODP用にアプリケーションにトランザクション・ガードを含めることができます。(TAFおよびACにはトランザクション・ガードが含まれます)
レプリケート・データベース	グローバル・データ・サービスの使用	アプリケーション・レイヤーを実行しているホストでのオペレーティング・システムの効率的なTCPタイムアウトの構成	BASICのみを使用したOCIクライアントに対する透過的Oracleフェイルオーバー(TAF)の構成。

^脚注1 クライアントがJDBC、UCPまたはAGLである場合、アプリケーション・コンティニュイティは、レプリケートされたデータベースを除いて、これらすべての構成のオプションでもあります。

次の項では、サービスの再配置とアプリケーション通知の詳細を説明します。

この章の内容は次のとおりです。

• サービス
  
• 高速アプリケーション通知
  

関連項目:

特定のクライアントまたはアプリケーションの構成およびベスト・プラクティスについては、My Oracle Supportのノート1617163.1を参照してください

3.17.1.1 サービス

サービス名とは、クライアント接続に使用するサービスの論理表現です。クライアントは、リスナーに接続するときにサービスへの接続をリクエストします。データベース・インスタンスは、起動時にインスタンス自体をリスナーに登録し、1つ以上のサービスとして名前で指定できるようになります。リスナーとして知られているように、単一サービスはOracle RACまたはData Guard環境の1つまたは複数のデータベース・インスタンスを識別できます。各データベース・インスタンスは、1つ以上のサービスをリスナーに登録できます。

この章の内容は次のとおりです。

• 単一インスタンス・データベースおよびData Guard環境でのサービスの使用
  
• Oracle RAC Database環境でのサービスの使用
  
• Oracle RAC DatabaseおよびData Guard環境でのサービスの使用
  
• レプリケートされた環境またはOracle Active Data Guard環境でのサービスの使用
  

3.17.1.1.1 単一インスタンス・データベースおよびData Guard環境でのサービスの使用

アプリケーションはプライマリ特有のサービス名、つまり、プライマリ・データベースでのみアクティブなユーザー作成サービスを使用してデータベースに接続する必要があります。Data Guardのフェイルオーバーのイベントで、このサービスは現在プライマリ・ロールを保持しているいずれかのデータベースに移行されます。これはON_STARTUPシステム・イベントに基づき実行されるトリガーを作成することによりインストールされたOracle Clusterwareのない単一インスタンス環境で実行できます。このトリガーはV$DATABASEビューのDATABASE_ROLE値をチェックし、値がPRIMARYの場合、ユーザー作成サービスを開始します。

3.17.1.1.2 Oracle RAC Database環境でのサービスの使用

サービスを定義すると、リソース・プロファイルは自動的に作成されます。リソース・ファイルには、Oracle Clusterwareによるサービスの管理方法と、PREFERREDインスタンスが停止した場合にサービスがフェイルオーバーされるインスタンスが定義されています。また、リソース・プロファイルでは、インスタンスおよびデータベースに対するサービスの依存性も定義します。この依存性の情報によって、データベースが停止した場合に、インスタンスおよびサービスが自動的に正しい順序で停止されます。

管理者管理データベースに対してサービスを定義する場合は、SRVCTLに-preferredパラメータを使用して、そのサービスを通常サポートするインスタンスを定義します。このようなインスタンスを、優先インスタンスといいます。サービスの優先インスタンスが失敗した場合に備えて、-availableパラメータを指定してSRVCTLを使用し、サービスをサポートするその他のインスタンスを定義することもできます。このようなインスタンスを、使用可能インスタンスといいます。

優先インスタンスを指定する場合は、サービスが通常実行されるインスタンスの数を指定します。これは、サービスの最大カーディナリティです。Oracle Clusterwareは、サービスを構成したインスタンス数でサービスが実行されることを確認しようとします。その後は、インスタンス障害またはサービスの計画的な再配置のために、使用可能インスタンスでサービスが実行される場合があります。

インスタンスが失敗した場合、リストに複数のインスタンスがあると、Oracle Clusterwareによってサービスがどの使用可能インスタンスに再配置されるかは制御できません。ただし、計画済操作時は、サービスを現在提供していない、優先リストまたは使用可能リスト内のインスタンスにサービスを手動で転送できます。

3.17.1.1.3 Oracle RAC DatabaseおよびData Guard環境でのサービスの使用

ご使用のOracle RAC環境でData Guardを構成してある場合は、SRVCTLに-lパラメータを使用して、各サービスにロールを定義できます。サービスにロールを指定すると、Oracle Clusterwareは、データベース・ロールがそのサービスに指定したロールに一致した場合にのみ自動的にサービスを起動します。有効なロールは、PRIMARY、PHYSICAL_STANDBY、LOGICAL_STANDBYおよびSNAPSHOT_STANDBYで、1つのサービスに複数のロールを指定できます。

クラスタ内の複数のデータベースが同じサービス名を提供すると、Oracle RACは、該当するすべてのデータベースにわたってそのサービスへの接続を均等に分散します。これはData Guardのスタンバイ・データベースおよびアクティブ・データベースに役に立ちますが、サービスへのクライアント接続を特定のデータベースに割り当てる必要がある場合、サービス名はクラスタ内で一意である(他のデータベースによって提供されない)必要があります。

関連項目:

データベース・ロールの詳細は、『Oracle Data Guard概要および管理』を参照してください。

3.17.1.1.4 レプリケートされた環境またはOracle Active Data Guard環境でのサービスの使用

グローバル・データ・サービス・フレームワークはグローバル・サービス向けのソフトウェア・インフラストラクチャです。このフレームワークはデータベース・クラウドの構成、メンテナンスおよび監視を自動化および集中化し、グローバル・サービスのロード・バランシングおよびフェイルオーバーを可能にします。このフレームワークでは、これらの仮想化リソースを最小限の管理オーバーヘッドで管理し、追加のクライアント要求を処理するために迅速にクラウドを有効化します。

Global Data Servicesフレームワークは、次の既存のOracle Databaseのテクノロジを中心に構築されます。

• Oracle Active Data Guard

  読取り専用データベースの高いパフォーマンスのファームを可能にします。

• Data Guard Broker

  プライマリ・データベースと最大30のスタンバイ・データベースを含むData Guard構成の作成、管理および監視を可能にします。

• Oracle GoldenGate

  複数のデータベースの間でレプリケーションの更新を可能にします。

3.17.1.2 高速アプリケーション通知

FANを使用して、Oracle RAC、Data Guardおよびグローバル・データ・サービスに構築された連続した動的データベース・サービスは、アプリケーションおよび中間層サーバーに拡張されています。データベース・サービスの状態が変わると(起動、停止または再起動なしなど)、新しいステータスがFANイベントを介して、関係のあるサブスクライバにポストされます。Oracleドライバおよびアプリケーションは、これらのイベントを使用して、障害を非常にすばやく検出し、障害後の接続プールを均等に分散し、障害の発生したコンポーネントが修復されると接続プールを再度分散します。たとえば、インスタンスのサービスが起動されると、そのリソースに作業をルーティングするためにFANイベントが即時に使用されます。インスタンスまたはモードのサービスが失敗すると、リカバリするアプリケーションを中断するために、FANイベントが即時に使用されます。

データベース接続での高可用性の問題を解決するには、サービスの状態が変わったらすぐに、Oracle ClusterwareおよびData Guard BrokerでFANイベントをポストし、さらにサーバー側のコールアウトを実行します。FANイベント・ペイロードには、Oracle RAC上のサービスのステータスを説明する関連情報が含まれます。FANイベントを受信すると同時に、アプリケーションでは、障害が発生したインスタンスまたはノードと通信中のセッションを終了し、操作の再開を待つセッションに通知し、補助のリソースが使用可能になると、着信する作業を再編成できます。処理すべきセッションを識別するために、Oracle Databaseを使用するどのセッションにも、一意の接続署名があります。接続署名は、FANペイロードと一致します。

計画停止の場合、構成されたFANで接続プールを使用します。OCI、UCP、ICC、WebLogic Server Active Grid LinkまたはODP.Netです。接続プールでFANを使用するのに加え、Java Thinドライバでは、Oracle Database 12cリリース2より、ons.jarおよびsimpleFAN.jarファイルをCLASSPATHに配置し、推奨のTNSフォーマットを使用してFANを自動的に有効化できるようになりました。

FAN計画イベントの場合、リクエスト境界で作業を排出します。顧客のコードは新しい接続で再試行できるため、プールを使用しない場合でも、計画メンテナンスでの停止を回避できます。すぐにFANイベントが計画停止のために受信され、そのサービスまたはインスタンスのプールからアイドル接続が削除され、アクティブ(借りた)接続は、プールに返されるときに解放のマークが付けられます。これにより、ユーザーを妨げることなく、計画停止のために作業が効果的にドレインされます。Java Thinドライバの場合、FANの停止イベントの受信後にコードで接続ステータスがチェックされると、接続が閉じます。アプリケーションを中断せずに、計画メンテナンス操作を正常に実行する手順は、My Oracle Supportドキュメント1593712.1を参照してください。

FANは、ランタイム接続のロード・バランシング、Web親和性およびデータ依存型ルーティングについてのアドバイザをポストする場合にも使用されます。

Oracle Database 12cリリース2 (12.2)では、Javaコンテナ、フレームワークおよびアプリケーションは新しいAPIを使用して、高可用性ソリューションを構築するためのOracle Database RAC FANイベントをサブスクライブできます。これらはFANイベント(高可用性およびロード・バランシング・アドバイザリ)をJDBCドライバを介して受信でき、UCPは不要です。

この章の内容は次のとおりです。

• OracleクライアントへのFANの有効化
  
• FANを使用できないアプリケーションの考慮事項
  

関連項目:

動的データベース・サービスの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

FANの自動的な有効化の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

JDBCのサブスクリプションの詳細は、『Oracle Database JDBC開発者ガイド』を参照してください。

アプリケーションを中断しない計画メンテナンスの詳細は、My Oracle Supportのノート1593712.1を参照してください。

3.17.1.2.1 OracleクライアントへのFANの有効化

Oracle RACデータベースへの接続に使用される多くの一般的なクライアント・アプリケーション環境は、FANと統合されました。FANを使用する最も簡単な方法は、Oracle統合クライアントを使用することです。Oracle Database 12cリリース2より、クライアント・ドライバはFAN対応になり、FANはデフォルトで有効になっています。これには、JDBC ThinドライバとOracle Data Provider for .NET (ODP.NET)ドライバが含まれます。

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管理およびデプロイメント・ガイド』を参照してください。

Oracle RAC FAN APIに対するJDBCのサポートの詳細は、『Oracle Database JDBC開発者ガイド』を参照してください。

HAイベント通知の詳細は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。

3.17.1.2.2 FANを使用できないアプリケーションの考慮事項

アプリケーション・レイヤーを実行しているホストでオペレーティング・システムの効率的なTCPタイムアウトを構成します。OS TCPタイムアウトは、データベース・レイヤーがフェイルオーバーするのにかかる時間およびデータベース・サービスが開始するのにかかる時間に設定される必要があります。TCPタイムアウトを適切に構成する方法については、オペレーティング・システムのマニュアルを参照してください。

例外のイベントに適切に応答するように、アプリケーション内の再接続ロジックを構成します。たとえば、接続プールからのセッションが切断となる例外(ORA-3113エラーなど)を受信すると、アプリケーションはそのセッションへの再接続を自動的に試みます。再接続の試行は、データベース・レイヤーをフェイルオーバーするのにかかる時間継続し、アプリケーション・サービスをオンラインにするように構成する必要があります。

3.17.2 トランザクション・フェイルオーバーおよび保護

トランザクションのフェイルオーバーおよび保護テクノロジには、トランザクション・ガードとアプリケーション・コンティニュイティがあります。

この章の内容は次のとおりです。

• トランザクション・ガード
  
• アプリケーション・コンティニュイティ
  

3.17.2.1 トランザクション・ガード

トランザクション・ガードは、アプリケーションで、計画済および計画外の停止に続くトランザクションに、信頼できる既知の結果を提供する汎用ツールです。アプリケーションでは論理トランザクションIDという新しい概念を使用して、停止に続くデータベース・セッション内でオープンになっている最終トランザクションの結果が判断されます。トランザクション・ガードを使用しないと、アプリケーションが停止の後に操作を実行しようとして、トランザクションが重複してコミットされ論理破損が発生する可能性があります。

最後の送信がコミットされたか、近いうちにコミットされるか、または完了まで実行されていないかを識別できない場合、アプリケーションがリプレイを試みることにより、すでに永続化されている変更の再発行が試みられる可能性があるため、トランザクションの送信が重複し、他の形式の論理的破損が発生する可能性があります。

トランザクション・ガードを使用しないと、トランザクションが開始され、コミットが発行された場合、クライアントに返されるコミット・メッセージに継続性がありません。トランザクションがコミットされたかどうかはクライアントにはわかりません。トランザクションは、非トランザクション状態が不正確な場合、またはそのトランザクションがすでにコミットされている場合は、有効に再送信できません。保障されたコミットや完了情報がないと、再送信により、トランザクションが複数回適用され、不適切な状態になる可能性があります。

Oracle Database 12cリリース2より、トランザクション・ガードはXA最適化をサポートするようになりました。トランザクション・ガードは、ローカル・トランザクションと、コミット操作時にTMONEPHASEを使用するXAトランザクションをサポートします。アプリケーションがTMTWOPHASEを使用するXAトランザクションを発行すると、トランザクション・ガードはそのトランザクションのために自らを無効にします。その後、自動的に次のトランザクションに向けて、再度有効にします。これにより、トランザクション・ガードは次に示すXAトランザクションをサポートできます。

• 自動コミットを使用するローカル・トランザクション

• 明示的なコミットを使用するローカル・トランザクション

• TMONEPHASEフラグを使用してコミットするXAトランザクション

関連項目:

Oracle RACおよび動的データベース・サービスでのトランザクション・ガードの詳細は、『Oracle Database 2日でReal Application Clustersガイド』を参照してください。

アプリケーション開発者向けのSQL処理の詳細は、『Oracle Database開発ガイド』を参照してください。

トランザクション・ガードの使用の詳細は、『Oracle Database開発ガイド』を参照してください。

DBMS_APP_CONTパッケージの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

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

高可用性アーキテクチャでは、アプリケーション層が生き残っているインスタンスまたはデータベースに透過的にフェイルオーバーして必要なサービスを通知する機能が必要です。これにより、アプリケーションは通常、データベース・セッション、ノード、インスタンス、ネットワーク、データ破損、読取り/書込みタイムアウトを含む、回復可能などの障害が発生した場合も使用可能または最小限の影響しか受けません。アプリケーション・コンティニュイティは、Oracle RAC、Oracle RAC One、またはActive Data Guardをインスタンスまたはサイトのフェイルオーバー用に実行している高可用性環境でハードウェア、ソフトウェア、ネットワーク、ストレージのエラーとタイムアウトをマスキングします。アプリケーション・コンティニュイティでは、別の使用可能なOracle RACインスタンスで、または別のデータベースに対して(Data Guardロール遷移の場合など)、リクエストをリプレイすることで、リカバリ可能な停止をマスキングしようとします。

アプリケーション・コンティニュイティには次のものが含まれます。

• FAN: 障害の通知

• 接続クリーン・アップ

• 別のOracle RACインスタンスまたはデータベースに存在するデータベース・サービスの自動再接続および再試行

• 進行中のリクエストのリプレイ

データベース・セッションの停止のマスキングはアプリケーション開発にとって複雑なタスクのため、結果的にエラーおよびタイムアウトが頻繁にユーザーに公開されます。アプリケーション・コンティニュイティは、リカバリ可能な停止(計画外および計画)に続いてデータベース・セッションをリカバリすることで、ユーザーおよびアプリケーションから停止をマスキングしようとします。アプリケーション・コンティニュイティはこのリカバリをアプリケーション外で実行するため、停止がアプリケーションでは遅れた実行のように表れます。リカバリを成功させるには、アプリケーション・コンティニュイティによりクライアントに対してリストアされたデータやメッセージが、アプリケーションで表示され、決定が下された可能性のあるものと同じであることが必要です。

アプリケーション・コンティニュイティは、通常、基本となるソフトウェア、フォアグラウンド、ハードウェア、通信、ネットワークまたは記憶域の層に関連する、リカバリ可能な停止に対して起動されます。アプリケーション・コンティニュイティは計画外停止および計画停止の両方を処理するときのユーザーの操作性を向上させるために使用されます。

アプリケーション・コンティニュイティは、Java、OCIおよびODP.NET、管理対象外ドライバを使用するアプリケーションで使用できます。

• XA以外のデータ・ソースとXAデータ・ソース用のOracle WebLogic Server

• スタンドアロンとして、またはIBM WebSphereやApache Tomcatを含むサード・パーティ・アプリケーション・サーバーのデータ・ソースとして使用されるOracle Universal Connection Pool

• JDBC PooledConnectionインタフェースを使用するJDBCアプリケーション

• Oracle JDBC-Thinリプレイ・ドライバ

• XA以外のデータ・ソース用Oracle Tuxedo

• Oracle OCIセッション・プール

• ODP.NET管理対象外ドライバ

• Oracle SQL*Plus

Oracle Database 12cリリース2 (12.2)より、アプリケーション・コンティニュイティはOracle XAデータ・ソースおよびFAILOVER_RESTOREをサポートし、接続に事前に影響するアプリケーションで、フェイルオーバー開始前に自動で初期状態にリストアできるようになりました。

アプリケーション・コンティニュイティは、進行中の作業の不完全な要求のリカバリを可能にし、システム障害、通信エラー、ハードウェア障害およびストレージの停止をユーザーからマスキングして、ユーザー・エクスペリエンスの向上、アプリケーションの可用性の強化、および開発者の生産性の向上を実現します。

関連項目:

トランザクションの詳細は、『Oracle Database概要』を参照してください。

トランザクションの詳細は、『Oracle Database開発ガイド』を参照してください。

動的データベース・サービスの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

XAデータ・ソース・インタフェースとAPIの詳細は、『Oracle Database JDBC開発者ガイド』を参照してください。

Oracle Call Interfaceプログラマーズ・ガイド

Oracle Data Provider for .NETの開発者ガイド

3.17.3 グローバル・データ・サービスを使用したOracle Database

グローバル・データ・サービスにより、管理者は共通のサービスを提供するレプリケートされたデータベース全体でクライアント・ワークロードを自動的および透過的に管理できます。データベース・サービスは、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

  複数のデータベース間のレプリケーション更新を可能にします。

図3-3 グローバル・データ・サービスのアーキテクチャ

「図3-3 グローバル・データ・サービスのアーキテクチャ」の説明

関連項目:

Oracle Database Global Data Services概念および管理ガイド

3.18 Oracle Multitenant

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

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のオーバーヘッドが削除または削減されるためです。Oracle Database 12cリリース2では、各CDBに4,095個までのPDBを格納できます。また、各PDBでは、同じCDB内の他のPDBと異なる文字セットを使用することもできます。この場合、CDBルートの文字セットはPDBのすべての文字セットのスーパーセットになります。ロジカル・スタンバイ・データベースは、この文字セットの混在もサポートして、一時ロジカル・スタンバイ・データベースを使用してローリング・アップグレード実行できます。

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

  • 停止時間がゼロに近い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を一度の操作でメンテナンスできます。Oracle Database 12cリリース2には次の機能が追加されています。

  • 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が、割り当てられている量を超えてシステム・リソースにアクセスすることはありません。Oracle Database 12cリリース2では、PDB制限におけるSGA、バッファ・キャッシュ、共有プールおよびPGAメモリーの保証された最小値と最大値を指定できます。

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

関連項目:

Oracle Multitenantの詳細は、『Oracle Database管理者ガイド』を参照してください。

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

3.19 Oracle Sharding

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

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

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

関連項目:

Oracle Database Sharding参照アーキテクチャ

Oracle Sharding環境の管理に関する詳細は、『Oracle Database管理者ガイド』を参照してください。

3.20 Oracle Restart

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

ご使用のプラットフォーム用のOracle Grid Infrastructureインストレーション・ガイド

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

3.22 Zero Data Loss Recovery Appliance

クラウド規模のZero Data Loss Recovery Appliance (通常、リカバリ・アプライアンスと呼ばれる)は、エンタープライズ内のすべてのOracleデータベースでデータ損失とバックアップ・オーバーヘッドを劇的に削減するエンジニアド・システムです。Recovery Manager (RMAN)と統合したリカバリ・アプライアンスによって、クラウド規模の耐障害性の高いハードウェアと記憶域を使用し、多数のデータベースに対応する、集中管理された永久的増分バックアップ計画が実現します。リカバリ・アプライアンスでは、継続してバックアップのリカバリ可能性が検証されます。

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

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

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

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

• クラウド規模の保護

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

関連項目:

Zero Data Loss Recovery Appliance。

『Zero Data Loss Recovery Appliance管理者ガイド』