Comments
Description
Transcript
Oracle Database 12cによる可用性の最大化
Oracleホワイト・ペーパー
2013年6月
Oracle Database 12cによる可用性の最大化
Oracle Database 12cによる可用性の最大化
はじめに ....................................................................................................................................................1
高可用性に関する課題...................................................................................................................... 2
Oracle Database高可用性 ............................................................................................................... 2
Oracle Database 12cにおける革新 ..................................................................................... 3
Oracle Database HA設計の原則 ........................................................................................... 3
Oracle Maximum Availability Architecture .................................................................... 5
計画外停止時間への対応................................................................................................................. 5
サーバーHA： Oracle Real Application Clusters ......................................................... 6
透過的なフェイルオーバー：アプリケーション継続性 ........................................ 7
ストレージ：Automatic Storage Management（ASM）..................................... 7
データ可用性および破損に対する保護 ........................................................................... 7
バックアップとリカバリ - Oracle Recovery Manager ............................................ 9
テープへのバックアップ - Oracle Secure Backup .................................................. 12
論理的破損からのリカバリ：Oracleフラッシュバック・テクノロジー .. 13
リアルタイムのデータ保護および可用性 - Oracle Data Guard ...................... 15
いかなる距離でもデータ損失ゼロ：Active Data Guard .................................... 16
アクティブ/アクティブHAおよび停止時間なしのアップグレード： Oracle
GoldenGate ................................................................................................................................... 18
サイト全体のフェイルオーバー：Oracle Site Guard ........................................... 19
計画停止時間への対応................................................................................................................... 19
オンライン・システム再構成 ............................................................................................ 20
オンラインでのデータおよびアプリケーションの変更 ..................................... 20
オンライン・アプリケーション・アップグレード：
エディションベースの再定義 ............................................................................................ 21
ホット・パッチ........................................................................................................................... 21
Oracle RACを使用したローリング・パッチ・アップグレード ...................... 22
Data Guard Standby-First Patch Assurance ................................................................ 22
Data Guardを使用したデータベース・ローリング・アップグレード ...... 22
Active Data Guardを使用したデータベース・ローリング・
アップグレード........................................................................................................................... 23
Oracle Database 12cによる可用性の最大化
プラットフォームの移行、システムの保守、データセンターの移転 ...... 23
Oracle GoldenGateを使用した停止時間ゼロの保守............................................. 24
Oracle Database高可用性ソリューションの管理 .......................................................... 24
グローバル・データ・サービス .............................................................................................. 25
結論 ........................................................................................................................................................... 27
付録： Oracle Database 12cの新しい高可用性機能 .................................................... 28
Oracle Database 12cによる可用性の最大化
はじめに
企業は、競争優位性の確保や運用コストの削減、また、顧客とのコミュニケーションやビジネス管理の強化
に情報技術（IT）を活用しています。そのため、企業は、ITインフラストラクチャとその継続的な可用性に
ますます依存するようになっています。アプリケーションが停止したりデータが使用できなくなったりする
と、生産性、収益、顧客満足度、および企業の評判の低下に直接つながります。
高可用性（HA）インフラストラクチャを構築するための基本的なアプローチは、多種多様なベンダーが提
供する冗長で、アイドル状態が頻繁に発生するハードウェアおよびソフトウェア・リソースをデプロイする
ことです。このアプローチは、多くの場合は高コストであるにもかかわらず、コンポーネントの疎結合、技
術上の制限、管理の複雑さのために期待されるサービス・レベルに達しません。これに対して、オラクルは、
コストを削減し、すべてのHAリソースの生産的な使用を通して投資収益率を最大化し、さらにユーザーへ
のサービス品質を向上させるための包括的で統合されたHAテクノロジーを顧客に提供しています。
このホワイト・ペーパーでは、ITインフラストラクチャに影響を与える停止のタイプを検証し、それらの停
止に総合的に対処するためのOracle Databaseテクノロジーを提示します。オラクルのMaximum Availability
Architecture（Oracle MAA）に統合されたこれらのテクノロジーは、計画外停止時間を短縮または回避し、
障害からの迅速なリカバリを可能にし、さらに計画停止時間を最小限に抑えます。Oracle Database 12cには、
それぞれ、アプリケーション・リカバリの機能強化、グローバル・データ・サービスのサポート、データ損
失ゼロの保護のグローバル・レベルへの拡張を行うアプリケーション継続性、グローバル・データ・サービ
ス、Active Data Guard Far Syncを含む新機能が導入されています。また、Real Application Clusters、
Automatic Storage Management、Recovery Manager、Data GuardとActive Data Guard、Oracle Secure
Backup、エディションベースの再定義などの既存のHA機能に対するOracle Database 12cのパフォーマンス、
機能、および使いやすさの向上についても説明します。
1
Oracle Database 12cによる可用性の最大化
高可用性に関する課題
実際の制約条件の下ですべてのビジネス目標を達成する高可用性（HA）アーキテクチャの設計、実装、お
よび管理はきわめて困難です。さまざまなサプライヤからの多くのテクノロジーやサービスがデータ損失と
停止時間からビジネスを保護することを提案していますが、誰を信頼できるでしょうか。
オラクルでは、HAには停止時間の防止という主要目的に加え、いくつかの重要な側面が含まれると考えて
います。包括的なHAアーキテクチャの重要な側面には、次のものが含まれます。
• データ可用性： ビジネスの中断を回避するためにデータへのアクセスを保証します。
• データ保護： ビジネスの実行可能性を損なうデータ損失を防止します。
• パフォーマンス： 効率的な業務のための十分な応答時間を提供します。
• コスト： 企業リソースを節約するために、デプロイメント、管理、およびサポート・コストを削減します。
• リスク： 、コストのかかる予期しない事態や失望する事態を発生させることなく、ビジネスの発展に合
わせて必要なサービス・レベルを長期間にわたり安定的に達成します。
HAの成功は、これらの各側面に沿って、ビジネスに必要なサービス・レベルを理解することから始まりま
す。これにより、テクノロジーに関する重要な決定が導かれるとともに、HAアーキテクチャへの投資の適
切なレベルが決定されます。
効果的なHAソリューションは、上記の各側面に沿ったサービス・レベル目標を達成します。サービス・レ
ベル要件はアプリケーション、ビジネス機能、およびユーザー・グループごとに異なるため、これらのソ
リューションは柔軟である必要があります。また、どのソリューションも永続的ではなく、要件はビジネス
条件の変化に伴って進化するため、すばやく適応できることも必要です。
Oracle Database高可用性
オラクルは、データベースに統合された包括的なHA機能を設計することにより、HAに関する課題のITによ
る解決を支援するために30年以上にわたって努力してきました。この革新的な取組みの結果、企業が高可用
性に対するサービス・レベル目標をもっとも費用効果に優れた方法で達成できるように支援することで、企
業に真の競合優位性を与えるHAソリューションが生まれました。
Oracle Database HA機能は、すべての計画停止および計画外停止に対処します。オラクルは、データベース
の内部コア機能と緊密に統合されたデータベース認識型のHA機能を構築し、提供します。これにより、ビ
ジネス・リスクを軽減し、固有のレベルのデータ保護、可用性、パフォーマンス、および投資収益率を達成
する、費用効果に優れたソリューションが生成されます。Oracle Database HA機能は、ユーザーが適切なレ
ベルのHAを選択できる柔軟性と、ユーザーの現在および将来におけるビジネス目標を効率的にサポートす
る適応性を備えています。
2
Oracle Database 12cによる可用性の最大化
Oracle Database 12cにおける革新
Oracle Database 12cの新しいオプションであるOracle Multitenantは、データベース統合およびクラウド・
コンピューティングのための画期的なテクノロジーを提供します。マルチテナント・アーキテクチャは、
データベース層の統合および仮想化のための真の'manage-as-one'アーキテクチャを可能にすることによっ
てITコストを削減します。マルチテナント・アーキテクチャではまた、ビジネス・クリティカルなアプリ
ケーションにデータベース統合が適用される場合、卓越した高可用性も基本的な要件になります。データ
ベース統合とは、定義上、'すべての卵を1つのバスケット内に収める'作業です。統合を通してコストの削減
に成功すればするほど、1つのバスケット内に収まる卵の数が増えると同時に、停止が発生した場合のビジ
ネスへの運用および財務上の影響も大きくなります。
Oracle Database 12cの新しい高可用性（HA）機能は、データベースをプライベート・クラウドに統合する
ために必要な、卓越したレベルの可用性を提供するように設計されています。これには、すべてのOracle
HA機能にまたがるマルチテナント・アーキテクチャ、新しいレベルの冗長性、実行中トランザクションの
透過的なフェイルオーバー、いかなる距離でもデータ損失ゼロの障害時保護機能のサポートが含まれます。
Oracle Multitenantのアーキテクチャは次世代のデータベース・テクノロジーを象徴しており、長年にわたっ
て実績のあるOracle HA設計の原則が最初から準備されているため、統合された環境に必要な卓越した可用
性が提供されます。
Oracle Database HA設計の原則
Oracle Database HAは、データベース・カーネル内に構築された、一連の緊密に統合されたHA機能に依存し
ています。オラクルの高可用性に対するビジョンは、次に説明する3つの原則によって導かれます。
最大のデータ保護を実現するためのOracleデータベースの内部機能の活用
その内部アルゴリズムとデータ構造（データベースのブロック構造やREDO形式を含む）の知識および制御
により、オラクルはインテリジェントな、オラクル固有のデータ保護を構築できます。たとえば、データ
ベース内の破損をもっとも早い機会に検出できるため、Oracle Data Guardは物理的破損の伝播、論理的なブ
ロック内破損、および書込み損失によって引き起こされる論理的破損を防止します。Active Data Guardでは
さらに、プライマリまたはスタンバイ・データベースのどちらでも発生する可能性のあるディスク上の物理
的破損を、ユーザーに影響を与えることなく自動的に修復します。
同様に、Oracle Recovery Manager（Oracle RMAN）は、オラクルが認識する物理および論理ブロック検証を
実行して有効なバックアップを保証します。Oracle RMANでは、変更されたブロックだけをバックアップす
る、1回のバックアップ、永久増分戦略が可能になるため、外部の重複排除アプライアンスより効率的な
ソース側の暗黙的重複排除が実現されます。Oracle RMANはまた、データファイル全体ではなく、個々のブ
ロックに対するきめ細かく効率的なリカバリも実行します。オラクル固有のデータ保護の別の例として、完
全なデータベース・リストアを実行することなく、データベース変更をエラーの範囲（データベース全体、
表、または個々のトランザクション）に対応した粒度レベルで取り消すフラッシュバック・テクノロジーの
機能があります。
3
Oracle Database 12cによる可用性の最大化
アプリケーションと統合された高可用性の提供
コールド・フェイルオーバー・クラスタを使用して、またはストレージ中心のソリューションによって実行
されるように生のビット・レベルでHAやデータ保護を提供するだけでは、包括的な保護と迅速なリカバリ
には不十分です。Oracle Real Application Clusters（Oracle RAC）を使用すると、1つのOracle Databaseをア
クティブ/アクティブ構成内のデータベース・サーバーのクラスタ上で実行できます。パフォーマンスは、
追加のサーバーのオンライン・プロビジョニングによって容易にスケールアウトできます。ユーザーはすべ
てのサーバー上でアクティブであり、すべてのサーバーが同じOracle Databaseへのアクセスを共有します。
計画外停止や計画保守の間も、サービスが停止されたサーバー上のユーザーを、引き続き機能している
Oracle RACクラスタ内の他のサーバーに移行することによってHAが維持されます。
停止は最終的にアプリケーションの可用性に影響を与えますが、ストレージ中心のソリューションとは異なり、
Oracle HAテクノロジーはビジネス・オブジェクト・レベルで動作するように設計されています（表の修復や、
特定のトランザクションのリカバリなど）。Oracleソリューションではきめ細かなリカバリが可能になるため、
非常に効率的であり、影響を受けないデータベースの部分を使用しているアプリケーションの可用性を中断す
ることはありません。オラクルはまた、オンライン再定義機能により、他のユーザーがアクセスおよび更新し
ている間の表の構造的な変更も可能にしています。Oracle Database 12cの新機能であるアプリケーション継続
性は、サーバーまたはサイト・フェイルオーバーが発生した後にセッションをアプリケーションに対して透過
的に再生することによって、多くの停止をエンドユーザーやアプリケーションからマスクします。
Oracle HAソリューションは、計画外停止の範囲にとどまりません。あらゆるタイプのデータベース保守を
オンラインまたはローリング方式で、停止時間をゼロまたは最小限に抑えて実行できます。Data Guardのス
タンバイ・システムは、テスト・システムとして簡単にさまざまな目的に使用できます。すべての変更が、
本番環境に適用される前に本番データベースの正確なコピー上で完全にテストされることが保証されるため、
リスクが軽減されます。
投資収益率の高い、自動化された統合型オープン・アーキテクチャの提供
Oracle Databaseに組み込まれたHA機能を個別に統合またはインストールする必要はありません。新しい
バージョンへのアップグレードは大幅に簡素化されているため、複数のベンダーのテクノロジー間でのリ
リース認定という、面倒で時間のかかるプロセスが不要になります。さらに、すべての機能をOracle
Enterprise Manager Cloud Controlの統合管理インタフェースで管理できます。オラクルは、すべてのステッ
プに自動化を組み込むことにより、手動の構成で発生しやすい一般的なミスを防止しています。たとえば、
顧客は本番データベースがオフラインになった場合はスタンバイ・データベースに自動的にフェイルオー
バーしたり、効率的な領域管理のためにバックアップを自動的に削除およびアーカイブしたり、物理的なブ
ロック破損を自動的に修復したりすることを容易に選択できます。
Oracle HAソリューションは本質的にアクティブであり、障害発生時にのみ機能するアイドル・コンポーネント
を回避します。すべてのOracle RACノードがアクティブであり、Data Guardのスタンバイ・システムは読取り
専用アプリケーション、データ抽出、および高速増分バックアップをサポートし、さらにOracle GoldenGateは、
update-anywhereアーキテクチャ内のOracle Databaseのレプリケートされたコピー間に分散された競合解消機
能により読み書きワークロードをサポートします。オラクルのアクティブHAアーキテクチャは高いROIを提供
すると同時に、障害のリスクを最小限に抑えます。起動の可否や、障害が発生した後、サービスを再開するま
でにどれくらいの時間がかかるかという疑問は存在しません。すべてのOracle HAコンポーネントがすでに起動
され、有効な作業をすでに実行し、継続的なユーザー検証を可能にして、高ワークロードに対応します。
4
Oracle Database 12cによる可用性の最大化
Oracle Maximum Availability Architecture
Oracle Maximum Availability Architecture（Oracle MAA）は、Oracle高可用性（HA）テクノロジーの統合さ
れた使用のための一連のベスト・プラクティス構想です（図1を参照）。1つのサイズですべての要件を満た
すことはできないため、MAAは、企業内の各アプリケーション・クラスに必要なさまざまなサービス・レベ
ル目標を達成するように設計された最適なHAアーキテクチャに関するガイダンスを提供しています。MAA
のベスト・プラクティスは、Oracle Database HA機能の統合された使用を継続的に検証しているOracle開発
者のチームによって作成および維持されています。また、MAAチームによって実行される検証には実際のカ
スタマー・エクスペリエンスも統合されるため、習得した教訓が他の顧客にも広がります。
MAAでは、サーバー、ストレージ、ネットワークなどの重要なインフラストラクチャ・コンポーネントのた
めのベスト・プラクティスが、その上にデプロイされているOracle HA機能のための構成および運用のベス
ト・プラクティスと組み合わされています。MAAリソース（oracle.com/goto/maa）は、継続的に更新およ
び拡張されています。
図1： オラクルの高可用性テクノロジーとOracle Maximum Availability Architecture
このドキュメントの残りの部分では、Oracle Database 12cのHA機能についてさらに詳しく検証します。
計画外停止時間への対応
サーバー障害を引き起こすハードウェア障害は基本的に予測不可能ですが、ひとたび発生するとアプリケー
ションの停止につながります。同様に、ストレージ破損、サイトの停止、人為的エラーなどのさまざまな
データ可用性障害もまた、計画外停止時間の発生につながります。この項では、計画外停止時間の発生防止
と短縮に向けて、オラクルのHAソリューションがどのようにしてこれらの基本的なタイプの障害に対処す
るかについて説明します。
5
Oracle Database 12cによる可用性の最大化
サーバーHA： Oracle Real Application Clusters
サーバーの可用性とは、ハードウェアまたはソフトウェアの障害によってデータベース・サーバーのホス
ト・マシンに予期しない障害が発生した場合にも、データベース・サービスへの連続したアクセスを確保す
る能力を示すものです。Oracle Real Application Clusters（Oracle RAC）は、このような障害に対してもっと
も効果的な保護を実現できます。
Oracle Real Application Clusters（Oracle RAC）は、オラクルの主要なシェアード・エブリシング型のデータ
ベース・クラスタリング・テクノロジーです。RACオプションを指定してOracle Databaseを使用すると、
データベースを構成する共有されたデータファイル・セットに対して、クラスタ内の異なるサーバー上で複
数のデータベース・インスタンスを実行できます。データベースは複数のハードウェア・システムにまたが
りますが、アプリケーションに対しては、1つの統合データベースとして表示されます。
Oracle RACアーキテクチャは、すべてのアプリケーションに特に次のような可用性とスケーラビリティの利
点をもたらします。
• サーバー・プール内のフォルト・トレランス（特に、コンピュータ障害用）。ノードは独立して実行され
るため、1つまたは複数のノードの障害が他のノードに影響することはありません。また、このアーキテ
クチャを使用すれば、ノードのグループを透過的にオンラインまたはオフラインに設定して、システムの
残りの部分で引き続きデータベース・サービスを提供できます。
• 容量計画の柔軟性と費用効率の高さ。これにより、ビジネス・ニーズの変化に応じてシステムを必要な任
意の容量に拡張できるようになります。Oracle RACによって、ユーザーは容量ニーズの増加に応じてシス
テムにノードを柔軟に追加できるようになり、既存のモノリシック・システムをより大規模なシステムに
置き換えるという、より高コストで業務の中断を要するアップグレード・パスを回避できるため、コスト
が削減されます。Oracle RACのサポートを使用すると、アプリケーションをまったく変更しなくても、ほ
ぼ線形のスケーリングが可能になります。
Oracle Database 12cの新機能であるアプリケーション継続性は、インスタンス、サーバー、ストレージ、
ネットワーク、またはその他の任意の関連コンポーネントによるデータベース・セッション障害からアプリ
ケーションを保護します。アプリケーション継続性は、影響を受けた"実行中"のリクエストを再生して、
RACノードの障害がアプリケーションにとっては短時間の実行遅延に見えるようにします。詳しくは、後述
の「アプリケーション継続性」を参照してください。
Oracle RACはまた、新しいマルチテナント・アーキテクチャもサポートしており、サーバーHAの提供に加えて、
Oracle RACソフトウェア・スタック 1もデータベース統合のための理想的な共有インフラストラクチャです。
詳しくは、OTNのReal Application Clustersのリソース（oracle.com/goto/rac）を参照してください。
1
Oracle Database RACソフトウェア・スタックは、Oracle Grid Infrastructure（Oracle ASM/ACFSとOracle Clusterwareを含
む）、およびOracle Real Application Clustersオプション付きのOracleデータベースで構成されます。
6
Oracle Database 12cによる可用性の最大化
透過的なフェイルオーバー：アプリケーション継続性
アプリケーションの開発でデータベース・セッションの停止をマスクすることは複雑です。その結果、エ
ラーやタイムアウトが頻繁にエンドユーザーに表示され、フラストレーションの原因になったり、生産性が
低下したりします。Oracle Database 12cでは、計画外停止が発生した後、データベース・セッションをリカ
バリすることによって停止をマスクする新機能であるアプリケーション継続性が導入されています。アプリ
ケーション継続性はこのリカバリをアプリケーションの後方で実行するため、アプリケーションにとってこ
の停止は短時間の実行遅延のように見えます。
ストレージ：Automatic Storage Management（ASM）
Oracle Automatic Storage Management（Oracle ASM）は、OracleデータベースやOracle ASM Cluster File System
（ACFS）によって使用される基盤となる（クラスタ化された）ボリューム・マネージャ・テクノロジーであり、
あらゆるタイプのデータを共有ストレージに格納して管理できるようにします。ASMは低コストで、管理しや
すく、高パフォーマンスであるため、Oracleデータベースに最適なストレージ・テクノロジーです。
ASMでは、パフォーマンスと高可用性のために、すべてのデータをストライプ化およびミラー化します。イ
ンテリジェントなミラー化機能によって、管理者は、2方向または3方向のミラー化を定義してデータを保護
できます。読取り操作によってディスク上に破損ブロックが存在することが識別されると、ASMは、有効な
ブロックをミラー・コピーからディスクの破損していない部分に自動的に再配置します。また、管理者は
ASMCMDユーティリティを使用して、特定のブロックを手動で再配置することもできます。ディスク障害が
発生した場合は、ミラー化されたディスク上で使用可能なデータを使用して、システム停止時間が回避され
ます。障害が発生したディスクがASMから永久に削除された場合は、高パフォーマンスを維持するために、
基盤となるデータが残りのディスク間でストライプ化またはリバランシングされます。
Oracle Database 12cの新機能であるFlex ASMは、ノード間のストレージ・フェイルオーバーを有効にし、
ASM関連のリソース消費を最大60%削減することによって、データベース（インスタンス）の可用性を向上
させます。Flex ASMによって、クラスタベースのデータベース統合が容易になります。それは、特定のサー
バー上のASMインスタンスに障害が発生しても、そのサーバー上で実行されているデータベース・インスタ
ンスが引き続き動作することが保証されるためです。
Oracle Database 12cの新機能であるASMディスク・スクラビングは、通常のディスク・グループと高レベル
の冗長ディスク・グループの両方にある論理的破損をチェックし、それを自動的に修復します。これは、
バックアップやリカバリ中にOracle RMANが実行するヘルス・チェックを補完するものです。
データ可用性および破損に対する保護
データ可用性は、ビジネス上重要なデータの損失、損傷、または破損といったデータ障害の回避と軽減に関
係します。データ障害は、ストレージ・サブシステムの障害、サイト障害、人為的エラー、破損といった原
因のいずれか、またはこれらの組合せによって発生します。これらの多面的な原因が、多くの場合、データ
障害の識別や診断を困難なものにしています。この項および以降の項では、データ障害の診断、防止、軽減、
およびリカバリに役立つ、Oracle Databaseに含まれているHAテクノロジーについて検証します。
7
Oracle Database 12cによる可用性の最大化
人為的エラーからの保護
人為的エラーは停止時間のおもな原因であるため、適切なリスク管理には、人為的エラーを防止および修正す
るための手段を含める必要があります。たとえば、正しくないWHERE句によって、UPDATEの影響が意図した
よりはるかに多くの行に及ぶことがあります。Oracle Database 12cには、このようなエラーを管理者が防止、
診断、およびリカバリするのに役立つ、一連の強力な機能が用意されています。また、エンドユーザーが問題
から直接リカバリすることで、損失データや損傷データのリカバリを高速化するための機能も含まれます。
コストのかかる人為的エラーを防止するための適切な方法は、ユーザーのアクセス範囲を必要なデータや
サービスのみに制限することです。Oracle Databaseには、ユーザーを認証し、管理者がその職務の実行に必
要な権限のみをユーザーに付与できるようにすることによってユーザー・アクセスを柔軟に制御するセキュ
リティ・ツールが用意されています。
たとえば、以前はバックアップ管理者に幅広いSYSDBA権限が付与されたため、その結果としてセキュリ
ティ上のリスクにさらされていました。Oracle Database 12cで使用可能な新しい権限には、データベース管
理の職務とよりきめ細かいスコープ定義の分離をサポートするSYSDGとSYSBACKUPが含まれています。
SYSDGは、ロール変更の構成、監視、実施などのData Guardアクティビティのためのものです。SYSBACKUP
は、データベースのバックアップやリストアなどのOracle Recovery Manager（Oracle RMAN）アクティビ
ティのためのものです。
以下の他の項では、人為的エラーからリカバリするためのバックアップおよびフラッシュバック・テクノロ
ジーについて説明します。
物理的なデータ破損からの保護
物理的なデータ破損は、I/O（入力/出力）スタックのいずれかのコンポーネントの障害によって発生します。
Oracleから書込みが発行されると、このデータベースI/O操作がオペレーティング・システムのコードに渡され
ます。この書込みは、I/Oスタック（ファイル・システムから順にボリューム・マネージャ、デバイス・ドライ
バ、ホストバス・アダプタ、ストレージ・コントローラ、NVRAMキャッシュまで）を通過した後、最終的に
ディスク・ドライブに達し、そこでデータが書き込まれます。これらのいずれかのコンポーネントにハード
ウェア障害またはバグがあると、無効なデータや破損したデータがディスクに書き込まれる場合があります。
この破損によって、内部のOracle制御情報またはアプリケーション・データやユーザー・データが損傷する可
能性があり、そのどちらの場合もデータベースの機能が深刻な打撃を受けるおそれがあります。以降のページ
では、データを破損から保護するためのオラクルの包括的なソリューション・セットについて説明します。
物理的および論理的なブロック内破損の検出と防止
破 損 に 対 す る 包 括 的 な 保 護 の た め に 、 Oracle MAA で は 、 Data Guard を デ プ ロ イ し 、 パ ラ メ ー タ
DB_ULTRA_SAFEを設定し、さらにフラッシュバック・データベースを有効にすることを推奨します。また、
Active Data Guardでは、自動ブロック修復機能も使用できます。プライマリ・データベースとスタンバイ・
データベースの両方でDB_ULTRA_SAFE=DATA_ONLYを設定すると、ブロック・ヘッダーのチェック、フル
ブロックのチェックサム、必要に応じてプライマリ・データベースとスタンバイ・データベースの両方を含
む書込み損失の検証などの主要な破損チェックが有効になります。これらの設定はパフォーマンスに影響を
与えるため 2、本番環境に導入される前にテストする必要があります。 3
2
MOS Note 1302539.1では、これらのパラメータでの保護とパフォーマンスのトレードオフについて説明しています。
3
詳しくは、MAAのホワイト・ペーパー『Preventing, Detecting, and Repairing Block Corruption』を参照してください。
8
Oracle Database 12cによる可用性の最大化
バックアップとリカバリ - Oracle Recovery Manager
どのようなIT組織でも、防止やリカバリのテクノロジーに加えて、複数の障害シナリオに対応するための完
全なデータ・バックアップ手順を実装する必要があります。オラクルは、データを効率的にバックアップお
よびリストアしたり、データを障害が発生する直前の時点までリカバリしたりするための、Oracleが認識す
るベスト・オブ・ブリードのツールを提供しています。オラクルは、ディスク、テープ、およびクラウド・
ストレージへのバックアップをサポートしています。この広範囲のバックアップ・オプションにより、ユー
ザーは、特定の環境に合わせた最適なソリューションを導入できます。以降の項では、オラクルのディスク、
テープ、クラウドのバックアップ・テクノロジー、およびData Recovery Advisorについて説明します。
Oracle Recovery Manager（Oracle RMAN）
Oracle Recovery Manager（Oracle RMAN）は、データベースのバックアップ、リストア、およびリカバリ・
プロセスを管理します。Oracle RMANは、構成可能なバックアップとリカバリ・ポリシーを保守し、すべて
のデータベースのバックアップ・アクティビティとリカバリ・アクティビティの履歴レコードを保持します。
大規模なデータベースは数百のファイルを含んでいる場合があるため、Oracleが認識するソリューションが
ないと、バックアップが非常に困難になります。重要なファイルが1つ欠落するだけで、データベース・
バックアップ全体が役に立たなくなる場合があり、さらに不完全なバックアップが、緊急時に必要になるま
で検出されない可能性もあります。Oracle RMANは、データベースを正常にリストアおよびリカバリするた
めに必要なすべてのファイルがデータベース・バックアップに含まれていることを確認します。バックアッ
プおよびリストア中、Oracle RMANは、破損ブロックが伝播されることがないようにすべてのデータを検証
します。リストア操作中に破損ブロックが見つかった場合は、リカバリを成功させるために、Oracle RMAN
は自動的に、必要に応じて以前のバックアップのファイルを使用します。
Oracle RMANでは、圧縮レベルを選択できます。BASICがOracle Database Enterprise Editionに含まれており、
LOW、MEDIUM、HIGHの各レベルはOracle Advanced Compressionオプション（ACO）の一部として提供さ
れています。圧縮率とCPU使用率を高い方から順に並べると、HIGH、BASIC、MEDIUM、LOWとなります。
つまり、HIGHの圧縮レベルを指定すると最高の圧縮率が得られる一方で、必要なCPUオーバーヘッドももっ
とも大きくなります。
Oracle RMANのActive Duplicate機能は、バックアップを使用せずに、ネットワーク経由でクローンまたは
フィジカル・スタンバイ・データベースを作成します。データファイル・コピーは、宛先データベースに直
接書き込まれます。Oracle Database 12cでは、ワークロードが補助チャネル経由で宛先サーバーに移動され
るため、ソース（通常は本番）データベース・サーバー上のリソースのボトルネックが解放されます。
Oracle Database 12cの新機能であるActive Duplicate Cloningは、Oracle RMANの圧縮機能とマルチセクショ
ン機能を使用して、パフォーマンスをさらに向上させることができます。未使用ブロックの圧縮は自動的に
実行されます。また、ネットワーク・トラフィックがボトルネックである場合、管理者は以前と同様に、バ
イナリ圧縮が適用されるようにOracle RMANを構成することもできます。
9
Oracle Database 12cによる可用性の最大化
クロス・プラットフォームのバックアップとリストア
Oracle Database 12cの新機能であるOracle RMANクロス・プラットフォーム機能を使用すると、表領域や
データベースの効率的な移行に有効な、異なるプラットフォーム間でのバックアップとリストアが可能にな
ります。 4 ソース・プラットフォームでは、BACKUPによって、ユーザー表領域のバックアップ・セット
（Data Pumpメタデータ・ダンプ・ファイルを含む）が読取り専用モードで作成されます。宛先プラット
フォームでは、RESTOREによって自動的にデータファイルのエンディアン変換が実行され、表領域がプラグ
インされます。読取り専用の影響を最小限に抑えるために、増分バックアップを作成することを推奨します。
このバックアップは後で変換され、リストアされたデータファイルに適用されます。表領域が読取り専用
モードにある間に作成が必要なのは最後の増分バックアップだけです。
Oracle Multitenantに対するOracle RMANのサポート
Oracle RMANはまた、マルチテナント・ アーキテクチャもサポートしています。使い慣れたBACKUP
DATABASEコマンドとRESTORE DATABASEコマンドは現在、そのすべてのプラガブル・データベース（PDB）
を含むマルチテナント・コンテナ・データベース（CDB）をバックアップおよびリストアします。また、
キーワードPLUGGABLEを使用して、個々のPDB（全体バックアップおよびリストアを含む）にRMANコマン
ドを適用することもできます。たとえば、プラガブル・データベースのポイント・イン・タイム・リカバリ
には、次の単純なRMANスクリプトを実行できます。
RMAN> RUN
{SET UNTIL TIME 'SYSDATE-3';
RESTORE PLUGGABLE DATABASE <PDB>;
RECOVER PLUGGABLE DATABASE <PDB>;
ALTER PLUGGABLE DATABASE <PDB> OPEN RESETLOGS;}
Oracle RMANはまた、（ユーザーが指定した）プラガブル・データベースの一部またはすべてを含むコンテ
ナ・データベースの効率的なクローニングもサポートしています。
Oracle Database 12cで使用可能なOracle RMANのその他の拡張機能
Oracle RMANでは現在、単純なRECOVER TABLEコマンドを使用して、バックアップから個々のデータベース表
をリカバリできます。これにより、RMANバックアップから1つまたは複数の表（最新バージョンまたは古い
バージョン）がリカバリされます。表はインプレースで、または別の表領域にリカバリできます。必要に応
じて、Oracle RMANで、表のData Pumpダンプ・ファイルを作成できます。この機能は、エラーが発生しやす
い手動のプロセスを置き換え、リカバリ時間目標（RTO）を改善します。フラッシュバックを適用できない場
合（たとえば、削除された表がごみ箱から消去されている場合や、リカバリする目的の時点が
UNDO_RETENTIONパラメータで指定された時間枠の範囲外である場合）は、リカバリの範囲が拡張されます。
4
クロス・プラットフォームの増分バックアップは、MOS Note 1389592.1で説明されているように、以前のリリースで
Linuxに対してサポートされています。従来、データベースをプラットフォーム間で移動するには、インポート/エクス
ポートまたはクロス・プラットフォーム・トランスポータブル表領域の手順のどちらかが必要だったためアプリケーショ
ンの可用性に大きな影響を与えていました。
10
Oracle Database 12cによる可用性の最大化
パフォーマンスと使いやすさを向上させるための、Oracle Database 12cでのOracle RMANのその他の拡張機
能には、次のようなものがあります。
• イメージ・コピーのマルチセクション・バックアップおよび増分バックアップに対するOracle RMANのサ
ポート。
• RECOVER DATABASE.. FROM SERVICEという単純なRMANコマンドを使用した、スタンバイ・データベース
とプライマリ・データベースとの迅速な同期
• RMANコマンドライン（CLI）でのSQL文の直接サポート。SQLキーワードや引用符は必要ありません。
詳しくは、OTNのOracle RMANのリソース（oracle.com/goto/rman）を参照してください。
ファスト・リカバリ領域
Oracle Databaseバックアップ戦略の1つの重要なコンポーネントとして、ファスト・リカバリ領域（FRA）
があります。これは、Oracleデータベースのリカバリに関連したすべてのファイルとアクティビティのため
の、ファイル・システムまたはASMディスク・グループ上の場所です。FRAには、メディア障害からデータ
ベースをリカバリするために必要なすべてのファイル（制御ファイル、アーカイブ・ログ、データファイ
ル・コピー、RMANバックアップを含む）を保存できます。FRA内の領域は自動的に管理されます。1つの
FRAを1つ以上のデータベースで共有できます。
FRAには、場所だけでなく、割当て制限も設定されます。複数のデータベースが1つのFRAを共有している場
合は、各データベースに独自の割当て制限が設定され、FRAのサイズはデータベースの割当て制限の合計に
なります。FRA内で新しいバックアップが作成されたときに、それを保持するための（設定された割当て制
限ごとの）十分な領域が存在しない場合は、領域を再利用するために、Oracle RMANの保存方針に適合しな
い（または、すでにテープにバックアップされた）バックアップとアーカイブ・ログが自動的に削除されま
す。FRAではまた、使用されているディスク領域が割当て制限に近づいていて、それ以上ファイルを削除で
きない場合も（アラート・ログを通して）管理者に通知します。管理者は、ディスク領域を追加するか、
ファイルをテープにバックアップしてFRAのディスク領域を解放するか、または保存方針を変更することが
できます。
Data Recovery Advisor
データの停止の多くは、停止の前に表示されるエラーやトレース・ファイルの正確な分析に基づいて軽減で
きます。Data Recovery Advisor（DRA）は、物理的な整合性を検証するデータベースのヘルス・チェックを
事前予防的に実行し、データベース停止の可能性のある前兆を識別して、管理者に警告することができます。
管理者はリカバリ・アドバイスを取得し、システム停止時間につながる前に、問題を修正するための予防措
置を実行できます。重要なビジネス・データが破損した場合、DRAはリカバリ・オプションや修復オプショ
ンを迅速かつ徹底的に評価することによって、データベース管理者がプレッシャーの下で安全で迅速なリカ
バリを確保できるように支援します。DRAは、Data GuardやOracle RMANなどのオラクルの他の高可用性機
能と緊密に統合されているため、具体的な条件に基づいて、どのリカバリ・オプションが実行可能かを特定
できます。これらのオプションは、データ損失の可能性が低い方から順にランク付けされて管理者に提示さ
れます。DRAはまた、最適なリカバリ・オプションを自動的に実装することも、管理者による手動のリカバ
リのためのガイドとしてのみ機能することもできます。
11
Oracle Database 12cによる可用性の最大化
テープへのバックアップ - Oracle Secure Backup
Oracle Secure Backupは、データベースとファイル・システムの両方のデータ向けの、オラクルのエンター
プライズ・クラスのテープ・バックアップ管理ソリューションです。Oracle Secure Backupは、次の機能を
提供することによって、分散した異機種IT環境のためのスケーラブルな、一元化されたテープ・バックアッ
プ管理を実現します。
• Oracle Recovery Manager（Oracle RMAN）統合。Oracle Database 10gからOracle Database 12cまでのバージョ
ンをサポートし、バックアップ・パフォーマンスを競合製品と比べて25～40%向上させることができます。
• UNIXサーバー、Windowsサーバー、Linuxサーバー用のファイル・システムのデータ保護と、Network
Data Management Protocol（NDMP）経由のネットワーク接続ストレージ（NAS）の保護。
• ポリシー・ベースのきめ細かな制御。これには、バックアップの暗号化と鍵管理、テープの複製、異なる
場所の間でのテープのローテーション（ボールティング）などが含まれます。
• Oracle Secure Backup環境は、コマンドライン、Oracle Secure Backup Webツール、またはOracle
Enterprise Managerを使用して管理できます。
Exadata環境には、最新リリースであるOracle Secure Backup 10.4の次の拡張機能が最適です。
• NUMA（Non-Uniform Memory Access）環境でのパフォーマンス向上。Oracleデータベースのシャドウ・
バックアップおよびリストア・プロセスとOracle Secure Backupデータ・サービスは、プロセス間のデータ
転送のための共有メモリ領域を通して通信します。NUMAマシンでは、Oracle Secure Backup 10.4により、
最速パフォーマンスを実現するために、これらのプロセスが同じNUMA領域内で動作することが保証されま
す。
• TCP/IPの代わりにRDS/RDMA（Reliable Datagram Socket over Remote Direct Memory Access）を利用す
ることによる、InfiniBand（IB）経由のデータ転送速度の向上。これには、次の2つの重要な利点がありま
す。最初に、フロントエンドのスループットが向上するとメディア・サーバーごとに使用できるテープ・
ドライブの数が増えるため、パフォーマンス目標を達成するために必要なメディア・サーバーの数を削減
できます。 52つ目に、メディア・サーバーが複数のIBポートを使用できます。これに対して、現時点では
アダプタ・ボンディングがTCP/IP over InfiniBandをサポートしていない（RDS/RDMAのみである）ため、
TCP/IP over IBを使用している場合は1つだけです。
• ロードバランシング・ネットワーク・インタフェースによるネットワーク使用率の向上。これにより、パ
フォーマンスが向上し、いずれか1つのインタフェースの使用率が高すぎたり、低すぎたりすることがな
くなります。ホストに特定のタイプの複数のネットワーク・インタフェースが含まれている場合、Oracle
Secure Backup 10.4は、クライアント・ホストとメディア・サーバー・ホストの間のデータ接続にそのタ
イプの使用可能なすべてのインタフェースを使用します。 6
5
たとえば、RDS/RDMA over InfiniBandでのスループットが50%高い場合は、InfiniBandポートを1つ備えたメディア・
サーバーあたり2GB/秒ではなく、約3GB/秒になります。
6
Oracle Secure Backupは、RDS/RDMA、InfiniBand、IPv6、IPv4の順序でネットワーク・インタフェースのタイプを選択し
ます。
12
Oracle Database 12cによる可用性の最大化
Oracle Secure Backup Cloud Module
クラウド・ストレージ（AmazonのS3など）により、信頼性の高いオフサイト・バックアップへのアクセス
が容易になります。Oracle RMANとOracle Secure Backup Cloud Moduleを使用すると、Amazon S3に直接
バックアップを送信するか、またはローカルでバックアップしてからクラウドにコピーを送信できます。
データベースがAmazon Web Servicesのクラウド・サーバー上で実行されている場合は、Oracle Secure
Backup Cloud Moduleが理想的なデータ保護ツールになります。
Oracle Secure Backup Cloud Moduleは、サポートされているすべてのバージョンのOracle Databaseをバッ
クアップできます。 7管理者は、引き続き既存のバックアップ・ツール（Oracle Enterprise ManagerやRMAN
スクリプトなど）を使用してクラウド・バックアップを実行できます。詳しくは、OTNのOracle Secure
Backupのリソース（oracle.com/goto/osb）を参照してください。
論理的破損からのリカバリ：Oracleフラッシュバック・テクノロジー
人為的エラーは必ず発生します。Oracle Databaseのフラッシュバック・テクノロジーは、ミスの影響を選択
的かつ効率的に取り消すことで人為的エラーを無効にする、独自の豊富なデータ・リカバリ・ソリューショ
ン・セットです。フラッシュバック機能が登場する前は、データベースの損傷には数分しかかからなくても、
そのリカバリには数時間かかることがありました。フラッシュバック機能を使用した場合、エラーからのリ
カバリに必要な時間は、そのエラーが発生した後に実行された作業に依存します。リカバリ時間はデータ
ベース・サイズに依存しません。これは、データベース・サイズが引き続き増加しているために必要不可欠
になった機能であり、またOracle Databaseに固有の機能です。フラッシュバック機能は、行レベル、トラン
ザクション・レベル、表レベル、およびデータベース全体など、全レベルでのリカバリをサポートします。
フラッシュバック機能は簡単に使用でき、複雑な手順を踏まずに、1つの短いコマンドでデータベース全体をリ
カバリできます。フラッシュバック機能ではまた、きめ細かな分析や、間違った顧客注文が削除された場合など
の局部的な損傷に対する修復も提供されます。フラッシュバック機能はまた、前日のすべての顧客注文が削除さ
れた場合など、より広範囲に及ぶ損傷であっても、長期の停止時間を引き続き回避しながら修復できます。
フラッシュバック問合せ
Oracleフラッシュバック問合せを使用すれば、管理者は過去のある時点のデータを問い合わせることができ
ます。この強力な機能を使用すると、誤って削除や変更が行われた可能性のある破損したデータを表示した
り、論理的に再構築したりできます。たとえば、次のような単純な問合せがあります。
SELECT * FROM emp AS OF TIMESTAMP time WHERE…
この問合せは、指定時刻（たとえば、TO TIMESTAMP変換を通して取得されるタイムスタンプ）におけるemp表
の行を表示します。管理者は、フラッシュバック問合せを使用することにより、論理的なデータ破損を特定して
解決できます。また、この機能はアプリケーションに組み込むことができるため、ユーザーはデータベース管理
者に連絡することなく、迅速で簡単なメカニズムを使用してデータの誤変更を取り消すことができます。
7
Oracle Secure Backup Cloud Moduleは、Oracle RMANのメディア管理インタフェースを使用します。このインタフェー
スは、すべてのデータベース・バックアップおよびリカバリ操作のために、外部バックアップ・ライブラリをOracle
RMANとシームレスに統合します。
13
Oracle Database 12cによる可用性の最大化
フラッシュバック・バージョン問合せ
フラッシュバック・バージョン問合せを使用すれば、管理者は一時点ではなく、指定した時間間隔で各種
バージョンの行を取得できます。たとえば、次のような問合せがあります。
SELECT * FROM emp VERSIONS BETWEEN TIMESTAMP time1 AND time2 WHERE…
この問合せは、指定されたタイムスタンプの間の各バージョンの行（その行を操作したトランザクションを
含む）を表示します。管理者は、データがいつ、どのようにして変更されたかを正確に特定できるため、
データの修復とアプリケーションのデバッグの両方で大きな利点があります。
フラッシュバック・トランザクション問合せ
論理的破損はまた、誤ったトランザクションが複数の行または表のデータを変更した場合にも発生すること
があります。フラッシュバック・トランザクション問合せを使用すると、管理者は特定のトランザクション
によって行われたすべての変更を参照できます。たとえば、次のような問合せがあります。
SELECT * FROM FLASHBACK_TRANSACTION_QUERY WHERE XID = transactionID
この問合せは、このトランザクションによって行われた変更を表示するとともに、そのトランザクションを
取り消す（フラッシュバックする）ために必要なSQL文も生成します（このtransactionIDは、フラッシュ
バック・バージョン問合せで取得できます）。こうした精密なツールを使用することで、管理者はデータ
ベースの論理的破損を効率的に特定して解決できます。
フラッシュバック・トランザクション
多くの場合、データ障害の特定には時間がかかる上、以前の'不適切な'トランザクションが論理的に破損さ
せたデータに対して、追加の'正常な'トランザクションが処理を行っている場合があります。この状況では、
管理者は、その'不適切な'トランザクションによって行われた変更だけでなく、その同じデータにその後修
正が加えられた他の（従属）トランザクションによって行われた変更も分析して、'不適切な'トランザク
ションの取消しによってデータの元の正しい状態が保持されることを確認する必要があります。この分析は、
特に複雑なアプリケーションでは手間のかかる作業になる場合があります。
フラッシュバック・トランザクションを使用すると、管理者は1つの'不適切な'トランザクションと、オプ
ションでそのすべての従属トランザクションを1つのPL/SQL操作でフラッシュバックできます。あるいは、
管理者はOracle Enterprise Managerウィザードを使用して、必要なトランザクションを特定し、フラッシュ
バックすることもできます。
フラッシュバック・データベース
データベース全体を以前のある時点にリストアする場合、従来の方法では、RMANバックアップからデータ
ベースをリストアしてから、エラー発生前の時点にリカバリします。これには、データベースの（増え続け
る）サイズに比例した時間（数時間か、場合によっては数日）がかかります。
これに対して、Oracleで最適化されたフラッシュバック・ログを使用するフラッシュバック・データベース
では、データベース全体を特定の時点に迅速にリストアできます。フラッシュバック・データベースが高速
なのは、変更されたブロックのみをリストアするためです。フラッシュバック・データベースでは、次のよ
うな簡単なコマンドを使用して、データベース全体を数分でリストアできます。
14
Oracle Database 12cによる可用性の最大化
FLASHBACK DATABASE TO TIMESTAMP time
複雑なリカバリ手順は必要なく、バックアップをリストアする必要もありません。フラッシュバック・データ
ベースにより、データベースのポイント・イン・タイム・リカバリに必要な停止時間が大幅に削減されます。ま
た、Data Guardのスナップショット・スタンバイやフェイルオーバーの後の以前のプライマリの復旧をサポート
するために、フラッシュバック・データベースはData Guardとも統合されます（「Data Guard」の項も参照）。
フラッシュバック表
論理的破損が1つの表または表のセットに制限される場合、管理者はフラッシュバック表を使用して、影響
を受けた表を特定の時点に容易にリカバリできます。次のような問合せがあります。
FLASHBACK TABLE orders, order_items TIMESTAMP time
この問合せは、指定時刻の後に行われたorders表とorder_items表への更新をすべて取り消します。
フラッシュバック・ドロップ
従来、誤って削除された表を元に戻すには、関連するすべての表属性のリストア、リカバリ、エクスポート
/インポート、および再作成が必要でした。フラッシュバック・ドロップを使用すると、FLASHBACK TABLE
<table> TO BEFORE DROP文を使用して、削除された表を容易にリカバリできます。これにより、削除され
た表とそのすべての索引、制約、およびトリガーがごみ箱（削除されたオブジェクトのための論理コンテナ）
からリストアされます。
詳しくは、OTNのフラッシュバックのリソース（oracle.com/goto/flashback）を参照してください。
リアルタイムのデータ保護および可用性 - Oracle Data Guard
企業は、クラスタまたはデータセンター全体をオフラインにする可能性のあるイベントから、重要なデータとア
プリケーションを保護する必要があります。人為的エラー、データ破損、またはストレージ障害のために、クラ
スタが使用できなくなる場合があります。自然災害、停電、および通信障害が、サイト全体の可用性に影響を与
える場合があります。Oracle Databaseは、クラスタまたはサイト障害によるコストのかかる停止時間から企業を
保護できる、さまざまなデータ保護ソリューションを提供します。HA戦略全体の基盤を成しているのは、頻繁
に更新および検証されるローカル・バックアップとリモート・バックアップです。ただし、マルチテラバイトの
バックアップの完全なリストアは、企業が共用できる時間よりも時間がかかる場合があり、またバックアップに
最新バージョンのデータが含まれていない可能性もあります。これらの理由から、企業は多くの場合、本番デー
タベースの1つ以上の同期レプリカを別のデータセンターに保持しています。オラクルは、この目的に使用でき
るソリューションをいくつか提供しています。Oracle Data GuardおよびActive Data Guardは、Oracleデータを保
護するように最適化されているため、高可用性とディザスタ・リカバリの両方が提供されます。
Data Guardは、ミッション・クリティカルなOracle Databaseのシングル・ポイント障害を解消するための包
括的なソリューションです。これは、本番データベース（プライマリ）の同期された物理レプリカ（スタン
バイ）を維持することによって、データ損失と停止時間を簡単かつ経済的に防止します。プライマリ・デー
タベースが使用できない場合、管理者は、スタンバイ・データベースへの手動または自動どちらかのフェイ
ルオーバーを選択できます。クライアント接続をスタンバイに迅速かつ自動的にフェイルオーバーし、サー
ビスを再開できます。
15
Oracle Database 12cによる可用性の最大化
Data Guardは、Oracle Databaseとの緊密な統合、強力な障害分離、およびOracleが認識するデータ検証を通
して、もっとも高いレベルのデータ保護を実現します。プライマリ・データベースに影響を与えるシステム
やソフトウェアの欠陥、データ破損、管理者のエラーなどは、スタンバイにはミラー化されません。
Data Guardでは、非同期（ほぼデータ損失ゼロ）または同期（データ損失ゼロ）のどちらかの保護を選択でき
ます。非同期構成は導入が容易であり、プライマリ・データベースとスタンバイ・データベースの間の距離に
関係なく、プライマリのパフォーマンスには影響を与えません。ただし、同期トランスポートはパフォーマン
スに影響を与えるため、プライマリ・データベースとスタンバイ・データベースの間の距離が実質的に制限さ
れます。パフォーマンスに影響を与えるのは、現在のトランザクションへの変更が保護されたことをスタンバ
イが確認するまで、プライマリ・データベースが次のトランザクションに進まないためです。確認応答の待機
に費やされる時間はプライマリとスタンバイの間の距離が長いほど増加するため、アプリケーションの応答時
間やスループットに直接影響を与えます。Fast SyncおよびActive Data Guard Far Syncは、この制限に対処する
ためのOracle Database 12cの2つの新機能です（Far Syncについては、「Active Data Guard」の項を参照）。
Fast Sync
Fast Syncは、データ損失ゼロの同期構成でパフォーマンスを向上させるための簡単な方法を提供します。
Fast Syncを使用すると、スタンバイはスタンバイREDOログ・ファイルへのディスクI/Oを待たなくても、
REDOをメモリ内に受信したらすぐにプライマリ・データベースを確認できます。これにより、プライマリ
とスタンバイの間の合計のラウンドトリップ時間が短縮されるため、プライマリ・データベースのパフォー
マンスへの同期トランスポートの影響が軽減されます。Fast Syncは、Data Guardに含まれています。
いかなる距離でもデータ損失ゼロ：Active Data Guard
Active Data Guardを使用すると、障害から保護しながら、読取り専用のレポート作成アプリケーション、非
定型問合せ、データ抽出などを最新のフィジカル・スタンバイ・データベースにオフロードできるようにな
ります。Active Data Guardは、最高のパフォーマンスを得るために固有の同時実行性の高い適用プロセスに
依存する一方で、プライマリ・データベースで実施されるのと同様に、スタンバイでも、読取り一貫性モデ
ルを読取り専用アクセスで実施します。これを実行する物理または論理レプリケーション・ソリューション
は他にありません。これは、アイドル状態の冗長性のコストを削除しながら、読取り専用ワークロードをア
クティブ・スタンバイにオフロードするうえで魅力的です。
グローバル一時表への書込みや一意のシーケンスへのアクセスという要件を除き、読取り専用データベース
を使用することが望ましいレポート作成アプリケーションも多く存在します。Active Data Guardには、アク
ティブ・スタンバイでのグローバル一時表への書込みや一意のシーケンスへのアクセスを可能にするための
Oracle Database 12cの新機能が含まれています。これにより、プライマリ・データベースからオフロードで
きるレポート作成アプリケーションの数がさらに増えます。これらのすべての機能を提供できる物理または
論理レプリケーション・ソリューションは他にありません。Active Data Guardに比べると、1つ以上の領域
に1つずつの代替ソリューションでは不十分です。Active Data Guardは、Oracle Database Enterprise Edition
のオプションです。
16
Oracle Database 12cによる可用性の最大化
Active Data Guard Far Sync：いかなる距離でもデータ損失ゼロ
Active Data Guard Far Syncは、Oracle Database 12cの新機能であり、プライマリ・ロケーションからの距離を
問わず、同期されたスタンバイ・データベースを維持することにより、データベース・パフォーマンスに影響
を与えることなく、コストや複雑さを最小限に抑えて、本番データベースでのデータ損失ゼロの保護を実現し
ます。Far Syncインスタンス（新しいタイプのData Guard宛先）は、プライマリ・データベースから変更を同
期的に受信し、それをリモート・スタンバイに非同期的に転送します。本番環境を、データ損失をゼロに保ち
ながら、手動または自動でリモート・スタンバイ・データベースに迅速にフェイルオーバーできます。
Far Syncインスタンスは、制御ファイルとログ・ファイルのみを管理する軽量エンティティです。これには、
スタンバイ・データベースのCPU、メモリ、I/Oリソースのごく一部が必要になります。ユーザーのデータ
ファイルを保管することはなく、リカバリを実行することもありません。その唯一の目的は、プライマリ・
データベースをリモート宛先へのサービス提供から透過的に解放することです。Far Syncインスタンスは、
Oracle Advanced Compressionオプションを使用して転送の圧縮を実行することにより、ネットワーク帯域
幅を節約できます。
図2： Active Data Guard Far Sync - いかなる距離でもデータ損失ゼロの保護
ニューヨークにプライマリがあり、ロンドンにスタンバイがある非同期のData Guard構成について考えます。
データ損失ゼロへのアップグレードは、Active Data Guardを使用して、ニューヨークの同期レプリケーショ
ンの距離（240km未満）以内にFar Syncインスタンスをデプロイするだけです。既存の環境が中断されるこ
とはなく、独自仕様のストレージ、特殊なネットワーク、データベース・ライセンスの追加、複雑な管理な
ども一切必要ありません。
OTNのData GuardおよびActive Data Guardのリソース（oracle.com/goto/dataguard）も参照してください。
17
Oracle Database 12cによる可用性の最大化
Active Data Guardの自動ブロック修復
ブロックレベルのデータ損失は通常、断続的なI/Oエラーのほか、ディスクに書き込まれるメモリ破損に
よって発生します。Oracle Databaseはブロックを読み取って破損を検出すると、そのブロックを破損として
マークし、アプリケーションにエラーを報告します。Active Data Guardを使用していない限り、そのブロッ
クが手動でリカバリされるまで、そのブロックのそれ以降の読取りは成功しません。Active Data Guardでは、
ブロック・メディア・リカバリが自動的かつ透過的に実行されます。Active Data Guardは、プライマリ・
データベース上の物理的破損を、スタンバイから取得された正常なバージョンのブロックを使用して修復し
ます。逆に、スタンバイ・データベース上で検出された破損ブロックは、プライマリ・データベースの正常
なバージョンを使用して自動的に修復されます。
アクティブ/アクティブHAおよび停止時間なしのアップグレード：
Oracle GoldenGate
Data Guardの物理レプリケーションは、特定の目的、つまり最適なデータ保護と可用性のための単純で、透
過的な、一方向の物理レプリケーションに対して最適化されます。これに対して、Oracle GoldenGateは機
能の豊富な論理レプリケーション製品であり、マルチマスター・レプリケーション、ハブ・アンド・スポー
ク・デプロイメント、サブセット・レプリケーション、およびデータ変換をサポートすることによって、顧
客にレプリケーション要件に完全に対処するための柔軟なオプションを提供する高度な機能を備えています。
Oracle GoldenGateはまた、Oracleの範囲を超えた、幅広い異機種ハードウェア・プラットフォームおよび
データベース管理システム間のレプリケーションもサポートしています。
図3： Oracle GoldenGate - アクティブ/アクティブの双方向レプリケーション
アプリケーションは、最小限の変更または特殊な処理でOracle GoldenGateを使用できます。Oracle GoldenGate
は、たとえば、データベース全体、一連のスキーマ、または個々の表の変更を取得するように構成できます。
Oracle GoldenGateテクノロジーを使用するデータベースを異機種（たとえば、Oracle、DB2、SQL Serverな
どの混在）にすることができます。これらのデータベースは、さまざまなプラットフォーム（Linux、Solaris、
Windowsなど）でホストできます。また、参加しているデータベースは、Oracle GoldenGateを使用して
データを適切な形式に変換することによって、異なるデータ構造を維持することもできます。これらのすべ
ての機能により、大企業はOracle GoldenGateをレプリケーション・テクノロジーの単一の標準にすること
で、そのIT環境を簡素化できるようになります。
18
Oracle Database 12cによる可用性の最大化
アクティブ/アクティブHA
Oracle GoldenGateのアクティブ/アクティブ構成では、ソース・データベースと宛先データベースの両方を
読取り/書込みに使用できるため、参加しているすべてのデータベースにわたってすべてのワークロードを
分散できる分散構成が実現されます。これによって、個々のサイトで障害が発生した場合に高可用性とデー
タ保護が提供されます。また、停止時間ゼロの保守を実行するための優れた方法も提供されます。それには、
あるレプリカに変更を実装し、それを以前のバージョンで動作しているソース・データベースと同期した後、
停止時間ゼロのユーザーを新しいバージョンで動作しているレプリカに徐々に移行します。
Oracle GoldenGateのアクティブ/アクティブ構成内のユーザーは同じ表の異なるコピーをどこからでも更新で
きるため、異なるデータベース内の同じデータ要素に対して変更が同時に行われることによって更新の競合が
発生する可能性があります。Oracle GoldenGateは、競合を回避、検出、および解決するためのさまざまなオプ
ションを提供しています。これらのオプションは、データの値とフィルタに基づいて、またはデータベース・
エラー・メッセージなどのイベント駆動型条件を通して、オブジェクト単位でグローバルに実装できます。詳
しくは、OTNのOracle GoldenGateのリソース（oracle.com/goto/goldengate）を参照してください。
サイト全体のフェイルオーバー：Oracle Site Guard
Oracle Site GuardはOracle Enterprise Manager Cloud Control 12cの一部であり、ディザスタ・リカバリの自
動化をOracleスタックの残りの部分にまで拡張します。Oracle Site Guardを使用すると、管理者はサイト全
体のフェイルオーバーを自動化できます。Oracle Site Guardは、複雑なフェイルオーバー操作を手動で実行
する負担からITスタッフを解放することによって、停止時間の延長やデータ損失につながる場合がある人為
的エラーの可能性を低減することで、特殊なスキル・セットの必要性をなくします。Oracle Site Guardは、
Oracle Fusion Middleware、Oracle Databaseの調整されたフェイルオーバーをオーケストレーションするだ
けでなく、その他のデータセンター・コンポーネントを含むように拡張できます。Oracle Site Guardは、プ
ライマリ環境とスタンバイ環境を同期し、ミッション・クリティカルなデータを保護する基盤のレプリケー
ション・メカニズム（Oracleデータの場合はOracle Data Guard、Databaseの外部にあるファイル・システ
ム・データの場合はストレージ・レプリケーション）と統合します。
計画停止時間への対応
計画停止時間は通常、管理者にシステムやアプリケーションの保守を実行するための時間枠を提供するよう
にスケジュールされます。これらの保守時間枠の間に、管理者はバックアップの作成、ハードウェア・コン
ポーネントの修復または追加、ソフトウェア・パッケージのアップグレードまたはパッチ適用、およびデー
タ、コード、データベース構造などのアプリケーション・コンポーネントの変更を行います。オラクルは、
これらのシステム・アクティビティや保守活動を実行しながら、計画停止時間を最小化または排除する必要
性を認識してきました。Oracle Database 12cを使用すると、本番バージョンのデータベースに対してオンラ
インで、または本番データベースの同期されたコピーを使用してローリング方式で、あるいはあるバージョ
ンから次のバージョンに停止時間ゼロで移行するために本番データベースの2つのコピー間の双方向レプリ
ケーションを使用して計画保守を実行できます。以降の項では、これらの機能について説明します。
19
Oracle Database 12cによる可用性の最大化
オンライン・システム再構成
オラクルは、Oracleハードウェア・スタックのすべてのコンポーネントに対する動的なオンライン・システ
ム再構成をサポートしています。オラクルのAutomatic Storage Management（ASM）には、ASMディスク
のオンラインでの追加または削除を可能にする組込み機能があります。ASMディスク・グループにディスク
が追加または削除されると、ストレージ、データベース、およびアプリケーションはオンラインのまま、
Oracleは新しいストレージ構成全体のデータを自動的にリバランシングします。Oracle Real Application
Clusters（Oracle RAC）は、優れたオンライン再構成機能を提供します。管理者は、データベースやアプリ
ケーションを中断することなく、クラスタ化されたノードを動的に追加したり、削除したりできます。オラ
クルはまた、このオンライン機能を備えたSMPサーバー上でのCPUの動的な追加または削除もサポートして
います。最後に、オラクルの動的な共有メモリ・チューニング機能により、管理者は共有メモリやデータ
ベース・キャッシュをオンラインで拡大したり、縮小したりできます。自動メモリ・チューニング機能を使
用すると、管理者はオラクルのメモリ使用特性の分析に従って、共有メモリのサイズ設定や分散をOracleで
自動的に実行させることができます。オラクルの広範囲にわたるオンライン再構成機能は、保守活動による
システム停止時間を最小限に抑えるだけでなく、企業でも必要に応じて容量を拡張できるようにする管理者
の能力をサポートします。
オンラインでのデータおよびアプリケーションの変更
オンラインでのデータやスキーマの再編成では、ユーザーが再編成プロセス全体を通してデータベースに完
全にアクセスできるようにすることで、全体的なデータベースの可用性を向上させ、計画停止時間を短縮し
ます。たとえば、デフォルト値を持つ列を追加しても、データベースの可用性やパフォーマンスには影響を
与えません。多くのデータ定義言語（DDL）保守操作では、管理者がロック待機のタイムアウトを指定でき
るため、保守操作やスキーマ・アップグレードの実行中に高可用性環境を維持できます。また、索引は
INVISIBLE属性で作成できるため、DML操作によって引き続き維持されている場合でも、コストベース・オプ
ティマイザ（CBO）はそれらの索引を無視します。索引が本番環境で使用できる状態になったら、簡単な
ALTER INDEX文を使用して、索引をCBOから認識できるようにします。
オンラインでのデータファイル移動およびオンラインでのパーティション移動
Oracle Database 12cには、ユーザーがALTER DATABASE MOVE DATAFILEコマンドを使用してデータにアク
セスしている最中にそのデータファイルを移動する機能があります。この機能により、保守操作中でもデー
タ可用性が維持されます。この機能は、アクセス頻度の低いデータファイルをより低コストのストレージに
移動する場合に役立ちます。別の使用例として、ASM以外のストレージからASMストレージへのデータベー
スの移動があります。
Oracle Database 12cの新機能であるオンラインでのパーティション移動により、オンラインでの圧縮が容易
になります。1つのセッション内のオンラインでのマルチパーティション再定義がサポートされます。
20
Oracle Database 12cによる可用性の最大化
オンライン表再定義
ビジネス要件が進化するにつれ、ビジネスをサポートするアプリケーションとデータベースも進化します。
DBMS_REDEFINITIONパッケージ（Oracle Enterprise Managerでも使用可能）を戦略的に使用すれば、管理者は
オンラインの本番システムのサポートを継続しつつ表構造の変更が可能なため、データベース保守での停止時
間を短縮できます。管理者がこのAPIを使用すると、保守プロセスによって表の暫定コピーが変更されている間、
エンドユーザーは元の表にアクセスできます（挿入、更新、削除などの操作を含む）。仮表は、元の表と定期
的に同期されます。保守手順が完了すると、管理者は最後の同期を実行し、新しく構造化された表をアクティ
ブ化します。Oracle Database 12cのオンライン表再定義の拡張機能には、次のようなものがあります。
• start_redef_tableの新しいパラメータcopy_vpd_optを使用した、VPDポリシーによる表のオンライン再定義。
• 新しいREDEF_TABLE手順による単一コマンドでの再定義。
• sync_interim_tableパフォーマンスの向上、より適切なロック管理によるfinish_redef_tableのリジリエン
スの向上、パーティション・レベルのロックのみによるパーティション再定義での可用性の向上、および
指定されたパーティションのみに対する変更のログ記録によるパフォーマンスの向上。
オンライン・アプリケーション・アップグレード：エディションベースの再定義
Oracle Databaseのエディションベースの再定義機能を使用すると、アプリケーションの可用性を損なうこと
なく、アプリケーションをオンラインでアップグレードできます。アップグレードのインストールが完了す
ると、アップグレード前のアプリケーションとアップグレード後のアプリケーションを同時に使用できます。
つまり、既存のセッションは、ユーザーが終了するまでアップグレード前のアプリケーションを引き続き使
用できます。それに対して、新しいセッションはすべて、アップグレード後のアプリケーションを使用しま
す。アップグレード前のアプリケーションを使用しているすべてのセッションが終了したら、古いエディ
ションを廃止できます。そのため、アプリケーションが全体として、アップグレード前のバージョンから
アップグレード後のバージョンへのホット・ロールオーバーを実現していることになります。エディション
ベースの再定義では、次のスコープ（エディション）が導入されます。
• コード変更は、新しいエディションに内部的にインストールされます。
• データ変更は、古いエディションからは見えない新しい列または新しい表にのみ書き込むことによって安
全に実行されます。エディショニング・ビューは、各エディションに表の異なる射影を公開して、各エ
ディションには独自の列のみ表示します。
• クロスエディション・トリガーは、古いエディションによって行われたデータ変更を新しいエディション
の列に、または（ホット・ロールオーバーでは）その逆方向に伝播します。
ホット・パッチ
OPatchと統合されたオンライン・パッチを使用すると、Oracleインスタンスを停止することなく、そのイン
スタンス内のプロセスにパッチを適用できます。そのインスタンスに関連した各プロセスは、安全な実行ポ
イントでパッチ・コードを確認した後、そのコードを自身のプロセス領域にコピーします。
21
Oracle Database 12cによる可用性の最大化
Oracle RACを使用したローリング・パッチ・アップグレード
オラクルは、パッチ適用プロセス全体を通してデータベースを使用可能な状態に維持したまま、Real Application
Clusters（Oracle RAC）システムのノードにローリング方式でパッチを適用する方法をサポートしています。
ローリング・アップグレードを実行するには、いずれかのインスタンスが静止されてパッチが適用される間、
サーバー・プール内のその他のインスタンスは引き続きサービスを提供します。すべてのインスタンスにパッチ
が適用されるまで、このプロセスが繰り返されます。ローリング・アップグレードの方法は、Patch Set Update
（PSU）、Critical Patch Update（CPU）、OPATCHを使用した1回限りのデータベース・パッチや診断パッチ、オ
ペレーティング・システム・アップグレード、およびハードウェア・アップグレードに使用できます。
Data Guard Standby-First Patch Assurance
Data Guard Standby-First Patch Assurance（Oracle Database 11.2.0.1以降）を使用すると、Oracleパッチを
ローリング方式で適用および検証する目的のために、フィジカル・スタンバイがプライマリ・データベース
とスタンバイ・データベースの間で異なるソフトウェア・パッチ・レベルをサポートできます。 8対象とな
るパッチには、次のようなものがあります。
• Patch Set Update、Critical Patch Update、Patch Set Exception、Oracle Databaseバンドル・パッチ、およ
びフル・リリースへのアップグレード。
• Oracle Exadata Database Machineバンドル・パッチ、Oracle Exadata Storage Serverソフトウェア・パッチ。
Data Guardを使用したデータベース・ローリング・アップグレード
一時ロジカル・データベースのローリング・アップグレード・プロセスでは、Data Guardのフィジカル・ス
タンバイ・データベースを使用して、完全なOracle Databaseパッチセット（Oracle 11.2.0.1から11.2.0.3に）
またはメジャー・リリース（Oracle 11.2から12.1に）をインストールするか、あるいはデータベースの論理
構造を変更するその他のタイプの保守を実行します。このプロセスは、プライマリ・データベースとフィジ
カル・スタンバイ・データベースで始まります。古いバージョンと新しいバージョンの間で同期するために
一時的にData Guardの論理レプリケーション（SQL Apply）が使用される場合を除き、スタンバイが通常ど
おりに最初にアップグレードされます。REDO Applyとは異なり、論理レプリケーションではSQLを使用して
バージョン間のレプリケーションを行うため、異なるOracleリリース間に存在する可能性のあるREDOの物
理構造の違いによる影響を受けません。
元のプライマリのアップグレードと再同期が完了すると、スイッチオーバーによって本番環境がスタンバ
イ・データベース上の新しいバージョンに移行されます。元のプライマリは次に、アップグレード・プロセ
スが開始された時点にフラッシュバックされ、新しいプライマリのフィジカル・スタンバイに変換されます。
フィジカル・スタンバイは新しいOracleホームにマウントされ、新しいプライマリによって生成されたREDO
を使用してアップグレードおよび再同期されます（2つ目のカタログのアップグレードは必要ありません）。
8
Standby-First Patch Applyの対象となるパッチについて詳しくは、MOS Note 1265700.1を参照してください。
22
Oracle Database 12cによる可用性の最大化
Active Data Guardを使用したデータベース・ローリング・アップグレード
上述のデータベースのローリング・アップグレード・プロセスは、計画停止時間の短縮に非常に効果的です
が、多くのステップを含む手動の手順であるため、エラーが発生しやすくなります。これにより、ローリン
グ・アップグレード・プロセスの使用に対する抵抗が生まれ、ユーザーは従来のアップグレード方法に関連
した長い停止時間を受け入れることになります。また、従来のアップグレード方法では、結果が確実になる
前に本番データベースに対して保守が実行されるため、リスクも増します。
Oracle Database 12cの新機能であるActive Data Guardを使用したデータベース・ローリング・アップグレード
では、ローリング・データベース・アップグレードを実行するために必要な40を超える手動の手順を、このプ
ロセスの多くを自動化する3つのPL/SQLパッケージに置き換えることによってこの問題を解決します。この自
動化は、ユーザーを新しいバージョンに移行する前に本番環境の完全なレプリカに対してすべての変更を実装
し、徹底的に検証することによって、計画停止時間を最小限に抑え、かつリスクを軽減するのに役立ちます。
データベース・バージョンのアップグレードに対するこの機能は、Oracle Database 12cの最初のパッチセッ
トから使用できます。 9また、Oracle Database 12cでのその他のデータベース保守タスクで使用できます。 10
プラットフォームの移行、システムの保守、データセンターの移転
Data Guardではまた、プライマリ・データベースとスタンバイ・データベースが異なるオペレーティング・
システムやハードウェア・アーキテクチャを使用するシステム上で動作するためのある程度の柔軟性がある
ため、停止時間を最小限に抑えてプラットフォームを移行する非常に簡単な方法が提供されます。 11また、
Data Guardを使用すると、停止時間とリスクを最小限に抑えてASMに容易に移行したり、シングル・インス
タンスのOracle DatabaseからOracle RACに移行したり、データセンターを移転したりすることもできます。
Oracle GoldenGateにより、停止時間をゼロまたは最小限に抑えて異機種プラットフォーム間でプラット
フォームを移行するためのもっとも高い柔軟性が得られます。
9
Oracle Database 11gからOracle Database12cに、またはOracle Database 12.1からOracle Database 12.1の最初のパッチ
セットにアップグレードする場合、引き続き一時ロジカル・スタンバイ・アップグレードを使用する必要があります。
10
保守タスクには、パーティション化されていない表のパーティション化、BasicFiles LOBのSecureFiles LOBへの変更、
CLOBストレージXMLTypeのバイナリXMLストレージへの移動、表のOLTPでの圧縮への変更などがあります。
11
Data Guard構成でサポートされているプラットフォームの組合せについて詳しくは、MOS Note 413484.1を参照してく
ださい。
23
Oracle Database 12cによる可用性の最大化
Oracle GoldenGateを使用した停止時間ゼロの保守
Oracle GoldenGateは、計画停止時間を短縮または解消するためのもっとも柔軟な方法です。その異機種レ
プリケーションは、ほぼすべてのプラットフォーム移行、テクノロジー更新、データベース・アップグレー
ドのほか、バックエンド・データベース・オブジェクトを変更する多くのアプリケーション・アップグレー
ドを、停止時間をゼロまたは最小限に抑えてサポートできます。Oracle GoldenGateの論理レプリケーショ
ンは、データベースを異なるプラットフォーム上に、バージョンが同期された状態で保持できます。これに
より、変更を本番環境のコピーに実装してから、古いバージョンと同期することができます。検証が完了す
ると、ユーザーは新しいバージョンで実行されているコピー、または新しいプラットフォーム上のコピーに
切り替えられます。Oracle GoldenGateの一方向のレプリケーションでは、すべてのユーザーが古いバー
ジョンから切断されてから新しいバージョンに再接続されるまで、ある程度の停止時間が必要になります。
競合解消機能を使用したOracle GoldenGateの双方向レプリケーションでは、ユーザーを古いバージョンか
ら停止時間ゼロで段階的に移行できます。
Oracle Database高可用性ソリューションの管理
Oracle Enterprise Manager Cloud Control 12cは、Oracle環境のための管理インタフェースです。Oracle
Cloud Controlは、Oracleテクノロジーを実行するシステムや、Oracle以外のテクノロジーを実行するシステ
ムを含むOracle ITインフラストラクチャ全体に一元管理機能を提供します。Oracle Cloud Controlは、幅広い
一連の管理、構成管理、プロビジョニング、エンド・ツー・エンド監視、およびセキュリティ機能を備えて
いるため、複雑な環境を管理するためのコストと複雑さが低減される一方、顧客がITインフラストラクチャ
の必要なサービス・レベルを維持するのに役立ちます。
Oracle Enterprise Manager Cloud Control 12cには、次のような重要なHA機能が含まれています。
• さまざまなHA領域（クラスタリング、バックアップとリカバリ、レプリケーション、ディザスタ・リカ
バリなど）の監視を統合し、HA全体の構成ステータスを表示し、さらに適切な操作を開始するための高
可用性コンソールを提供します。
• Maximum Availability ArchitectureのConfiguration Advisorページでは、構成を評価し、サーバー、サイト、
ストレージ、人為的、データ破損などの障害から保護するためのソリューションを特定できるため、ワー
クフローにオラクルが推奨するソリューションを実装できます。
• データベースのASMへの移行や、シングル・インスタンス・データベースのOracle RACへの変換を最小限
の停止時間で実行できるようにすることによって、MAAのさらなる自動化を可能にします。
• Oracle Secure Backup管理サーバーの管理や、Oracle Secure Backupファイル・システムのバックアップ/
リストアおよびレポート作成をサポートします。
24
Oracle Database 12cによる可用性の最大化
グローバル・データ・サービス
多くの顧客が読取り専用ワークロードや、ほぼ読取り専用のワークロードをActive Data Guardのスタンバ
イ・レプリカにオフロードしており、Oracle GoldenGateレプリケーションでもまた、複数のデータベース
間でのるワークロードの分散（データセンター内とデータセンター間の両方）が可能になっています。マル
チ・データセンター・アーキテクチャでは、動的で、透過的な、さらに自動化されたロードバランシングと
高可用性を実装して運用することが困難です。Oracle Database 12cの新機能であるグローバル・データ・
サービス（GDS）はこれらの課題に、データベース・サービスというなじみのある概念を近く、または遠く
の場所にある複数のデータベース・インスタンスにまたがるように拡張することによって対処します。GDS
は、RACのようなフェイルオーバー、サービス管理、およびサービスのロードバランシングをレプリケート
されたデータベース構成にまで拡張します（図4を参照）。GDSは、レプリケーションに対応したアプリ
ケーションを対象にしています。
グローバル・データ・サービス（GDS）の利点には、次のようなものがあります。
• ローカル・データベースとグローバル・データベースにまたがるサービス・フェイルオーバーのサポート
による可用性の向上。
• 複数のデータベース間のロードバランシングの提供によるスケーラビリティの向上。
• グローバル・リソースの一元管理による管理性の向上。
図4： データセンター間のフェイルオーバーとロードバランシングのためのグローバル・データ・サービス
25
Oracle Database 12cによる可用性の最大化
GDSは、レプリケートされたデータベース間での領域間および領域内のロードバランシングを提供します。
たとえば、スタンバイ・インスタンスで構成された読取りファームにまたがって負荷を分散することができ、
また条件を満たせば、読取りトラフィックをプライマリに送信することさえ可能です。既存のOracle
Databaseに加えて、GDSには、1つ以上のグローバル・サービス・マネージャ（GSM）とGDSカタログ・
データベースが必要です。各領域には、独自のGSM（およびHAのためのレプリカ）があります。このGSM
は、データベースの負荷と可用性を監視し、ワークロードを適切に転送する特殊なソフトウェアを備えた
サーバーです。アプリケーション・レイヤー（データベース・サービスを使用しているクライアント）には、
GSMはリスナーのように見えます。GDSカタログは、GDSの動作に必要なメタデータを、Oracle RMANカタ
ログのバックアップ・メタデータのホスティングと同様の方法でホストするデータベースです（GDSフレー
ムワーク全体で1つですが、HAのためにレプリケートされます）。GSMとGDSカタログは、Oracle Database
12cの新しいGDS機能と連携して機能します。
GDSでは、Data Guardが引き続きロール移行を実行しますが、GDSはそれを認識し、必要に応じて負荷を転
送します。Active Data Guardでは、GDSは次の機能をサポートします。
• ローカル・データセンターおよびリモート・データセンター内のレプリケートされたデータベースにまた
がるサービス・フェイルオーバーとロードバランシング。
• Data Guardのロール移行時の自動的なロールベースのサービス。
• 読取りファームのロードバランシング。
Oracle GoldenGateでは、GDSは、ローカル・データセンターおよびリモート・データセンターのフェイル
オーバーとロードバランシングをサポートします。Active Data GuardおよびOracle GoldenGateによって本
番ワークロードのレプリケーション資産へのオフロードが可能になると、GDSによりレプリカの使用率が改
善されるため、パフォーマンス、スケーラビリティ、および可用性が向上します。
26
Oracle Database 12cによる可用性の最大化
結論
成功した企業は、重要なデータや情報システムを保護するために、高可用性テクノロジー・インフラストラ
クチャを導入して運用しています。多くのミッション・クリティカルな情報システムの中心となっているの
は、ITインフラストラクチャの可用性、セキュリティ、信頼性を管理するOracleデータベースです。数十年
にわたる技術革新を経て誕生したOracle Database 12cは、計画保守活動を行う場合と予期しない障害が発生
した場合の両方でのデータとアプリケーションの可用性を最大化するために、その世界レベルの可用性およ
びデータ保護ソリューションを引き続き改善しています。
オラクルのMAAベスト・プラクティスにより、それぞれの要件および制約条件に見合ったリソースやテクノ
ロジーを導入することによって、顧客は高可用性の目標を達成できます。これらのベスト・プラクティスを
使用すると、顧客は、さまざまなプラットフォームやデプロイメントでHAを達成できます。MAAは、水平
方向のスケーラビリティによって可用性とパフォーマンスが向上する、低コストの汎用サーバー上のデータ
ベース・デプロイメントに適用されます。MAAはまた、ハイエンドのストレージ・サーバーや汎用サーバー
にも適用されます。最後に重要なこととして、オラクルのエンジニアド・システムは、MAAに従って最初か
ら構築されています。最大の可用性とともに卓越したパフォーマンスを求める顧客は、そのデータベース中
心のITインフラストラクチャの中核としてOracle Exadata Database Machineを導入します。オラクルのMAA
ベスト・プラクティスの基盤となるITインフラストラクチャとデータベース・テクノロジーに対する同じ深
い理解が、数千のグローバルでミッション・クリティカルなデプロイメントにおける実証済みの成功ととも
に、Oracle Exadata Database Machineの基盤にもなっています。
オラクルのHAソリューションは幅広い顧客に採用されており、今日のビジネスに必要な24時間365日のアッ
プタイム要件をサポートするデータベース・テクノロジーを選択する場合の、引き続き重要な差別化要因に
なっています。oracle.com/goto/availabilityを参照して、世界中のさまざまな業界にわたるOracle HAの顧客
の成功事例を確認してください。
27
Oracle Database 12cによる可用性の最大化
付録： Oracle Database 12cの新しい高可用性機能
機能
ページ
Oracle Database 12cの新機能または拡張機能の説明
アプリケーション継続性
6
インスタンス、サーバー、ストレージ、ネットワーク、またはその他の任意の関連コンポーネントによ
るデータベース・セッション障害からアプリケーションを保護します。アプリケーション継続性は、影
響を受けた"実行中"のリクエストを再生して、RACノードの障害がアプリケーションにとっては短時間
の実行遅延に見えるようにします。
Oracle Flex ASM
7
ノード間のストレージ・フェイルオーバーを有効にし、ASM関連のリソース消費を最大60%削減するこ
とによって、データベース（インスタンス）の可用性を向上させ、クラスタベースのデータベース統合
を容易にします。
ASMディスク・スクラビング
7
通常のディスク・グループと高レベルの冗長ディスク・グループの両方にある論理的破損をチェック
し、それを自動的に修復します。これは、バックアップやリカバリ中にOracle RMANが実行するヘル
ス・チェックを補完するものです。
Data Guard Fast Sync
15
スタンバイは、スタンバイREDOログ・ファイルへのディスクI/Oを待たなくても、REDOをメモリ内に
受信したらすぐにプライマリ・データベースを確認できます。
Data Guard Far Sync
15
プライマリ・サイトからどれだけ離れた場所であっても同期されたスタンバイ・データベースを維持す
ることにより、コストや複雑さを最小限に抑えて、本番データベースでのデータ損失ゼロの保護を実現
します。
22
データベース・サービスを近く、または遠くの場所にある複数のデータベース・インスタンスにまたが
るように拡張します。GDSは、RACのようなフェイルオーバー、サービス管理、およびサービスのロー
ドバランシングをレプリケートされたデータベース構成にまで拡張します。GDSは、レプリケーション
に対応したアプリケーションを対象にしています。
Oracle Secure Backup
11
NUMA（Non-Uniform Memory Access）環境でのパフォーマンス向上。TCP/IPの代わりにRDS/RDMA
を利用することによる、InfiniBand（IB）経由のデータ転送速度の向上。ロードバランシング・ネット
ワーク・インタフェースによるネットワーク使用率の向上。
Oracle RMANおよびマルチテナ
ント・アーキテクチャ
9
BACKUP DATABASEコマンドとRESTORE DATABASEコマンドは現在、そのすべてのプラガブル・
データベース（PDB）を含むマルチテナント・コンテナ・データベース（CDB）をバックアップおよび
リストアします。また、キーワードPLUGGABLEを使用して、個々のPDB（全体バックアップおよびリ
ストアを含む）にRMANコマンドを適用することもできます。
クロス・プラットフォーム
9
表領域やデータベースの効率的な移行のための、異なるプラットフォーム間でのRMANバックアップお
よびリストア。
9
バックアップから個々のデータベース表の最新バージョンまたは古いバージョンをリカバリできます。
表はインプレースで、または別の表領域にリカバリできます。イメージ・コピーのマルチセクション・
バックアップおよび増分バックアップ。コマンドを使用した、スタンバイ・データベースとプライマ
リ・データベースとの迅速な同期。RMANコマンドラインでのSQL文の直接サポート。SQLキーワード
は必要ありません。
19
オンラインでのデータ移動機能を使用すると、ユーザーがデータにアクセスしている最中にそのデータ
ファイルを移動できます。
グローバル・データ・サービス
（GDS）
Oracle Recovery Manager
（Oracle RMAN）のその他の拡
張機能
オンライン移動機能
オンラインでのパーティション移動は、1つのセッション内のオンラインでのマルチパーティション再
定義をサポートします。
オンライン表再定義の拡張機能
19
単一コマンドでの再定義。sync_interim_tableパフォーマンスの向上、より適切なロック管理による
finish_redef_tableのリジリエンスの向上、パーティション・レベルのロックのみによるパーティション再定
義での可用性の向上、および指定されたパーティションのみに対する変更のログ記録によるパフォーマン
スの向上
Active Data Guardを使用した
アップグレード
21
ローリング・データベース・アップグレードを実行するために必要な数十の手順を、このプロセスの多
くを自動化する3つのPL/SQLパッケージに置き換えます。ユーザーを新しいバージョンに移行する前に
本番環境の完全なレプリカに対してすべての変更を実装し、徹底的に検証することによって、計画停止
時間とリスクを最小限に抑えます。
28
Oracle Database 12cによる可用性の最大化
Copyright © 2012, Oracle and/or its affiliates. All rights reserved.
2013年6月
本文書は情報提供のみを目的として提供されており、ここに記載される内容は予告なく変更されることがあります。本文書は一切間違いがないこ
著者：Cris Pedregal Martin
共著者：Joseph Meeks、
HA Product Management Team
Oracle Corporation
World Headquarters
とを保証するものではなく、さらに、口述による明示または法律による黙示を問わず、特定の目的に対する商品性もしくは適合性についての黙示
的な保証を含み、いかなる他の保証や条件も提供するものではありません。オラクル社は本文書に関するいかなる法的責任も明確に否認し、本文
書によって直接的または間接的に確立される契約義務はないものとします。本文書はオラクルの書面による許可を前もって得ることなく、いかな
る目的のためにも、電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません。
OracleおよびJavaはOracleおよびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。
500 Oracle Parkway
IntelおよびIntel XeonはIntel Corporationの商標または登録商標です。すべてのSPARC商標はライセンスに基づいて使用されるSPARC International,
Redwood Shores, CA 94065
Inc.の商標または登録商標です。AMD、Opteron、AMDロゴおよびAMD Opteronロゴは、Advanced Micro Devicesの商標または登録商標です。
U.S.A.
UNIXは、The Open Groupの登録商標です。0113
海外からのお問い合わせ窓口：
電話：+1.650.506.7000
ファクシミリ：+1.650.506.7200
www.oracle.com