Oracle® Database

高可用性概要

11gリリース2 (11.2)

B56308-04(原本部品番号:E17157-09)

2013年7月

Oracle Database高可用性概要, 11gリリース2(11.2)

B56308-04

Copyright © 2005, 2013, Oracle and/or its affiliates.All rights reserved.

原本著者: Virginia Beecher、Viv Schupmann、Janet Stern

原本協力者: Ahmed Abbas, Lance Ashdown, Andrew Babb, Tammy Bednar, Peter Belknap, Janet Blowney, Larry Carpenter, Immanuel Chan, Tim Chien, Donna Cooksey, Tulika Das, Mark Dilman, Ray Dutcher, Richard Exley, Craig Foch, Ameet Kini, Frank Kobylanski, Bryn Llewellyn, Barb Lundhild, Rahim Mau, Patricia McElroy, Joe Meeks, Markus Michalewicz, Valarie Moore, Dan Norris, Michael Nowak, Darryl Presley, Ashish Ray, Mark Scardina, Viv Schupmann, Jia Shi, Michael T.Smith, Vinay Srihari, Hubert Sun, Lawrence To, Douglas Utzig, James Viscusi, Tak Wang, Shari Yamaguchi

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

1 高可用性の概要

- 1.1 高可用性とは

- 1.2 可用性の重要性

- 1.3 停止時間のコスト

- 1.4 停止時間の原因

- 1.5 最大可用性アーキテクチャ(MAA)実装のロードマップ

2 高可用性要件の特定

- 2.1 高可用性の要件の決定

- 2.2 高可用性要件の特定のための分析フレームワーク

- 2.2.1 ビジネス影響分析

- 2.2.2 停止時間のコスト

- 2.2.3 リカバリ時間目標(RTO)

- 2.2.4 リカバリ・ポイント目標(RPO)

- 2.2.5 管理性目標

- 2.2.6 総所有コスト(TCO)および投資利益率(ROI)

- 2.3 高可用性アーキテクチャ要件

- 2.3.1 ビジネスのパフォーマンス、予算および成長の計画

3 計画外停止時間用Oracle Database高可用性ソリューション

- 3.1 計画外停止時間用Oracle高可用性ソリューションおよびリカバリ

- 3.2 ファスト・スタート・リカバリ

- 3.3 Oracle Restart

- 3.4 Oracle Real Application ClustersおよびOracle Clusterware

- 3.4.1 Oracle Clusterware使用の利点

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

- 3.5 Oracle RAC One Node

- 3.6 Oracle Data Guard

- 3.6.1 フィジカル・スタンバイ・データベース

- 3.6.2 Oracle Active Data Guard

- 3.6.3 一時的なロジカル・スタンバイ・データベース

- 3.6.4 スナップショット・スタンバイ・データベース

- 3.6.5 ロジカル・スタンバイ・データベース

- 3.7 Oracle GoldenGateおよびOracle Streams

- 3.7.1 Oracle GoldenGateの概要

- 3.7.2 Oracle GoldenGateとOracle Active Data Guardの使用

- 3.8 Oracle Flashback Technology

- 3.8.1 Oracle Flashback Query

- 3.8.2 Oracle Flashback Version Query

- 3.8.3 Oracle Flashback Transaction

- 3.8.4 Oracle Flashback Transaction Query

- 3.8.5 Oracle Flashback Table

- 3.8.6 Oracle Flashback Drop

- 3.8.7 Oracle Flashbackのリストア・ポイント

- 3.8.8 Oracle Flashback Database

- 3.8.9 フラッシュバック・ログを使用したブロック・メディア・リカバリ

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

- 3.9 Oracle Automatic Storage Management

- 3.10 高速リカバリ領域

- 3.11 Recovery Manager

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

- 3.13 Oracle Secure Backup

- 3.14 Oracleセキュリティ機能

- 3.15 LogMiner

- 3.16 Oracle Exadata Storage Server Software(Exadataセル)

- 3.17 Oracle Exadata Database Machine

- 3.18 Oracle Database File System(DBFS)

- 3.19 クライアント・フェイルオーバー

- 3.20 自動ブロック修復

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

4 計画停止時間用Oracle Database高可用性ソリューション

- 4.1 計画停止時間用Oracle高可用性ソリューションおよびリカバリ時間

- 4.1.1 オペレーティング・システムのアップグレードおよびハードウェアのアップグレード

- 4.1.2 Oracle Data Guardを使用したシステムおよびクラスタのアップグレードと移行

- 4.1.3 Oracle Databaseパッチ

- 4.1.4 Oracle Clusterwareのアップグレード

- 4.1.5 Oracle Automatic Storage Management(Oracle ASM)のアップグレード

- 4.1.6 ストレージの移行

- 4.1.7 Oracle Exadata Storage Server Softwareの移行

- 4.1.8 Oracle Exadata Storage Server Softwareのアップグレード

- 4.1.9 パッチ・セットおよびデータベースのアップグレード

- 4.1.10 同じエンディアン形式のプラットフォーム間でのプラットフォームの移行

- 4.1.11 異なるエンディアン形式のプラットフォーム間でのプラットフォームの移行

- 4.2 動的リソース・プロビジョニング

- 4.2.1 データベースの動的再構成

- 4.2.2 メモリー管理の自動チューニング

- 4.2.3 データ・ファイル、制御ファイルおよびログ・ファイルの分散の自動化

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

- 4.4 トランスポータブル・テクノロジ

- 4.5 アプリケーションのオンライン・メンテナンスおよびオンライン・アップグレード

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

- 4.5.2 ローリング・アップグレードに使用するOracle GoldenGate

- 4.5.3 WAITオプションを使用したDDL

- 4.5.4 CREATE TRIGGERのENABLE、DISABLEおよびFOLLOWS句

- 4.5.5 ADD COLUMN機能の拡張

- 4.5.6 きめ細かな依存性

- 4.5.7 不可視の索引

- 4.5.8 表のオンライン再定義後の依存PL/SQLの再コンパイル

5 投資利益率(ROI)の最適化

- 5.1 グリッド・コンピューティング

- 5.2 データベース・サーバー・グリッド

- 5.3 データベース・ストレージ・グリッド

- 5.4 アクティブ・スタンバイ・データベースを使用した障害時リカバリ

- 5.4.1 フィジカル・スタンバイ・データベースのOracle Active Data Guardオプション

- 5.4.2 スタンバイ・リーダー・ファームを使用したWebスケール

- 5.5 Oracle VMとドメイン・ライブ・マイグレーション

6 管理性の最適化

- 6.1 インテリジェントなインフラストラクチャ

- 6.2 変更の保証

- 6.3 Oracle Enterprise Manager Grid Control

7 高可用性アーキテクチャおよびソリューション

- 7.1 Oracle Database高可用性アーキテクチャ

- 7.1.1 Oracle Database

- 7.1.2 Oracle Clusterware使用のOracle Database(コールド・クラスタ・フェイルオーバー)

- 7.1.3 Oracle RAC One Node使用のOracle Database

- 7.1.4 Oracle Real Application Clusters(Oracle RAC)使用のOracle Database

- 7.1.5 Oracle Data Guard使用のOracle Database

- 7.1.6 Oracle ClusterwareおよびOracle Data Guard使用のOracle Database

- 7.1.7 Oracle RAC One NodeおよびOracle Data Guard使用のOracle Database

- 7.1.8 Oracle RACおよびOracle Data Guard使用のOracle Database

- 7.1.9 Oracle GoldenGate使用のOracle Database

- 7.2 正しい高可用性アーキテクチャの選択

- 7.3 アプリケーション・サーバーの高可用性の統合

- 7.3.1 Oracle Application Serverの高可用性アーキテクチャ

- 7.3.2 冗長アーキテクチャ

- 7.3.3 Oracle Application Serverの高可用性サービス

- 7.4 すべてのアプリケーションの高可用性の統合

用語集

索引

はじめに

このマニュアルでは、可用性の高いデータベース環境をデプロイするOracleベスト・プラクティスを紹介します。また、高可用性について概説し、高可用性要件の特定を支援します。高可用性をサポートするよう設計されたOracle Databaseの製品と機能、およびビジネスの高可用性実現に役立つ主要なデータベース・アーキテクチャについても説明します。

「はじめに」では、次の項目について説明します。

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

対象読者

このマニュアルは、次の仕事を遂行するCTO(最高技術責任者)、情報テクノロジ・アーキテクト、データベース管理者、システム管理者、ネットワーク管理者およびアプリケーション管理者を対象としています。

- データ・センターの計画

- データ・センター・ポリシーの実装

- 高可用性システムのメンテナンス

- 高可用性ソリューションの計画および構築

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWeb サイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

Oracleサポート・サービスでは、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info) か、聴覚に障害のあるお客様は (http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。

関連ドキュメント

このマニュアルで説明されている構成と実装の詳細を理解するには、Oracle Database、Oracle RACおよびOracle Data Guardの概念および用語に関する知識が必要です。詳細は、Oracle Databaseのドキュメント・セットを参照してください。特に関連性の高いドキュメントを次に示します。

- 『Oracle Database高可用性ベスト・プラクティス』
ベスト・プラクティスを確定するには広範囲なテストが必要なため、このマニュアルは通常『Oracle Database高可用性概要』よりも遅れます。リリース11.2のマニュアルが使用可能になるまで、リリース11.1.0.7用の『Oracle Database高可用性ベスト・プラクティス』に有用な方法がある可能性があります。

- 『Oracle Database管理者ガイド』

- 『Oracle Database 2日でReal Application Clustersガイド』

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

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

- 『Oracle Automatic Storage Management管理者ガイド』

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

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

ドキュメント・セット内の多くのマニュアルでシード・データベースのサンプル・スキーマが使用されていますが、このシード・データベースはOracleのインストール時にデフォルトでインストールされます。これらのスキーマの使用方法については、『Oracle Databaseサンプル・スキーマ』を参照してください。

Oracle MAAベスト・プラクティス・ホワイト・ペーパーを次のWEBサイトからダウンロードすることもできます。

http://www.oracle.com/goto/maa

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ドキュメントのタイトル、強調またはユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 高可用性の概要

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

- 高可用性とは

- 可用性の重要性

- 停止時間のコスト

- 停止時間の原因

- 最大可用性アーキテクチャ(MAA)実装のロードマップ

1.1 高可用性とは

可用性は、要求に応じてアプリケーション、サービスまたは機能がどの程度使用可能であるかを表しています。可用性は、アプリケーションのエンド・ユーザーの感覚を基準に評価されます。データが使用できない場合やコンピュータ・システムが予想どおりに機能しない場合、ユーザーは不満を感じます。ユーザーがソリューション全体の複雑なコンポーネントを理解したり、区別しようと考えたりすることはありません。予想を超える使用状況が原因で発生したパフォーマンス障害は、アーキテクチャの重要なコンポーネントに障害が発生した場合と同じ混乱をもたらします。ユーザーがシステムにアクセスできないことを使用不可といいます。一般的に、システムの使用不可期間は停止時間と呼ばれます。

システムをいつでも使用できる状態にしておくには、高可用性が必要です。可用性の高いシステムは、主要期間、年間を通じて毎日毎時間、割込みのない計算処理を提供するように設計されています。これは24x365と表されます。ただし、一部の操作(システムのハードウェアやソフトウェアのアップグレードなど)を実行する際には、例外として最小限の停止時間が発生します。

信頼性、リカバリ可能性、タイムリなエラー検出および継続的稼働は、高可用性ソリューションの主な特徴です。

- 信頼性: 信頼できるハードウェアは高可用性ソリューションの1つの要素です。信頼できるソフトウェア(データベース、Webサーバー、アプリケーションなど)も同様に、高可用性ソリューションを実現する上で重要です。関連する特性はリジリエンスです。たとえば、低コストの汎用ハードウェアをOracle Real Application Clusters(Oracle RAC)などのソフトウェアを組み合せることで、非常に信頼性の高いシステムの実装に使用できます。Oracle RACデータベースのリジリエンスが高ければ、個々のサーバーに障害が発生しても、処理は続行できます。

- リカバリ能力: 障害からのリカバリには多数の方法がある場合があります。したがって、高可用性の環境でどのようなタイプの障害が発生する可能性があるかを判断し、ビジネスの要件を満たしてタイムリにそれらの障害からリカバリする方法を決めることが重要です。たとえば、重要な表が誤ってデータベースから削除された場合、その表をリカバリするにはどのような処置を取ればよいでしょうか。アーキテクチャには、品質保証契約(SLA)で規定された時間内にリカバリする能力があるでしょうか。

- タイムリなエラー検出: アーキテクチャのコンポーネントに障害が発生した場合、予期しない障害からリカバリするには素早い検出が重要です。停止から素早くリカバリできても、問題の検出にさらに90分かかったとしたら、SLAを遵守できない可能性があります。環境の状態を監視するには、状態を素早く表示するための信頼できるソフトウェア、およびデータベース管理者に問題を通知する機能が必要です。

- 継続的稼働: データへの継続的なアクセスを提供することが、メンテナンス・アクティビティを実行するための停止時間をほとんど、あるいはまったく許容できないという場合に不可欠です。表をデータベース内の別の場所に移動したり、ハードウェアにCPUを追加したりといったアクティビティは、高可用性アーキテクチャではエンド・ユーザーに対して透過的に行う必要があります。

より具体的に言えば、高可用性アーキテクチャは次の特徴を備えている必要があります。

- 中断を最小限またはゼロにして、処理が継続するように障害を許容すること

- システム、データまたはアプリケーションの変更に対して透過的である(または耐性がある)こと

- 予防措置が組み込まれていること

- 障害のアクティブな監視と素早い検出が可能であること

- 素早いリカバリが可能であること

- 検出操作およびリカバリ操作が自動化されていること

- データ損失を最小限に抑えるか防止するためにデータを保護すること

- 運用面でのベスト・プラクティスを実施して環境を管理していること

- できるかぎり安価な総所有コストでSLA(リカバリ時間目標(RTO)やリカバリ・ポイント目標(RPO)など)で設定した目標を達成すること

1.2 可用性の重要性

高可用性がどの程度重要であるかはアプリケーションによって異なります。データベースとインターネットは、組織やコミュニティの隅々にまでデータベース・アプリケーションを行き渡らせ、世界的なコラボレーションと情報共有を可能にしました。こうしたデータベース・アプリケーションの浸透により、データ管理ソリューションにおける高可用性の重要性が浮き彫りになっています。中小企業もグローバルな企業も、1日24時間データへのアクセスを必要とするユーザーを世界中に抱えています。このデータ・アクセスが行えなければ、業務は停止し、収益が失われます。これらのソリューションに依存する傾向が強まったことを反映して、ユーザーは情報技術(IT)部門やソリューション提供者の品質保証契約を求めるようになりました。可用性は、時間と利便性のみでなく、ドル、ユーロおよび円で評価されることがますます増えています。

企業は、そのITインフラストラクチャを利用して、競争力を付け、生産性を高め、より多くの情報に基づいてより迅速に決定を下す力をユーザーに与えてきました。しかし、こうした利点により、インフラストラクチャへの依存度はますます高まりました。重要なアプリケーションが使用できなくなった場合、ビジネスが危機に瀕します。ビジネスの収益が減少し、違約金を被り、顧客や会社の株価に対する影響が続く悪評を呼ぶ可能性があります。

データの保護方法を決定する要因について検討し、ユーザーへの可用性を最大限に高めることが非常に重要です。

1.3 停止時間のコスト

企業がソリューションを再構築して競争力を強めるにつれて、より高いレベルの可用性を提供する必要性は高まる一方です。ほとんどの場合、こうした新しいソリューションは重要なビジネス・データへの即時アクセスに依存しています。データが使用できない場合、業務が停止する可能性もあります。停止時間は、生産性の低下、収益の損失、カスタマ・リレーションシップの悪化、悪評および訴訟につながりかねません。

停止時間の直接のコストを試算するのは必ずしも容易ではありません。顧客の怒り、従業員の空き時間、悪評などはすべてコストに結び付きますが、通貨に直接換算することはできません。その一方で、SLAの目標が達成されないことによる収益の損失や法的処罰は容易に定量化可能です。ソリューションに依存してサービスを提供している業界では、停止時間のコストが急速に増大する可能性があります。

停止時間のコストという点で考慮が必要なその他の要因は、次のとおりです。

- 1回の計画外停止の最大許容時間
イベントの継続時間が30秒未満の場合、イベントが与える影響は非常に小さく、エンド・ユーザーがイベントを感じ取ることはほとんどありません。停止時間が長くなるにつれて、その影響は著しく大きくなり、ビジネスにも悪影響を及ぼすことになります。

- 許容できるインシデントの最大頻度
停止の頻度が高くなると、停止が短時間であったとしても、同様に業務が中断する可能性があります。

ソリューションを設計する場合、停止時間の実際のコストを把握して、可用性が向上することでどのように利益が得られるのかを認識することが重要です。

オラクル社では、規模に関係なくあらゆる組織に適する幅広い高可用性ソリューションを提供しています。小規模なワークグループもグローバルな企業も同様に、重要なビジネス・アプリケーションの利用範囲を拡大できます。Oracleとインターネットがあれば、いつでもどこからでも、アプリケーションおよびデータへの信頼性の高いアクセスが可能になります。

1.4 停止時間の原因

高可用性ソリューションを設計する上での課題の1つは、停止時間のあらゆる原因を検討し、対処することです。フォルト・トレラントおよびリジリエンスがあるITインフラストラクチャを設計する際、計画外停止時間と計画停止時間の両方の原因を考慮することは重要です。複数のタイムゾーンのユーザーをサポートするグローバル企業では特に、計画停止時間も計画外停止時間と同じく業務に悪影響を及ぼします。

表1-1は、計画外停止のタイプと説明、および各タイプの例を示しています。

表1-1 計画外停止時間の原因

タイプ

説明

例

サイト障害

サイト障害は、データ・センターでのすべての処理か、またはデータ・センターでサポートされているアプリケーションのサブセットに影響する可能性があります。

- サイト全体に及ぶ停電

- サイト全体のネットワーク障害

- データ・センターを操業不可能にする自然災害

- 業務またはサイトへのテロまたは悪意のある攻撃

クラスタ全体の障害

Oracle RACデータベースのホストであるクラスタ全体が使用不可能になるか、故障します。次のような機能があります。

- クラスタ内のノードの障害

- クラスタが使用不可能になる原因となった他のコンポーネントの障害および使用不可能なサイト上のOracleデータベースやインスタンスの障害

- Oracle RACクラスタで残った最後のノードが故障し、再起動不能

- 冗長クラスタのインターコネクトが両方故障またはクラスタウェアの障害

- データベースの破損が、現行データ・サーバーでの継続が不可能になるほど深刻

- ディスク・ストレージ障害

コンピュータ障害

コンピュータ障害による停止は、データベースを実行しているシステムが停止またはアクセス不可能になり、使用できない状態になったときに発生します。

- データベース・システム・ハードウェア障害

- オペレーティング・システム障害

- Oracleインスタンス障害

- ネットワーク・インタフェース障害

ストレージ障害

ストレージ障害による停止は、データベース・コンテンツの一部またはすべてが格納されているストレージが停止またはアクセス不可能になり、使用できない状態になったときに発生します。

- ディスク・ドライブ障害

- ディスク・コントローラ障害

- ストレージ・アレイ障害

データ破損

破損ブロックは変更されたブロックです。そのため、Oracle Databaseが検出するものとは異なります。ブロック破損は、物理的ブロック破損と論理的ブロック破損に分類されます。

- 物理的破損はメディア破損とも呼ばれ、データベースがブロックを完全に認識しません。チェックサムは無効になり、ブロック内はすべてゼロになるか、またはブロックのヘッダーとフッターが一致しません。

- 論理的破損では、ブロックの内容が論理的に一貫していません。論理的破損の例として、行の一部や索引エントリの破損があげられます。

ブロック破損は、さらにインターブロック破損とイントラブロック破損に分類できます。

- イントラブロック破損の場合、破損はブロック内部で発生します。これは物理的破損または論理的破損のいずれかです。

- インターブロック破損の場合、破損はブロック間で発生します。これは論理的破損です。

データ破損による停止は、ハードウェア、ソフトウェアまたはネットワークのコンポーネントで、読取りまたは書込み対象のデータが破損したときに発生します。データ破損による停止から受けるサービス・レベルの影響は、データベースの一部(単一データベース・ブロック・レベル)から大部分(基本的に使用不可にする)まで、大きく異なります。

- オペレーティング・システムまたはストレージ・デバイス・ドライバ障害

- 障害のあるホスト・バス・アダプタ

- ディスク・コントローラ障害

- ディスクの不正な読取りまたは書込みの原因となるボリューム・マネージャ・エラー

- ソフトウェアの不具合

人的エラー

人的エラーによる停止は、データベース内のデータを破損または使用不可能の状態にする意図的でない操作やその他の操作が行われた場合に発生します。人的エラーによる停止から受けるサービス・レベルの影響は、影響を受けたデータの量および重大性によって大きく異なります。

- (ファイル・システム・レベルの)ファイルの削除

- 削除されたデータベース・オブジェクト

- 故意でないデータ変更

- 悪意のあるデータ変更

書込み欠落

データ破損のもう1つの形である書込み欠落は、素早く検出し修復することがさらに困難です。データ・ブロックの宛先違いの書込みまたは書込み欠落は次の場合に発生します。

- 書込み欠落は、書込みI/Oが永続記憶域で発生しなくても、I/Oサブシステムがブロック書込みの完了を確認する場合。プライマリ・データベースでの後続ブロック読取りのときに、I/Oサブシステムが、データベースの他のブロックの更新に使用される古いバージョンのデータ・ブロックを返すため、ブロックが破損します。

- 宛先違いの書込みは、書込みI/Oは完了したが、他の場所に書き込まれ、後続の読取り操作で古い値が返される場合。

- Oracle RACシステムでは、1つのクラスタ・ノードからの読取りI/Oで、別のノードからの書込みI/O完了後に古いデータが返される場合(書込みの欠落)。たとえば、属性キャッシュを無効にせずに(noacオプションを使用しないなど)ネットワーク・ファイル・システム(NFS)がOracle RACでマウントされている場合に発生します。この場合、1つのノードからの書込みI/Oは、キャッシュされるために別のノードに即時表示されません。

- オペレーティング・システムまたはストレージ・デバイス・ドライバ障害

- 障害のあるホスト・バス・アダプタ

- ディスク・コントローラ障害

- ボリューム・マネージャ・エラー

- その他のアプリケーション・ソフトウェア

- クラスタ全体で見えないネットワーク・ファイル・システム(NFS)書込み

停止または減速

停止または減速は、リソースやロックの競合が原因でデータベースまたはアプリケーションがトランザクションを処理できない場合に発生します。認識される停止は、システム・リソースの不足が原因で引き起こされます。

- データベースまたはアプリケーションのデッドロック

- システム・リソースを消費する暴走プロセス

- ログオン・ストームまたはシステム・フォルト

- システム・リソースまたはデータベース・リソースの不足によるアプリケーション・ピークの組合せ

- アーカイブREDOログの宛先または高速リカバリ領域の宛先がいっぱいになった場合

表1-2は、計画停止のタイプと説明、および各タイプの例を示しています。

表1-2 計画停止時間の原因

タイプ

説明

例

システム変更およびデータベース変更

計画されたシステム変更は、日常的、定期的なメンテナンス業務および新しいデプロイメントが行われるときに発生します。

計画されたシステム変更には、データベース内の組織データ構造外で発生する計画的な業務環境への変更が含まれます。

計画されたシステム変更から受けるサービス・レベルの影響は、計画停止時間の性質および範囲、変更の実装前に行われるテストと検証作業、影響を最小化するためのテクノロジならびに機能により、大きく異なります。

- SMPサーバーへのプロセッサの追加、またはSMPサーバーからの削除

- クラスタへのノードの追加、またはクラスタからのノードの削除

- ディスク・ドライブまたはストレージ・アレイの追加および削除

- 構成パラメータの変更

- システム・ハードウェアおよびソフトウェアのアップグレードまたはパッチ適用

- Oracleソフトウェアのアップグレードまたはパッチ適用

- アプリケーション・ソフトウェアのアップグレードまたはパッチ適用

- システム・プラットフォームの移行

- データベースの再配置

- 32ビットから64ビットへの移動

- クラスタ・アーキテクチャへの移行

- 新しい記憶域への移行

データ変更

計画されたデータ変更は、Oracle Databaseオブジェクトの論理的構造または物理的組織に変更があった場合に発生します。この変更を行うのは主に、パフォーマンスまたは管理性を改善するためです。

- 表定義の変更

- 表のパーティション化の追加

- 索引の作成および再構築

アプリケーション変更

計画されたアプリケーション変更には、データ変更やスキーマおよびプログラムの変更などがあります。この変更を行うのは主に、パフォーマンス、管理性および機能性を改善するためです。

- アプリケーションのアップグレード

オラクル社では、計画外停止時間と計画停止時間の回避、および障害からのリカバリに役立つ高可用性ソリューションを提供しています。これらの高可用性ソリューションの詳細は、第3章および第4章で説明します。

1.5 最大可用性アーキテクチャ(MAA)実装のロードマップ

Oracleの高可用性ソリューションと正常な操作実行が、ITインフラストラクチャの実装を成功させる鍵です。ただし、テクノロジのみでは十分ではありません。

可用性要件に最も適したアーキテクチャを選択し、実装するのは、きわめて困難な作業です。MAAは、ビジネス要件に適した高可用性アーキテクチャを選択し実装するプロセスを簡略化します。MAAアーキテクチャには次のような働きがあります。

- すべてのコンポーネントに冗長性を持たせること

- コンピュータ障害、ストレージ障害、人的エラー、データ破損、書込み欠落、システムの停止または減速、およびサイト障害からの保護および許容が可能であること

- できるだけ素早く透過的に停止からリカバリすること

- 計画停止時間をなくすか短縮するソリューションを提供すること

- 一貫した高パフォーマンスと堅牢なセキュリティを実現すること

- デプロイが単純で、効率的に管理でき、拡張が容易であること

- できるかぎり安価な総所有コストでSLAを遵守すること

このようなアーキテクチャを構築、実装および維持するには、次のことが必要です。

1. ビジネスやアプリケーションに対するOracle高可用性機能の重要な効果を理解します。第3章および第4章を参照してください。

2. ITシステムおよびビジネス・プロセスの技術面および運営面の両方を含め、固有の高可用性の要件を分析します。第2章「高可用性要件の特定」を参照してください。

3. 高可用性アーキテクチャを選択します。第7章「高可用性アーキテクチャおよびソリューション」を参照してください。

4. 次のリソースを使用して、高可用性アーキテクチャを実装します。

- MAAおよび高可用性ベスト・プラクティスのホワイト・ペーパーおよびその他の情報
オラクル社では、各種ベスト・プラクティス・ホワイト・ペーパー、概念実証を伴うカスタマMAAペーパー、カスタマ・ケース・スタディ、記録されているWebキャスト、デモンストレーションおよびプレゼンテーションを提供しています。これらのリソースは、MAAの様々な高可用性テクノロジに関する技術的な詳細を、そのようなテクノロジを構成および使用するためのベスト・プラクティス推奨事項とともに提供します。

これらのMAAリソースは次のWebサイトからダウンロードできます。

http://www.oracle.com/goto/maa

- 『Oracle Database高可用性ベスト・プラクティス』
このマニュアルでは、ベスト・プラクティスの推奨事項と情報について詳しく説明します。これは、新しい高可用性環境を構成したり、簡素化やパフォーマンスを損わずに、既存の構成を移行して冗長かつ信頼できるシステムを作成したりする場合に役立ちます。

高可用性分析フレームワーク、ビジネス推進要因およびシステムの機能を含む明確な高可用性ベスト・プラクティスを備えた企業は、運用面でのリジリエンスを高め、ビジネスの敏捷性を強化できます。

2 高可用性要件の特定

この章では、次の項目について説明します。

- 高可用性の要件の決定

- 高可用性要件の特定のための分析フレームワーク

- 高可用性アーキテクチャ要件

2.1 高可用性の要件の決定

高可用性計画を設計および実現しようとする企業は、高可用性を必要とするビジネス要因の徹底的な分析から始める必要があります。高可用性の実現は、次のような重要な課題を伴います。

- レガシー・システムの廃止

- より高度で堅牢なシステムや設備への投資

- この高可用性モデルに合せたITアーキテクチャと操作全体の再設計

- ビジネス・プロセスの再設計

- 人員の雇用およびトレーニング

この章では、ビジネスの高可用性要件を効果的に評価するためのフレームワークを示します。ビジネス要件を分析した上で、様々な高可用性ソリューションの実装に必要な投資レベルを理解することで、ビジネス面と技術面の両方の目的を達成する高可用性アーキテクチャの開発が可能になります。

高可用性分析フレームワークを使用すると、次のことが可能になります。

1. ビジネス影響分析の実施

2. 高可用性要件を持つ重要なビジネス・プロセスの特定および分類

3. 停止時間のコストの公式化

4. 各種ビジネス・プロセスの使用率、リカバリ時間目標(RTO)およびリカバリ・ポイント目標(RPO)の設定

5. 管理性、総所有コスト(TCO)および投資利益率(ROI)の目標の理解

このフレームワークにより、ビジネスの重要な局面の高可用性という見地から品質保証契約(SLA)を定義することができます。たとえば、SLAではビジネス・プロセスをいくつかの高可用性層に分類できます。

- 第1層のプロセスはビジネスに最大の影響を与えます。これらは最も厳しい高可用性要件を持ち、RTOおよびRPOはゼロに近くなります。また、継続的に使用できるサポート・システムが必要です。E-Commerceを大規模に展開しているビジネスの場合、Webベースの顧客対応システムなどがこれに当たります。

- 第2層のプロセスの高可用性およびRTOおよびRPOの要件は、多少緩やかでもかまいません。E-Commerceビジネスの第2層は、サプライ・チェーン・システムやマーチャンダイジング・システムなどです。たとえば、これらのシステムはきわめて高い可用性を維持する必要はないため、RTOおよびRPOの値がゼロではないこともあります。したがって、第2層のプロセスをサポートするために選択する高可用性システムは、第1層のプロセスとは異なっている可能性があります。

- 第3層のプロセスは、内部開発プロセスや品質保証プロセスに関連したものです。これらのプロセスをサポートするシステムには、他の層のような厳しい高可用性要件はありません。

図2-1に示すように、次のステップは、各種高可用性システムおよびテクノロジの機能を評価し、ビジネス・パフォーマンスの問題、予算の制約、および予想されるビジネスの成長によって決まるガイドラインの範囲内で、SLA要件を満たすものを選択することです。

図2-1 可用性の高い企業の計画および実現

2.2 高可用性要件の特定のための分析フレームワーク

この分析フレームワークは次の要素で構成されます。

- ビジネス影響分析

- 停止時間のコスト

- リカバリ時間目標(RTO)

- リカバリ・ポイント目標(RPO)

- 管理性目標

- 総所有コスト(TCO)および投資利益率(ROI)

2.2.1 ビジネス影響分析

厳密なビジネス影響分析では、次のことが行われます。

- 組織内の重要なビジネス・プロセスの特定

- 各ビジネス・プロセスに影響を与える計画外IT停止および計画IT停止の定量化可能な損失リスクの算出

- 停止が与える影響の概略のまとめ

- 基本的なビジネス機能、人的リソースおよびシステム・リソース、政府規制、内部および外部のビジネス依存関係の考慮

- 豊富な知識を持つ経験豊かな人員とのインタビューで収集した客観的、主観的データの使用

- ビジネス手法の履歴や財務報告書、ITシステム・ログなどの調査

ビジネス影響分析では、IT関連の停止の影響の重大度に基づいてビジネス・プロセスを分類します。たとえば、世界各地にチップ製造工場を持つ半導体製造業者について考えてみましょう。半導体製造業は、高生産量で償却される、巨額な財政投資を必要とする非常に競争の激しいビジネスです。工場管理で使用される人的リソース・アプリケーションは、工場の製造プロセスを制御するアプリケーションほどミッションクリティカルであるとみなされない傾向があります。製造をサポートするアプリケーションに障害が発生すると、その影響は生産レベルに及び、企業の決算報告に直接の影響が出ます。

同様に、経営コンサルティング企業では内部ナレッジ管理システムがミッションクリティカルであるとみなされる傾向があります。これは、クライアントを重視する企業のビジネスにとって、コンサルタントやナレッジ・ワーカーが内部調査にアクセスできることが基本であるためです。このようなシステムの停止時間のコストは、このビジネスにとってきわめて高くつきます。そこで、高可用性要件フレームワークの次の要素である停止時間のコストについて考えてみることにします。

2.2.2 停止時間のコスト

ビジネス影響分析を完全に実施すれば、計画外停止時間および計画停止時間のコストの定量化に必要な見通しが得られます。このコストは、高可用性の投資の優先付けに役立ち、停止時間のリスクを最小限に抑えるために選択する高可用性テクノロジに直接影響を与えるため、必ず理解しておく必要があります。

様々な業界の停止時間のコストをまとめた各種レポートが発行されています。コストは、仲買業務やクレジット・カード販売の1時間当たり数百万ドルから、荷物輸送サービスの1時間当たり数万ドルまで、多岐にわたります。

これらの数字は驚異的ですが、その理由は明らかです。インターネットでは、ビジネスと何百万もの顧客を直接結び付けることができます。アプリケーションの停止時間によってこの結び付きは分断され、ビジネスと顧客が切り離されてしまいます。停止時間は収益の損失を生むだけでなく、カスタマ・リレーションシップ、競争力、法的義務、業界での評価、株主の信頼などにも悪影響を及ぼす可能性があります。

2.2.3 リカバリ時間目標(RTO)

ビジネス影響分析では、リカバリ時間目標(RTO)を決定します。RTOは、組織が受け入れがたい結果(経済的損失、顧客不満足、評価など)を被り始める前に、ITベースのビジネス・プロセスを停止できる最大時間として定義されます。RTOは、一般的に、ビジネス・プロセスまたは組織の許容停止時間に相当します。

RTO要件はビジネスのミッションクリティカル性によって左右されます。したがって、証券取引所を運営するシステムの場合、RTOはゼロまたは非常にゼロに近い数値になります。

組織には、各種ビジネス・プロセスにまたがる様々なRTO要件があるものです。したがって、大規模なE-Commerce Webサイトの場合、高速のレスポンスが期待され、顧客のスイッチング・コストが非常に小さいため、E-Commerceの売上を押し上げるWebベースの顧客対応システムのRTOはゼロに近くなります。しかし、出荷や請求などのバックエンド業務をサポートするシステムのRTOはそれより長くてもかまいません。このようなバックエンド・システムが停止した場合は、一時的に手動操作に切り替えて、重大な影響が出るのを防ぐことができます。

E-Commerce Webサイトを介してすばやく注文を受けられること(RTO)のほうがPROより重要です。失われたデータは後でリロードできるためです。

2.2.4 リカバリ・ポイント目標(RPO)

ビジネス影響分析では、リカバリ・ポイント目標(RPO)も決定します。RPOは、組織に損害を与えずに、ITベースのビジネス・プロセスで失うことのできる最大データ量です。RPOは、一般的に、ビジネス・プロセスまたは組織の許容データ損失量に相当します。このデータ損失は、通常、5時間または2日分のデータ損失というように、時間に換算して測定されます。

毎分数百万ドルに相当するトランザクションが発生する証券取引所では、データを失うわけにはいきません。したがって、RPOをゼロにする必要があります。E-Commerceの例について言えば、Webベースの販売システムではRPOがゼロであることが厳密に求められるわけではありませんが、顧客満足のためにはRPOを抑えることが不可欠です。ただし、バックエンドのマーチャンダイジング・システムおよび在庫更新システムでは、RPOが大きくなることもあります。失ったデータの再入力が可能であるためです。

2.2.5 管理性目標

管理性目標は、RPOやRTOよりも主観的です。これは、組織で使用できるスキル・セットや管理リソースの客観的な評価、および組織が高可用性アーキテクチャのすべての要素を正常に管理できる程度に起因します。RPOおよびRTOが停止時間やデータ損失に対する組織の許容差を測定するのと同様に、管理性目標はIT環境の複雑さに対する組織の許容差を測定します。複雑さがそれほど要求されない場合、高可用性を実現するには、管理が複雑な方法よりも単純な方法が好まれ、複雑な方法の方が積極的なRTOおよびRPO目標を達成できる場合でも当てはまります。管理性目標を理解すれば、組織で実現が可能と思われる事項と実現が実用的である事項とを区別する際に役立ちます。

2.2.6 総所有コスト(TCO)および投資利益率(ROI)

総所有コスト(TCO)と投資利益率(ROI)を理解することは、組織のビジネス目標を達成する高可用性アーキテクチャを選択する際に不可欠です。TCOには、選択するソリューションの耐用年数におけるすべてのコスト(取得、実装、システム、ネットワーク、設備、スタッフ、トレーニングおよびサポートなど)が含まれます。同様に、ROIの計算では、指定の高可用性アーキテクチャで発生するすべての金銭的利益が算出されます。

たとえば、リモートのスタンバイ・サイトのITシステムおよびストレージがアイドル状態の高可用性アーキテクチャがあり、そのスタンバイ・システムで処理できるビジネス用途が他にないとします。このスタンバイ・サイトの投資利益率は、フェイルオーバー・シナリオで使用する場合に回避される停止時間のコストのみです。このアーキテクチャと別の高可用性アーキテクチャを比較します。別の高可用性アーキテクチャでは、スタンバイ・サイトのITシステムおよびストレージがスタンバイ・ロールで本番用に使用できます(レポート作成や、エンドユーザーの問合せのプライマリ・システムのオーバーヘッドをオフロードする場合など)。このようなアーキテクチャの利益投資率には、回避された停止時間のコストと、スタンバイ・データベース・ロールでの本番使用で生じる金銭的利益の両方が含まれます。

2.3 高可用性アーキテクチャ要件

次の各項では、高可用性システムの機能、ビジネスのパフォーマンス、予算および成長の計画について詳しく説明します。「正しい高可用性アーキテクチャの選択」も参照してください。

2.3.1 ビジネスのパフォーマンス、予算および成長の計画

高可用性ソリューションでは、最終的にビジネス要件に対処することが必要です。たとえば、プライマリ・データベースのすべてのトランザクションをリモート・データベースに同期的にミラー化する、データ損失ゼロのソリューションを使用したとします。しかし、光速限界およびネットワークに関連する物理的限界を考えると、ネットワーク送信にはラウンドトリップ遅延が発生します。この遅延は距離とともに増大し、ネットワーク帯域幅、トラフィックの輻輳、ルーターの待機時間などによって変化します。したがって、この同期ミラー化を大規模なWide Area Network(WAN)上で実行した場合、プライマリ・サイトのパフォーマンスに影響が出る可能性があります。

オンライン・バイヤーはこうしたシステム待機時間に気づき、システムのレスポンスの遅さに不満を抱きます。その結果、どこか他へ行って購入することになります。これは、データ損失ゼロのソリューションの採用とシステム・パフォーマンスの最大化のいずれかを犠牲にする必要がある例です。逆に、ビジネス推進要因によってこのトレードオフを回避するための投資が正当であると証明されれば、プライマリ・サイトに近いデータ損失ゼロの同期スタンバイ・サイトと、何千マイルも離れた場所にある別の非同期スタンバイ・サイトを配置するマルチサイト・アーキテクチャを実装できます。

高可用性ソリューションでは、財務的な問題および将来的な成長の予測を念頭におくことも必要です。ITインフラストラクチャ全体に冗長性を持たせ、インフラストラクチャの障害対策が万全であることを主張したくなるものです。高可用性は必ずしもコスト増加を意味するわけではありませんが、軽率に判断すると、予算超過に陥るだけでなく、非常に複雑で統合やメンテナンスにコストがかかり、管理性もスケーラビリティもないソリューションの組合せが生まれる可能性があります。

パフォーマンス・ベンチマークですばらしい結果を収めた高可用性ソリューションは、魅力的に思えます。しかし、テクノロジの機能がビジネス推進要因にどのように一致するかを注意深く分析せずにそのようなソリューションに投資することは浅はかです。結果として次のようなソリューションで終わる可能性があります。

- システム・インフラストラクチャの他の部分とうまく統合できません。

- 実装コストを優に上回る統合コストやメンテナンス・コストが毎年かかります。

賢明で思慮深い意思決定者は、適切に統合され、標準に準拠し、実装、メンテナンスおよび管理が容易で、将来的なビジネスの成長に対応できるスケーラブルなアーキテクチャを持つソリューションにのみ投資するはずです。

3 計画外停止時間用Oracle Database高可用性ソリューション

Oracle Databaseは、可用性を高め、計画停止時間と計画外停止時間のいずれもゼロまたは最小限に抑える高可用性ソリューションの統合スイートを提供します。これらのソリューションは、企業が24時間年中無休でビジネスの継続性を維持する場合に役立ちます。一方で、Oracle高可用性ソリューションは、プライマリ・システムおよびセカンダリ・システムでのシステム使用効率を高め、パフォーマンス、スケーラビリティおよび管理性全体の向上を支援するソリューションを提供することにより、停止時間の短縮にとどまらない機能を実現します。

Oracleには、次のような高可用性機能が備わっています。

- ファスト・スタート・リカバリ

- Oracle Restart

- Oracle Real Application ClustersおよびOracle Clusterware

- Oracle RAC One Node

- Oracle Data Guard

- Oracle GoldenGateおよびOracle Streams

- Oracle Flashbackテクノロジ

- Oracle Automatic Storage Management

- 高速リカバリ領域

- Recovery Manager

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

- Oracle Secure Backup

- Oracleセキュリティ機能

- LogMiner

- Oracle Exadata Storage Server Software(Exadataセル)

- Oracle Exadata Database Machine

- Oracle Database File System(DBFS)

- クライアント・フェイルオーバー

- 自動ブロック修復

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

また、第4章「計画停止時間用Oracle Database高可用性ソリューション」では、各種の計画停止時間に対応する主な高可用性ソリューションと、各ソリューションのリカバリ時間の概要について説明します。

関連項目:

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

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

3.1 計画外停止時間用Oracle高可用性ソリューションおよびリカバリ

Oracle Databaseでは、あらゆるタイプの計画外障害に対して停止時間を防止および短縮するための高可用性ソリューションを提供しています。

表3-1は、計画外停止時間に対する様々なOracle高可用性ソリューションの説明です。この表は、3.2項から3.21項で説明した機能を使用して、計画外停止時間の様々な原因に対処する方法を示しています。いくつかのOracleソリューションがリストされている場合、MAA推奨ソリューションはOracleソリューション列に示しています。

また、各Oracle高可用性アーキテクチャでのあらゆるタイプの計画外停止時間に対する達成可能なリカバリ時間の概要は、表7-4を参照してください。

表3-1 計画外停止時間の停止タイプとOracle高可用性ソリューション

停止範囲

Oracleソリューション

利点

サイトの障害

Oracle Data Guard(MAA推奨)

- 統合Oracleクライアントによるファスト・スタート・フェイルオーバーおよびFAN

- フィジカル・レプリカ、高パフォーマンス、すべてのデータ型のサポート

サイトの障害

Oracle GoldenGateおよびOracle Streams

- 柔軟なアクティブ-アクティブ高可用性ソリューション脚注1

サイトの障害

Recovery Manager

- 完全に管理されたデータベース・リカバリおよびOracle Secure Backupとの統合

コンピュータ障害

Oracle Real Application ClustersおよびOracle Clusterware(MAA推奨)

- 障害が発生したノードとインスタンスの自動リカバリ

- 統合Oracleクライアント・フェイルオーバーによる高速アプリケーション通知(FAN)

コンピュータ障害

Oracle RAC One Node

- 常時有効な単一インスタンス・データベース・サービス

- 従来のコールド・フェイルオーバー・ソリューションよりも高いデータベースの可用性

- データベース・サービスの統合

コンピュータ障害

ファスト・スタート・リカバリ

- コンピュータ障害からのチューニングおよび予測可能なキャッシュ・リカバリ

コンピュータ障害

Oracle Data Guard

- 統合Oracleクライアントによるファスト・スタート・フェイルオーバーおよびFAN

コンピュータ障害

Oracle GoldenGateおよびOracle Streams

- 障害発生時に処理を再開するのに使用できる本番データベースのローカルまたはリモート・コピーの作成を容易にする

ストレージ障害

Oracle Automatic Storage Management(MAA推奨)

- ミラー化およびオンライン自動リバランスによる、個別の障害グループへのデータの冗長コピーの配置。

ストレージ障害

Oracle Data Guard(MAA推奨)

- 統合Oracleクライアントによるファスト・スタート・フェイルオーバーおよびFAN

ストレージ障害

高速リカバリ領域およびOracle Secure Backupを使用するRecovery Manager

- 完全に管理されたデータベース・リカバリとディスクおよびテープのバックアップ

ストレージ障害

Oracle GoldenGateおよびOracle Streams

- 本番データベースの(ローカルまたはリモート)オンライン・レプリカ・コピーでの処理の再開

データ破損

Oracle Exadata Storage Server Software(Exadataセル)およびOracle Automatic Storage Management(MAA推奨)

- Oracle ASMでは、破損を検出し、良好なミラーがある場合、良好なブロックを返し、後続の書込みI/O中にその破損を修復

- Exadataセルは、ディスクへの書込みによる破損を防ぐための最も包括的なソリューションです。

データ破損

破損の予防、検出および修復(MAA推奨)

DB_BLOCK_CHECKING、DB_BLOCK_CHECKSUMおよびDB_LOST_WRITE_PROTECTなどのデータベース初期化設定

- 様々なレベルのブロック破損予防とデータベース・レベルでの検出

データ破損

高速リカバリ領域を使用するデータ・リカバリ・アドバイザおよびRecovery Manager(MAA推奨)

- データ・リカバリ・アドバイザでは、データ破損が自動的に検出され、最適なリカバリ計画が推奨されます。

- RMANオンライン・ブロック・メディア・リカバリ時間はより高速です。これは、RMANがフラッシュバック・ログを使用して、リカバリにデータ・ブロックの最新のコピーをリストアできるためです。

データ破損

Oracle Data Guard(MAA推奨)

- フィジカル・スタンバイ・データベースから良好なバージョンを取得することにより、リアルタイムでプライマリ・データ・ブロックを修復

- 統合Oracleクライアントによるファスト・スタート・フェイルオーバーおよびFAN

データ破損

Oracle GoldenGateおよびOracle Streams

- 本番データベースの(ローカルまたはリモート)オンライン・レプリカ・コピーでの処理の再開

人的エラー

Oracleセキュリティ機能

- 予防として、アクセスを限定

人的エラー

Oracle Flashbackテクノロジ

- きめの細かいデータベース全体の巻戻し機能

人的エラー

LogMiner

- REDOログの分析

書込み欠落

Oracle Data Guard、Recovery ManagerおよびDB_LOST_WRITE_PROTECT初期化パラメータ

- DB_LOST_WRITE_PROTECT初期化パラメータでは、書込み欠落が検出されます。

- プライマリ・データベースで発生した書込み欠落がフィジカル・スタンバイ・データベースによって、またはプライマリ・データベースのメディア・リカバリ時に検出されると、リカバリはデータベースの一貫性を保つために停止します。ただし、Oracle Data Guardを使用してスタンバイ・データベースにフェイルオーバーすると、データの一部が失われます。

- 書込み欠落がスタンバイ・データベースで検出される場合、書込み欠落を分離させて、ハードウェアの問題を修正できれば、影響を受けたファイルをリストアして、REDO Applyを再起動できます。
注意: 書込み欠落はデータベース全体を破損する可能性があり、ハードウェアの問題を解決した後に、影響を受けたデータベースを再構築することが必要になります。

書込み欠落

Oracle Data Guard

Oracle Exadata Storage Server Software(Exadataセル)

- 別のデータ・ファイルへの誤った(宛先違いの)書込みの検出および予防。

- 最も包括的な書込みの欠落の防止には、Oracle Data Guardを使用し、プライマリおよびスタンバイ・データベースの両方でDB_LOST_WRITE_PROTECTパラメータを(TYPICALまたはFULLに)設定します。

停止または減速

Oracle DatabaseおよびOracle Enterprise Manager

- Oracle Databaseは、自動的にデータベースの停止を監視し、解決しようとします。

- アプリケーションまたはレスポンス時間の減速を検出し、これらのSLA違反に対応するようにOracle Enterprise Managerまたはカスタマイズしたアプリケーションのハートビートを構成できます。
たとえば、Enterprise Managerのビーコンを構成して、アプリケーションのレスポンス時間を監視および検出できます。一定のしきい値に到達すると、Enterprise ManagerによってOracle Data GuardのDBMS_DG.INITIATE_FS_FAILOVER PL/SQLプロシージャがコールされ、フェイルオーバーが開始されます。『Oracle Data Guard Broker』の、アプリケーションによって開始されるファスト・スタート・フェイルオーバーに関する項を参照してください。

脚注1アプリケーションにより競合が回避または管理できる場合に有効です。アクティブ・アクティブ構成では通常、データの競合が回避されるか、少なくともアプリケーションにより管理される必要があります。そのため、リアルタイム・レプリケーションのためのアクティブ-アクティブ・アーキテクチャはカスタム・アプリケーションにより適してします。

3.2 ファスト・スタート・リカバリ

Oracle Databaseには、システム・フォルトとデータベース障害からの高速で予測可能なリカバリ機能があります。Oracle Databaseに含まれているファスト・スタート・リカバリ・テクノロジは、セルフチューニングされるチェックポイント処理を使用して、起動時にインスタンス・リカバリ時間を自動的に制限します。これにより、リカバリ時間を高速で予測可能なものにし、サービス・レベルの目標の達成能力を高めます。Oracleのファスト・スタート・リカバリ機能によって、負荷の多いデータベースのリカバリ時間を数十分から数秒に短縮できます。

ファスト・スタート・リカバリ機能には次のものがあります。

- インスタンス障害、データベース障害およびコンピュータ障害からの、予測可能で、制限的なリカバリ

- 希望のリカバリ時間目標を維持するためのセルフチューニングであるデータベース・チェックポイント

関連項目:
Oracle Databaseパフォーマンス・チューニング・ガイド

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

- プラットフォームの詳細は、Oracle Grid Infrastructureインストレーション・ガイドを参照

3.4 Oracle Real Application ClustersおよびOracle Clusterware

Oracle Real Application Clusters(Oracle RAC)とOracle Clusterwareを使用すると、Oracle Databaseはクラスタ化された一連のサーバー全体にパッケージまたはカスタム・アプリケーションを実行できます。この機能により、高いレベルの可用性および最も柔軟的なスケーラビリティが得られます。クラスタ化されたサーバーに障害がある場合でも、Oracle Databaseは残りのサーバー上で稼働し続けます。より高い処理能力が必要なときは、データへのユーザーのアクセスを中断することなく、他のサーバーを追加できます。

Oracle RACを使用すると、インターコネクトでリンクされた複数のインスタンスによるOracleデータベースへのアクセスの共有が可能になります。Oracle RAC環境では、単一の共有データベースに同時にアクセスしている間、Oracle Databaseはクラスタ内の2つ以上のシステム上で稼働します。その結果、複数のハードウェア・システムにまたがる単一データベース・システムとなり、Oracle RACではクラスタ内での障害時に高可用性と冗長性を提供できます。Oracle RACは、読取り専用のデータ・ウェアハウス・システムから更新頻度の高いオンライン・トランザクション処理(OLTP)システムまで、あらゆるタイプのシステムに対応しています。

Oracle Clusterwareは、同じオペレーティング・システムを実行するサーバーにインストールされる場合、これらのサーバーが連係して単一サーバーとして機能できるようにして、ユーザー・アプリケーションとOracleデータベースの可用性を管理するソフトウェアです。また、ノードのメンバーシップ、グループ・サービス、グローバルなリソース管理、高可用性機能といったクラスタ管理に必要な機能もすべて提供します。

- 高可用性については、Oracleデータベース(単一インスタンスまたはOracle RACデータベース)とユーザー・アプリケーション(OracleおよびOracle以外)をOracle Clusterwareの管理と保護の下に置いて、プロセス障害時にはデータベースとアプリケーションが再起動し、ノード障害後には別のノードへのフェイルオーバーが行われるようにすることができます。

- クラスタ管理については、複数の独立したサーバーがまるで単一システムのイメージまたは単一の仮想サーバーであるかのように示されます。この単一の仮想サーバーは、すべての管理操作に対してクラスタ全体で維持されるため、管理者はインストール、構成、バックアップ、アップグレードおよび監視の機能を実行できます。その後、Oracle Clusterwareが、これらの管理機能の実行を、クラスタ内の該当するノードに自動的に分散します。

Oracle Clusterwareは、Oracle RACを使用するための要件です。Oracle Clusterwareは、Oracle RACが動作する大部分のプラットフォームに必要な唯一のクラスタウェアです。Oracle Databaseでは引き続きサード・パーティのクラスタウェア製品を指定されたプラットフォームでサポートしますが、Oracle Clusterwareを使用すれば、次の主な利点があります。

- ベンダー独自開発のクラスタウェアが不要

- Oracle Automatic Storage Management(Oracle ASM)によるディスク管理を提供するOracleから、Oracle DatabaseおよびOracle RACによるデータ管理まで、統合ソフトウェア・スタックを使用

さらに、OracleサービスなどのOracle Database機能では、Oracle Clusterwareの基本的なメカニズムを使用して、それらの機能を提供します。

Oracle Clusterwareには2つのクラスタウェア・コンポーネントが必要です。1つはノード・メンバーシップ情報を記録する投票ディスク、もう1つはクラスタ構成情報を記録するOracle Cluster Registry(OCR)です。投票ディスクとOCRは共有ストレージに存在する必要があります。Oracle Clusterwareでは、各ノードがプライベート・インターコネクト経由でプライベート・ネットワークに接続されている必要があります。

詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

3.4.1 Oracle Clusterware使用の利点

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

- コンピュータおよびインスタンス障害を許容し、迅速にリカバリします。

- Oracle ClusterwareとOracle Databaseの併用により、管理およびサポートを単純に行えます。少数のベンダーとすべてのOracleスタックを使用することで、サード・パーティ・クラスタウェアを使用した場合より優れた統合を得られます。

- システム変更およびハードウェア変更のローリング・アップグレードを実行します。たとえば、次のようなローリング方式で、Oracle Clusterwareのアップグレード、パッチ・セットおよび個別パッチを適用できます。

- Oracle ClusterwareをOracle Database 10gからOracle Database 11gにアップグレード

- Oracle ClusterwareをOracle Databaseリリース11.1からリリース11.2にアップグレード

- Oracle Database 11.1.0.6から11.1.0.7へのパッチをOracle Clusterwareに適用

- Oracle Database 10.2.0.2 Bundle 1からOracle Database 10.2.0.2 Bundle 2へのパッチをOracle Clusterwareに適用

- エラーが発生したOracleプロセスを自動的に再開。

- 仮想IP(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.4.2 Oracle Real Application ClustersおよびOracle Clusterware使用の利点

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

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

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

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

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

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

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

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

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

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

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

3.5 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の開発およびテスト・プラットフォームのコストの低減

- Oracle Data Guardを使用して構成された、Oracle RACプライマリおよびスタンバイ・データベースの再配置(この機能はOracle Database 11gリリース2(11.2.0.2)から使用可能)

また、データベース記憶域の統合を促進し、データベース環境を標準化し、必要な場合は、完全な複数インスタンスOracle RACデータベースに停止時間または中断なしに移行することができます。

詳細は、7.1.3項を参照してください。

3.6 Oracle Data Guard

Oracle Data Guardは、企業データの高可用性、データ保護および障害時リカバリを保証します。Oracle Data Guardは、Oracleデータベースが災害およびデータ破損に耐えられるよう、1つ以上のスタンバイ・データベースの作成、メンテナンス、管理および監視を行うサービスの包括的なセットを提供します。Oracle Data Guardでは、スタンバイ・データベースがトランザクション的に一貫したプライマリ(本番)・データベースのコピーとしてメンテナンスされます。計画停止または計画外停止によりプライマリ・データベースが使用できなくなった場合は、任意のスタンバイ・データベースをプライマリ・ロールに切り替えて、停止に伴う停止時間を最小限に抑えることができます。Oracle Data Guardを従来のバックアップ、リストアおよびクラスタ技術とともに使用すると、高度なデータ保護およびデータ可用性が提供されます。Oracle Data Guardでは、管理者は、必要に応じて、リソース集中型バックアップ操作およびレポート作成操作をスタンバイ・システムにオフロードすることによって、プライマリ・データベースのパフォーマンスを向上できます。

Oracle Data Guard構成は、1つのプライマリ・データベースと1つ以上のスタンバイ・データベースからなります。プライマリ・データベースは、単一インスタンスOracleデータベースまたはOracle RACデータベースのいずれかになります。プライマリ・データベースのバックアップ・コピーを使用して、最大30のスタンバイ・データベースの作成およびOracle Data Guard構成への統合が可能です。スタンバイ・データベースが作成されると、Oracle Data Guardは、このスタンバイ・データベースにプライマリ・データベースからREDOデータを送信および適用して、自動的に各スタンバイ・データベースのメンテナンスを行います。

プライマリ・データベースと同様に、スタンバイ・データベースは、単一インスタンスOracleデータベースまたはOracle RACデータベースのいずれかになります。

スタンバイ・データベースは、フィジカル・スタンバイ・データベース、スナップショット・スタンバイ・データベース、ロジカル・スタンバイ・データベース、一時ロジカル・スタンバイ・データベースまたはOracle Active Data Guardのいずれかになります。Oracle Data Guard構成にはこのようなスタンバイ・データベースの種類の組合せ(フィジカル・スタンバイ・データベース、スナップショット・スタンバイ・データベースおよびロジカル・スタンバイ・データベース)を含めることができます。

Oracle Data Guard使用の利点

Oracle Data Guardには次のような利点があります。

- リアルタイムでトランザクション的に一貫したデータベースのコピーが保持されるため、計画外の停止時間および災害からの保護を実現。

- コンピュータ障害、人的エラー、データ破損、書込み欠落およびサイト障害からのデータ保護および迅速な修復。

- すべてのネットワーク構成とビジネス要件をサポートする、柔軟性の高いデータ保護レベルを備えた自動フェイルオーバー。

- 様々な強化機能による、REDO適用、REDO転送およびロール遷移の高速化。

- システム変更、一部のプラットフォームの移行、ハードウェアおよびシステムのアップグレード、Oracleパッチ・セットとデータベースのアップグレードを目的とした計画停止時間の短縮(表4-1も参照)。

- システム・パフォーマンス要件に対し、データ可用性のバランスを取るための複数レベルのデータ保護およびパフォーマンス。

- 問合せ機能およびレポート作成機能をプライマリ・データベースからスタンバイ・データベースに転送することにより、システム・リソースの使用効率の向上を実現する、スケーラブルで可用性の高いリーダー・ファームの構成をサポート

- レポート作成またはテスト(クローニング)を目的とするスナップショット・スタンバイ・データベースのサポート、およびレポート作成またはテスト完了後のプライマリ・データベースとの自動再同期化。

- シームレスなアプリケーション接続および透過的なフェイルオーバーのための自動アプリケーション通知のサポート。

- フェイルオーバーに続く、障害が発生したプライマリ・データベースの自動再同期化。

- 管理を簡素化するため、すべてのシステムを単一の構成として管理。

- プライマリ・システムとスタンバイ・システムで異なるCPUアーキテクチャ、オペレーティング・システム(WindowsとLinuxなど)、オペレーティング・システム・バイナリ(32ビットと64ビット)、Oracleデータベース・バイナリ(32ビットと64ビット)が使用されているOracle Data Guard構成の柔軟性の向上(http://support.oracle.com/のサポート・ノート413484.1に定義されている制限が前提)。

3.6.1 フィジカル・スタンバイ・データベース

フィジカル・スタンバイ・データベースは、プライマリ・データベースの物理的に同一なコピーになります。このコピーにはプライマリ・データベースと同一のデータ・ファイルがあります。索引などのデータベース・スキーマは同じです。また、フィジカル・スタンバイ・データベースは、REDO Applyによってプライマリ・データベースと同期化され、プライマリ・データベースから受信したREDOデータをリカバリし、フィジカル・スタンバイ・データベースに適用します。

障害リカバリ以外のビジネス目的で、フィジカル・スタンバイ・データベースを使用できます。たとえば、次のことができます。

- REDOデータがスタンバイ・データベースに適用されている間、読取り専用アクセス用に開くことができます。このモードはOracle Active Data Guardオプションまたはリアルタイム問合せと呼ばれ、障害リカバリおよびOracle Databaseのデータ保護を提供しながら、ユーザーは最新のフィジカル・スタンバイ・データベースにアクセスできます。詳細は、3.6.2項を参照してください。

- Oracle Active Data Guardを使用して、高速増分バックアップをスタンバイ・データベースにオフロードします。

- プライマリ・データベースからのバックアップ実行のオーバーヘッドをオフロードできます。これが可能なのは、フィジカル・スタンバイ・データベースがプライマリ・データベースの完全なコピーであるためです。

- フィジカル・スタンバイ・データベースを一時的なロジカル・スタンバイ・データベースに一時的に変換して、ローリング・アップグレードを実行します。3.6.3項を参照してください。

- フィジカル・スタンバイ・データベースをスナップショット・スタンバイ・データベースに一時的に変換して、クローンまたはテスト・データベースとして使用します。3.6.4項を参照してください。

- フィジカル・スタンバイ・データベースをロジカル・スタンバイ・データベースに変換します。

フィジカル・スタンバイ・データベースの利点

フィジカル・スタンバイ・データベースには、次の全体的な利点があります。

- プライマリ・データベースの物理的なブロック対ブロックのコピーを保証

- リアルタイムのレポート作成のためにREDO Applyがアクティブになっている間に、読取り専用問合せ用にオープン可能(3.6.2項で説明されているActive Data Guardオプションが必要)

- ロール遷移時に、スタンバイ・データベースが古いプライマリ・データベースの正確なレプリカであることを保証

- プライマリ・データベースからのバックアップのオフロードに使用可能

- 非常に高いパフォーマンス、ワークロード・プロファイルに対する完全な透過性を提供

- データ型制限なし

- 計画された多数のメンテナンス・イベントに対する停止時間の最短化に便利

3.6.2 Oracle Active Data Guard

Oracle Active Data GuardはOracleデータベースのデータ保護および障害時リカバリに対するOracleの戦略的機能です。

Oracle Active Data Guardは、Oracle Data Guardのインフラストラクチャの組込みオプションで、プライマリ・データベースから変更が適用されている間も、フィジカル・スタンバイ・データベースを読取り専用で開くことができます。これにより、読取り専用アプリケーションは、プライマリ・データベースで非常に大きいトランザクション・ボリュームの処理中であっても、スタンバイ・データベースとプライマリ・データベース上のデータ間での遅延を最小限に抑えながら、フィジカル・スタンバイを使用できます。これはリアルタイム問合せと呼ばれることもあります。

注意:
Oracle Active Data Guardのリアルタイム問合せ機能を使用すると、REDO Applyがアクティブである間、フィジカル・スタンバイ・データベースを読取り専用で開くことができます。Oracle Active Data GuardはOracle Enterprise Editionの別個のデータベース・オプションとしてパッケージ化されています。本番データベースおよびOracle Active Data Guardオプションに使用されるすべてのフィジカル・スタンバイ・データベースにライセンスが必要です。

Oracle Active Data Guardスタンバイ・データベースは、アプリケーションに透過的に、プライマリ・データベースにより検出されたデータ破損の自動修復に使用されます。プライマリ・データベースでの計画外停止の場合も、スタンバイ・データベースへの迅速なフェイルオーバーにより高可用性が保たれます。Active Data Guardスタンバイ・データベースを使用して、プライマリのブロック対ブロックのフィジカル・レプリカである特定のプライマリ・データベースから高速増分バックアップをオフロードすることもできます。

Oracle Active Data Guardの利点

Oracle Active Data Guardには次のような利点があります。

- 既存のフィジカル・スタンバイ・データベースを本番用に使用

- スタンバイ・データベースに処理をオフロードすることによりプライマリ・データベースのパフォーマンスが向上

- プライマリ・データベースからアクティブ・スタンバイに高速増分バックアップをオフロードすることによりバックアップのパフォーマンスが向上

- ユーザーおよびアプリケーションに透過的に、アクティブ・スタンバイがプライマリ・データベースで検出されたブロック破損を自動的に修復可能(逆も同様)

- レポート用のリアルタイムのデータ・アクセスを提供

- Business Intelligence、EPMおよびOracle Exadata用のリアルタイム・データを提供

- リーダー・ファームを介して、障害時リカバリを維持しながら、読取りパフォーマンスのスケールを変更する柔軟なオプションを提供します。

3.6.3 一時的なロジカル・スタンバイ・データベース

一時的なロジカル・スタンバイ・データベースでは、現在のフィジカル・スタンバイ・データベースを一時的にロジカル・スタンバイに変換して、ローリング・データベース・アップグレードを実行し、停止時間を最小限に抑えて再利用できます。

ローリング・データベース・アップグレードに対するMAA推奨のベスト・プラクティスは、一時的なロジカル・スタンバイ・データベースおよび、Oracleパッチ・セットまたは完全データベース・リリースへのデータベースのローリング・アップグレードを自動化するBourneシェル・スクリプト(Oracleにより作成)を使用します。データベースのローリング・アップグレードは、既存のData Guardフィジカル・スタンバイ・データベースおよび一時的なロジカル・スタンバイ・ローリング・アップグレード・プロセスを使用して実行されます。

physruという名前のBourneシェル・スクリプトは、アップグレード手順のほとんどを自動化することにより、ローリング・データベース・アップグレードの実行の複雑さを軽減します。スクリプトには、Oracle RACおよび単一インスタンス・データベースの両方のアップグレードを処理する機能を含む、多くの利点があります。physruスクリプトはアップグレード・タスクを自動化しますが、一時的なロジカル・データベース・ローリング・アップグレードの実行の手動プロセスと同じ前提条件および制限が適用されます。たとえば、 拡張データ・タイプへの対応には拡張データ型サポート(EDS)の実装が必要な場合があります。

関連項目:
次のMAAベスト・プラクティス・ホワイト・ペーパーを参照してください。

- 一時的なスタンバイ・データベースおよびphysruスクリプトを使用したローリング・アップグレードの実行の手順については、「Database Rolling Upgrades Made Easy by Using a Data Guard Physical Standby Database」を参照してください。

- 「Database Rolling Upgrades Using Transient Logical Standby: Oracle Data Guard 11g」および前提条件、制限、要件を十分理解するには、特に制限に関する一般的な情報およびデータ型のサポートの確認に関する項を参照してください。

- ロジカル・スタンバイ・データベースが本来サポートしないデータ型に対応する方法は、「Extended Datatype Support(EDS) for Oracle Data Guard SQL Apply and Oracle Streams」を参照してください。

これらのホワイト・ペーパーはMAA Webサイトから入手可能です。

http://www.oracle.com/goto/maa

一時的なロジカル・スタンバイ・データベースの利点

一時的なロジカル・スタンバイ・データベースには、次の全体的な利点があります。

- 本番アプリケーションおよびクライアントをアップグレードしたシステムへ切り替える前に、完全に別のシステムおよびデータベースで変更を適用およびテストできます。

- PL/SQLの再コンパイルなどの、従来のデータベース・アップグレードに関連する多くの一般的なタスクに必要な計画停止をなくすことで、可用性を大幅に改善します。

- データベース・ローリング・アップグレードに既存のフィジカル・スタンバイ・データベースを利用します。つまり、ローリング・アップグレードのためだけに、別のロジカル・スタンバイ・データベースをデプロイする作業または追加のストレージは必要ありません。

- プライマリおよびスタンバイ・データベースの両方を新しいOracleリリースに移行するための単一カタログのアップグレードのみを実行する必要があります。

- アプリケーションおよびクライアントを新しい環境に切り替える前に、アップグレードおよびシステムの追加の検証が可能です。

- アップグレード・プロセスの完了時には、プライマリ・データベースおよびフィジカル・スタンバイ・データベースは両方とも新しいOracleリリースで実行します。

関連項目:

- 様々な状況でのローリング・アップグレード方針については、4.1項「計画停止時間用Oracle高可用性ソリューションおよびリカバリ時間」を参照してください。

- 複数のスタンバイ・データベース・アーキテクチャの詳細は、7.1.5.2項を参照してください。

3.6.4 スナップショット・スタンバイ・データベース

スナップショット・スタンバイ・データベースは、更新可能なスタンバイ・データベースに一時的に変換されたフィジカル・スタンバイ・データベースです。スナップショット・スタンバイ・データベースをクローンまたはテスト・データベースとして使用して、新しい機能や新しいリリースを検証でき、その終了後は、データベースをフィジカル・スタンバイに変換できます。スナップショット・データベース・ロールで実行している間も、REDOデータの受信およびキューへの保存は継続するので、データ保護およびRPOが犠牲になることはありません。

スナップショット・スタンバイ・データベースは、プライマリ・データベースからREDOデータを受信してアーカイブすることでプライマリ・データベースのデータを常時保護しますが、スタンバイが読取り/書込みアクセス用にオープンしているときにはプライマリ・データベースのREDOデータを適用しません。そのため、スナップショット・スタンバイは、時間が経過するにつれてプライマリ・データベースと異なるものになります。REDO Applyは、スナップショット・スタンバイ・データベースをフィジカル・スタンバイ・データベースに戻し、スナップショット・スタンバイ・データベースに対して行われたローカルな更新がすべて破棄されるまでREDOデータを適用しません。スナップショット・スタンバイ・データベースのローカルな更新によって相違は増えますが、プライマリ・データベースのデータは、スタンバイ・サイトにあるREDOログによって完全に保護されます。

1つのコマンドでスナップショット・スタンバイをフィジカル・スタンバイ・データベースに戻すことができます。このとき、スナップショット・スタンバイ状態に加えられた変更が破棄され、アーカイブされたREDOを使用してフィジカル・スタンバイ・データベースとプライマリ・データベースがREDO Applyによって自動的に再同期化されます。

スナップショット・スタンバイ・データベースの利点

スナップショット・スタンバイ・データベースには、次の全体的な利点があります。

- フィジカル・スタンバイ・データベースのすべての属性を継承

- プライマリ・データベースとは無関係に、読取り/書込みI/O用にオープン可能、およびトランザクション処理可能

- 読取り/書込みI/O用にオープン中のプライマリ・データベースを保護

- 1つのコマンド発行により、スナップショット・スタンバイ・データベースを同期化したフィジカル・スタンバイ・データベースに変換可能

- 特にOracle Real Application Testingと組み合せたときに、理想的なテスト・システムを実現

3.6.5 ロジカル・スタンバイ・データベース

ロジカル・スタンバイ・データベースには、プライマリ・データベースと同じ論理的な情報が含まれますが、データの物理的な編成と構造は異なります。ロジカル・スタンバイ・データベースは、SQL Applyによってプライマリ・データベースと同期化されます。SQL Applyは、プライマリ・データベースから受信したREDOデータをSQL文に変換し、スタンバイ・データベースでそのSQL文を実行します。

ロジカル・スタンバイ・データベースの利点

ロジカル・スタンバイ・データベースには、次の全体的な利点があります。

- ロジカル・スタンバイ・データベースの主な利点は、レポート作成のワークロードを最適化する重要な補助構造(プライマリ・データベースのトランザクションのレスポンス時間に対する抑制効果をもたらす構造など)を作成できることです。ロジカル・スタンバイ・データベースは次のことが可能です。

- データを、様々な索引を持ち、オンデマンドのリフレッシュ・マテリアライズド・ビューを作成および維持し、パーティションが異なる別のタイプの記憶域に物理的に再編成可能。マテリアライズド・ビューの概要は、『Oracle Database概要』を参照してください。

- データ・キューブおよびその他のOLAPデータ・ビューの作成を実行するために使用可能。詳細は、『Oracle OLAP Java API開発者ガイド』を参照してください。

- 障害リカバリ要件の達成、ユーザーに対する問合せ用のロジカル・スタンバイ・データベースへのアクセスの許可、レポート作成といった目的に加えて、いつでも他のビジネス目的に使用可能。

- Oracle Databaseソフトウェアとパッチ・セットをほとんど停止時間なしでアップグレードするために使用可能。

このように、データ保護、レポート作成およびデータベースのアップグレード目的でロジカル・スタンバイ・データベースを同時に使用することができます。

- プライマリ・データベースの論理的なトランザクション対トランザクションのコピーを提供

- 追加オブジェクトの作成、オブジェクトの変更が可能

- 特定のオブジェクトに対する適用のスキップ機能

- リアルタイムのレポート作成をサポート

- 読取り/書込みI/O用にオープン(SQL Apply用に保持されている表内のデータは変更不可能)

- ソフトウェア・アップグレードに対する停止時間の最小化(SQL Applyを使用したOracle Databaseソフトウェアのローリング・アップグレードの実行方法は『Oracle Data Guard概要および管理』を参照。)

3.7 Oracle GoldenGateおよびOracle Streams

Oracle GoldenGateはデータ分散とデータ統合に関するOracleの戦略的な製品です。これは高パフォーマンスのソフトウェア・アプリケーションで、ログ・ベースの双方向データ・レプリケーションを使用して、リアルタイムの取得、変換、ルーティング、異機種システム間のデータベース・トランザクションの配信を行います。Oracle GoldenGateにより、ミッションクリティカルなデータのリアルタイム統合および連続可用性が達成されます。詳細は、3.7.1項を参照してください。

Oracle Streamsは非常に柔軟で強力なデータベース・レプリケーション機能です。Oracleではこの機能へのサポートを継続する予定ですが、今後のリリースで大きな機能強化は行われない予定です。投資利益率を最大化するために既存のOracle Streamsデプロイメントを使用し続けることができます。ただし、組織向けの長期的なレプリケーション計画として、Oracle GoldenGateを検討する必要があります。Oracle Streamsのデータ・レプリケーションおよび統合の詳細は、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』、『Oracle Streams概要および管理』および『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

Oracle GoldenGateはOracle Streamsの多くの優れた機能を強化し、両者の長所を生かした情報分散ソリューションを作成していきます。

3.7.1 Oracle GoldenGateの概要

Oracle GoldenGateは非同期、ログ・ベース、リアルタイムのデータ・レプリケーション製品で、異機種データベース、ハードウェアおよびオペレーティング・システム環境間で、影響を最小限に抑えながら、大量のトランザクション・データを移動します。

典型的な環境として、取得、ポンプおよび配信プロセスがあります。これらの各プロセスは、Oracle Databaseおよび非Oracleデータベースを含む、ほとんどの一般的なオペレーティング・システムおよびデータベースで実行できます。データのすべてまたは一部をレプリケートすることができ、プロセス内のデータは、異機種環境だけでなく、異なるデータベース・スキーマでも操作できます。Oracle GoldenGateはマルチマスター・レプリケーション、ハブ・アンド・スポーク方式のデプロイメントおよびデータ変換をサポートします。したがって、Oracle GoldenGateにより、クリティカルなシステムの24時間365日の稼動が可能になり、関連データを企業内に分散させて意思決定を最適化できます。

Oracle GoldenGateはプラットフォームの移行に加えて、アプリケーションおよびデータベースのアップグレードなどの、計画メンテナンス中の停止時間を最小化するための優れた方法でもあります。

Oracle GoldenGateの利点

Oracle GoldenGateは次の理由で、リアルタイムの情報アクセスおよび可用性を最適化します。

- Oracle Databaseおよび非Oracleデータベースの異機種混合を含むレプリケーションをサポートします。

- ミッションクリティカルなシステムの継続的な可用性を維持します。

- 障害時リカバリおよびデータ保護
最新のデータを使用した即時フェイルオーバー・サイトを作成および維持し、ミッションクリティカルなシステムのリカバリ時間を最小限に抑えます。

- 停止時間ゼロ操作
システム・アップグレード、移行およびメンテナンス・アクティビティ中も業務を中断させないことが可能です。

- データ分散
可用性およびスケーラビリティの向上のために、リアルタイムで分散アプリケーションのデータを同期させます。

- 問合せのオフロード
異機種ソースおよびターゲット間でデータをレプリケートすることにより、必要な読取り専用アクティビティをサポートしながら、本番システムでの高いパフォーマンスを保証します。

- 企業内でリアルタイムのデータ統合を可能にします。

- リアルタイム・データ・ウェアハウス
OLTPシステムおよびデータ・ウェアハウス間で、最新の変更データの連続的でリアルタイムの取得および配信を提供します。

- 操作レポート
レポート・アクティビティを、本番データベースから、リアルタイム・レポート用の現在のデータが含まれる、より低コストのセカンダリ・システムにオフロードします。

- 操作データの統合
OLTPシステム間の操作データをリアルタイムで統合します。

3.7.2 Oracle GoldenGateとOracle Active Data Guardの使用

Oracle Golden GateおよびOracle Active Data GuardはOracleのソフトウェア・ポートフォリオ内の戦略的機能であり、互いに補完するものです。Oracle GoldenGateとOracle Active Data Guardを一緒に使用することで、他の製品では提供できない、ユニークなデータ保護および情報分散のソリューションが提供されます。

注意:
Oracle GoldenGateはOracleおよびサード・パーティのデータベース管理システム用のOracle Databaseとは別に販売されているOracle製品です。これはOracle Database Enterprise EditionおよびOracle Database Standard Editionの両方で使用できます。Oracle GoldenGateのライセンスには、Oracle Active Data Guardのライセンスが含まれます。

どちらの機能も一般的にはレプリケーション・テクノロジのカテゴリに分類されますが、重点を置く領域が大きく異なります。

- Oracle Active Data GuardはOracle Databaseのデータ保護および障害時リカバリに対するOracleの戦略的製品です。
Oracle Active Data GuardはOracle Database Enterprise Editionに含まれる標準のData Guard機能のサブセットなので、Active Data GuardもData Guardのすべての機能を継承します。

- すべてのデータ型、記憶域属性、DMLおよびDDL間で透過的な操作

- データベース全体の単純な一方向レプリケーションによる、管理の簡易さ

- 優れた破損保護

- 非同期または同期(データ損失ゼロ)保護の選択

- 自動データベースおよびクライアント・フェイルオーバーによる計画外イベント中の高可用性

- プライマリおよびスタンバイ・データベース間でのローリング方式による、データベース・アップグレードの実装、システムおよびサイトのメンテナンスまたはテクノロジの更新による停止時間を最小化

Oracle Active Data Guardには別個のライセンスが必要で、Oracle Database Enterprise Editionとともに使用します。Oracle Database Enterprise EditionのActive Data Guardオプションとして購入できます。また、Oracle GoldenGateにも含まれています。基本Data Guard機能には別個のライセンスは必要なく、Oracle Enterprise Editionに含まれています。Oracle Active Data Guardについては、3.6.2項を参照してください。

- Oracle GoldenGateはデータ分散およびデータ統合に関するOracleの戦略的製品です。
Oracle GoldenGateはその異機種間および双方向のレプリケーション機能によりActive Data Guardを補完し、企業全体にわたる情報分散、停止時間ゼロのアップグレードおよび移行、異機種システムへの問合せのオフロードおよびマルチマスター・データベース・ソリューションを可能にします。

ビジネスの状況に応じて次のように選択します。

- Oracle Active Data Guardを選択して、Oracleデータベース全体の障害時リカバリ、データ保護および高可用性に対する、単純で高パフォーマンスなドロップイン・ソリューションを実現します。

- Oracle GoldenGateを選択して、Oracle間レプリケーション構成によるデータ分散およびデータ同期ソリューション、またはより柔軟なマルチマスターHAソリューションを実現します。

図3-1は、Oracle Data Guardフィジカル・スタンバイ・データベースが最適なデータ保護およびプライマリ・データベースからの読取り専用ワークロードのオフロードを提供する構成を示しています。また、本番データベースの様々なサブセットの複数のターゲット・データベースへの異機種間レプリケーションを提供します。本番データベースでのホストOracle GoldenGateレプリケーションではなく、Oracle GoldenGate取得プロセスが、アーカイブされたREDOログから変更が取得されレプリケートされるフィジカル・スタンバイ・データベースにオフロードされます。本番システムにOracle GoldenGateの処理のオーバーヘッドは必要ありません。

図3-1 計画外停止に対するOracle GoldenGateおよびOracle Data Guard

Oracle GoldenGateは、アプリケーションおよびデータベースのアップグレードやプラットフォームの移行などの、計画メンテナンス中の停止時間を最小化するための優れた方法でもあります。

関連項目:

- データベース・アップグレードを実行するためのOracle GoldenGateの使用の詳細は、4.1.9.3項を参照してください。

- プラットフォーム移行を実行するためのOracle GoldenGateの使用の詳細は、4.1.10.2項を参照してください。

3.8 Oracle Flashbackテクノロジ

フラッシュバック・テクノロジは、過去の様々な時点におけるデータのビューを切り替えるための一連の機能を提供します。フラッシュバック機能を使用すると、スキーマ・オブジェクトの過去のバージョンや履歴データを問い合せることができます。また、変更分析の実行、データベースをオンラインにしたまま論理的破損からリカバリするセルフサービス修復も可能になります。

フラッシュバック・テクノロジは、人的エラーの分析および修復を素早く行うためのSQLインタフェースを提供します。フラッシュバック・テクノロジでは、誤った顧客オーダーの削除など、局部的な損傷のきめ細かな分析および修復が行われます。フラッシュバック・テクノロジを使用すると、より広範な損傷の修正も可能になります。しかも、修正は迅速に行われるため、停止時間が長期化することはありません。フラッシュバック・テクノロジはOracle Databaseに特有のものであり、行、トランザクション、表、表領域、データベースなどのあらゆるレベルでのリカバリをサポートしています。

他の機能(フラッシュバック・データベースやブロック・メディア・リカバリなど)ではフラッシュバック・ログが使用されるのに対し、ほとんどのフラッシュバック機能ではUNDOデータが使用されます。

- UNDO表領域: データベースが自動UNDO管理モードで実行される場合に、UNDO情報のみが格納される専用表領域。

- フラッシュバック・データ・アーカイブ: 表領域に格納されるアーカイブ。レコードの存続期間中に表のすべてのレコードに対して行われたトランザクションの変更が含まれます。アーカイブされたデータは、UNDO表領域で提供される保存期間よりも長く保存できます。

- フラッシュバック・ログ: フラッシュバック・データベース操作またはブロック・メディア・リカバリ操作の実行に使用されるOracle生成ログ。データベースは、高速リカバリ領域にのみフラッシュバック・ログを書き込むことができます。フラッシュバック・ログは連続して書き込まれ、アーカイブされません。このログをディスクにバックアップすることはできません。

次の各項で、フラッシュバック機能について説明します。

3.8.1 Oracle Flashback Query

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

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

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

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

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

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

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

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

詳細は、『Oracle Database開発ガイド』を参照してください。

3.8.2 Oracle Flashback Version Query

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

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

詳細は、『Oracle Database開発ガイド』を参照してください。

3.8.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.8.4 Oracle Flashback Transaction Query

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

詳細は、『Oracle Database開発ガイド』を参照してください。

3.8.5 Oracle Flashback Table

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

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

3.8.6 Oracle Flashback Drop

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

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

3.8.7 Oracle Flashbackのリストア・ポイント

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

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

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

- スナップショット・スタンバイとプライマリ・データベースの再同期化が可能

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

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

3.8.8 Oracle Flashback Database

Oracle Flashback Databaseは、データベースのポイント・イン・タイム・リカバリよりも効率的な代替策です。Oracle Flashback Databaseを使用すると、現行のデータ・ファイルを過去の内容に戻すことができます。つまり、データ・ファイルのバックアップからデータをリストアして、データベースのポイント・イン・タイム・リカバリを実行する場合とほぼ同じです。ただし、フラッシュバック・データベースではデータ・ファイルのリストアとほとんどのREDOデータの適用が省略されます。

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

- データベース全体に影響を与える人的エラー修正時のバックアップのリストア時間を排除

- リアルタイム適用を使用してスタンバイ・データベースとプライマリ・データベースを同期化することにより、人的エラーを素早く元に戻すことが可能

- データベースのフェイルオーバー後、スタンバイ・データベースの迅速な再インスタンス化が可能

参照:

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

- 『Oracle Database SQL言語リファレンス』

3.8.9 フラッシュバック・ログを使用したブロック・メディア・リカバリ

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

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

関連項目:

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

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

- 3.20項「自動ブロック修復」

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

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

詳細は、『Oracle Database開発ガイド』を参照してください。

3.9 Oracle Automatic Storage Management

Oracle ASM は、垂直方向に統合されたファイル・システムおよびボリューム・マネージャを直接Oracle Databaseカーネル内に構築し、次の機能を提供します。

- データベース・ストレージのプロビジョニングに必要な作業量を大幅に削減

- より高いレベルの可用性

- 特殊なストレージ製品のコスト、インストールおよびメンテナンスを排除

- データベース・アプリケーションの固有の機能

最適なパフォーマンスを実現するため、Oracle ASMは、ファイルをすべての使用可能なストレージ間で分散させます。また、データ損失から保護するために、Oracle ASMは、SAME(Stripe and Mirror Everything)の概念を拡大して、ディスク全体のレベルではなくデータベース・ファイル・レベルでのミラー化が可能となるように、SAMEにより柔軟性を持たせます。

さらに重要なことに、Oracle ASMは、ミラー化の設定、ディスクの追加および削除プロセスを簡素化します。数百または数千にもなりうる(大規模なデータ・ウェアハウスの場合)多数のファイルを管理するかわりに、DBAは、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 ACFSファイルシステムのネットワーク経由でのリモート・サイトへのレプリケーションを可能にすることにより、ファイルシステムの障害時リカバリ機能を提供

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

3.10 高速リカバリ領域

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

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

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

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

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

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

- 高速リカバリ領域全体のバックアップとリストアが可能

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

3.11 Recovery Manager

Oracle Recovery Manager(RMAN)は、データベースのバックアップや、さらに重要なデータベースのリカバリを管理するためのOracleのユーティリティです。RMANは、操作の複雑さを排除するとともに、データベースの優れたパフォーマンスおよび可用性をもたらします。

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

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

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

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

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

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

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

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

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

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

- ネットワークでデータベースを作成する場合の、ステージング領域の削除による領域消費の削減

- 増分バックアップをイメージ・コピーにバックグラウンドでマージし、最新のリカバリ可能性を提供

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

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

- 前回失敗した操作のバックアップおよびリストアを再開可能

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

- データベースをホット・バックアップ・モードにする必要のないオンライン・バックアップ

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

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

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

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

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

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

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

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

- 修復の実行可能性チェック
データ・リカバリ・アドバイザでは、修復オプションが示される前に、特定の環境や提案される修復処理を完了するために必要なメディア・コンポーネントの可用性に関して、これらの修復オプションが検証されます。

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

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

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

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

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

詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』のデータ・リカバリ・アドバイザを使用した障害の診断および修復に関する項を参照してください。

3.13 Oracle Secure Backup

Oracle Secure Backupは、UNIX、Linux、WindowsおよびNetwork Attached Storage(NAS)の分散環境で実行される異種データ保護を提供する、集中型のテープ・バックアップ管理ソリューションです。ファイル・システムとOracle Databaseのデータを保護することにより、Oracle Secure BackupはIT環境に完全なテープ・バックアップ・ソリューションを提供します。

Oracle Secure BackupはRMANと緊密に統合されてRMANのメディア管理層を提供し、Oracle9i以降のリリースをサポートしています。Oracle Secure BackupとRMANは、最適化された統合ポイントを使用して、Oracle Databaseに最速で効率性が最も高いテープ・バックアップ機能を提供します。

バックアップ・ポリシーを使用して、分散サーバーをOracle Secure Backup中央管理サーバーからローカルおよびリモートのテープ・デバイスにバックアップできます。完全自動操作の場合はカレンダーに基づくスケジュールで、迅速な要件の場合はオンデマンドでバックアップされます。高度にスケーラブルなクライアント/サーバー・アーキテクチャにより、Oracle Secure Backupは安全なイントラドメイン通信と双方向サーバー認証のためにSecure Sockets Layer(SSL)を利用して、ローカルおよびリモートのデータ保護を提供します。

Oracle Secure Backupには次のような利点があります。

- 現在使用されているブロックのみをバックアップして、バックアップ・パフォーマンスを10%から25%向上させることで、Oracle Databaseのテープ・バックアップを最適化

- ポリシーに基づく管理により、バックアップ管理者はバックアップ・ドメインの正確な制御が可能

- 動的ドライブ共有によるテープ・リソースの使用率の向上

- 異種ストレージ・エリア・ネットワーク(SAN)のサポートにより、NAS、UNIX、WindowsおよびLinuxでテープ・ドライブとメディアの共有が可能

- 完全および増分オフサイト・バックアップ・スケジューリングによる、ファイル、ディレクトリ、ファイル・システムまたはRAWパーティション・レベルでのファイル・システム・バックアップ

- Oracle Enterprise Managerとの統合による、直感的で使いやすいインタフェースの提供

- テープへのバックアップの暗号化

- SANおよびSCSI環境における新しいテープ・デバイスと従来の幅広テープ・デバイスのサポート

- Network Data Management Protocol(NDMP)のサポートによる、NASファイルの効率性の高いバックアップ

- スケーラブルで低コストのライセンス・モデルによる、ITコストの削減と運用面の考慮事項の軽減

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

3.14 Oracleセキュリティ機能

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

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

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

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

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

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

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

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

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

関連項目:

- Oracle Databaseセキュリティ・ガイド

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

3.15 LogMiner

Oracleログ・ファイルには、Oracle Databaseのアクティビティおよび履歴に関する有益な情報が含まれています。また、ログ・ファイルには、データベースのリカバリの実行に必要なすべてのデータが含まれており、データベース内のデータおよびメタデータに加えられたあらゆる変更も記録されます。

LogMinerは、SQLを使用したREDOログ・ファイルの読取り、分析および解析を可能にする完全なリレーショナル・ツールです。LogMinerを使用したログ・ファイルの分析は、次の用途に使用できます。

- データへの変更の追跡または監査

- チューニングおよび容量計画用に補足情報を提供

- 複雑なアプリケーションのデバッグ用重要情報の取得

- 削除されたデータのリカバリ

- 論理障害のトラブルシューティングと解決に役立つ、ブラウザを中心とした簡素化

LogMiner機能には次のものがあります。

- アプリケーション・レベルで発生したエラーなど、データベースの論理的破損が発生した可能性のある時期を特定

- トランザクション・レベルでのきめの細かいリカバリを実行するために必要な処置を決定

- 傾向分析によるパフォーマンス・チューニングおよび容量計画の提供

- LogMinerの包括的なREDOログ・ファイルへのリレーショナル・インタフェースを使用した、システムの動作の分析およびデータベース使用の監査

詳細は、『Oracle Databaseユーティリティ』のLogMinerに関する章を参照してください。

3.16 Oracle Exadata Storage Server Software(Exadataセル)

Oracle Exadata Storage Server Softwareは、Oracle Databaseで使用するために高度に最適化された記憶域製品です。Exadataセルとも呼ばれ、Oracle Databaseの格納およびアクセスに使用されます。Oracle Exadata Storage Server SoftwareではExadataセル・ソフトウェアを実行します。従来の記憶域アレイおよび製品に加えて使用できます。Exadataセルは、SQL処理およびデータベース・アプリケーションに対する透過性を維持しながら、データベース・サーバーからデータベース処理をオフロードする機能など、データベースを意識した記憶域サービスを提供します。

Oracle Storage Gridは、Oracle ASMとOracle Exadata Storage Server Software、またはOracle ASMとサード・パーティのストレージを使用して実装されます。Exadataを使用したOracle Storage Gridを使用すると、MAA関連のテクノロジをシームレスにサポートでき、パフォーマンスが向上し、無制限のI/Oスケーラビリティが得られます。また、使用および管理が容易で、企業はミッション・クリティカルな可用性および信頼性を得られます。また、Exadataセルは、ディスクへの書込みによる破損を防ぐための最も包括的なソリューションです。DB_BLOCK_CHECKSUM初期化パラメータが有効化されると、Exadataはブロック・チェックサムを評価します。

関連項目:

- Oracle Storage Gridのベスト・プラクティス推奨事項は、『Oracle Database高可用性ベスト・プラクティス』を参照してください。

- Oracle Exadata Storage ServerのWebサイト(http://www.oracle.com/exadata)

3.17 Oracle Exadata Database Machine

Oracle Exadata Database Machineは事前に完全な最適化および構成が行われたソフトウェア、サーバーおよびストレージのパッケージで、スキャン集中型のデータ・ウェアハウス・アプリケーションから同時実行性の高いOLTPアプリケーションまで、あらゆるデータベース・ワークロードに対して最適なソリューションを提供します。Oracle Exadata Storage Server Software、Oracle DatabaseソフトウェアおよびSunのハードウェア・コンポーネントを組み合わせることにより、可用性が高く、非常にセキュアな環境で卓越したパフォーマンスを実現します。Oracle特有のクラスタリングおよびワークロード管理機能により、Database Machineは複数のデータベースを単一グリッドへ統合するのにも適しています。

Exadata Database MachineはOLTPおよびデータ・ウェアハウス・アプリケーションに高いパフォーマンス、スケーラビリティおよび可用性を提供するように設計されています。

計画外停止に対し、Exadata Database Machineはフォルト・トレラントであり、MAAベスト・プラクティスと統合されて、次の利点をもたらします。

- Oracle RACによるノードおよびインスタンス障害への耐性

- Oracle ASMおよびOracle Exadata Storage Server Gridによるディスクおよびセルの障害への耐性

- Oracle ASM自動修復メカニズム、Exadataストレージ組込み破損チェックおよびOracle汎用ブロック破損パラメータを使用した、破損の防止および自動修復

- 冗長でフォルト・トレラントなポート、ケーブル、ホスト・チャネル・アダプタおよび結合ネットワークの提供

- Oracle Data Guardおよび別のExadata Database Machineを使用した完全なクラスタまたはDatabase Machineの障害を迅速に修復する機能の提供

計画メンテナンスに対し、Exadata Database Machineは次の利点をもたらします。

- Oracle ASM、Oracle ClusterwareおよびOracle RACローリング・アップグレードまたはソフトウェア変更のサポート

- Oracle Exadata Storage Server Softwareのパッチ用ローリング・アップグレードのサポート

- Oracle Data GuardおよびOracle GoldenGateを使用したアプリケーションおよびシステム変更が可能

- データベースへの一般的なオンライン・メンテナンス機能のすべてをサポート

バックアップおよびリカバリ操作に対し、単一のExadata Database Machineに特有な主要なパフォーマンスの差別化には、次のことを達成する機能が含まれます。

- 1時間当たり7TBのRMANテープ・ベースおよびディスク・ベースの完全バックアップ

- 1時間当たり10～48TBの、RMAN増分バックアップを使用したRMAN有効バックアップ率

- 1時間当たり23TBのRMANリストア率

- ワークロードに応じた、1秒当たり200～637MBのREDO Applyおよびリカバリ率

- ハイエンドOLTPおよびデータ・ウェアハウス・アプリケーション向けの Data Guardデプロイメント

MAA構成ベスト・プラクティスは、Exadata Database MachineおよびExadata Cellの最初のインストールおよびデプロイ中に引き続き統合され組み込まれます。

MAA OTN WebサイトでExadata Database MachineのMAAベスト・プラクティスを参照してください。

3.18 Oracle Database File System(DBFS)

Oracle Database File System(DBFS)は、データベース表に格納されているファイルおよびディレクトリの最上位に、標準のファイル・システム・インタフェースを作成します。Oracle DBFSは、ローカル・ファイル・システムと類似した共有ネットワーク・ファイル・システムを提供する点で、ネットワーク・ファイル・システム(NFS)プロトコルと似ています。

NFSと同様に、サーバー・コンポーネントおよびクライアント・コンポーネントが存在します。サーバーはOracle Databaseで、ファイルはデータベース表のSecureFile LOBに格納されます。ファイルはデータベースに格納され、Oracle Databaseが提供する高可用性と障害時リカバリ保護はそのまま利用できるため、フル・スタックの障害時リカバリ・ソリューションが実現します。データベース内でのファイル・システムの実装はDBFSコンテンツ・ストアと呼ばれ、これによって各データベース・ユーザーは、クライアントによるマウントが可能な1つ以上のファイル・システムを作成できます。各ファイル・システムには、ファイル・システム・コンテンツが保持されるシステム専用の表があります。一連のPL/SQLプロシージャにより、ファイル・システム・アクセス(CREATE、OPEN、READ、WRITEおよびLIST DIRECTORYなど)がデータベースに実装されます。

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

- 非構造化データと構造化データの両方を同じデータベースに格納する機能。
これにより、両タイプのデータのバックアップおよび同期ポイント・イン・タイム・リカバリを実行できます。

Oracle DBFSは、クライアントに対してNFSのようなファイル・システムを提示することにより、構造化されていない内容をデータベースに格納する機能を提供します。ファイル・システム自体は、Oracle Databaseの表領域に格納されます。データベース記憶域は、従来のNFSがマウントされた同じ機能のファイル・システムとして表示されるため、クライアントにとっては透過的ですが、DBFSでは、通常はファイル・システムに格納するあらゆる種類のファイル(ログや生成済レポートなど)を、データベースに直接格納する機能が提供されます。

- 軽量プロセスによるクラスタ化ファイル・システム機能
Oracle DBFSは、複数のクライアント・マシン(データベース・サーバー、中間層)にマウントでき、その結果、クラスタ化されたファイル・システムとしても使用可能です。ファイル・システムをアクセス可能にするために、軽量のプロセスは各クライアント・マシンで開始されます。このプロセスでは、Filesystem in Userspace(FUSE)APIを使用して、ファイル・システム・アクセスを実行します。

- ファイル・システムとデータベースの両操作の高速かつ透過的なクライアント・フェイルオーバー(フル・スタック障害時リカバリ)
クライアント・システム上のプロセスはOCIに基づいています。したがって、クライアントは、同じサービスベースの接続方法を使用して、FANおよび高速接続フェイルオーバー機能を利用できます。

詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。

3.19 クライアント・フェイルオーバー

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

クライアント・フェイルオーバーには、障害の通知、接続のクリーンアップ、自動再接続、および別のOracle RACインスタンスまたはデータベースに存在するデータベース・サービスの再試行が含まれ、問合せの再試行も含まれる可能性があります。

クライアント・フェイルオーバーのベスト・プラクティスおよびネットワークのベスト・プラクティスについては、MAAホワイト・ペーパーのData Guard 11g リリース2のクライアント・フェイルオーバーのベスト・プラクティスを参照してください。

http://www.oracle.com/goto/maa

3.20 自動ブロック修復

自動ブロック修復を使用すると、破損したデータ・ブロックを破損検出と同時に自動修復できます。この機能により、ブロック破損によってデータがアクセス不可になる時間が短縮されます。最新の良好なブロックをリアルタイムで使用するため、ディスクやテープのバックアップまたはフラッシュバック・ログからブロックを取得するより、ブロックのリカバリ時間が短縮されます。

自動ブロック修復ではOracle Active Data Guardオプションの使用が必要で、これにより読取り/書込みI/Oでフィジカル・スタンバイ・データベースを開くことができます。また、この機能では、Oracle Data Guardが最大可用性モードで実行中で、LOG_ARCHIVE_DEST_n初期化パラメータがSYNC REDOトランスポート・モードに設定されている必要があります。

注意:
Oracle Active Data Guardのリアルタイム問合せ機能を使用すると、REDO Applyがアクティブである間、フィジカル・スタンバイ・データベースを読取り専用で開くことができます。Oracle Active Data GuardはOracle Enterprise Editionの別個のデータベース・オプションとしてパッケージ化されています。本番データベースおよびOracle Active Data Guardオプションに使用されるすべてのフィジカル・スタンバイ・データベースにライセンスが必要です。

表3-2 破損データ・ブロックの自動検出および修復

状況

結果

破損データ・ブロックがプライマリ・データベースで検出された

リアルタイム問合せモードで稼働するフィジカル・スタンバイ・データベースを使用して、プライマリ・データベースの破損データ・ブロックを修復できます。可能な場合は、プライマリ・データベースへのアクセス時に発生したすべての破損データ・ブロックが、リアルタイム問合せモードで稼働するフィジカル・スタンバイ・データベースの同じブロックの破損していないコピーに自動的に置換されます。自動修復不可の場合はORA-1578エラーが戻されます。

破損データ・ブロックがフィジカル・スタンバイ・データベースで検出された

フィジカル・スタンバイ・データベースで次のデータベース初期化パラメータが構成されている場合は、破損の自動修復がサーバーによって試行されます。この修復では、プライマリ・データベースからブロックのコピーが取得されます。

- DG_CONFIGリストを使用してLOG_ARCHIVE_CONFIGパラメータを構成

- プライマリ・データベースのLOG_ARCHIVE_DEST_nパラメータを構成

また、RMAN RECOVER BLOCKコマンドを使用して破損データ・ブロックを手動で修復することもできます。このコマンドは、複数の場所でデータ・ブロックの破損していないコピーを検索します。デフォルトでは、検索場所の1つは、リアルタイム問合せモードで稼働する使用可能な任意のフィジカル・スタンバイ・データベースです。RMAN RECOVER BLOCKコマンドのEXCLUDE STANDBYオプションを使用すると、置換ブロックのソースとしてフィジカル・スタンバイ・データベースを除外できます。

関連項目:

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

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

- リアルタイム問合せスタンバイ・データベースを使用した自動ブロック修復の詳細は、『Oracle Data Guard概要および管理』を参照してください。

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

MAA推奨の、最も包括的にデータ破損の防止および検出を実現する方法は、Oracle Data Guardを使用し、DB_BLOCK_CHECKING、DB_BLOCK_CHECKSUMおよびDB_LOST_WRITE_PROTECTデータベース初期化パラメータを、Data Guardプライマリおよびスタンバイ・データベースで構成することです。

Oracle Data GuardはOracleデータをデータ損失および破損、書込みの欠落から保護する最適なソリューションです。企業データを障害、エラーおよびデータ破損から守るために1つまたは複数のスタンバイ・データベースを保持するのはOracleの機能のみです。Data Guardを使用すると、ローカルまたはリモートのデータ・センターで、プライマリ(本番)データベースの1つまたは複数のスタンバイ・コピーをデプロイおよび管理できます。データ保護のすべての利点は、この事実から生じています。

たとえば、Data Guardを使用して、本番データベースからの変更で継続的に更新されているスタンバイ・データベース上のデータの別のコピーを保持できます。Data Guardはすべての変更をスタンバイ・データベースに適用される前に検証し、物理的な破損が伝播してフィジカル・スタンバイ・データベースを破損しないようにします。本番データベースがサイトの障害、データ破損または人的エラーにより使用できなくなった場合に、スタンバイ・データベースをアクティブにできます。

Oracle Database 11gリリース2(11.2)から、破損ブロックの修復は、フィジカル・スタンバイ・データベースから同じブロックの状態のよいバージョンを取得することで、プライマリ・データベースによりリアルタイムで自動的に行われます。さらに、Oracle Active Data Guardオプションの、REDO Applyがアクティブである間フィジカル・スタンバイ・データベースを読取り専用でオープンできる機能が、自動ブロック修復に必要です。この機能により、破損の検出後すぐに破損データ・ブロックを自動的に修復できます。詳細は、このホワイト・ペーパーの自動ブロック修復に関する項を参照してください。

注意:
Exadataセルは、ディスクへの書込みによる破損を防ぐための最も包括的なソリューションでもあります。破損を早期に検出して破損データがディスクに書き込まれるのを防ぐことができます。Exadataセルの詳細は、3.16項を参照してください。

Oracle Database 11gより前では、RMANで検出されたブロックの破損はV$DATABASE_BLOCK_CORRUPTIONで記録されていました。Oracle Database 11gからは、RMANなどのデータベースのコンポーネントとユーティリティで破損ブロックを検出でき、このビューで記録できます。Oracle Databaseは、(たとえば、ブロック・メディア・リカバリまたはデータ・ファイル・リカバリを使用して)破損ブロックが検出または修復されると、このビューを自動的に更新します。ブロックの破損は、今ではより早く発見されるようになりました。

これらの機能は、データ破損をすぐに検出できるため、Oracle Databaseにとって重要な高可用性の利点となります。

データ破損の防止、検出および修復の詳細は、『Oracle Database高可用性ベスト・プラクティス』を参照してください。これらのビューおよび初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

4 計画停止時間用Oracle Database高可用性ソリューション

計画停止時間は、計画外停止時間と同様、業務に悪影響を及ぼします。これは、特に、複数のタイムゾーンのユーザーをサポートする必要がある、または顧客に24時間年中無休でインターネット・アクセスを提供する必要があるグローバル企業に当てはまります。

以前は、次のような作業を実行する場合に停止時間が必要でした。

- データベース、アプリケーション、オペレーティング・システム、ミドルウェアまたはネットワークを更新するためのパッチ適用またはシステムの再構成などの定期的なメンテナンス。

- ハードウェア、データベース、アプリケーション、オペレーティング・システム、ミドルウェアまたはネットワークの主要アップグレードまたは新規導入などの新規デプロイメント。

4.1項に、あらゆるタイプの計画メンテナンスによる停止時間を防止、許容および短縮するためのOracle高可用性ソリューションを要約します。

4.1 計画停止時間用Oracle高可用性ソリューションおよびリカバリ時間

Oracleでは、あらゆるタイプの計画メンテナンスに対して停止時間を防止、許容および短縮するための高可用性ソリューションを提供しています。表4-1では、計画停止時間用の各種Oracle高可用性ソリューション、および各ソリューションで達成可能な停止時間について説明しています。どのような場合でも、計画メンテナンス操作を実行する前に広範囲なテストを行うことをお薦めします。また、各Oracle高可用性アーキテクチャでのあらゆるタイプの計画停止時間に対する達成可能なリカバリ時間の概要は、表7-5を参照してください。

表4-1 計画停止時間用Oracle高可用性ソリューション

メンテナンス・タイプ

推奨されるOracleソリューション

ソリューションの説明

停止時間

オペレーティング・システムおよびハードウェアのアップグレード

Oracle Real Application ClustersおよびOracle ClusterwareまたはOracle RAC One Node(単一インスタンスOracle RACデータベースの場合)

4.1.1項

停止時間ゼロ

Oracle個別パッチ

Oracle Real Application Clusters(Oracle RAC)

4.1.3項

停止時間ゼロ脚注1

Oracle Clusterwareのアップグレードおよびパッチ

Oracle ClusterwareまたはOracle RAC One Node(単一インスタンスOracle RACデータベースの場合)

4.1.4項

停止時間ゼロ

Oracle ASMのアップグレード

Oracle Automatic Storage Management

4.1.5項

停止時間ゼロ

ストレージの移行脚注2

Oracle Automatic Storage Management

4.1.6項

停止時間ゼロ

Exadata Storageへの移行

「Best Practices for Migrating to Oracle Exadata Storage Server」プレゼンテーション脚注3で説明されているOracle MAAのベスト・プラクティス

4.1.7項

停止時間は選択したソリューションによって異なる

Exadata Storageのアップグレード

Exadataパッチ・マネージャ

4.1.8項

停止時間ゼロ

単一インスタンス・データベースのOracle RACへの移行

Oracle Clusterware

4.1.1項

停止時間ゼロ

Oracle ASMへの移行、またはOracle RACへの単一インスタンス・データベースの移行

Oracle Data Guard

4.1.2項

数秒から数分

パッチ・セットおよびデータベースのアップグレード

SQL Applyを使用したOracle Data Guard

4.1.9項

数秒から数分

Oracle個別パッチ、Oracleクラスタウェアのアップグレードおよびパッチ、Oracle ASMのアップグレード、オペレーティング・システムおよびハードウェアのアップグレード

Oracle Data Guard Standby-First Patchの適用

My Oracle Support Noteの「Oracle Patch Assurance - Data GuardのStandby-First Patchの適用」

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1265700.1

数秒から数分

WindowsプラットフォームとLinuxプラットフォーム、および選択したその他のプラットフォーム間でのプラットフォームの移行脚注4

Oracle Data Guard

4.1.9項

数秒から数分

同じエンディアン形式のプラットフォーム間でのプラットフォームの移行

トランスポータブル・データベース

4.1.10項

数分から数時間

異なるエンディアン形式のプラットフォーム間でのプラットフォームの移行

トランスポータブル表領域

4.1.11項

数時間

パッチ・セットとデータベースのアップグレード、プラットフォームの移行、ローリング・アップグレード、および異なるキャラクタ・セットが必要な場合

Oracle GoldenGateおよびOracle Streams

4.1.9項、4.1.10項、4.1.11項および4.5項

数秒から数分

アプリケーションのアップグレード

アプリケーションのオンライン・メンテナンスおよびオンライン・アップグレード

4.5項

停止時間ゼロ

脚注1ローリング・アップグレードの実行で適用できないパッチは、パッチ適用による可用性の影響が少ないOPatchユーティリティのMINIMIZE_DOWNTIMEオプションで適用できます。

脚注2従来型のストレージから低コストのストレージへの移行などの例があります。

脚注3Oracle MAA Webサイト(http://www.oracle.com/goto/maa)から入手できます。

脚注4My Oracle Support(旧OracleMetalink)Note 413484.1(http://support.oracle.com/)を参照してください。

関連項目:

- SQL ApplyでData Guardを使用してOracle Databaseをアップグレードするには、『Oracle Data Guard概要および管理』を参照してください。

- トランスポータブル表領域の詳細は、『Oracle Database概要』および『Oracle Database管理者ガイド』を参照してください。

- ローリング・アップグレードのベスト・プラクティスに関するMAAホワイト・ペーパーは、次のWebサイトから入手できます。

http://www.oracle.com/goto/maa

4.1.1 オペレーティング・システムのアップグレードおよびハードウェアのアップグレード

システムとハードウェアのアップグレード時の停止時間を回避するには、Oracle RACを使用するソリューションをお薦めします。単一インスタンスOracle RACデータベースの場合は、Oracle RAC One Nodeを使用できます。

4.1.2項に示すように、Oracle RACまたはOracle RAC One Nodeを使用してアップグレードを実行できない場合は、Oracle Data Guardとフィジカル・スタンバイ・データベースを使用するソリューションをお薦めします。もしくは、4.1.4項に示すように、Oracle Clusterwareを使用したコールド・クラスタ・フェイルオーバーを使用することもできます。

次のリストに、Oracle RACを使用してアップグレードする場合の手順の高レベルの概要を示します。

1. 次の前提条件チェックを実行します。

- 計画メンテナンスがオペレーティング・システムの観点からローリング形式で行うことができるかどうかを確認します。

- データベースとクラスタウェアのバージョンが、新規システムおよびハードウェアの変更で動作保証されているかどうかを確認します。

2. クラスタ内の複数のインスタンスでアプリケーション・サービスが稼働している場合は、アプリケーション・サービスを停止します。アップグレード対象のインスタンスのみでアプリケーション・サービスが稼働している場合は、クラスタ内の別のノードにサービスを再配置します。
高速アプリケーション通知(FAN)を使用している場合、アプリケーション・サービスを停止すると、接続が接続先インスタンスから暗黙的にリダイレクトされます。

3. IMMEDIATEオプションを指定して接続先インスタンスを停止します。

4. Oracle Clusterwareを停止して無効にします。
Oracle Clusterwareを無効にすると、自動起動しなくなります。

5. メンテナンスを実行します。

6. Oracle Clusterwareを有効にして、起動します。
この手順により、データベース・インスタンスが暗黙的に起動されます。

7. アプリケーション・サービスを起動します。
この手順により、FANを使用している場合、接続先インスタンスに接続が暗黙的にリダイレクトされます。

8. 次のノードですべての手順を繰り返します。

また、使用しているオペレーティング・システム別のOracle Real Application Clustersのインストレーション・ガイドを参照してください。

4.1.2 Oracle Data Guardを使用したシステムおよびクラスタのアップグレードと移

Oracle Data Guardとフィジカル・スタンバイ・データベースは、Oracle RACローリング・アップグレードを使用してアップグレードできないシステムとクラスタのアップグレードを実行する場合に推奨されるソリューションです。Oracle Data Guardは、Oracle ASM、Oracle RACおよび64ビット・システムへの移行、WindowsとLinux間での移行、あるいは同じプロセッサ・アーキテクチャのプラットフォームへの移行にも推奨されます。次に例を示します。

- システムの制限によりOracle RACのローリング・アップグレードを使用してアップグレードできないシステム・アップグレードには、Oracle Data Guardを使用します。

- Oracle ASMへの移行、クラスタ化されていない環境からOracle RACへの移行、同じエンディアン形式の別のプラットフォームへの移行、または同じプロセッサ・アーキテクチャの別のプラットフォームへの移行を行う場合、Oracle Data Guardを使用します。スイッチオーバーを実行するのに必要な時間は発生する停止時間のみです。詳細は、My Oracle Supportのノート413484.1の「同一Data Guard構成の異機種間プライマリ・スタンバイおよびフィジカル・スタンバイに関するData Guardのサポート」を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=413484.1

通常、フィジカル・スタンバイ・データベースを最初にアップグレードしてから、フィジカル・スタンバイ・データベースに対してOracle Data Guardスイッチオーバーを実行します。

4.1.2.1 フィジカル・スタンバイ・データベースのアップグレード

フィジカル・スタンバイ・データベースのアップグレードおよびスイッチオーバーの実行手順:

1. システムをアップグレードするか、またはフィジカル・スタンバイ・データベース・システムを移行先環境に変更します。
たとえば、Oracle ASMを使用して、スタンバイ・データベースを単一インスタンス・データベースからOracle RACデータベースに変換できます。プライマリ・データベースへの影響はありません。次に、スタンバイ・データベースを再起動し、これが移行先環境に合っているかどうかを確認して、REDO Applyによるスタンバイ・データベースへのREDOデータの適用が終わるまで待機します。

2. Oracle Data Guardスイッチオーバーを実行します。最適なスイッチオーバーの所要時間は、数秒から数分程度です。

3. 元のプライマリ・データベースを停止します(これでスタンバイ・データベースになる)。

4. アップグレードするか、元のプライマリ・データベースへのシステム変更を行います。

5. スタンバイ・データベースとしてアップグレードしたデータベースを再起動し、リカバリでデータベースを自動的に同期化します。

6. 必要に応じて、Oracle Data Guardスイッチオーバーを実行して、スタンバイ・データベースをプライマリ・データベース・ロールに戻します。

注意:
Oracle Databaseパッチ・セットの適用またはOracle Databaseのアップグレードを同時に行う場合、32ビットから64ビットへの変換は自動的に行われます。オペレーティング・システムのみをアップグレードする場合は、My Oracle SupportのNote 414043.1(http://support.oracle.com/)に記述されている追加のアップグレード後の手順を実行する必要があります。アップグレードの詳細は、『Oracle Databaseアップグレード・ガイド』も参照してください。

4.1.2.2 システムおよびクラスタのアップグレードおよび移行のベスト・プラクティス

システムおよびクラスタのアップグレードと移行では、次のベスト・プラクティスおよびガイドラインを考慮します。

- スイッチオーバーを高速化するには、スタンバイ・データベースでリアルタイム適用が使用されるように構成し、できれば、アーカイブ・ログ・ギャップが存在しないように、スイッチオーバー操作の開始前にデータベースがほとんど同期化されているようにします。

- Oracle RACローリング・アップグレードまたはオンライン・パッチを使用できない場合は、Oracle Data Guardおよびフィジカル・スタンバイ・データベースを使用して、システムおよびクラスタのアップグレードを実行します。詳細は、『Oracle Data Guard概要および管理』を参照してください。

4.1.3 Oracle Databaseパッチ

通常、データベース・ソフトウェアへのOracleパッチは、ソフトウェアの問題に対する既知の修正を実装するため、または診断パッチを適用して問題に関する情報を収集するために適用します。パッチの適用は、予定したメンテナンス停止の際に行うように計画します。

Oracleデータベース・パッチを適用する際に停止時間を回避するには、Oracle RACを使用してローリング・パッチ・アップグレードを実行します。RACを使用すると新規パッチの約90% を適用できます。Oracleには、OPatchコマンドライン・ユーティリティを使用した、データベースの停止時間がほとんどないかゼロの、Oracle RACを使用したローリング・パッチのアップグレードを行う機能があります。Oracle RACを使用できない場合は、Oracle Data Guardおよびフィジカル・スタンバイ・データベースを使用します。詳細は、4.1.2項を参照してください。

パッチには複数の種類があります。

- 個別パッチ
パッチ・セットのリリース間の特定の修正を提供するために作成される1つのパッチ。

- バンドル・パッチ
パッチ・セット間で発行されるパッチを集めたもの。パッチ・バンドルは通常は累積されます。Database用のMicrosoft Windowsバグ修正は、通常は個別パッチではなくパッチ・バンドルで発行されます。

- パッチ・セット更新(PSU)
該当製品の最重要の修正を含む四半期ごとのパッチ(セキュリティ修正を含む)で、1つのパッチを適用して多くの問題を解決できます。

- クリティカル・パッチ・アップデート(CPU)
四半期ごとに提供される優先度の高い修正(通常はセキュリティ上の問題)を集めたもの。CPUは、セキュリティの事前修正の観点から累積されますが、セキュリティ以外のパッチ(マージ・リクエストの必要性を軽減)と競合するパッチに対処できるように他の修正が含まれる場合があります。

- 診断パッチ
バグの修正ではなく、問題の診断に限定して作成されるパッチ。

Oracle RACによるローリング・アップグレードでは、計画停止の間、Oracle RACインストールのインスタンスを、1つを除いてすべて使用できます。その結果、計画停止に必要なアプリケーション停止時間に対する影響はさらに減少します。OracleのOPatchユーティリティを使用すると、インストール済のOracle RACの異なるインスタンスに対してパッチを連続的に適用できます。

ローリング・アップグレードの実行は、ローリング・アップグレード用に認可されているパッチの場合のみ可能です。

4.1.3.1 オンライン・パッチ適用

オンライン・パッチは、インスタンスがオンラインのままで適用できる特殊な個別パッチまたは診断パッチです。次の場合にのみ、個別パッチまたは診断パッチをオンラインで適用してください。

- パッチのREADMEには、オンラインで適用できることが記載されています。

- パッチはすぐに適用する必要がありますが、通常(オフライン)バージョンのパッチを適用する場合は、データベース・インスタンスを停止できません。

OPatchコマンドライン・ユーティリティを使用してOracleデータベースでオンライン・パッチ適用を実行できます。

また、オンライン・パッチを実行するときは、次の点に注意してください。

- オラクル社では、正規の個別または診断パッチをコンボ・パッチとして提供しており、同じバグ修正でオンライン・パッチとオフライン・パッチの両方が含まれています。
そのため、このオンライン・パッチを最初に適用すると、計画外停止時間を回避できます。ただし、オンライン・パッチではメモリーのオーバーヘッドが発生するため、計画停止時にオンライン・パッチをロールバックしてオフライン・パッチを適用する必要があります。

- オンライン・パッチを適用すると、各Oracleプロセスではパッチの適用時にプログラム・グローバル領域(PGA)のメモリーを多く使用するため、システムのメモリー消費が増加します。オンライン・パッチを適用する前に、メモリー要件を考慮してください。各オンライン・パッチは独自のものであり、メモリー要件はパッチごとに異なります。パッチをまずテスト・システムに適用することで、本番システムでのオンライン・パッチの効果を評価し、追加のメモリー使用量を予測できます。

関連項目:

- My Oracle Supportのノート761111.1「RDBMSオンライン・パッチAkaホット・パッチ」
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=761111.1

- オンライン・パッチとOPatchユーティリティの詳細は、『Oracle Universal InstallerおよびOpatchユーザーズ・ガイド for Windows and UNIX Systems』を参照してください。

- ローリング・アップグレードおよびローリング・パッチの概要は、『Oracle Databaseアップグレード・ガイド』を参照してください。

4.1.4 Oracle Clusterwareのアップグレード

Oracle Clusterwareのアップグレード時の停止時間を回避するには、Oracle Clusterwareのローリング・アップグレードを実行するソリューションをお薦めします。単一インスタンスOracle RACデータベースの場合は、Oracle RAC One Nodeの使用を検討してください。

Oracle Clusterwareへのアップグレードはすべて、ローリング方式で実行できます。

関連項目:

- 使用するオペレーティング・システム別のOracle Clusterwareのインストレーション・ガイド

- 使用するオペレーティング・システム別のOracle Real Application Clustersのインストレーション・ガイドを参照してください。

4.1.5 Oracle Automatic Storage Management(Oracle ASM)のアップグレード

Oracle ASMのアップグレードには、ローリング・アップグレードの実行をお薦めします。Oracle Database 11g(およびこれ以降のリリース)でのアップグレードはすべて、ローリング方式で実行できます。

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

4.1.6 ストレージの移行

ストレージの移行を実行するには、Oracle ASMを使用するソリューションをお薦めします。

Oracle ASMを使用して、すべてのディスクを1つのストレージ・アレイに追加した後、別のアレイからすべてのディスクを削除できます。Oracle ASMは、データベースが稼働したままの状態で、自動的にデータのリバランスを行い、新規ストレージに移行します。ソース・ストレージ・アレイを削除する前に、リバランスが完了したかどうか確認してください。

詳細は、MAAホワイト・ペーパー「Migration to Automatic Storage Management(ASM)」および「Best Practices for Creating a Low-Cost Storage Grid for Oracle Databases」(http://www.oracle.com/goto/maa)を参照してください。

4.1.7 Oracle Exadata Storage Server Softwareの移行

MAAプレゼンテーション「Exadataデータベース・マシンへの移行のためのベスト・プラクティス」のガイドラインには、従来のストレージからOracle Exadata Storage Serverへの移行前および移行後のベスト・プラクティスが定義されています。これらのベスト・プラクティスは、アプリケーション・サービスのレベルおよび属性を考慮して最適な移行方法を判断するのに役立ちます。MAAプレゼンテーションは、MAA Webサイト(http://www.oracle.com/goto/maa)から入手できます。

4.1.8 Oracle Exadata Storage Server Softwareのアップグレード

アップグレードを実行するためのソリューションおよびツールの詳細は、Oracle Exadata Storage Server Softwareのドキュメントを参照してください。

関連項目:

- My Oracle Support(旧OracleMetalink)のNote 791275.1(http://support.oracle.com/)に含まれる次の資料
Oracle Exadata Storage Server Software Documentation Addendum

Oracle Exadata Storage Server Software Planning and Deployment Guide

Oracle Exadata Storage Server Software Patch Application Example

- Oracle Exadata Storage ServerのWebサイト(http://www.oracle.com/exadata)

4.1.9 パッチ・セットおよびデータベースのアップグレード

パッチ・セットおよびデータベースのアップグレードを最小の停止時間で実行するには、SQL Applyを使用するOracle Data Guardのソリューションをお薦めします。このソリューションについては、4.1.9.1項で説明します。ソース・データベースがSQL Applyでもともとサポートされていないデータ型を使用している場合、拡張データ型サポート(EDS)を使用することで、対応する拡張データ型をさらにいくつか増やすことができます。

ソース・データベースが、SQL Applyのローリング・アップグレードでサポートされていないソフトウェア・バージョンを使用している場合(Oracle Databaseリリース10.1.0.3より前のリリース)、またはEDSを使用してもSQL Applyのデータ型の競合を十分に解決できない場合、Database Upgrade Assistant(DBUA)脚注1、トランスポータブル表領域またはOracle GoldenGateの使用を検討します。

- DBUAには、アップグレード・プロセスの手順を示すグラフィカル・ユーザー・インタフェース(GUI)ユーティリティが備わっており、データベースのアップグレードの方法としては最も簡単で推奨できる方法です。ただし、DBUAでデータベースのアップグレードにかかる時間が定義されたメンテナンス・ウィンドウの期間に納まらない場合は、1時間未満でデータベース・アップグレードを実行するために、トランスポータブル表領域機能の使用を検討してください。

- SQL Applyを使用できず、メンテナンス・ウィンドウで停止時間を1時間未満にする必要がある場合、およびアップグレードされるデータベースに単純なスキーマや、トランスポート・プロセスの一部として転送する必要のないデータ・ファイル(データ・ファイルが所定の場所で使用される場合など)が少ない場合には、トランスポータブル表領域を使用します。トランスポータブル表領域ソリューションについては4.1.9.2項で説明します。

- Oracle GoldenGateは、データベース・アップグレードを実行する際の最も柔軟な方法と、追加のデータ型サポートを提供します。このソリューションについては、4.1.9.4項で説明します。

Oracle RACを使用してパッチ・セットのローリング・アップグレードを実行しないでください。また、使用しているオペレーティング・システム別のOracle Real Application Clustersのインストレーション・ガイドを参照してください。

詳細と、ユーザーの構成に適したデータベース・アップグレード方法の選択に役立つ情報は、『Oracle Database高可用性ベスト・プラクティス』を参照してください。

4.1.9.1 Data GuardおよびSQL Applyを使用したデータベース・アップグレードの実行

次のリストで、アップグレードの高レベルの手順を説明します。

1. ロジカル・スタンバイ・データベースを新規リリースにアップグレードして、変更を評価します。

2. SQL ApplyによってREDOデータがすべてロジカル・スタンバイ・データベースに適用されたかどうかを確認します。

3. アプリケーションを切断します。

4. Oracle Data Guardスイッチオーバーを実行します。

5. アプリケーションを新規プライマリ・データベースに再接続します。

6. 元のプライマリ・データベースを停止します(これでロジカル・スタンバイ・データベースになる)。

7. 新しいスタンバイ・データベースでデータベース・ソフトウェアのアップグレード手順を実行します。

8. スタンバイ・データベースを再起動し、リカバリが同期化されるようにします。

9. 必要に応じて、Oracle Data Guardスイッチオーバーを実行して元のデータベースに戻ります。

パッチ・セットおよびデータベース・アップグレードを実行する際は、次の点を考慮してください。

- SQL Applyによるローリング・アップグレードは、Oracle Databaseリリース10.1.0.3以上の場合のみサポートされます。詳細は、『Oracle Data Guard概要および管理』のSQL Applyを使用したOracle Databaseのアップグレードに関する章を参照してください。

- SQL Applyにはいくつかのデータ型制限があります(制限のリストは、『Oracle Data Guard概念および管理』を参照)。データ型の制限がある場合は、拡張データ型サポート(EDS)の実装を検討してください。
EDSによりSQL Applyで、1つのデータベースから別のデータベースに、本来サポートされていないいくつかのデータ型を含む表への変更をレプリケートできます。Oracle Database 10gリリース2(10.2.0.4)パッチ・セット3から、SQL Applyでは、EDSの基礎となるロジカル・スタンバイ・データベースでトリガーを起動させる機能がサポートされています。EDSの概要は、http://www.oracle.com/goto/maaで入手可能なMAAホワイト・ペーパー「Extended Datatype Support Using SQL Apply and Oracle Streams」を参照してください。

本来SQL Applyではサポートされていないデータ型をサポートするためのEDSの使用例は、http://support.oracle.com/のNote 559353.1を参照してください。

- Oracle Database 11gリリース11.1以降では、フィジカル・スタンバイ・データベースでKEEP IDENTITY句および一時的なロジカル・スタンバイ・データベースを使用して、ローリング・データベース・アップグレードを実行できます。

- Oracle RACによるローリング・アップグレードができず、データ型の制限がない場合は、Oracle Data Guardが最適なアプローチです。

関連項目:

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

- http://www.oracle.com/goto/maaから入手できる次のMAAホワイト・ペーパー
「Database Rolling Upgrades Made Easy by Using a Data Guard Physical Standby Database」

「Database Rolling Upgrades Using Transient Logical Standby」

4.1.9.2 トランスポータブル表領域を使用したデータベース・アップグレードの実行

データ型が競合するためにSQL Applyを使用できず、テストの結果、DBUAでのアップグレードが稼働時間の要件を満たせないことがわかる場合、トランスポータブル表領域ソリューションを利用したデータベースのアップグレードを検討してください。

トランスポータブル表領域機能を利用してOracle Databaseをアップグレードするには、次の手順に従います。

1. トランスポート先システムにOracle Databaseソフトウェアをインストールし、ソース・データベースで最初の手順を実行し、トランスポート・プロセスの準備をします。

2. ソースおよびトランスポート先データベースを準備します。

1. ソース・データベースから情報を収集します。

2. Database Configuration Assistant(DBCA)でトランスポート先データベースを作成します。

3. Oracle Data Pump使用のためと、トランスポートされる表領域を受け入れるために、トランスポート先データベースの準備をします。

3. 次の手順でユーザー表領域をトランスポートします。

1. ユーザーを切断し、ソース・データベースへのアクセスを制限することで、ソース・データベースのトランスポートの準備をし、すべてのユーザー表領域をREAD ONLYにして、ソース・データベースから順序の開始値を取得します。

2. ユーザー表領域をトランスポートします。

4. トランスポート先データベースが完全であり機能することを確認した上でバックアップします。

トランスポータブル表領域を使用する場合、次の点を考慮してください。

- トランスポータブル表領域機能は、単純なスキーマを持ち、トランスポート・プロセスの一部としてデータ・ファイルを転送する必要がない(データ・ファイルが所定の場所で使用される場合など)データベースに対して、1時間未満でデータベース・アップグレードを実行するためのオプションです。次のWebサイトにあるMAAホワイト・ペーパー「Database Upgrade Using Transportable Tablespace」を参照してください。
http://www.oracle.com/goto/maa

- トランスポータブル表領域機能を使用すると、以前のリリースのソフトウェアが稼働するデータベースから、現行リリースのソフトウェアが稼働する空のトランスポート先データベースに、すべてのユーザー表領域を移動することにより、データベースのアップグレード時間が短縮されます。トランスポータブル表領域を持つ表領域データ・ファイルは、データ・ファイルをトランスポート先データベースにコピーし、オブジェクト・メタデータをトランスポート先データベースにインポートすることで、データベースに接続されます。

4.1.9.3 Oracle GoldenGateを使用したデータベース・アップグレードの実行

図4-1の構成は、Oracle Data Guardデータベース・ローリング・アップグレードによりサポートされないアップグレードおよび移行などによる、停止時間および計画停止の危険性を最小限に抑えるためのOracle GoldenGateおよびOracle Data Guardの構成方法を示します。これには、異なるハードウェア・アーキテクチャおよびオペレーティング・システムへの移行、データベース・オブジェクトを変更するアプリケーション・アップグレードの実行などが含まれます。この構成では、フィジカル・スタンバイ・データベースにより、移行の前後および移行中の停止時間またはデータ損失を防く災害からの保護が提供されます。また、移行の実行に必要な作業から本番データベースを分離することにより、パフォーマンスへの影響または操作上の危険性を回避します。

図4-1 計画停止時間を最小限に抑えるためのOracle GoldenGate構成

スタンバイ・データベース(図4-1の右上)から新しい本番データベース(右下)にGoldenGateをレプリケートするには、Oracle GoldenGateアーカイブ・ログ・モードが必要です。アーカイブ・ログ・モードの要件を満たすことができない場合は、元の本番データベース(左上のデータベース)から直接レプリケートします。

これらの要件は、新しいプラットフォーム上にパラレル環境を作成することにより達成されます。計画された移行のタイプによっては、新規プライマリ・データベースのインスタンス化が、既存のスタンバイ・データベースのバックアップのリストアと同じくらい単純になる可能性があります。より複雑な移行の場合は、Oracleトランスポータブル・テクノロジやOracle Data Pumpなどの、別のOracleテクノロジを使用して新規プライマリ・データベースをインスタンス化します。インスタンス化の後、新しい本番システム上で追加の変更を実装します。すべての変更が実装されると、新規フィジカル・スタンバイ・データベースが作成され、稼働開始後の継続的なデータ保護が提供されます。Oracle GoldenGateの異機種間レプリケーション(以前に構成済)が使用されて、新しい本番システムと、新しい環境の実装中に古いシステムで発生したすべてのトランザクションが同期化されます。同期化が完了すると、本番システムは新しい環境で稼働できるようになります。また、しばらくの間、新しい本番システムと同期された古い環境を保持するために、稼働後にOracle GoldenGate異機種間レプリケーションを使用するオプションもあります。ファスト・フォールバック・オプションでは、予期せぬ問題が発生する可能性があります。

4.1.9.4 Oracle GoldenGateを使用したデータベース・アップグレードの実行

Oracle GoldenGateは、Oracle Data Guard SQL Applyと機能上類似しています。SQL Applyと同様に、Oracle GoldenGateでは拡張データ型サポート(EDS)を利用して、本来サポートされていないいくつかのデータ型を含む表に対する変更を、データベース間でレプリケートできます。

Oracle GoldenGateを使用したデータベース・アップグレードの実行手順:

1. アップグレード・プロセスを開始する前に、ユーザー定義型を持つデータベースでデータベース・アップグレードを実行する方法については、Oracle GoldenGateのドキュメントを参照してください。

2. PRE_INSTANTIATIONプロシージャを使用して、Oracle Goldengateを構成します。

3. 複製データベースを作成します。(理想的なレプリカは、最新のフィジカル・スタンバイ・データベースとして始まります。)

4. データベースをアクティブにして、後続バージョンにアップグレードします。

5. 必要に応じて、POST_INSTANTIATIONプロシージャを使用して、追加の構成を実行します。

6. Oracle GoldenGateレプリケーションを有効にします。

7. レプリカのアップグレード中に、ソース・データベースはそのまま稼働し続けます。レプリカが遅れを取り戻したら、スイッチオーバーを実行します。

関連項目:

- オンライン・データベース・アップグレードの実行の詳細は、Oracle GoldenGateのドキュメントを参照してください。

- データベースの複製に関する詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

4.1.10 同じエンディアン形式のプラットフォーム間でのプラットフォームの移行

同じエンディアン形式のプラットフォーム間でプラットフォームの移行を実行する場合、次のアプローチを検討します。

- LinuxおよびWindowsプラットフォーム間で移行を実行するには、Oracle Data Guard(フィジカル・スタンバイ・データベース)のソリューションをお薦めします。このソリューションについては、4.1.2項で説明します。

- クロス・プラットフォームのフィジカル・スタンバイ・データベースが移行対象のプラットフォームの組合せに使用できない場合、トランスポータブル・データベース機能を使用します。このソリューションについては、4.1.10.1項で説明します。

- トランスポータブル・データベース機能で移行を迅速に実行できない場合は、Oracle GoldenGateを使用します。このソリューションについては、4.1.10.2項で説明します。

4.1.10.1 トランスポータブル・データベースを使用したプラットフォーム移行

クロス・プラットフォームのフィジカル・スタンバイ・データベースまたはロジカル・スタンバイ・データベースが、該当するプラットフォームの組合せに対してサポートされていない場合のみ、プラットフォーム移行にトランスポータブル・データベースを使用してください。脚注2

たとえば、Windows x86-64からLinux x86-64に移動する場合、トランスポータブル・データベースではなく、クロス・プラットフォームのスタンバイ・データベースを使用するのが適しています。停止時間が少なく(スイッチオーバーに要する時間のみ)、新しいプラットフォームでスタンバイ・データベースを一時的に実行して、すべてが計画どおりに機能するかどうかを確認できます。

トランスポータブル・データベース(移動先システムの変換を含む)を使用したプラットフォームの移行を実行する高レベルの手順を次に示します。

1. 読取り専用モードでソース・データベースを設定します。

2. RMANのCONVERT DATABASEコマンドを実行します。

3. 移動先システムにファイルを移動します。

4. RMAN生成スクリプトを実行して、UNDOが含まれるデータ・ファイルを移動先プラットフォームの形式に変換します。

5. RMAN生成スクリプトを実行して、移行を完了します。

トランスポータブル・データベース・ソリューションを使用する場合、プラットフォームの移行に必要な停止時間は、次の操作に要する時間によって異なります。

- 読取り専用モードでソース・データベースを設定

- UNDOが含まれるデータ・ファイルを新しいプラットフォームの形式に変換(UNDOが含まれていないデータ・ファイルは変換不要)

- ソース・システムから移動先システムにすべてのデータ・ファイルを転送します。
ストレージ・インフラストラクチャを使用すると、物理的にファイルを移動しなくても移動先システムでデータ・ファイルを使用できるため、この時間を大幅に短縮できます。

- SQLスクリプトutlirp.sqlおよびutlrp.sqlを使用して、すべてのPL/SQLを無効化および再コンパイル

詳細は、http://www.oracle.com/goto/maaから入手可能なホワイト・ペーパー「Platform Migration Using Transportable Database」を参照してください。

4.1.10.2 Oracle GoldenGateを使用したプラットフォームの移行

Oracle GoldenGateを使用すると、Oracleのプラットフォームやデータベースのリリースに関係なく、複数のデータベース間で更新をレプリケートできます。したがって、Oracle GoldenGateは、データベースのアップグレードおよびプラットフォームの移行に最も高速なアプローチを提供することになります。

Oracle GoldenGateでは、幅広いデータ型のデータベースをサポートしていますが、一部のデータ型のデータ移動は本来サポートされていません。ただし、このデータ型の制限は、拡張データ型サポート(EDS)を使用すると回避でき、Oracle GoldenGateの柔軟性を生かしてさらに多くの拡張データ型に対応できます。

この回避策を実現するために、PL/SQLパッケージEXTENDED_DATATYPE_SUPPORT(EDS)を使用して適切なデータベース・オブジェクトを生成できます。EXTENDED_DATATYPE_SUPPORTパッケージは、この記事の添付ファイルとしてダウンロードできます。ダウンロードしたファイル(My Oracle SupportのNote 556742.1:1からダウンロード可能)には、ReadmeファイルおよびデータベースにロードするSQLファイルが含まれます。

EDSパッケージによって、次のデータ型を含む表のOracle GoldenGateサポートを有効にする回避スクリプトが生成されます。

- 単純なオブジェクト型を含むオブジェクト列

- ネストしたオブジェクト型を含むオブジェクト列

- VARRAY

- 空間型SDO_GEOMETRY

- XML型

EDSパッケージをインストールしたら、EDS_SUPPORTEDビューの問合せを実行して、Oracle GoldenGateで本来サポートされていないがEDSでサポート可能なデータ型の表のリストを識別できます。

Oracle GoldenGateの実装は非常に柔軟でカスタマイズ可能なため、構成、テストおよび管理で付加的な作業が伴います。

Oracle GoldenGateでのプラットフォームの移行手順:

1. ソース・データベースでOracle GoldenGate環境を設定します。

2. ソース・データベースから新しい移動先データベースへデータをコピーして、レプリカ・データベースをインスタンス化します。

3. 移動先データベースでOracleGoldenGate環境を設定します。

4. Oracle GoldenGateで、ソース・データベースに加えられた変更をすべて移動先データベースに伝播して、移動先データベースとソース・データベースを完全に同期できるようにします。

5. ユーザーを移動先データベースに接続して、ソース・データベースを停止します。

6. Oracle GoldenGate構成を削除します。

関連項目:

- http://www.oracle.com/goto/maaから入手可能なMAAホワイト・ペーパー「Extended Datatype Support: SQL Apply and Streams」

- My Oracle SupportのNote 556742.1:1(http://support.oracle.com)

- Oracle GoldenGateの管理者ガイド

4.1.11 異なるエンディアン形式のプラットフォーム間でのプラットフォームの移行

異なるエンディアン形式のプラットフォームでプラットフォーム移行を実行する場合、次のアプローチを検討します。

- 停止時間を大幅に短縮するには、異なるエンディアン形式のプラットフォーム間でプラットフォーム移行を実行するための、トランスポータブル表領域機能のソリューションをお薦めします。トランスポータブル表領域を使用した移行は、このリストの後で説明します。
トランスポータブル表領域ソリューションには、キャラクタ・セット、不透明型およびシステム表領域オブジェクトに関して制限があります。前述の各ソリューションと異なり、手順は自動化されません。

次の事項がすべて当てはまる場合、トランスポータブル表領域を使用してプラットフォーム移行を実行します。

- ソース・プラットフォームと移行先プラットフォームのエンディアン形式が異なる。

- 完全なデータ・ポンプ・エクスポートおよびインポートの実行に必要な時間がメンテナンス・ウィンドウの期間に納まらない。

- すべてのアプローチの中で最も単純な方法として、Oracle Data Pumpの使用を検討してください。Oracle Data Pumpの使用方法の詳細は、『Oracle Databaseユーティリティ』を参照してください。

- 計画停止時間が数秒の可能性がある場合は、4.1.10.2項で説明するように、Oracle GoldenGateの使用を検討してください。

トランスポータブル表領域を使用したデータベースの新規プラットフォームへの移行方法を説明する高レベルの手順を次に示します。

1. 移行先プラットフォームで、新しい空のデータベースを作成します。

2. トランスポート操作に必要なオブジェクトを、ソース・データベースから移動先データベースにインポートします。

3. すべてのユーザー表領域のトランスポータブルなメタデータをソース・データベースからエクスポートします。

4. ユーザー表領域のデータ・ファイルを移動先システムに転送します。

5. RMANを使用して、データ・ファイルを移動先システムのエンディアン形式に変換します。

6. すべてのユーザー表領域のトランスポータブルなメタデータを移動先データベースにインポートします。

7. 残りの(トランスポート操作で移動されなかった)データベース・オブジェクトとメタデータをソース・データベースから移動先データベースにインポートします。

ヒント:
移動先データベースが移行時に新しい場所(新しいデータ・センターなど)に移動する場合は、移動先データベースと共存している最初のプライマリ・データベースからフィジカル・スタンバイ・データベースを作成します。Oracle Data Guardスイッチオーバー後、ファイル転送時間が停止時間の一部となることなく、表領域をソースから移動先にトランスポートします。

関連項目:

- http://www.oracle.com/goto/maaから入手できるMAAホワイト・ペーパー「Platform Migration Using Transportable Tablespace」

- データ・ファイルの変換の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

4.2 動的リソース・プロビジョニング

システムおよびデータベースの変更には、次の各項で説明する動的リソース・プロビジョニング機能を使用します。

- データベースの動的再構成

- メモリー管理の自動チューニング

- データ・ファイル、制御ファイルおよびログ・ファイルの分散の自動化

4.2.1 データベースの動的再構成

Oracleでは、サービスを中断することなく、ハードウェアの要求の変化に適応できるように、データベースの動的再構成のサポートを継続的に拡大しています。Oracle Databaseは、ハードウェアおよびデータベース構成への様々な変更に対して、次の機能を提供して動的に対応します。

- 対称型マルチプロセッシング(SMP)サーバーからのプロセッサの追加および削除

- Oracle RAC環境でのノードとインスタンスの追加および削除

- 自動共有メモリー管理を使用した、共有メモリーの割当ての動的な拡張と縮小、およびオンラインでのメモリーのチューニング

- データベース・アクティビティに影響しない、Oracle ASMを使用したオンラインによるデータベース・ディスクの追加および削除

- データベース・アクティビティに影響しない、Oracle ASMを使用したオンラインによるストレージ・アレイまたはExadataセルの追加および削除脚注3

- Oracle ASMを使用したデータベース・ストレージ全体のI/Oロードの自動リバランス

- ストレージ構成が変更するたびに自動的にデータベース・ストレージのリバランスを行う、Oracle ASMを使用したディスクの追加または削除時のオンラインによるデータ・ファイルの移動

- 次のいずれかのSQL*Plus文を使用することで、インスタンスを停止せずに、ほとんどすべての初期化パラメータを変更

- ALTER SESSION文は、セッション中にパラメータの値を変更します。

- ALTER SYSTEM文は、インスタンスの期間中、インスタンスのすべてのセッションでパラメータの値を変更します。

これらの機能により、エンタープライズ・グリッド・コンピューティングの基本要件であるシステム変更およびキャパシティ・オンデマンド・プロビジョニングがコストなしで実現されます。

4.2.2 メモリー管理の自動チューニング

2つのメモリー管理初期化パラメータ、MEMORY_TARGETとMEMORY_MAX_TARGETは、システム・グローバル領域(SGA)、プログラム・グローバル領域(PGA)およびOracle Databaseの実行に必要なその他のメモリーの自動管理を可能にします。

MEMORY_MAX_TARGETは、MEMORY_TARGETの動的な最大値を指定します。

表4-2 MEMORY_MAX_TARGETおよびMEMORY_TARGET

1つ目の条件

2つ目の条件

結果

MEMORY_MAX_TARGETを省略する

MEMORY_TARGETを省略する

初期化パラメータはデフォルト値(0)のままで、Oracle Databaseでは、メモリーは自動的にチューニングされません。

MEMORY_MAX_TARGETを省略する

MEMORY_TARGETの値を含める

データベースでは、MEMORY_MAX_TARGETがMEMORY_TARGETの値に自動的に設定されます。

MEMORY_TARGETを省略する

MEMORY_MAX_TARGETの値を含める

MEMORY_TARGETパラメータがデフォルトでゼロになります。

Oracle Databaseでは非集中型ポリシーを使用して、SGAおよびPGAの各サブコンポーネントのメモリーを解放して取得します。また、メモリーのグラニュルをあまり必要としないコンポーネントから、より必要とするコンポーネントに転送するようオペレーティング・システムに要求することにより、メモリーを自動的にチューニングします。メモリー転送の粒度は、現在の空きメモリーと、サービスに支障のない基本レベルを維持するためにオペレーティング・システムが必要とするメモリー量によって決まります。

注意:
MEMORY_TARGETおよびMEMORY_MAX_TARGET初期化パラメータを使用する自動メモリー管理は、Linux、Windows、Solaris、HP-UXおよびAIXでサポートされます。サポートされるすべてのプラットフォームの詳細は、『Oracle Database概要』および『Oracle Database管理者ガイド』を参照してください。

4.2.3 データ・ファイル、制御ファイルおよびログ・ファイルの分散の自動化

Oracle ASMでは、使用可能なディスク全体にデータ・ファイル、制御ファイルおよびログ・ファイルを自動的に分散します。ディスク、Exadataセルまたはストレージ・アレイの追加と削除など、ストレージ構成に変更があった場合に、データベース・ストレージのリバランスが行われます。Oracle ASMは、データベース・ファイルのミラー化を通じて冗長性を提供するとともに、使用可能なすべてのディスクにわたりデータベース・ファイルを自動的にストライプ化することにより最適なパフォーマンスを提供します。

関連項目:
Oracle ASMの詳細は、次のマニュアルを参照してください。

- Oracle Database概要

- 『Oracle Automatic Storage Management管理者ガイド』

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

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

オンライン再編成および再定義アーキテクチャには次のような利点があります。

- オンラインの表編成および再定義:

- 表の物理属性をオンラインで変更します(新しい場所への表の移動、表のパーティショニング、1つの構成(ヒープ構成など)から別の構成(索引構成など)への表の変換など)。

- 名前、型、サイズなどの多くの論理属性を変更します。列を追加、削除またはマージできます。ただし、表の主キーは変更できません。

- オンライン索引操作:

- 索引をオンラインで作成し、それらを同時に分析します。論理ROWIDの物理的推測コンポーネント(索引構成表の2次索引およびマッピング表で使用)のオンライン修復も使用できます。

- 索引構成表および2次索引をオンラインで再編成して、再編成のメンテナンス・ウィンドウを排除できます。2次索引は、ブロック・ヒント(物理的推測)の効率的な使用をサポートします。索引編成表で2次索引に格納される論理ROWIDの無効な物理的推測のオンライン修復も実行できます。

- 2次索引を再構築せずに索引構成表または表パーティションを再編成できるため、再編成のメンテナンス期間が短縮されます。

- パーティション化された表のオンライン移動

- アドバンスト・キュー、クラスタ表、マテリアライズド・ビューおよび抽象データ型(オブジェクト)に対するオンラインで再編成のサポート

- デフォルト値による高速なADD COLUMN操作(すべての行をデフォルト値に更新する必要はありません)

- 不可視の索引によるアプリケーションの移行とテストの高速化

- 明示的なヒントで移行の速度を上げ、終了したらヒントを削除します。

- 新しく作成された索引の早まった使用を防止します。

- 必要に応じて、索引を可視化してDROP INDEXの影響をテストするため、索引の再構築は必要ありません。

- DML操作の実行を中断しない索引のオンライン作成(DMLの排他ロックは不要)

- オンライン再定義が論理的にオブジェクトに影響を与えない場合(列が表に追加される場合やプロシージャがパッケージに追加される場合など)、依存オブジェクトの再コンパイルは不要

- オンラインでの表DDL操作の簡略化(停止ではなく、アクティブなDML操作を待つオプション)

- マテリアライズド・ビューやマテリアライズド・ビュー・ログがある表の再定義をサポート

表の物理属性の変更、およびデータと表構造の両方を変換する機能は、Oracle8iリリース以降に使用可能になりました。データ再編成の機能を表4-3に包括的に示します。

表4-3 各リリースの新規データ再編成機能

機能

Oracle 9i

Oracle Database 10gリリース1

Oracle Database 10gリリース2

Oracle Database 11g

パッケージDBMS_REDEFINITIONを使用したオンライン再編成

表記憶域パラメータの変更

異なる表領域への表の移動

パラレル問合せのサポートの追加

パーティション化サポートの追加または削除

断片化を回避するための表の再作成

表から索引構成表または索引構成表から表への変更

列の追加または削除

関数を使用した列の変換

権限、制約およびトリガーのクローニング

LONGからLOBへの変換

一意キーを使用した再編成

表順序の基準となる列の指定

単一のパーティションの再編成

アドバンスト・キューおよびクラスタ表

ADTを含んだ表

統計の保存およびクローニング

チェック制約およびNOT NULL制約

ネストした表の依存オブジェクトのコピー

マテリアライズド・ビュー・ログやマテリアライズド・ビューを含む表

再定義が論理的にオブジェクトに影響を与えない場合、依存オブジェクトの再コンパイルは不要

未使用の領域の解放

適用不可

次の文でSHRINK SPACE句を使用:

ALTER TABLE

ALTER INDEX

ALTER MATERIALIZED VIEW

ALTER MATERIALIZED VIEW LOG

適用不可

適用不可

オンラインでの索引の作成

CREATE INDEX emp.ename.idx ON emp(ename) ONLINE;

- パラレル操作をサポート

- パーティションをサポート

- クラスタを除くすべての索引タイプ

適用不可

適用不可

DMLをロックしないオンライン索引作成(ワークロードに依存しない透過的な作成が可能)

オンラインでの索引の結合

ALTER INDEX emp.ename_idx COALESCE;

- パラレル操作をサポート

- パーティションをサポート

- すべての索引タイプ

適用不可

適用不可

適用不可

オンラインでの索引構成表の移動

ALTER TABLE emp MOVE ONLINE;

- パラレル操作はサポート対象外

- パーティションをサポート

- 索引構成表のみ

適用不可

適用不可

適用不可

関連項目:
『Oracle Database管理者ガイド』

4.4 トランスポータブル・テクノロジ

新規プラットフォームへのデータベースの移行には、トランスポータブル・テクノロジの機能を使用します。トランスポータブル・テクノロジでは、トランスポータブル・データベースとトランスポータブル表領域が提供されます。

- トランスポータブル・データベース機能は、データベース全体(ユーザー・データとOracleディクショナリ)を同じエンディアン形式の新しいプラットフォームに移動する場合に使用されます。トランスポータブル・データベースでは、すべてのユーザー・データをソース・データベースからアンロードして移動先データベースにロードする時間のかかる方法を使用せずに、新しいプラットフォームに最小限の停止時間で移行できます。

- トランスポータブル表領域機能は、あるデータベースのサブセットを別のデータベースに移動します。エンディアン形式が異なるプラットフォーム間でも可能です。

- トランスポータブル表領域機能のクロス・プラットフォーム機能を使用すると、データベース内のすべてのユーザー・データを、異なるエンディアン形式の新しいプラットフォームに移行できます。この方法でトランスポータブル表領域機能を使用すれば、すべてのユーザー・データをソース・データベースからアンロードして移動先データベースにロードする時間のかかる方法を使用せずに、新しいプラットフォームに最小限の停止時間で移行できます。

- トランスポータブル表領域機能を使用すれば、データベースには単純なスキーマがあり、トランスポート・プロセス中にデータ・ファイルをコピーする必要がない場合(データ・ファイルが所定の場所で使用されている場合など)、データベースのアップグレードのための停止時間を短縮できます。

関連項目:

- 4.1.9.2項「トランスポータブル表領域を使用したデータベース・アップグレードの実行」および4.1.10.1項「トランスポータブル・データベースを使用したプラットフォーム移行」

- 別のデータベースに表領域を移動またはコピーする方法の詳細(プラットフォーム間の表領域のトランスポートの詳細を含む)は、『Oracle Database管理者ガイド』を参照してください。

4.5 オンライン・アプリケーションのメンテナンスおよびアップグレード

アプリケーションの変更には次に示す機能を使用します。これらの機能を使用することで、アプリケーションのデータベース・オブジェクトの変更に必要なアプリケーションの停止時間を大幅に短縮する(またはゼロにする)ことができます。

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

- ローリング・アップグレードに使用するOracle GoldenGate

- WAITオプションを使用したDDL

- CREATE TRIGGERのENABLE、DISABLEおよびFOLLOWS句

- ADD COLUMN機能の拡張

- きめ細かな依存性

- 不可視の索引

- 表のオンライン再定義後の依存PL/SQLの再コンパイル

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

エディションベースの再定義により、アプリケーションの使用中にアプリケーションのデータベース・コンポーネントをアップグレードできるため、停止時間を最小化またはゼロにすることができます。管理者が変更を行っても、アプリケーションのユーザーには影響はなく、アップグレードされたアプリケーションがユーザー全員に使用可能になるまで、ユーザーは変更されていないアプリケーションを引き続き実行します。

順調な場合は、ロールオーバーが可能です。アップグレード前とアップグレード後のエディションは同時に使用できるため、アップグレード後のエディションの公開前に開始されたセッションは、自然に終了するまで、引き続きアップグレード前のエディションを使用することができ、新しいセッションではアップグレード後のエディションが使用されます。順調でない場合は、アップグレード前のセッションをすべて終了させないと、新しいセッションでアップグレード後のエディションを使用できません。そのような場合、アプリケーションは少しの間停止することになります。

この後の項では、エディションベースの再定義のエディション、エディショニング・ビューおよびcrosseditionトリガーの機能について説明します。詳細は、『Oracle Database開発ガイド』を参照してください。

4.5.1.1 エディション

エディションは非スキーマ・オブジェクトであり、所有者が存在しません。エディションは単一のネームスペースで作成され、データベース内で複数のエディションが共存できます。エディション機能を使用すると、データベース・オブジェクトをコピーし、コピーしたオブジェクトを分離して再定義できます。

エディションにより、新しいコードのインストールや、データ変更を行うためのプライバシ・メカニズムが提供され、実行中の本番アプリケーションではその変更は見えません。必要な変更がすべて非公開で行われ、1つの原子動作で公開されます。

4.5.1.2 エディショニング・ビュー

1つ以上の表の構造を変更する場合、オンライン・アプリケーション・アップグレード中に基礎となる表に加えられる変更からアプリケーション・コードを隔離するには、エディショニング・ビュー機能も使用する必要があります。表は編集できません。

基礎となる表に列が追加され、それらを公開してデータを移入するために、アップグレード後のエディションで新しいエディショニング・ビューが作成されます。(エディションには、基礎となる表のバージョンは使用できません。)

エディショニング・ビューにはトリガーを作成でき、ビューの列はSQLのヒントで使用できます。エディショニング・ビューを定義するSELECT文には、FROMリストとNO WHERE句に表を1つ指定します。SELECTリストを使用して、表の列のサブセットを推定し、通常はそれらの名前を変更します。その結果、このリストにより物理列の論理列へのマッピングが定義されます。

4.5.1.3 crosseditionトリガー

crosseditionトリガーは、エディションベースの再定義の一部として使用され、アップグレード前のエディションとアップグレード後のエディションのデータが互いに一致するように保ちます。アップグレード前のアプリケーションは、変更が適用され、アップグレード前のエディションがアップグレード後のエディションに再定義されている間もそのまま使用されます。

表構造の変更中に、ユーザーが表のデータを変更できるようにするには、forward crosseditionトリガーも使用します。他のユーザーがアプリケーションの古いバージョンを使用し続けている間、アップグレード済のアプリケーションを一部のユーザーが使用できるようにするには、reverse crosseditionトリガーも使用します。crosseditionトリガーは、アップグレードしたアプリケーションをユーザー全員が使用できるようにしたら削除するか無効にするため、アプリケーションの永続的な部品ではありません。

4.5.2 ローリング・アップグレードに使用するOracle GoldenGate

高速ローリング・アップグレードにOracle GoldenGateを使用することを検討してください。ただし、Oracle GoldenGateによるアップグレードでは、データベースの停止時間を最小限またはゼロにできますが、このソリューションを構成するには、運用面での投資がある程度必要になります。必要に応じて、3.7項およびGoldenGateのドキュメントを参照してください。

4.5.3 WAITオプションを使用したDDL

データ定義言語(DDL)コマンドには、内部構造で排他ロックが必要です。DDLコマンドが発行されると、これらのロックは使用できず、DDLが何秒か後に成功する場合があっても、文はすぐに失敗します。WAITオプション(新しいデフォルト)でDDLを指定すると、この問題が解決します。待機時間をインスタンス全体(初期化パラメータ・ファイル)で指定し、セッション・レベルで待機時間を変更します。

WAITオプションでDDLコマンドを指定すると、すぐにエラーが発生するのではなく、コマンドが成功するまでの猶予期間を定義する柔軟性が得られるため、このようなエラーに対処する追加のアプリケーション・ロジックが必要になります。詳細は、『Oracle Database管理者ガイド』を参照してください。

4.5.4 CREATE TRIGGERのENABLE、DISABLEおよびFOLLOWS句

状態(ENABLEおよびDISABLE)と順序付け(FOLLOWS)はトリガーの起動を制御するためのトリガーです。このような状態が追加されたことで、トリガーの管理制御が向上しています。CREATE TRIGGER文を無効な状態で使用すれば、有効にする前にコンパイルが成功したかどうかを検証できます。また、トリガーの順序をFOLLOWS句で制御できます。詳細は、『Oracle Database開発ガイド』を参照してください。

4.5.5 ADD COLUMN機能の拡張

列のデフォルト値は、NOT NULLとして指定された列のデータ・ディクショナリで管理されます。

DEFAULT値とNOT NULL制約を指定して新しい列を追加する場合、デフォルト値を既存のすべてのレコードに格納する必要がなくなります。この拡張は、既存のデータ量に関係なく動作し、スキーマ変更を数秒以内に行えるほか、領域を消費することもありません。詳細は、『Oracle Database管理者ガイド』を参照してください。

4.5.6 きめ細かな依存性

Oracle Database 11gより前のリリースでは、メタデータはオブジェクト全体の粒度でオブジェクト間の相互の依存性を記録します。(たとえば、PL/SQLの単位PはPL/SQLの単位Qに依存し、ビューVは表Tに依存するとします。)このような場合、依存オブジェクトは場合によって不必要に無効になっていました。たとえば、ビューVが表Tの列C1、C2およびC3にのみ依存し、新しい列C99が追加される場合、ビューVの有効性は論理的に影響を受けません。それにもかかわらず、以前のリリースでは、Vは列C99が加えられたことによって無効になっていました。

Oracle Database 11gリリース1(11.1)から、依存性メタデータはよりきめ細かい粒度レベルで記録されるため、C99が追加されたことでビューVが無効になることはありません。同様に、プロシージャPがパッケージPKGの要素E1およびE2にのみ依存し、要素E99がPKGに追加される場合も、プロシージャPは無効になりません。(Oracle Database 10gでは、PKGに要素E99が加えられると、プロシージャPは無効になります)。

依存対象のオブジェクトの変更に応じて依存オブジェクトが結果的に無効になることが少なくなることで、アプリケーションの可用性を向上させることができます。これは、開発環境や、稼働中のアプリケーションを解析またはアップグレードする場合に役立ちます。スキーマ・オブジェクトに対する変更には互換性が必要であるため、Oracle Databaseのパッチ・セットを適用する場合にこれが役立ちます。詳細は、『Oracle Database開発ガイド』を参照してください。

4.5.7 不可視の索引

不可視の索引は、索引を使用できなくしたり、索引を削除したりすることの代替方法です。不可視の索引はDML操作に対して維持されますが、ヒントで索引を明示的に指定しないかぎり、オプティマイザで使用されません。

アプリケーション全体をオフラインにできないときでも、アプリケーションの変更が必要になることがしばしばあります。不可視の索引を使用すると、アプリケーション全体に影響を与えることなく、アプリケーションの特定の操作やモジュールに対して一時的な索引構造を利用できます。さらに、不可視の索引を使用して、索引をすぐに削除せずに削除のテストを行うことができるため、本番環境でテストするための猶予期間ができます。詳細は、『Oracle Database管理者ガイド』を参照してください。

4.5.8 表のオンライン再定義後の依存PL/SQLの再コンパイル

この機能は、表のオンライン再定義後に依存PL/SQLパッケージを再コンパイルする必要性を最小限に抑えます。再定義によってPL/SQLパッケージに論理的な影響が出ない場合、再コンパイルは必要ありません。この最適化はデフォルトで有効です。

再コンパイルが必要な場合、この機能によって、表のオンライン再定義後に依存PL/SQLパッケージを手動で再コンパイルする時間が短縮され、その手間が軽減されます。再コンパイルには、再定義によって論理的に影響を受けないビュー、シノニム、その他の表依存オブジェクト(トリガーを除く)なども含まれます。オンラインでの表の再定義の詳細は、『Oracle Database管理者ガイド』を参照してください。

脚注の凡例

脚注1: DBUAでは停止時間が発生します。停止時間の量は、要因の数によって異なります。アップグレード・オプションとしてDBUAを選択したときの追加の考慮事項は、『Oracle Database高可用性ベスト・プラクティス』を参照してください。Oracle DatabaseソフトウェアのアップグレードにDBUAを使用する手順は、『Oracle Databaseアップグレード・ガイド』を参照してください。
脚注3: Oracle Databaseリリース11g以降では、Oracle Data Guard構成のプライマリ・システムとスタンバイ・システムで異なるCPUアーキテクチャ、オペレーティング・システム(WindowsやLinuxなど)、オペレーティング・システム・バイナリ(32ビットと64ビット)、Oracle Databaseバイナリ(32ビットと64ビット)を使用できます。最新の機能と制限については、My Oracle SupportのNote 413484.1(http://support.oracle.com/)を参照してください。
脚注4: Exadataのホワイト・ペーパーのOracle Exadata Storage Serverのベスト・プラクティスへの移行(http://www.oracle.com/technetwork/database/exadata/index.htm)を参照してください。

5 投資利益率(ROI)の最適化

Oracleグリッド・コンピューティング、障害時リカバリ・ソリューションとスタンバイ・データベースの高度な使用、および仮想化は、すべて投資利益率(ROI)の最適化に役立ちます。

高可用性および防災の両方を実現しながら、既存のシステム・インフラストラクチャをスケールアウトできます。Oracle Data Guardスタンバイ・データベースはグリッドに不可欠な部分であり、停止の原因や範囲に関係なく、データ保護および可用性を提供します。停止の原因は、個々のデータベースに影響するデータ破損から広い地域に影響を及ぼす自然災害まで様々です。

Data Guardの高度な機能は、スタンバイ・ロールでもスタンバイ・データベースを(読取り専用問合せやレポート作成などの)本番用に使用することを可能にし、最大のROIをもたらします。スタンバイ・データベースをアイドル状態にしておくかわりに、これらを利用してアクティビティをサポートできるため、他のシステム用に追加の容量を購入する必要がありません。また、プライマリ・データベース用の容量を追加購入する必要がなくなるか、購入を見合せることができます。これにより、ミッション・クリティカルなOracle Databaseに対する世界レベルの防災のコストを効果的に削減できます。

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

- グリッド・コンピューティング

- データベース・サーバー・グリッド

- データベース・ストレージ・グリッド

- アクティブ・スタンバイ・データベースを使用した障害時リカバリ

- Oracle VMとドメイン・ライブ・マイグレーション

5.1 グリッド・コンピューティング

グリッド・コンピューティングとは、あらゆる企業のコンピューティング・ニーズに応えるため、多数のサーバーおよびストレージを柔軟性のあるオンデマンド・コンピューティング・リソース内に効果的にプールするコンピューティング・アーキテクチャです。

Oracle Databaseには、パフォーマンス、スケーラビリティ、セキュリティ、管理性、機能性またはシステム可用性を犠牲にせずに、コスト面におけるグリッド・エンタープライズ・コンピューティングの利点が取り込まれています。

- データベース・サーバー・グリッドは、1つ以上のデータベースを実行するために接続された汎用サーバーの集合です。

- データベース・ストレージ・グリッドは、相互に組み合され、データベース・サーバー・グリッド内のコンピュータからアクセスされる低コストのモジュラ・ストレージ・アレイの集合です。

同じグリッド・コンピューティングの概念を使用して、データ保護、計画停止時間の最小化、品質保証テストに適したテスト・システムなどを複数のプライマリ・データベースに対して提供する、スタンバイ・データベースのハブを作成できます。グリッドの機能により、現在の優先順位に応じて、システム・リソースの動的プロビジョニングおよびプロビジョニング解除が可能です。たとえば、プライマリ・データベースがData Guardハブのいずれかのスタンバイ・データベースにフェイルオーバーした場合、テスト・アクティビティに割り当てられているリソースが減少している間、そのスタンバイ・データベースにより多くのシステム・リソースとストレージ・リソースを割り当てることができます。グリッドでは、ビジネス要件を損うことなく、高レベルの使用率と低TCOが可能になります。

図5-1に、グリッド・エンタープライズ・コンピューティング環境内のデータベース・サーバー・グリッドおよびデータベース・ストレージ・グリッドを示します。

図5-1 グリッド・コンピューティング環境

5.2 データベース・サーバー・グリッド

低コストのおよび信頼性のあるブレード・サーバーの可用性、小規模のマルチ・プロセッサ・サーバーおよびLinuxなどの安価なオープンソース・オペレーティング・システムによって、可用性、スケーラビリティ、柔軟性および管理性が非常に高いデータベース・サーバー・グリッドの構築が可能になりました。

Oracle RACはデータベース・サーバー・グリッドを有効にするテクノロジです。それぞれがOracleデータベースのアクティブなインスタンスを実行する複数の低コスト・サーバーにわたって、単一のOracle RACデータベースをデプロイすることで、コストを下げることができます。もしくは、単一クラスタを使用して、Oracle RACの複数のデータベースにわたるシステム使用率増加の管理を統合できます。

Oracle RACによって、グリッド内の動的プロビジョニング・リソースおよびサービスに柔軟性が与えられ、コンピューティング・ニーズの変化に対応し、容量への需要増加に合せてグリッドにシステムを追加したり、システムを削除できます。また、Oracle RACでは、クライアントの自動遷移、および障害が発生したノードから同じOracle RACデータベース内の残りのノードに処理を再分散することで、システム障害からの保護が提供されます。グリッド・コンピューティングのスケーラビリティおよび可用性の利点は、低コストのサーバーに限定されるものではありません。グリッド・コンピューティングは、すべてのシステム・アーキテクチャに効果があります。

5.3 データベース・ストレージ・グリッド

低コストのAdvanced Technology Attachment(ATA)ディスクベース・ストレージ・アレイおよびストレージ・ネットワークの可用性により、Oracle Databaseでデータベース・ストレージ・グリッドを非常に低コストで使用できるようになりました。ソリューションの一例は、パフォーマンスおよび可用性に関して優れた特性を提供するOracle Exadata Storage Serverです。各Exadataセルを、I/Oのパフォーマンスとキャパシティの単位で表示できます。

Oracle Storage Gridは、Oracle Automatic Storage Management(ASM)とOracle Exadata Storage Server Software、またはASMとサード・パーティのストレージを使用して実装されます。Exadataを使用したOracle Storage Gridを使用すると、MAA関連のテクノロジをシームレスにサポートでき、パフォーマンスが向上し、無制限のI/Oスケーラビリティが得られます。また、使用および管理が容易で、企業はミッション・クリティカルな可用性および信頼性を得られます。Oracle Storage Gridの推奨事項およびExadataの使用方法は、『Oracle Database高可用性ベスト・プラクティス』を参照してください。

データベース管理者は、Oracle ASMインタフェースを使用して、Oracle ASMがすべてのサーバーおよびストレージ・プラットフォームにわたり管理するデータベース・ストレージ・グリッド内のディスクを指定できます。Oracle ASMは、ディスク領域をパーティション化し、ストレージ・アレイ全体でデータ記憶域を均一に分散します。さらに、ストレージ・アレイがデータベース・ストレージ・グリッドに追加または削除される際、Oracle ASMは自動的にデータ記憶域を再分散します。

また、I/Oリソース管理を使用して管理し、サービス・レベルの要件を満たすことができます。リソース・マネージャは、データベース内またはデータベース間でのグリッドおよび優先アプリケーションの管理を可能にします。

5.4 アクティブ・スタンバイ・データベースを使用した障害時リカバリ

スタンバイ・データベースは、障害時リカバリの提供に加えて、ITおよびアプリケーションの動的な要件を満たすために利用できます。Oracle Data GuardのOracle Active Data Guardオプションを使用すると、障害時リカバリ・ソリューションを提供する以外に、通常操作時に他の有用な作業にフィジカル・スタンバイ・データベースを使用できます。

次の項では、他のビジネス目的でフィジカル・スタンバイ・データベースを利用できるOracle Data Guardの機能について説明します。

- フィジカル・スタンバイ・データベースのOracle Active Data Guardオプション

- スタンバイ・リーダー・ファームを使用したWebスケール

5.4.1 フィジカル・スタンバイ・データベースのOracle Active Data Guardオプション

Data GuardのREDO Apply(フィジカル・スタンバイ・データベース)は、相対的に簡単なことと、高パフォーマンスおよび高度なデータ保護のために、障害時リカバリの一般的なソリューションになっています。Oracle Active Data Guardオプション脚注1(Oracle Database 11gリリース1(11.1)以降のリリースで使用可能)を使用すると、REDO Applyがアクティブである間、読取り専用アクセスのためにフィジカル・スタンバイ・データベースをオープンできます。そのため、データ保護を犠牲にしたり、フェイルオーバーが必要な場合のリカバリ時間を延長したりせずに、最新のフィジカル・スタンバイ・データベースに対して問合せやレポート作成を実行できます。読取り専用のワークロードをプライマリ・データベースからアクティブ・スタンバイ・データベースにオフロードすると、パフォーマンスが向上し、追加の容量の購入を見送ることができます。

Oracle Active Data Guardオプションを有効にするには、読取り専用モードでデータベースを開き、ALTER DATABASE RECOVER MANAGED STANDBY文を発行します。プライマリ・データベースとフィジカル・スタンバイ・データベースの両方で、COMPATIBLEパラメータを11.0.0以上に設定する必要があります。この機能の使用は、Oracle Databaseへの読取り専用アクセスを必要とするすべてのアプリケーションに対して完全に透過的です。

Oracle Active Data Guardオプションは、次の機能により、究極の高可用性ソリューションを提供します。

- プライマリ・データベースとスタンバイ・データベースでOracle RACをサポートします。
Oracle Active Data Guardオプションは、単一インスタンスおよびOracle RACのフィジカル・スタンバイ・データベースの両方で機能します。REDO Applyは1つのOracle RACインスタンスでのみ実行できますが、適用インスタンスを含むすべてのインスタンスを読取り専用モードで実行できます。

- プライマリ・データベースの最新状態にきわめて近い一貫した結果を、トランザクションにより返します。
遅延設定や適用頻度により、スタンバイ・データベースはプライマリ・データベースと同時か何秒か遅れます。問合せは、常にトランザクションでは一貫しており、そのときの最後にコミットしたトランザクションの一貫したビューを示します。

- スタンバイ・データベースが読取り専用で開いているときに、プライマリ・データベースで生成されたREDOがスタンバイ・データベースにすでに適用され、スタンバイ・データベースがプライマリ・データベース・ロールをすぐに引き継ぐことができるため、高速なスイッチオーバーまたはフェイルオーバーが可能です。

- プライマリ・データベースに障害が発生した場合、ファスト・スタート・フェイルオーバーを自動フェイルオーバーのために使用できます。

注意:
Oracle Active Data Guardが有効な実行中のフィジカル・スタンバイ・データベースをトランザクションが変更しようとすると、そのトランザクションはエラーで失敗します。

Oracle Active Data Guardの使用の詳細は、『Oracle Data Guard概要および管理』を参照してください。

5.4.2 スタンバイ・リーダー・ファームを使用したWebスケール

複数のフィジカル・スタンバイ・データベース(Oracle Active Data Guardオプションを使用)とロジカル・スタンバイ・データベースを使用して、リーダー・ファームをデプロイできます。このような構成の例を図5-2に示します。この図は、プライマリ・データベースに障害が発生した場合、Oracle Data Guardのファスト・スタート・フェイルオーバーを使用してフェイルオーバーが自動的に行われることを示しています。フェイルオーバーが行われると、リーダー・ファームのすべてのスタンバイ・データベースは、新しいプライマリ・データベースを自動的に認識することに注意してください。

リーダー・ファームを使用すると、基本的なシステムおよびストレージ・アーキテクチャのサポート可能範囲を超えて、最も要求の厳しいWebアプリケーションの読取りパフォーマンスを向上できます。これにより、I/Oが駆動要因となるグリッド・アーキテクチャを使用して拡張を行う比較的低コストの方法が可能になります。

この概念は単純です。つまり、1つのプライマリ・データベースが読取り/書込みのトランザクションをサポートし、複数のスタンバイ・データベースがWebユーザーに読取り専用アクセスを提供します。このようなアプローチでは、スタンバイ・データベースが追加されるにつれて、読取りパフォーマンスが直線的に高まります。また、1つのスタンバイ・データベースに影響を及ぼす問題が構成内の他のスタンバイ・データベースから分離されるため、フォルトを分離する効果的な方法でもあります。

フィジカル・スタンバイ・データベースのリーダー・ファームを作成する利点には次のようなものがあります。

- フォルトの分離

- フィジカル・スタンバイ・データベースとREDO Applyによる高パフォーマンス

- REDO Applyを使用した、すべてのDDLとデータ型のシームレス・サポート

- プライマリ・データベースの変更を含めて、すべてのリーダー・データベースを最新の状態に維持

- データ損失をゼロまたは最小限に抑えた、自動フェイルオーバー機能

- グリッド・コントロールによる一元的な構成としての管理

- 1つのライター・データベースとn個のリーダー・データベースを使用した拡張

- ローリング・アップグレード機能

図5-2は、Oracle Data Guard、フィジカル・スタンバイ・データベースおよびOracle Active Data Guardオプションを使用して、ビジネスの迅速な成長に必要な柔軟性を提供し、その一方で障害時リカバリも提供する適切な使用例を示しています。この構成では、プライマリ・データベースはREDOデータを複数のスタンバイ・データベースに転送し、そのうちの1つが、データ損失をゼロまたは最小限に抑えた自動フェイルオーバーを行うファスト・スタート・フェイルオーバー用に有効になっています。

図5-2 スタンバイ・データベースのリーダー・ファーム

図5-2のOracle Data Guard構成で、ファスト・スタート・フェイルオーバーがトリガーされるとします。

- 自動フェイルオーバーは目的のスタンバイ・データベースに対して行われます。

- すべてのスタンバイ・データベースは新しいプライマリ・データベースからデータを受け入れます。

- スイッチオーバーを適宜実行して、すべてのデータベースを元のロールに戻すことができます。

5.5 Oracle VMとドメイン・ライブ・マイグレーション

グリッド・コンピューティング、スタンバイ・データベースを高度に使用した障害時リカバリ・ソリューション、および仮想化は、すべてROIの改善に役立ちます。仮想化の主な利点には、統合や、すべてのリソースを効率的に使用することが含まれます。

Oracle VMを使用すると、サポートされている仮想化環境内にオペレーティング・システムとアプリケーション・ソフトウェアをデプロイできます。各仮想マシンには独自の仮想CPU、ネットワーク・インタフェース、記憶域およびオペレーティング・システムがあるため、Oracle VMでは基礎となるハードウェアの物理制約からワークロードが分離されます。Oracle VMは、計画サーバー停止またはワークロードの不均衡と関連したサービス停止を大幅に減らす機会を提供します。Oracle VMのドメイン・ライブ・マイグレーション機能を使用して、ドメインを1つの物理サーバーから、仮想マシンが稼働しているもう1つの同質のコンピュータに移行すると、可用性を高めることができます。たとえば、次のことができます。

- 障害が発生したサーバーから、修復中に操作を続けられる存続能力のあるサーバーにドメインを移行

- 1つのサーバーが過負荷にならないようにワークロードをリバランス

移行中もドメインではサービスの提供は続けられ、エンド・ユーザーは何の変化にも気付きません。

関連項目:

- 『Oracle VM Serverユーザーズ・ガイド』

- OTN内のOracle VMのWebサイト(http://www.oracle.com/virtualization)

脚注の凡例

脚注1: Oracle Active Data GuardはOracle Data Guardドキュメントではリアルタイム問合せと呼ばれます。

6 管理性の最適化

複雑な環境では、構成の変更、システムのアップグレードおよび新しいアプリケーションのロールアウトの調整が要求されます。この項では、高可用性アーキテクチャでの操作を自動化して簡素化するのに使用可能なツールについて説明し、自己管理のOracleデータベース実現に向けての一歩を踏み出せるようにします。

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

- インテリジェントなインフラストラクチャ

- 変更の保証

- Oracle Enterprise Manager Grid Control

6.1 インテリジェントなインフラストラクチャ

Oracle Databaseには、データベースが自己学習し、この情報を使用してワークロードの変動に対応したり、あらゆる潜在的な問題のほとんどを自動的に修正したりすることができる高度な自己管理インフラストラクチャがあります。自己管理インフラストラクチャ脚注1には次のようなものがあります。

- 自動ワークロード・リポジトリ
自動ワークロード・リポジトリ(AWR)は、問題の検出やセルフチューニングのためにOracle Databaseが使用するパフォーマンス統計を含む組込みリポジトリです。Oracle Databaseでは重要な統計とワークロード情報のスナップショットを定期的に作成し、AWRに格納します。スナップショットに含まれるデータは、自動データベース診断モニター(ADDM)で分析されます。

AWRおよびADDMの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

- アクティブ・セッション履歴
一時的なパフォーマンスの問題は長続きしないため、ADDM分析に表示されません。これらの問題に対処するために、アクティブ・セッション履歴(ASH)を使用してデータベースの起動時にアクティブ・セッションのサンプリングを開始できます。ASHのサンプルは次の場合に収集できます。

- データベースが(Oracle ASMインスタンスなどに)マウントされる前。

- データベースが(Oracle Data Guardフィジカル・スタンバイ・インスタンスなどに)マウントされているが、オープンされていないとき。

- データベースが(Oracle Active Data Guardフィジカル・スタンバイ・インスタンス、別名リアルタイム問合せなどに)マウントされているが、読取り専用にオープンされているとき。

注意:
アクティブ・セッション履歴のサンプリングは、Oracle Active Data GuardインスタンスおよびOracle Automatic Storage Management(ASM)インスタンスで使用できます。ただし、このリリースでは、Oracle Data Guardの構成でインテリジェントなインフラストラクチャのすべての機能を使用できるわけではありません。

フィジカル・スタンバイ・インスタンスの場合、ディスク上のASHデータはプライマリ・データベースのアクティビティを表し、メモリー内のASHデータはスタンバイ・データベースのアクティビティを表します(V$ACTIVE_SESSION_HISTORY内に表示)。ASHレポートでは、レポート生成にプライマリ・データベースとスタンバイ・データベースのどちらからサンプリングされたデータを使用するかを指定するよう求められます。

関連項目:

- 『Oracle Databaseパフォーマンス・チューニング・ガイド』に含まれる、特定のデータベース・インスタンスでのASHレポートの生成に関する項

- フィジカル・スタンバイ・データベースおよびOracle Active Data Guard(リアルタイム問合せ)の詳細は、『Oracle Data Guard概要および管理』を参照してください。

- MAAホワイト・ペーパー「Oracle Active Data Guard for Oracle Data Guard 11g Release 1」(http://www.oracle.com/goto/maa)

- 自動メンテナンス・タスク
AWRに格納された情報を分析することにより、データベースは日常的なメンテナンス・タスクを実行する必要があるかどうかを確認できます。自動メンテナンス・タスク・インフラストラクチャ(AutoTaskと呼ばれる)を使用すると、Oracle Databaseはこのような操作を自動的にスケジュール設定することができます。AutoTaskでは、メンテナンス期間と呼ばれるOracle Scheduler期間のセットで自動メンテナンス・タスクを実行するようにスケジュール設定します。メンテナンス期間は、Oracle Scheduler期間グループMAINTENANCE_WINDOW_GROUPのメンバーである期間です。詳細は、『Oracle Database管理者ガイド』および『Oracle Database 2日でデータベース管理者』を参照してください。

- フォルト診断インフラストラクチャ
Oracle Databaseには、問題の防止、検出、診断および解決を行う高度なフォルト診断インフラストラクチャがあります。対象となる問題は、データベース・コードの不具合、メタデータの破損およびユーザー・データの破損から生じる重要なエラーです。診断インフラストラクチャには次のような機能があります。

- 自動診断リポジトリ(ADR)は、トレース、アラート・ログ、状態モニターのレポートといったデータベース診断データ用のファイルベースのリポジトリです。複数のインスタンスや製品にまたがる一元化されたディレクトリ構造を持っています。

- データベース管理者が、重大なエラーに関連するすべての診断データ(トレース、状態チェック・レポート、SQLテスト・ケースなど)を自動で簡単に収集し、そのデータをOracleサポート・サービスへの転送に適したZIPファイルにまとめるために使用できるインシデント・パッケージ・サービス。

これらのコンポーネントの詳細は、『Oracle Database管理者ガイド』を参照してください。

- サーバー生成アラート
問題が自動的に解決されず(領域不足など)、管理者に通知する必要がある場合、Oracle Databaseはサーバー生成アラートを提供します。Oracle Databaseは自らを監視し、アラートを送信して問題をユーザーに通知し、報告された問題の解決方法に関する提案を行います。これにより、問題が素早く解決され、潜在的な障害の防止に役立ちます。

- アドバイザ・フレームワーク
Oracle Databaseには、データベースの様々なサブシステムに対する複数のアドバイザがあり、対応するサブコンポーネントの操作をさらに最適化できる方法を自動的に決定します。たとえば、SQLチューニング・アドバイザとSQLアクセス・アドバイザは、SQL文をより速く実行するための提案を行います。メモリー・アドバイザは、試行錯誤による方法を使用せず、様々なメモリー・コンポーネントのサイズ調整に役立ちます。セグメント・アドバイザは、領域関連の問題(消費済領域の再利用の提案や成長傾向の分析など)に対処し、UNDOアドバイザはUNDO表領域のサイズ設定を正しく行います。アドバイザの使用の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

6.2 変更の保証

Oracle Databaseでは、データベースやSQLの変更による影響を分析できるように、変更前後のワークロードの自動取得とリプレイ機能を提供します。

- データベース・リプレイ
データベース・リプレイ機能では、本番システムの実際のデータベース・ワークロードを取得して、それをテスト・システムでリプレイすることにより、実際のテストを実行できます。また、潜在的な問題(エラーの発生やパフォーマンスの相違)やその問題を修正する推奨方法を示す分析とレポート作成も提供されます。

- SQLパフォーマンス・アナライザ
SQLパフォーマンスの低下は、データベースのアップグレード、初期化パラメータの変更、および索引の追加や削除などのシステム変更において常に懸念事項になります。SQLパフォーマンス・アナライザ機能では、SQL文のパフォーマンスに対する変更の影響を評価する方法を提供して、変更前後のレスポンス時間を比較および対比することにより、この懸念事項を軽減します。SQパフォーマンス・アナライザを使用すると、本番データベースなどのソース・システムからSQLワークロードを取得して、変更が適用されたテスト・システムでこのワークロードをリプレイできます。

詳細は、『Oracle Database Real Application Testingユーザーズ・ガイド』を参照してください。

6.3 Oracle Enterprise Manager Grid Control

日常的なタスクや繰返しタスクの実行に必要な人的作業を減らすことで、サービスの安定性、信頼性および可用性が向上します。これは、管理者が多くのシステムをできるかぎり効率的に管理する必要がある場合に特に重要です。

Oracle Enterprise Manager Grid Controlは、管理者がOracleテクノロジ・スタック全体(ビジネス・アプリケーション、アプリケーション・サーバー、データベース、E-Business Suite)、およびOracle以外のコンポーネントにわたり完全な監視を行うことができるHTMLベースのインタフェースです。高速アプリケーション通知(FAN)のコンポーネントが使用できない、またはパフォーマンスの問題が発生した場合、Grid Controlには自動生成されたアラートが表示されるので、管理者は適切なリカバリ処置を行えます。

Grid Controlのコンポーネントには、次のものがあります。

- Oracle Management Service (OMS)
OMS機能は、Grid Controlのインタフェースを提供するJ2EE Webアプリケーションのセットで、すべての管理エージェントと連係して監視情報を処理し、管理リポジトリを永続的なデータ・ストアとして使用します。

- Oracle Management Agents
各監視対象ホストにデプロイされているプロセスで、ホスト上のすべてのターゲットを監視し、その情報をOMSに送信し、ホストおよびターゲットのメンテナンスを行います。

- Oracle Management Repository
Oracle Database内のスキーマで、Grid Controlによって管理される管理者、ターゲットおよびアプリケーションに関するあらゆる情報が含まれます。

Grid Control、OMSおよびOracle Management Agents間の通信は、HTTPを通じて行われます。ファイアウォールで保護されている環境内の層と層の間における安全な通信を可能にするため、Secure Sockets Layer(SSL)を有効にできます。管理エージェントは、収集された監視データをOMSにアップロードし、OMSは、管理リポジトリにデータをロードします。ターゲット状態に変更(可用性状態の変更など)があると、Grid Controlにアラートが生成されます。

Grid Controlを使用して、管理者は次の操作を行うことができます。

- アーキテクチャ・コンポーネントの監視、および障害発生時のアラートの受信

- データベース・クラスタ内のノードの数、および現在のステータスなど全体的なシステム・ステータスの表示

- すべてのインスタンスに関して発せられたアラートの表示

- クラスタ全体のデータベースごとにアラート生成に対するしきい値の設定

- すべてのインスタンスにまたがるパフォーマンス・メトリックの監視

- バックアップおよびリカバリなど、データベース・クラスタ全体の操作の実行

- クラスタ・データベースの監視のインターコネクト

関連項目:

- Oracle Enterprise Manager Grid Controlの詳細は、『Oracle Enterprise Manager Grid Controlインストレーションおよび基本構成』と『Oracle Enterprise Manager概要』を参照してください。

- 「Using Enterprise Manager Grid Control to Implement or Extend High Availability with Oracle Database 11g and Oracle Data Guard」ホワイト・ペーパーは、次のWebサイトから入手できます。

http://www.oracle.com/goto/maa

脚注の凡例

脚注1: この項で説明している多くの自己管理機能を使用するには、Oracle Diagnostics Packのライセンスの購入が必要です。Oracle管理パックのライセンス情報の詳細は、『Oracle Databaseライセンス情報』を参照してください。

7 高可用性アーキテクチャおよびソリューション

最大可用性アーキテクチャ(MAA)は、Oracleのベスト・プラクティスの将来図です。これは、実績のあるOracle高可用性テクノロジと推奨事項に基づいています。MAAの目標は、お使いのアーキテクチャとOracle機能を最適化するために、構成上の推奨事項と調整のヒントを提供することにより、最適な高可用性アーキテクチャを設計する際の複雑さをなくすことです。

この章では、Oracle環境の様々な高可用性アーキテクチャについて説明します。これは組織に適したアーキテクチャの選択に役立ちます。

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

- Oracle Database高可用性アーキテクチャ

- 正しい高可用性アーキテクチャの選択

- アプリケーション・サーバーの高可用性の統合

- すべてのアプリケーションの高可用性の統合

7.1 Oracle Database高可用性アーキテクチャ

次の各項では、Oracle Database高可用性アーキテクチャの概要およびMAAベスト・プラクティスの実装について説明します。

- Oracle Database

- Oracle Clusterware使用のOracle Database(コールド・クラスタ・フェイルオーバー)

- Oracle RAC One Node使用のOracle Database

- Oracle Real Application Clusters(Oracle RAC)使用のOracle Database

- Oracle Data Guard使用のOracle Database

- Oracle ClusterwareおよびOracle Data Guard使用のOracle Database

- Oracle RAC One NodeおよびOracle Data Guard使用のOracle Database

- Oracle RACおよびOracle Data Guard使用のOracle Database

- Oracle GoldenGate使用のOracle Database

異なるアーキテクチャの比較と、利点および考慮事項の最も重要な点は、7.2項を参照してください。

アーキテクチャを選択すると、MAAホワイト・ペーパーや『Oracle Database高可用性ベスト・プラクティス』に記述されている運用上および構成上のベスト・プラクティスを使用してそのアーキテクチャを実装できます。各アーキテクチャの利点を最大限に生かすには、これらのベスト・プラクティスが必要です。ベスト・プラクティスのドキュメントの詳細は、1.5項「最大可用性アーキテクチャ(MAA)実装のロードマップ」を参照してください。

7.1.1 Oracle Database

Oracle Databaseは単一インスタンスのスタンドアロン(非クラスタ)データベースで、すべての高可用性アーキテクチャの基礎となります。Oracle Databaseの単一インスタンス・データベース・アーキテクチャで使用できる高可用性機能は多数あります。

次のOracle機能を使用して、単一コンピュータ上のスタンドアロン・データベースを、特定の障害および計画メンテナンス・アクティビティに使用できるようにすることをお薦めします。

- ファスト・スタート・リカバリは、インスタンスやデータベースのリカバリ時間を制限および最適化します。

- Oracle Restartは、Oracleプロセスを監視し、自動的に再開することで、単一インスタンス環境でのOracle Database、リスナーおよびOracle ASMインスタンスの可用性を強化します。

- Oracle Automatic Storage Management(Oracle ASM)およびOracle Automatic Storage Managementクラスタ・ファイルシステム(Oracle ACFS)は、ストレージ障害を許容し、ストレージのパフォーマンスと使用率を最適化します。

- Oracle Flashbackテクノロジは、論理障害の修復を最適化します。十分な領域で自動UNDO管理を使用して必要なUNDO保存の保証を実現し、Oracle Flashback Databaseを有効にして、高速リカバリ領域に十分な領域とI/O帯域幅を割り当てることをお薦めします。

- 高速リカバリ領域は、ローカル・リカバリに関連するファイルを管理します。

- Recovery Manager(RMAN)は、データ障害の論理的な修復を最適化します。高速リカバリ領域にローカル・バックアップを作成および保存することをお薦めします。

- データ・リカバリ・アドバイザは、様々なデータ障害について優れたアドバイスと修復を行います。

- Oracle Secure Backupは、一元化されたテープ・バックアップ管理ソリューションを提供します。

- Oracleセキュリティ機能は、認可されていないアクセスや変更を防止します。

- 破損防止、検出および修復は、破損や書込み欠落を検出および防止します。

- オンライン再編成および再定義は、動的データ変更を可能にします。

- 動的リソース・プロビジョニングは、動的システム変更を可能にします。

- オンライン・パッチ適用は、診断パッチおよび個別パッチの動的データベース・パッチを可能にします。

- エディションベースの再定義を使用したアプリケーションのオンライン・メンテナンスおよびオンライン・アップグレードにより、アプリケーションの可用性を妨げずにアプリケーションのデータベース・オブジェクトを変更できます。

- Oracle Enterprise Managerのパッチ・アプリケーションのサポートにより、ソフトウェアのメンテナンスが単純化されます。

図7-1は、Oracle ASMインスタンスを含む基本的な単一ノードのOracle Databaseを示しています。脚注1このアーキテクチャには、フラッシュバック・データベース、オンライン再定義、Recovery ManagerおよびOracle Secure Backupなどの高可用性機能が組み込まれています。

図7-1 Oracle ASMインスタンスを使用した単一ノードの非クラスタOracle Database

7.1.2 Oracle Clusterware使用のOracle Database(コールド・クラスタ・フェイルオーバー)

Oracle Database 11gリリース2 (11.2)では、Oracle Clusterware (コールド・クラスタ・フェイルオーバー)を使用するよりも、より完全で、機能豊富なソリューションであるOracle RAC One NodeまたはOracle RACをお薦めします。詳細は、7.1.3項「Oracle RAC One Node使用のOracle Database」を参照してください。

3.4.1項で説明したように、Oracle Clusterwareは、同じオペレーティング・システムを実行するサーバーにインストールされる場合、これらのサーバーが連係して単一サーバーとして機能できるようにして、ユーザー・アプリケーションとOracle Databaseの可用性を管理するソフトウェアです。Oracle Clusterwareを実行するサーバーは、同じオペレーティング・システムを実行している必要があります。

現在、高可用性アーキテクチャの多くは、基本的なノードの冗長性と自動ノード・フェイルオーバーを提供するためにクラスタのみを使用します。ただし、Oracle Clusterwareを使用すると、サード・パーティのクラスタウェアを使用する必要性やメリットがなくなります。

Oracle Clusterwareには、サード・パーティのクラスタウェアよりも優れた多くの利点があります。Oracle Clusterwareの利点は次のとおりです。

- Oracleのソフトウェア・ソリューションをすべて使用できるので、他のクラスタウェア・ソフトウェアを管理するコストや複雑さを回避できます。
調整やサポートが必要なソフトウェアの組合せが減ることで、システム・ソフトウェアの管理性および可用性が向上します。

- Oracle Real Application Clustsers(Oracle RAC)やOracle Data Guardとの統合や移行がシームレスに行われます。
7.1.8項では、Oracle RACおよびOracle Data Guardによる最高レベルの可用性を実現する方法について説明します。

- クラスタ管理に必要な機能がすべて含まれています。これらの機能には、ノード・メンバーシップ、グループ・サービス、グローバル・リソース管理、および高可用性機能(サード・パーティ・アプリケーションの管理、イベント管理、および障害後にOracleクライアントが新しいプライマリ・データベースに再接続できるOracle通知サービスなど)があります。

- プライベート・ネットワークおよび投票ディスク・ベースの通信を使用して、スプリット・ブレイン脚注2・シナリオを検出して解決します。

Oracle Clusterwareでは、システムやサーバーの障害からOracle Databaseインスタンスを保護するコールド・クラスタ・フェイルオーバーを提供できます。コールド・クラスタ・フェイルオーバーの基本的な機能として、サーバーで稼働しているデータベース・インスタンスを監視し、障害が検出された場合は、クラスタ内のスペア・サーバーでそのインスタンスを再起動します。ネットワーク・アドレスは、バックアップ・ノードにフェイルオーバーされます。ネットワーク上のクライアントはフェイルオーバー実行時にロックアウトされますが、インスタンスが起動すると、他のデータベース・インスタンスで処理されます。また、別のノードにワークロードを移動する方法として、Oracle Clusterware機能を使用してアプリケーションとアプリケーション・リソースを再配置し(crsctl relocate resourceコマンドを使用)、本番サーバーで計画システム・メンテナンスを実行できます。

Oracle Clusterwareを使用したコールド・クラスタ・フェイルオーバー・ソリューションには、基本的なデータベース・アーキテクチャよりも優れた次のような利点があります。

- ノード障害とインスタンス障害を数分で自動リカバリ

- Oracle統合クライアントの自動通知および再接続脚注3

- 障害検出メカニズムのカスタマイズが可能。
たとえば、データベース・チェック・アクションで好きなアプリケーション問合せを使用できます。アプリケーション別の障害検出を行うと、Oracle Clusterwareはインスタンス停止などの明らかな場合だけでなく、アプリケーション問合せが特定のサービス・レベルを満たしていないなどの場合にもフェイルオーバーできます。

- サード・パーティ・アプリケーションを管理する高可用性機能

- Oracle Clusterwareのローリング・リリース・アップグレード

Oracle Clusterwareのコールド・クラスタ・フェイルオーバーの動作については、図7-2および図7-3を参照してください。これらの図は、Oracle Clusterwareのフレームワークを使用して、Oracle Databaseおよびカスタム・アプリケーションの高可用性を実現する方法を示しています。

図7-2は、Oracle Clusterwareを使用して、基本的なOracle Databaseアーキテクチャを拡張し、コールド・クラスタ・フェイルオーバーを実現する構成を示しています。この図では、構成は通常モードで機能します。ノード1は、アプリケーションとユーザーにサービスを提供するアクティブ・インスタンスで、Oracle Databaseに接続されています。ノード2は、ノード1とOracle Databaseに接続されていますが、現在スタンバイ・モードになっています。

図7-2 Oracle Clusterware使用のOracle Database(コールド・クラスタ・フェイルオーバー前)

図7-3は、コールド・クラスタ・フェイルオーバー後のOracle Clusterware構成です。この図では、ノード2はOracle Databaseに接続されたアクティブ・インスタンスで、アプリケーションとユーザーにサービスを提供しています。ノード1は、ノード2とOracle Databaseに接続されていますが、現在スタンバイ・モードでアイドルになっています。

この透過的なフェイルオーバー機能を実現するために、Oracle Clusterwareでは、クラスタ内のノードごとに仮想IP(VIP)アドレスが必要です。また、Oracle Clusterwareでは、アプリケーションのVIPも定義するため、ユーザーはそのアプリケーションが稼働しているクラスタ・ノードのアプリケーションに個別にアクセスできます。複数のアプリケーションVIPを定義できます。通常、実行中のアプリケーションごとに1つのアプリケーションVIPを定義します。Cluster Ready Services(CRS)で定義されるアプリケーション・リソースに依存することで、アプリケーションVIPはアプリケーションと結び付けられます。

図7-3 Oracle Clusterware使用のOracle Database(コールド・クラスタ・フェイルオーバー後)

注意:
Oracle Enterprise ManagerとOracle Universal Installer(OUI)はどちらも、Oracle Clusterware構成をサポートしません。Oracle Clusterware環境を構成するには、プラットフォーム別のOracle Clusterwareのインストレーション・ガイドの手順に従って実行します。

7.1.3 Oracle RAC One Node使用のOracle Database

従来Oracle RACは、マルチノード・アーキテクチャで、別々のサーバー上で実行している多くの個別のデータベース・インスタンスとともに使用されます。Oracle RAC One Nodeでは、クラスタ内の単一ノードでOracle RACデータベースの1つのインスタンスを実行できます。したがってこの機能により、サーバー障害のイベントにおけるインスタンスの迅速な再配置により高可用性を提供したまま、多くのデータベースを1つのクラスタに統合し、管理を容易にすることができます。

Oracle RAC One Nodeを実行しているノードがオーバーロードになった場合、オンライン・データベース再配置ユーティリティ(srvctl relocate database)を使用して、アプリケーション・ユーザーの停止時間ゼロで、インスタンスをクラスタ内の別のノードに再配置できます。

Oracle Database Resource Manager Instance Cagingを使用して、サーバー・リソースを複数のインスタンスに配置できます。サーバーのスケーラビリティは無制限で、アプリケーションが増大して1つのノードで提供できるリソース以上のリソースを必要とする場合には、従来のマルチノードOracle RAC構成にオンラインでアップグレードできます。

Oracle RAC One Nodeの使用に対する高可用性の利点には次のものがあります。

- 従来のコールド・フェイルオーバー・ソリューションよりも高いデータベースの可用性を提供

- hypervisorベースのソリューションよりも高度なデータベースの仮想化を提供

- データベース・インスタンスのオンライン移行、オペレーティング・システムおよびデータベース・ソフトウェアのオンライン・パッチおよびアップグレード(停止時間を発生させない)が可能

- 包括的な単一ベンダーのソリューションを、サード・パーティ製品の実装を必要とせずに提供

- マルチノードOracle RACへの拡張およびアップグレードが可能

- 単一ノードおよびマルチノードの両方に共通のツールセットと標準化された環境を提供

- コールド・フェイルオーバー・ソリューションまたはOracle RACの完全デプロイメントよりもコストが低い

- Oracle Data Guardを完全にサポート。Data Guard構成のデータベース(プライマリまたはスタンバイ・データベース)はOracle One Nodeデータベースにできます。

仮想化に対し、Oracle RAC One NodeとOracle VMをともに使用することで、Oracle RACの高可用性とスケーラビリティによりOracle VMの利点が増加します。VMのサイズが小さすぎる場合、Oracle RAC Oneインスタンスをクラスタ内の別のより大きいOracle VMノードに移行するか(オンライン・データベース再配置ユーティリティを使用)、またはOracle RAC Oneインスタンスを別のOracle VMノードに移動してからOracle VMのサイズを変更できます。Oracle RAC One Nodeインスタンスを新しくサイズを変更したOracle VMノードに移動する場合、リソース・マネージャのインスタンス・ケージングを使用してプログラムされた制限を動的に増加させることができます。

詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』のOracle RAC One Nodeの管理の項を参照してください。

7.1.4 Oracle Real Application Clusters(Oracle RAC)使用のOracle Database

Oracle DatabaseとOracle RACを組み合せたアーキテクチャは、本質的に高可用性システムです。従来のモノリシック・データベース・サーバーは高価で、容量およびリソースへの要求の変化に対して柔軟性がありませんが、これとは異なり、Oracle RACでは複数のインターコネクトされたコンピュータの処理能力を組み合せて、システムの冗長性、スケーラビリティおよび高可用性を提供します。

Oracle RAC環境の典型的なクラスタでは、計画停止および計画外停止に対して連続的なサービスを提供できます。Oracle RACは、標準のOracle Database機能をベースに、さらに高度な可用性を確立します。フラッシュバック・テクノロジやオンライン再編成などの単一インスタンス高可用性機能は、すべてOracle RACにも適用されます。Oracle RAC環境では、アプリケーションは、アプリケーション・コードを変更せずに増加するデータ処理要求を満たすようスケール変更されます。さらに、アプリケーションがクラスタ内の他の部分で実行している間、クラスタ内のコンポーネントのサブセット上でメンテナンス操作を行うことが可能なため、計画停止時間を短縮できます。

Oracle RACはクラスタ化によって得られる冗長性を利用し、nノード・クラスタのn-1ノード障害における可用性を提供しています。1つのノードが完全にアイドルになっているコールド・クラスタ・モデルとは異なり、アプリケーションのスケールを変更するためにすべてのインスタンスとノードをアクティブにできます。ノード間の通信は冗長インターコネクトの使用(結合またはその他のテクノロジの使用を必要とせず)により最適化され、安定性、信頼性およびスケーラビリティを提供します。

Oracle RAC使用のOracle Databaseアーキテクチャには、従来のモノリシック・データベース・サーバーやコールド・クラスタ・フェイルオーバー・モデルよりも優れた次のような利点があります。

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

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

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

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

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

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

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

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

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

- データベース・ワークロードへのリソース割当てをポリシーベースでランタイム管理するためのOracle Quality of Service(QoS)管理(動的状況下でのビジネス・ニーズの順にサービス・レベルが満たされます)。この機能はOracle Database 11gリリース2(11.2.0.2)から使用可能になりました。

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

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

図7-4 Oracle RAC使用のOracle Databaseアーキテクチャ

7.1.4.1 拡張クラスタ上のOracle RAC使用のOracle Database

Oracle RAC使用のOracle Databaseアーキテクチャは、単一データ・センターにあるスケーラビリティおよび可用性ソリューションとして主に設計されています。特定の状況では、クラスタ内のノードが遠く離れているOracle RACシステムを構築してデプロイすることができます。このアーキテクチャは、拡張クラスタと呼ばれます。

Oracle RAC拡張クラスタは、サイト障害からの超高速リカバリを実現し、全サイトのすべてのノードが1つのデータベース・クラスタの構成要素としてトランザクションをアクティブに処理できるアーキテクチャです。たとえば、キャンパスを持つ企業の場合、拡張Oracle RAC構成が別の建物内にある個別Oracle RACノードで構成されている可能性があります。拡張クラスタ上のOracle RACは、ローカルのOracle RACクラスタよりも優れた高可用性を実現しますが、組織の障害時リカバリ要件を完全に満たすとはかぎりません。

2つのデータ・センターが互いに比較的近い場所にある場合、拡張クラスタは一部の災害に対しては優れた保護効果がありますが、すべての災害から保護できるわけではありません。両方のサイトが同じ災害の影響を受ける可能性があるかどうかを確認する必要があります。たとえば、拡張クラスタ構成を適切に設定すると、局地的な停電、航空機の墜落事故またはサーバー・ルームの水害といった災害に備えることができます。ただし、拡張クラスタは、データベースに影響を及ぼすすべてのデータ破損や特定のデータ障害、または広い地域に影響を及ぼす地震、ハリケーンおよび洪水などの広範囲な災害から保護することはできません。(完璧な障害時リカバリおよびデータ保護については、図7-8で説明するアーキテクチャを使用します。)

拡張クラスタでOracle RACを使用する利点は次のとおりです。

- インスタンス障害やノード障害に対するフェイルオーバー時間全体にわたって危険にさらされることなく、すべてのシステム・リソースの十分な使用が可能

- 1つのサイトに障害が発生した場合の超高速リカバリ

- 7.1.4項に示したOracle RACのすべての利点

注意:
拡張クラスタ・アーキテクチャは効率的であり、実装に成功していますが、この説明で推奨された環境(距離、待機時間および保護の程度を含む)においてのみ実装してください。

図7-5は、2つの異なる場所にある6つのノード(サイトAとサイトBにそれぞれ3つのノードがある)に複数のアクティブ・インスタンスが存在する構成用のOracle RAC拡張クラスタを示しています。パブリック・インターコネクト、プライベート・インターコネクト、およびストレージ・エリア・ネットワーク(SAN)は、すべて別々の専用チャネル上にあり、それぞれが冗長性を持たせて構成されています。可用性の理由から、Oracle Databaseは両方のサイトでミラー化される単一のデータベースです。また、いずれかのサイトに障害が発生した場合のクラスタ全体の停止を防ぐために、構成には、安価な標準ネットワーク・ファイル・システム(NFS)でマウントされた3つ目の投票ディスク・デバイスが含まれています。

図7-5 Oracle RAC拡張クラスタ

関連項目:

- 拡張クラスタ上のOracle RAC使用のOracle Database 11gの構成の詳細は、『Oracle Database高可用性ベスト・プラクティス』を参照してください。

- 拡張(ストレッチ)クラスタおよび拡張クラスタ構成で3つ目の投票ディスクをサポートする標準NFSの使用に関するホワイト・ペーパー(http://www.oracle.com/technetwork/database/clustering/overview/から入手できます)

7.1.5 Oracle Data Guard使用のOracle Database

Oracle Data Guardは、データベース障害、ノード障害、破損およびメディア障害が発生した場合に超高速自動フェイルオーバー(ファスト・スタート・フェイルオーバーと呼ばれる)を提供する高可用性および障害時リカバリ・ソリューションです。さらに、スタンバイ・データベースは、読取り専用アクセス、続いてリーダー・ファーム、レポート作成、テストおよび開発に使用できます。

従来のソリューション(テープからのバックアップおよびリカバリ、ストレージ・ベースのリモート・ミラー化およびデータベース・ログの送信など)では、ある程度の高可用性が提供されますが、Oracle Data GuardではOracle Databaseの包括的な高可用性および障害時リカバリ・ソリューションが提供されます。

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

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

- データ破損、書込み欠落、およびデータベース障害とサイト障害に対応する高速自動データベース・フェイルオーバー

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

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

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

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

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

- Oracle Database File System(DBFS)をサイト全体のフェイルオーバー操作の一部として使用した、データベース以外のファイルの統合が可能

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

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

- アプリケーションのフェイルオーバーに対する透過的で統合されたサポート

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

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

リモート・ミラー化ソリューションと比較したOracle Data Guardの利点

次のリストは、リモート・ミラー化ソリューションの使用と比較した、Oracle Data Guard使用の利点をまとめたものです。

- ネットワーク効率の向上: Oracle Data Guardでは、リモート・サイトに送信する必要があるのはREDOデータのみであり、REDOデータは圧縮可能なためネットワーク効率がさらに向上します。一方で、リモート・ミラー化ソリューションがデータ保護に使用される場合、通常はデータベース・ファイル、オンラインREDOログ、アーカイブREDOログおよび制御ファイルをミラー化する必要があります。高速リカバリ領域がリモートでミラー化されるソースのボリューム上にある場合、フラッシュバック・ログもリモートでミラー化する必要があります。つまり、Oracle Data Guardと比較すると、リモート・ミラー化ソリューションでは各変更を何度もリモート・サイトに送信します。

- パフォーマンスの向上: Oracle Data Guardは書込みI/Oをプライマリ・データベースのREDOログ・ファイルにのみ送信しますが、リモート・ミラー化ソリューションでは、これらの書込みとすべての書込みI/Oを、データ・ファイル、オンライン・ログ・ファイル・グループに追加されたメンバー、アーカイブREDOログ・ファイルおよび制御ファイルに送信する必要があります。
Oracle Data Guardは、データ・ファイルに書き込むOracleデータベース書込み(DBWR)プロセスに影響を与えないように設計されています。これは、DBWRを低速化するものはどのようなものでもデータベースのパフォーマンスに影響を及ぼすためです。一方で、リモート・ミラー化ソリューションは、データ損失ゼロの同期構成に伴うネットワークおよびディスクI/Oの遅延に対するDBWRプロセスの書込みI/Oをすべて制御するため、DBWRプロセスのパフォーマンスに影響を与えます。

ミラー化と比較すると、Oracle Data Guardではパフォーマンスと効率性が向上します。Oracle Data Guardは常にスタンバイ・データベースの状態を検証し、REDOデータを適用する前にデータを確認します。また、プライマリ・データベースを保護しながら、更新にスタンバイ・データベースを使用できます。

- WANに対する適性の向上: ストレージ・システムに基づくリモート・ミラー化ソリューションでは、ストレージ・システムで使用される基本的な通信テクノロジ(ファイバ・チャネルまたはESCON(Enterprise Systems Connection))が原因で距離の制限がある場合があります。一般的な例として、システム同士がポイント・ツー・ポイント方式で接続され、同期して実行している場合、このシステム間で可能な距離は最大でわずか10kmです。専用デバイスを使用すれば、この距離は66kmまで伸ばせます。ただし、データ・センター間の距離が66kmを超える場合は、サード・パーティ・ベンダーの一連のリピータやコンバータを使用する必要があります。これらのデバイスにより、ESCONまたはファイバ・チャネルは適切なIP、ATMまたはSONETネットワークに変換されます。

- リジリエンスおよびデータ保護の向上: Oracle Data Guardでは、リモート・ミラー化ソリューションよりも優れたデータ保護とデータ・リジリエンスが保証されます。これは、本番データベースで発生した破損はリモート・ミラー化ソリューションによってスタンバイ・サイトにミラー化できますが、Oracle Data Guardでは破損が削除されるためです。
たとえば、ディスクに宛先違いの書込みが発生した場合、ファイル・システムに破損がある場合、あるいはディスクにブロックを書き込む際にホスト・バス・アダプタによってブロックが破損した場合、リモート・ミラー化ソリューションはこの破損を障害時リカバリ・サイトに伝播します。Oracle Data GuardではログのREDOデータのみを伝播し、REDOデータの適用前にログ・ファイルの一貫性がチェックされるため、このような外部破損はすべてOracle Data Guardによって削除されます。自動ブロック修復が可能なため、Oracle Data Guard構成での停止時間はゼロになります。

- 柔軟性の向上: Oracle Data Guardは純粋な汎用ハードウェアに実装されます。必要なものは、2つのコンピュータ間で確立されるTCP/IPベースの標準ネットワーク・リンクのみです。高価なハードウェアは不要です。また、プライマリ・コンピュータとは異なる方法でストレージをレイアウトできます。たとえば、異なるディスク、ボリューム、ファイル・システムなどにファイルを配置できます。

- 機能性の向上: Oracle Data Guardには、データ保護および障害時リカバリに関してリモート・ミラー化ソリューションよりも最適化された包括的で効率的なソリューションを提供する、完全なデータ保護機能が備わっています。たとえば、Active Data Guard、フィジカル・スタンバイ・データベースのREDO Apply、ロジカル・スタンバイ・データベースのSQL Apply、複数の保護モード、プッシュボタンによる自動スイッチオーバーとフェイルオーバー機能、自動ギャップ検出および解決、GUI駆動による管理および監視フレームワーク、REDOログの宛先のカスケード表示などです。

- ROIの増加: ビジネスでは、IT投資からできるかぎり多くの価値を取得し、使用されていないITインフラストラクチャが存在しないようにする必要があります。Oracle Data Guardは、ビジネスが障害時リカバリ・サイトに対する高額の投資から有益なものを得られるように設計されています。通常、これはリモート・ミラー化ソリューションでは不可能です。

次の項では、Oracle Data Guardを使用する、推奨される高可用性および障害時リカバリ・アーキテクチャについて説明します。

- 単一のスタンバイ・データベース・アーキテクチャの概要

- 複数のスタンバイ・データベース・アーキテクチャの概要

- Oracle Data Guard(スタンバイ)ハブ

7.1.5.1 単一のスタンバイ・データベース・アーキテクチャの概要

単一のスタンバイ・データベース・アーキテクチャは、次の主な特性および推奨事項で構成されています。

- プライマリ・データベースはサイトAにあります。

- スタンバイ・データベースはサイトBにあります。プライマリ・データベースに対するパフォーマンスの影響を最小限に抑えてデータ損失をゼロにする必要がある場合、ベスト・プラクティスは、プライマリ・データベースから200マイル以内の場所にセカンダリ・サイトを配置することです。ただし、同期REDO転送では物理的な距離制限ないことに注意してください。

- ファスト・スタート・フェイルオーバーは、ユーザーが操作せず、リカバリ時間の制限がない状態で自動フェイルオーバーを提供する場合に推奨されます。プライマリ・データベースが非同期REDO転送を使用する場合、ビジネス要件を満たすには、許容される最大データ損失またはOracle Data GuardブローカのFastStartFailoverLagLimitプロパティを構成します。オブザーバ(Thinクライアントのウォッチドッグ)がアプリケーション層に存在し、プライマリ・データベースの可用性を監視します。オブザーバの詳細は、『Oracle Data Guard Broker』を参照してください。

- 読取り専用アクセスが十分な場合は、フィジカル・スタンバイ・データベースを使用します。

- レポートを作成するために索引を追加する必要がある場合、およびロジカル・スタンバイ・データベースとSQL Applyでサポートされるデータ型のみをアプリケーションで使用する場合は、ロジカル・スタンバイ・データベースを評価します。

図7-6は、ファスト・スタート・フェイルオーバーの発生時、および発生前後のプライマリ・データベース、ターゲット・スタンバイ・データベースおよびオブザーバの関係を示しています。この図は、次に示すように、3つの異なるフレームの同じOracle Data Guard構成を示しています。

1. 左端のフレームは、ファスト・スタート・フェイルオーバーが発生する前の構成を示しています。Oracle Data Guardは安定した状態で機能しています。プライマリ・データベースはターゲット・スタンバイ・データベースにREDOデータを送信し、オブザーバは構成全体の状態を監視しています。

2. 中央のフレームは、ファスト・スタート・フェイルオーバー発生時の構成を示しています。プライマリ・データベースで障害が発生し、プライマリ・データベースからオブザーバおよびターゲット・スタンバイ・データベースに対するネットワーク接続が失われています。通信が中断されたことをオブザーバが検出すると、ファスト・スタート・フェイルオーバーを開始する前に、FastStartFailoverThresholdプロパティで定義されている時間でプライマリ・データベースとの接続を再確立しようとします。オブザーバがプライマリ・データベースとの接続を指定の時間内に回復できない場合、ターゲット・スタンバイ・データベースがファスト・スタート・フェイルオーバーに対応する準備を整え、ファスト・スタート・フェイルオーバーが行われます。

3. 右端のフレームは、ファスト・スタート・フェイルオーバーが発生した後の構成を示しています。ファスト・スタート・フェイルオーバーが完了し、ターゲット・スタンバイ・データベースがプライマリ・データベース・ロールで稼働しています。以前のプライマリ・データベースが修復されると、オブザーバはそのデータベースとの接続を再確立し、新しいスタンバイ・データベースとして復活させます。新しいプライマリ・データベースは、新しいスタンバイ・データベースへのREDOデータの送信を開始します。

図7-6 ファスト・スタート・フェイルオーバー時のプライマリ・データベース、スタンバイ・データベースおよびオブザーバ

次に、単一のスタンバイ・データベースを使用したOracle Data Guardの構成例について説明します。

- ある国営エネルギ企業では、プライマリ・データ・センターから10マイル離れた設備にあるスタンバイ・データベースを使用しています。顧客サービスや安全性に影響を与える停止またはデータ損失は、Oracle Data Guardの同期転送および自動フェイルオーバー(ファスト・スタート・フェイルオーバー)によって回避されます。

- 通信業界向けのあるインフラストラクチャ・サービス・プロバイダは、同期REDO転送用に構成されたプライマリ・データベースから400マイル以上離れた場所にある単一のスタンバイ・データベースを使用し、データ保護と高可用性を最大限に高めるデータ損失ゼロのフェイルオーバーを実現しています。

- ある通信プロバイダは非同期REDO転送を使用して、米国の西海岸にあるプライマリ・データベースと、3,000マイル以上離れた東海岸のスタンバイ・データベースを同期化しています。これにより、プロバイダは地理的に離れた既存のデータ・センターを使用して、独自の高可用性を提供できます。

- ある世界規模の製造会社では、Oracle Data Guardを使用してストレージ・ベースのリモート・ミラー化に替えて、プライマリ・サイトから50マイル離れたリカバリ・サイトでスタンバイ・データベースを管理しています。Oracle Data Guardでは、より包括的なデータ保護が提供されます。また、ネットワークがより効率的に使用されるため、ネットワーク・アップグレードの経費をかけなくても成長するのに十分な余裕が生まれます。

7.1.5.2 複数のスタンバイ・データベース・アーキテクチャの概要

このアーキテクチャは、同じOracle Data Guard構成に複数のスタンバイ・データベースがある点を除き、7.1.5.1項で説明した単一のスタンバイ・データベース・アーキテクチャと同じです。次に、複数のスタンバイ・データベース・アーキテクチャの実装について説明します。

- プライマリ・データベースまたはターゲット・スタンバイ・データベースで機能停止が発生した場合の、継続した透過的な障害または高可用性の保護

- リーダー・ファームまたは検索データベース

- レポート作成データベース

- レスポンス時間を改善する、地域別のレポート作成データベースまたはリーダー・データベース

- 最適レベルのパフォーマンスとデータ保護のためにローカル・スタンバイ・データベースへの送信を行う同期REDO転送およびリモート・スタンバイ・データベースへの送信を行う非同期REDO転送

- 停止時間を最小限に抑えたローリング・アップグレードのための一時ロジカル・スタンバイ・データベース(3.6.3項を参照)

- スナップショット・スタンバイ・データベースを使用したテストおよび開発クローン(3.6.4項を参照)

- 追加のロジカル・スタンバイ・データベースまたはスナップショット・スタンバイ・データベースを作成することによる構成のスケール変更

図7-7は、プライマリ・サイトの本番データベースとセカンダリ・サイトにある複数のスタンバイ・データベースを示しています。この図は、Oracle Data Guardアーキテクチャを使用するOracle Databaseを示しています。

本番データベースは、フィジカル・スタンバイ・データベース・サイトおよびロジカル・スタンバイ・データベース・サイトとネットワークで接続されています(スタンバイ・データベースは同じサイトまたは異なるサイトにあります)。Oracle Data Guardブローカは、本番データベース、フィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データベースと通信します。

本番データベースは、REDOデータを(同期または非同期のいずれかで)フィジカル・スタンバイ・データベースのREDOログ・ファイルに送信します。REDOデータは、REDOログからフィジカル・スタンバイ・データベースに適用されます。フィジカル・スタンバイ・データベースは、REDOデータをフィジカル・メディアにバックアップします。

ロジカル・スタンバイ・データベースでは、REDOデータがSQL文に変換され、このSQL文はロジカル・スタンバイ・データベースに適用されます。ロジカル・スタンバイ・データベースには、索引とマテリアライズド・ビューを追加できます。ロジカル・スタンバイ・データベースと接続しているクライアントは、ロジカル・スタンバイ・データベースのデータを使用できます。

スナップショット・スタンバイ・データベースでは、REDOデータは受信されますが、スナップショット・スタンバイ・データベースがフィジカル・スタンバイ・データベースに再変換されるまで適用されません。この図では、ユーザーがスナップショット・スタンバイ・データベースをローカルで更新しています。これらの更新は、スナップショット・データベースがフィジカル・スタンバイ・データベースに再変換されると破棄されます。

また、スタンバイ・データベースが複数ある環境の別の例については、図5-2を参照してください。

図7-7 プライマリ・サイトと複数のスタンバイ・サイトでのOracle Data Guard使用のOracle Database

関連項目:

- 各種スタンバイ・データベースと、ロジカル・スタンバイ・データベースでサポートされるデータ型の詳細は、『Oracle Data Guard概要および管理』を参照してください。

- 構成ベスト・プラクティスについては、『Oracle Database高可用性ベスト・プラクティス』を参照してください。

- 次のWebサイトにあるホワイト・ペーパー「Managing Data Guard Configurations Having Multiple Standby Databases - Best Practices」およびその他のOracle Data Guardホワイト・ペーパー
http://www.oracle.com/goto/maa

次に、複数のスタンバイ・データベースを使用したOracle Data Guardの構成例を示します。

- 世界的に有名なある金融機関では、フェイルオーバー後の連続的なデータ保護を維持するために、2つのリモート・フィジカル・スタンバイ・データベースを使用しています。プライマリ・システムに障害が発生した場合、最初のスタンバイ・データベースが新しいプライマリ・データベースになります。2番目のスタンバイ・データベースは、新しいプライマリ・データベースからデータを自動的に受信するため、データが常に保護されることが保証されています。

- 米国内の有名なある保険会社では、同じOracle Data Guard構成で2つのスタンバイ・データベースを管理しています。1つはフィジカル・スタンバイ・データベース、もう1つはロジカル・スタンバイ・データベースです。この方法では、複数のスタンバイ・データベースを管理することでリスクがさらに軽減されます。各データベースは別のアーキテクチャ(REDO ApplyとSQL Apply)を使用して実装されています。

- 世界的に有名なあるE-Commerceサイトでは、フィジカル・データベースとロジカル・データベースを組み合せた複数のスタンバイ・データベースを使用しています。これらは、障害時リカバリと、SQL Applyを使用して複数のロジカル・スタンバイ・データベースをプロビジョニングすることによる読取りパフォーマンスの並列処理を目的としています。

- 法的機関や金融機関を対象とした、ある世界的な情報サービス・プロバイダでは、同じOracle Data Guard構成で複数のスタンバイ・データベースを使用して、データベースの大幅なアップグレードやプラットフォームの移行における停止時間を最小限に抑えています。

また、大規模なデータ・センターがOracle Data Guard要件に従って多くのアプリケーションをサポートする必要がある場合、Oracle Data Guardハブを構築して、総所有コストを削減できます。

7.1.5.3 Oracle Data Guard(スタンバイ)ハブ

データベース・サーバー・グリッドおよびデータベース・ストレージ・グリッド(5.2項および5.3項を参照)を使用して、システム・リソースのプールを利用するスタンバイ・データベースとテスト・ハブを構築できます。システム・リソースは、様々な優先度に応じて動的に割り当てたり、割当てを解除したりすることができます。たとえば、プライマリ・データベースがData Guardハブのいずれかのスタンバイ・データベースにフェイルオーバーした場合、テスト・リソースが一時的に不足している間に、新しいプライマリ・データベースが、より多くのシステム・リソースとストレージ・リソースを取得します。Oracle Gridのテクノロジでは、ビジネス要件を損うことなく、高レベルの使用率と低TCOが可能になります。

Oracle Data Guardハブは次の要素から構成できます。

- サーバー・クラスタ(グリッド・サーバーと呼ばれる)内にある、Oracle RAC環境の複数のスタンバイ・データベース

- ストレージ・グリッドの使用

Data Guardハブでは、より低コストでより高い使用率を実現することが前提になります。すべてのデータベースを同時にフェイルオーバーする可能性はほとんどありません。そのため、フェイルオーバーが発生した場合、本番アクティビティに対するシステム・リソースの優先順位を決め、スタンバイ・データベース機能に対する新しいシステム・リソースをグリッドに割り当てることができます。ロールの移行時に、そのアプリケーションに対してストレージ・リソースおよびシステム・リソースを追加で割り当てることができます。

たとえば、Oracle Data Guardハブには、グリッド・サーバーとストレージ・アーキテクチャでサポートされる複数のデータベースとアプリケーションを含めることができます。この構成は、グリッドで10個のアプリケーションとデータベースをサポートする一元集中リソースから構成されます。これに対して、非グリッド・インフラストラクチャでは10個のシステム単位またはストレージ単位を個別に管理します。

あるいは、スナップショット・データベースから構成されるテスト・ハブの構成もあります。スナップショット・スタンバイ・データベース・ハブでは、アプリケーションごとに個々のサーバーを構築および管理するのではなく、グリッドのストレージ・リソースとサーバー・リソースを組み合せて利用できます。

7.1.6 Oracle ClusterwareおよびOracle Data Guard使用のOracle Database

Oracle RACで提供されるスケーラビリティやその他の高可用性の利点がビジネスでは必要でないものの、Oracle Data Guardとコールド・クラスタ・フェイルオーバーの利点はすべて必要である場合、Oracle ClusterwareおよびOracle Data Guardを使用したOracle Databaseがアーキテクチャの妥協案になります。Oracle Clusterwareのコールド・クラスタ・フェイルオーバーとOracle Data Guardを組み合せると、緊密に統合されたソリューションが実現します。このソリューションでは、コールド・クラスタ・フェイルオーバーでセカンダリ・ノードへのフェイルオーバーが透過的であり、Oracle Data Guard環境の再構成や追加手順は必要ありません。

図7-8は、プライマリ・サイトとセカンダリ・サイトで構成されるOracle ClusterwareおよびOracle Data Guardのアーキテクチャを示しています。プライマリ・サイトとセカンダリ・サイトの両方に、Oracle Application Server、2つのデータベース・インスタンス、およびOracle Databaseがあります。

図7-8 Oracle Clusterware(コールド・クラスタ・フェイルオーバー)とOracle Data Guard

図7-8の詳細は次のとおりです。

- セカンダリ・サイトのアプリケーション・サーバーはWANトラフィック・マネージャと点線で結ばれています。これは、アプリケーション・サーバーがこの時点でクライアント・リクエストをアクティブに処理していないことを示します。(セカンダリ・サイトのアプリケーション・サーバーは、スタンバイ・データベースがフィジカル・スタンバイ・データベースでActive Data Guardオプションが有効な場合、またはロジカル・スタンバイ・データベースの場合は、アクティブになり、問合せなどのクライアント・リクエストを処理できます。)

- Oracle Data Guardでは、REDOデータはプライマリ・データベースからセカンダリ・サイトに送信され、データベース間で同期化されます。

- Oracle Clusterwareは、ユーザー・アプリケーションおよびOracle Databaseの可用性を管理します。

- Oracle Clusterwareはノード障害を許容するのに対し、Oracle Data Guardはデータ破損、書込み欠落、データベース障害およびサイト障害に対する追加の保護を提供します。(詳細は、7.1.5項を参照してください。)

- コールド・クラスタ・フェイルオーバーは図7-8に示されていませんが、セカンダリ・サイトにパッシブ・ノードを追加することで構成できます。

7.1.7Oracle RAC One NodeおよびOracle Data Guard使用のOracle Database

Oracle RAC One Nodeでは、Oracle Data Guardを使用して構成された、Oracle RACプライマリおよびスタンバイ・データベースの再配置(この機能はOracle Database 11gリリース2(11.2.0.2)から使用可能)が提供されます。Data Guard構成のデータベース(プライマリまたはスタンバイ・データベース)はOracle RAC One Nodeデータベースにできます。

詳細は、MAAホワイト・ペーパーのRapid Oracle RAC One Nodeスタンバイ・デプロイメントを参照してください。

http://www.oracle.com/goto/maa

7.1.8 Oracle RACおよびOracle Data Guard使用のOracle Database

Oracle RACおよびOracle Data Guardを使用すると、最高レベルの可用性を実現できます。また、これらのOracle Database機能を使用するためにアプリケーションを変更する必要はありません。Oracle RACとOracle Data Guardの組合せは、計画停止の停止時間を短縮し、計画外停止を防止、検出およびリカバリする最も包括的なアーキテクチャを提供します。このアーキテクチャは、最大可用性アーキテクチャ(MAA)の推奨構成です。

サイト障害から保護するために、MAAでは個々のシステム(クラスタ)とデータ・センターにOracle RACとOracle Data Guardを配置することをお薦めします。図7-9は、Oracle Database、Oracle RACおよびOracle Data Guardを使用するMAAの推奨構成を示しています。各サイトがロール遷移後のアプリケーションのパフォーマンスとスケーラビリティの要件に対応できるようにするには、対称型のサイトを構成することをお薦めします。さらに、サイトが対称型であると、ロール遷移における操作方法が簡単になります。

図7-9 Oracle RACおよびOracle Data Guard使用のOracle Database - MAA

7.1.9 Oracle GoldenGate使用のOracle Database

SQL ApplyモードでのOracle Data Guardの使用と同様に、Oracle GoldenGateでは、データベース変更を取得して宛先に伝播し、変更をこれらの宛先に適用できます。Oracle GoldenGateは、データのレプリケート用に最適化されます。Oracle GoldenGateでは、ソース・データベースで変更を取得して、取得した変更をレプリカ・データベースに非同期に伝播できます。Oracle GoldenGateを使用して構成およびメンテナンスされる論理コピーでは、通常定義のスタンバイ・データベースの範囲を超える多くの機能が提供されるため、ロジカル・スタンバイ・データベースではなくレプリカと呼ばれます。

本番データベースの論理コピーの構成およびメンテナンスにOracle GoldenGateの使用を選択する場合があります。Oracle GoldenGateを使用すると追加の作業が必要になりますが、特定のビジネス要件を満たすために必要な高い柔軟性が得られます。

Oracle GoldenGate使用のOracle Databaseには粒度があり、レプリケートの対象およびレプリケート方法を制御します。Oracle Streamsは、双方向レプリケーション、データ変換、サブセット化、カスタム適用関数および異種プラットフォームをサポートしています。また、プライマリ・データベースからレプリカ・データベースへの変更記録のルーティングをユーザーが完全に制御できるようにします。Oracle GoldenGateでは、プライマリ・データベースまたはレプリカ・データベースのダウンストリームでデータ変更を取得できるため、ユーザーは何百ものレプリカ・データベースをサポート可能なハブ・アンド・スポーク・ネットワーク構成を構築できます。

次の条件の中に当てはまるものが1つ以上ある場合は、Oracle GoldenGateとともにOracle Databaseを使用することを検討してください。

- 両方のサイトまたはデータベースで更新が必要であり、その変更を双方向で伝播する必要がある。

- サイト構成が異種プラットフォーム上にある。

- プライマリ・データベースとレプリカ間で異なるキャラクタ・セットが必要である。

- 情報のきめ細かな制御およびデータ共有が必要である。

- 統合高可用性ソリューションの構築およびメンテナンスのために、より多くの投資や専門知識を利用できる。

マルチソース・レプリケーション環境の構成の詳細は、Oracle GoldenGateのドキュメントを参照してください。

Oracle Data GuardでOracle GoldenGateを構成すると、構成内のデータベースを個別に保護できます。

7.2 正しい高可用性アーキテクチャの選択

この項では、様々な高可用性アーキテクチャの利点をまとめ、ビジネスに合った正しい高可用性アーキテクチャを選択するためのガイドラインを示します。

第2章では、ビジネスと割り当てられた予算に合う高可用性要件によって、適切なアーキテクチャを特定する方法について説明しています。主な要因は次のとおりです。

- 計画外停止および計画メンテナンスのリカバリ時間目標(RTO)およびリカバリ・ポイント目標(RPO)

- 管理オーバーヘッド(MO)

- 総所有コスト(TCO)および投資利益率(ROI)

たとえば、表7-1は、計画外アクティビティと計画アクティビティにおける様々な停止の確率に関する見通しを示しています。このデータは、ユーザーの実際の体験やOracleサービス・リクエストから得たものです。

表7-1 停止の頻度

アクティビティ

停止の頻度

メディア障害またはディスク障害

高

アプリケーションのパッチ

高

アプリケーション障害

高

論理データ(DMLおよびDDL)を操作する論理障害またはユーザー障害

高

データ破損および書込み欠損

中

コンピュータ障害

中

データベースのパッチ

中

ハードウェアのパッチおよびアップグレード

低

オペレーティング・システムのパッチおよびアップグレード

低

データベースまたはアプリケーションのアップグレード

低

データベース障害

低

プラットフォームの移行

非常に低い

サイトの障害

非常に低い

表7-2は、RTO、RPO、MO、スケーラビリティおよび他の要因に関するビジネス要件に基づいた推奨アーキテクチャを示しています。

表7-2 推奨される高可用性アーキテクチャ

使用を検討する高可用性アーキテクチャ

ビジネスまたはアプリケーションの影響

Oracle Clusterware使用のOracle Database(コールド・クラスタ・フェイルオーバー)

- インスタンスまたはノードの障害時の最大RTOが数分。

- MOが低い。

- ROIが低い。

- RPOがゼロ。

- データベースの停止時間ゼロによる、Oracle Clusterwareのローリング・アップグレードおよびパッチ機能

Oracle RAC One Node使用のOracle Database

- インスタンスまたはノードの障害時の最大RTOが数秒。

- MOが低い。

- ROIが中程度。

- RPOがゼロ。

- オンライン再配置。

- 各データベースに複数のOracle RAC One Node構成を実装することで、すべてのOracle RACノードをアクティブにすることが可能。

- Oracle Enterprise Manager Grid Controlのプロビジョニング機能使用時は停止時間がゼロ。

- システム、クラスタウェア、オペレーティング・システム、CPUおよび一部のOracle個別パッチのローリング・アップグレード。

Oracle Real Application Clusters(Oracle RAC)使用のOracle Database

- データベースの場合、インスタンスまたはノードの障害時の最大RTOがゼロ脚注1。

- MOが中程度。

- ROIが高い。

- RPOがゼロ。

- Oracle Database Quality of Service Managementを使用したランタイム・パフォーマンス・レベル管理(この機能はOracle Database 11gリリース2(11.2.0.2)から使用可能になりました)。

- Oracle Enterprise Manager Grid Controlのプロビジョニング機能使用時は停止時間がゼロ。

- システム、クラスタウェア、オペレーティング・システム、CPUおよび一部のOracle個別パッチのローリング・アップグレード。

- 1つのインスタンスまたはノードにとどまらないデータベース・スケーラビリティ。

拡張クラスタ上のOracle RAC使用のOracle Database

- Oracle RACのビジネス上のすべての利点。

- MOが高い脚注1。

- ROIが中程度。

- RPOがゼロ。

- 7.1.4.1項で説明されている特定の考慮事項による、データ・センター障害からの保護

- サーバーまたはコンピュータ・ルーム障害に対する最高度の可用性

- 高可用性の利点およびワークロード・バランシングがパフォーマンスの問題より重要

- データベース、データおよびクラスタの障害および破損を防ぐリモート・データ保護のために、追加のプロビジョニングを作成

Oracle Data Guard使用のOracle Database

- インスタンスまたはノードの障害時の最大RTOが数秒から数分。

- データ破損、データベースまたはサイト障害時の最大RTOが数秒から数分。

- ゼロ(SYNC)またはゼロに近い(ASYNC)RPOを選択。

- MOが低い。

- ROIが高い。

- システム、クラスタウェア、データベースおよびオペレーティング・システムのローリング・アップグレード

- 読取り専用、レポート作成、テスト、バックアップの各アクティビティをスタンバイ・データベースにオフロードする。

- 混合プラットフォームのサポートが制限される。詳細は、My Oracle Supportノートの「同一Data Guard構成の異機種間プライマリ・スタンバイおよびフィジカル・スタンバイに関するData Guardのサポート」を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=413484.1

フィジカル・スタンバイ・データベースでのこのソリューションの機能:

- 非常に高いプライマリ・データベース・スループットのサポート。

- フィジカル・レプリカの簡素化を実現。

- 物理的破損からの最大の保護を提供。

- 同期化されたスタンバイ・データベースへの読取り専用アクセスと、本番データベースのオフロードのための高速増分バックアップを提供

ロジカル・スタンバイ・データベースでのこのソリューションの機能:

- 一方向の論理レプリケーションの最も単純な形を提供

- 論理表への変更、スキーマ、索引およびマテリアライズド・ビューの追加など、スタンバイ・データベースへの構造上の変更が可能

- 同期化されたスタンバイ・データベースへの読取り専用アクセスを提供することで本番データベースをオフロードし、プライマリ・データベースにより変更されないローカル表への読取り/書込みアクセスを許可

Oracle ClusterwareおよびOracle Data Guard使用のOracle Database

- Oracle Clusterware(コールド・クラスタ・フェイルオーバー)とOracle Data Guardのビジネス上のすべての利点

- MOが低い。

- ROIが中程度。

- クラスタ・フェイルオーバーでRPOがゼロ、データベース・フェイルオーバーでゼロ(Data Guard SYNC)、またはゼロに近い(Data Guard ASYNC)RPOを選択。

Oracle RACおよびOracle Data Guard使用のOracle Database

- Oracle RACとOracle Data Guardのビジネス上のすべての利点

- MOが中程度。

- ROIが高い。

- クラスタ・フェイルオーバーでRPOがゼロ、データベース・フェイルオーバーでゼロ(Data Guard SYNC)、またはゼロに近い(Data Guard ASYNC)RPOを選択。

Oracle GoldenGate使用のOracle Database

- インスタンスまたはノードの障害時の最大RTOが数秒から数分。

- データ破損、クラスタ、データベースまたはサイトの障害時の最大RTOが数秒から数分。

- RPOがゼロに近い(非同期)。

- MOが高い脚注1。

- ROIが高い。

- システム、クラスタウェア、オペレーティング・システム、データベースおよびアプリケーションのローリング・アップグレード。

- 何に対してもどこでも行われる双方向のレプリケーションおよび更新のサポート。

- 異種プラットフォーム、バージョンおよびキャラクタ・セットのサポート。

- きめの細かいn方向マルチマスター、ハブ・アンド・スポーク、または多対1レプリケーション・アーキテクチャのサポート。

- データ、トランザクションおよびイベントの柔軟性のある伝播と管理。

- Oracle RAC統合により、データベースのスケーラビリティが可能。

脚注1MOが高いアーキテクチャでは、構築およびメンテナンスにさらなる時間と専門知識が必要になりますが、特定のビジネス要件を満たすために必要な柔軟性と機能性が高まります。

表7-3は、Oracle Databaseで構築するアーキテクチャによって提供されるその他の機能と、各アーキテクチャの最大の特徴を示しています。

表7-3 高度なOracle高可用性アーキテクチャのその他の機能

Oracle高可用性アーキテクチャ

主な特徴とその他の機能

Oracle Database(基本的なアーキテクチャ)

すべての高可用性アーキテクチャの基本

- ファスト・スタート・リカバリは、インスタンスやデータベースのリカバリ時間を数分に制限および最適化します。

- Oracle Restartは、Oracleプロセスを監視し、自動的に再開することで、単一インスタンス環境でのOracle Database、リスナーおよびOracle ASMインスタンスの可用性を強化します。

- Oracle Automatic Storage ManagementおよびOracle Automatic Storage Managementクラスタ・ファイルシステム(Oracle ACFS)は、ストレージ障害を許容し、ストレージのパフォーマンスと使用率を最適化します。

- Oracle Flashbackテクノロジは、論理障害の修復を最適化します。

- Recovery Managerは、ローカル・バックアップを使用してデータ障害の論理的な修復を最適化します。

- 高速リカバリ領域は、ローカル・リカバリに関連するファイルを自動的に管理します。

- Oracle Secure Backupは、一元化されたテープ・バックアップ管理ソリューションを提供します。

- Oracleセキュリティ機能は、認可されていないアクセスや変更を防止します。

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

- 破損防止、検出および修復は、破損や書込み欠落を検出および防止します。

- オンライン再編成および再定義は、動的データ変更を可能にします。

- 動的リソース・プロビジョニングは、動的システム変更を可能にします。

- オンライン・パッチ適用は、典型的な診断パッチの動的データベース・パッチ適用を可能にします。

- エディションベースの再定義を使用したアプリケーションのオンライン・メンテナンスおよびオンライン・アップグレードにより、アプリケーションの可用性を妨げずにアプリケーションのデータベース・オブジェクトを変更できます。

- Oracle Enterprise Managerのパッチ・アプリケーションのサポートにより、ソフトウェアのメンテナンスが単純化されます。

Oracle Clusterware使用のOracle Database(コールド・クラスタ・フェイルオーバー)

- Oracle Databaseのすべての利点

- コンピュータ障害に対する自動高速フェイルオーバー

- システム、クラスタウェアおよびオペレーティング・システムの最小のローリング・アップグレード機能脚注1

Oracle Real Application Clusters(Oracle RAC)使用のOracle Database

サーバー・データベース・グリッドの高可用性、スケーラビリティおよび基本

- Oracle Databaseのすべての利点

- 単一システムにとどまらないスケーラビリティ

- 障害が発生したノードとインスタンスの自動リカバリ

- 統合Oracleクライアント・フェイルオーバーによる高速アプリケーション通知(FAN)

- プールされたリソースおよびサード・パーティ・ベンダー中間層用の統合Oracleクライアント・フェイルオーバーによるFAN

- UCPを使用するJAVAアプリケーションとOracle RACおよびOracle Data Guardを含む統合Oracleクライアント・フェイルオーバーによるFAN。アプリケーションはエンド・ユーザーに対して容易に障害を隠すことができます。

- Oracle Database Quality of Service Managementを使用したランタイム・パフォーマンス・レベル管理(この機能はOracle Database 11gリリース2(11.2.0.2)から使用可能になりました)

- Grid Controlプロビジョニングでの停止時間がゼロ

- システム、クラスタウェア、オペレーティング・システム、CPUおよび一部のOracle個別パッチのローリング・アップグレード脚注1

拡張クラスタ上のOracle RAC使用のOracle Database

サイト障害の保護を備えたデータベース・グリッド

- Oracle Databaseのすべての利点

- サイト障害からの保護

Oracle Data Guard使用のOracle Database

最も単純な高可用性、データ保護および障害時リカバリ・ソリューション

- Oracle Databaseのすべての利点

- コンピュータ障害、ストレージ障害、データ破損、構成されているORAエラーまたは条件、およびデータベース障害に対する自動高速フェイルオーバー

- サイト障害からの保護

- システム、クラスタウェア、データベースおよびオペレーティング・システムのローリング・アップグレード脚注2

- スタンバイ・データベースへのバックアップのオフロードが可能

- スタンバイ・データベースへの読取りおよびレポート作成のワークロードのオフロードが可能

- 包括的な書込み欠落の保護のみ

Oracle ClusterwareおよびOracle Data Guard使用のOracle Database

データの追加および障害時リカバリ保護による高可用性ソリューション

- Oracle ClusterwareとOracle Data Guardのすべての利点

Oracle RACおよびOracle Data Guard使用のOracle Database

スケーラビリティが組み込まれた、最善の高可用性、データ保護および障害時リカバリ・ソリューション

- Oracle RACとOracle Data Guardのすべての利点

Oracle Streams使用のOracle Database脚注3

双方向のレプリケーションと情報の管理

- 読取り/書込み用にレプリカ・データベースの使用が可能

- 異種プラットフォームのサポート

- コンピュータおよびストレージ障害時の高速フェイルオーバー

- サイト障害からの保護

- コンピュータまたはサイトのメンテナンス、およびデータベースとアプリケーションのアップグレードに対する最小の停止時間

脚注1Oracle ClusterwareとOracle RACによるローリング・アップグレードでは、停止時間がゼロになります。

脚注2Oracle Data Guardによるローリング・アップグレードでは、停止時間が最小限に抑えられます。

脚注3堅牢なソリューションを構築するための初期投資は、特定のビジネス要件を満たすためにOracle GoldenGateが提供する長期間の柔軟性と機能に見合う十分な価値があります。

表7-4は、統合Oracleクライアントのリカバリ時間(検出時間およびクライアント・フェイルオーバー時間を含む)を適宜示しています。最適なリカバリ時間と構成を実現するには、MAAベスト・プラクティスを採用する必要があります。Oracle高可用性ベスト・プラクティスの推奨事項については『Oracle Database高可用性ベスト・プラクティス』と、次のWebサイトからダウンロード可能なホワイト・ペーパーを参照してください。

http://www.oracle.com/goto/maa

表7-4 計画外停止時に達成可能なリカバリ時間

停止タイプ

Oracle Database

コールド・クラスタ

Oracle RACと拡張クラスタ上のOracle RAC

Oracle Data Guard

Oracle RACとOracle Data Guard

Oracle GoldenGate

サイト障害

数時間から数日

数時間から数日

停止時間ゼロ脚注4(停止が1つの建物に制限される場合)

停止が両方の建物に影響を与える場合は数時間から数日

数秒から1分脚注1

数秒から1分脚注1

停止時間ゼロ脚注2

コンピュータ障害

数分から数時間脚注3

数分

停止時間ゼロ脚注4

数秒から1分

停止時間ゼロ脚注4

停止時間ゼロ脚注4

ストレージ障害

停止時間ゼロ脚注5

停止時間ゼロ脚注5

停止時間ゼロ脚注5

停止時間ゼロ脚注5

停止時間ゼロ脚注5

停止時間ゼロ脚注5

人的エラー

30分未満脚注6

30分未満脚注6

30分未満脚注6

30分未満脚注6

30分未満脚注6

30分未満脚注6

データ破損

場合によっては数時間脚注7

場合によっては数時間脚注7

場合によっては数時間脚注7

停止時間ゼロ脚注8

停止時間ゼロ脚注8

数秒から1分

脚注1このリカバリ時間は、データベースおよび既存の接続フェイルオーバーに適用されます。ネットワーク接続が変わり、他のサイト固有のフェイルオーバー・アクティビティによって、全体的なリカバリ時間が長くなる場合があります。

脚注2アプリケーションで、障害のあるシステムに接続されている部分が一時的に影響を受けます。レプリカにフェイルオーバーするように、障害のあるアプリケーション接続を構成できます。

脚注3リカバリ時間の大部分は、障害のあるシステムのリストアに要する時間です。

脚注4データベースはそのまま使用できますが、アプリケーションで障害のあるシステムに接続されている部分が一時的に影響を受けます。

脚注5ストレージ障害は、ミラー化および自動リバランス機能のあるOracle ASMを使用して防止されます。

脚注6人的エラー時のリカバリ時間は、主に検出時間によって異なります。悪意のあるDMLまたはDLLトランザクションの検出に数秒かかった場合、一般に、該当するトランザクションのフラッシュバックには数秒しかかかりません。通常、検出時間が長くなると、該当するトランザクションの修復に必要なリカバリ時間が長くなります。例外は表を元に戻す場合です。この場合は、検出時間にかかわらず、文字どおり即時にリカバリされます。

脚注7リカバリ時間はブロック・メディア・リカバリによって異なり、フラッシュバック・ログまたはデータベース・バックアップから一貫したブロックをリストアする時間、およびアーカイブ・ログおよびオンラインREDOログからすべてのREDOを適用してブロックをリカバリする時間によっても異なります。

脚注8これは、自動ブロック修復で最も一般的なブロック破損修復です。自動ブロック修復では対応できない破損もあります。これらについてはData Guardフェイルオーバーを使用できます(数秒から数分かかります)。

表7-5に、あらゆるタイプの計画停止時間に対して各Oracle高可用性アーキテクチャで達成可能なリカバリ時間を示します。

表7-5 計画停止時に達成可能なリカバリ時間

システム変更またはデータ変更

停止タイプ

Oracle Database

Oracle RAC

Oracle Data Guard

MAA

Oracle GoldenGate

システム変更: 動的リソース・プロビジョニング

--

停止時間ゼロ

停止時間ゼロ

停止時間ゼロ

停止時間ゼロ

停止時間ゼロ

システム変更: ローリング・アップグレード

システム・レベル・アップグレード

数分から数時間

停止時間ゼロ

数秒から5分

停止時間ゼロ

停止時間ゼロ

システム変更: ローリング・アップグレード

クラスタ全体またはサイト全体のアップグレード

数分から数時間

数分から数時間

数秒から5分

数秒から5分

停止時間ゼロ脚注1

システム変更: ローリング・アップグレード

ストレージの移行

停止時間ゼロ脚注2

停止時間ゼロ脚注2

停止時間ゼロ脚注2

停止時間ゼロ脚注2

停止時間ゼロ脚注2

システム変更: ローリング・アップグレード

データベースの個別パッチ

数分から1時間

停止時間ゼロ脚注3

数秒から5分

停止時間ゼロ脚注3

停止時間ゼロ

システム変更: ローリング・アップグレード

データベース・パッチ・セットおよびバージョンのアップグレード

数分から数時間

数分から数時間

数秒から5分

数秒から5分

停止時間ゼロ脚注1

システム変更: ローリング・アップグレード

プラットフォームの移行

数分から数時間

数分から数時間

数分から数時間

数分から数時間

停止時間ゼロ脚注1

データ変更

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

停止時間ゼロ

停止時間ゼロ

停止時間ゼロ脚注4

停止時間ゼロ脚注4

停止時間ゼロ脚注4

アプリケーション変更

エディションで修正される停止

停止時間ゼロ

停止時間ゼロ

停止時間ゼロ

停止時間ゼロ

停止時間ゼロ

脚注1メンテナンス中のシステムに接続されているアプリケーション(またはアプリケーションの一部)が一時的に影響を受けます。

脚注2Oracle ASMは、データベースがオンラインのまま、ディスクが追加または削除されると、格納されたデータのリバランスを自動的に行います。ストレージの移行の場合、Oracle ASMによって一時的に両方のストレージ・アレイを使用する必要があります。

脚注3正規の個別パッチの場合のみ。

脚注4DBMS_REDEFINITIONパッケージを使用して、表をオンラインで再編成できます。ただし、オンラインでの変更は、SQL Applyまたはデータ・キャプチャではサポートされていないため、このサブプログラムの影響は、ロジカル・スタンバイ・データベースまたはレプリカ・データベースでは見えません。詳細は、『Oracle Data Guard概要および管理』または『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

7.3 アプリケーション・サーバーの高可用性の統合

柔軟性のある自動高可用性ソリューションを使用することで、ビジネス目標の達成に必要な(Oracle Application Serverにデプロイする)アプリケーションの可用性を確実に満たすことができます。このマニュアルで説明するソリューションの詳細は、『Oracle Fusion Middleware高可用性ガイド』を参照してください。

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

- Oracle Application Serverの高可用性アーキテクチャ

- 冗長アーキテクチャ

- Oracle Application Serverの高可用性サービス

7.3.1 Oracle Application Serverの高可用性アーキテクチャ

Oracle Application Serverには、あらゆる障害に対する最大の保護を目的とした高可用性および障害時リカバリ・ソリューションがあり、インストール、デプロイメントおよびセキュリティにおける柔軟性の高いオプションが用意されています。これらのソリューションは、ローカル高可用性ソリューションと障害時リカバリ・ソリューションに分類されます。ローカル高可用性ソリューションは、単一データ・センターのデプロイメントで高可用性を提供します。障害時リカバリ・ソリューションは、一般的に地理的に分散されたデプロイメントで、洪水や広範囲のネットワーク停止などの災害からアプリケーションを保護します。

高度なレベルでは、Oracle Application Serverのローカルの高可用性アーキテクチャには、OracleAS中間層とOracleASインフラストラクチャのアクティブ-アクティブおよびアクティブ-パッシブのアーキテクチャがあります。どちらのソリューションも高可用性を提供しますが、通常、アクティブ-アクティブ・ソリューションの方が、高いスケーラビリティと高速フェイルオーバーを提供します。ただし、費用が高額になる傾向があります。アクティブ-アクティブまたはアクティブ-パッシブのカテゴリでは、インストール、コスト、スケーラビリティおよびセキュリティの容易さが異なる複数のソリューションがあります。

ローカルの高可用性ソリューションをベースに、Oracle Application Serverの障害時リカバリ・ソリューションを構築します。この独自のソリューションでは、Oracle Databaseで実績のあるOracle Data Guardテクノロジとアプリケーション分野の高度な障害時リカバリ・テクノロジを組み合せて、アプリケーション・システム全体の包括的な障害時リカバリ・ソリューションを作成します。障害時リカバリ・ソリューションでは、一般的に同質の2つのサイト(一方はアクティブ、もう一方はパッシブ)を設定します。いずれのサイトも自己完結型システムです。通常、アクティブ・サイトは本番サイト、パッシブ・サイトはスタンバイ・サイトと呼ばれます。通常の操作では、本番サイトがリクエストを処理しますが、サイトのフェイルオーバーやスイッチオーバーが発生した場合は、スタンバイ・サイトが本番サイトの役割を引き継ぎ、すべてのリクエストがそのサイトにルーティングされます。スタンバイ・サイトをフェイルオーバー用に保持するには、スタンバイ・サイトに同一のインストールおよびアプリケーションを含めるだけでなく、本番サイトからスタンバイ・サイトへデータおよび構成を絶えず同期化させることも必要です。Oracle Application Serverのインスタンスは、障害時リカバリ設定でインスタンスが妨害されないかぎりどちらのサイトにもインストールできます。2つのサイトが同種性を保つには、構成とデータを定期的に同期化する必要があります。

7.3.2 冗長アーキテクチャ

Oracle Application Serverでは、同じワークロードをサポートする複数のインスタンスをサポートすることにより、冗長性が得られます。このような冗長構成では、ワークロードの分散またはフェイルオーバーの設定のいずれか、またはその両方によって可用性が向上します。

Oracle Application Serverシステムへのエントリ・ポイント(コンテンツのキャッシュ)からバック・エンド層(データ・ソース)まで、リクエストが通過するすべての層は、Oracle Application Serverを使用して冗長方式で構成できます。この構成は、Oracle Application Server Clusterを使用したアクティブ-アクティブ構成、またはOracle Application Server Cold Cluster Failoverを使用したアクティブ-パッシブ構成のいずれかになります。

7.3.3 Oracle Application Serverの高可用性サービス

『Oracle Application Server高可用性ガイド』では、Oracle Application Serverの次の高可用性サービスの詳細を説明しています。

- プロセス停止の検出と自動再起動

- 構成の管理

- 状態のレプリケーション

- サーバーのロード・バランシングおよびフェイルオーバー

- バックアップおよびリカバリ

- 障害時リカバリ

7.4 すべてのアプリケーションの高可用性の統合

可用性が高く、リジリエンスがあるアプリケーションでは、アプリケーションのすべてのコンポーネントで障害および変更が許容される必要があります。可用性の高いアプリケーションは、そのアプリケーションに影響を与えるすべてのコンポーネント(ネットワーク・トポロジ、アプリケーション・サーバー、アプリケーションのフローと設計、システム、およびデータベースの構成やアーキテクチャなど)を分析する必要があります。このマニュアルでは、主にデータベースの高可用性ソリューションに焦点を当てています。

次のMAA WebサイトでOracle Application Server、Oracle Enterprise ManagerおよびOracle Applicationに関する高可用性ソリューションと推奨事項を参照してください。

http://www.oracle.com/goto/maa

脚注の凡例

脚注1: 単一インスタンス・データベースでは、クラスタ化されたOracle ASM(ストレージ・グリッド)またはクラスタ化されていないOracle ASMを使用できます。
脚注2: ネットワーク・スプリット(一般的にスプリット・ブレインと呼ばれる)は、双方のクラスタのノードがお互いを確認できない場合に発生します。
脚注3: Oracle Clusterwareはサービス・イベントを送信し、FAN統合クライアントはそのイベントに自動的に応答します。

用語集

ビジネス影響分析

IT関連の停止の影響の重大度に基づいてビジネス・プロセスを分類します。

クラスタ全体の障害

Oracle RACデータベースのホストであるクラスタ全体が使用不可能になるか、故障します。これには、クラスタ内のノードの障害や、クラスタが使用不可能になる原因となった他のコンポーネントの障害、使用不可能なサイト上のOracleデータベースやインスタンスの障害が含まれます。

コンピュータ障害

データベースが稼働しているシステムが、停止またはアクセス不可能のために使用できない状態になったときに発生する停止。

停止時間のコスト

ビジネス影響分析を完全に実施すれば、計画外停止時間および計画停止時間のコストの定量化に必要な見通しが得られます。このコストは、高可用性の投資の優先付けに役立ち、停止時間のリスクを最小限に抑えるために選択する高可用性テクノロジに直接影響を与えるため、必ず理解しておく必要があります。

データ破損

破損ブロックは変更されたブロックです。そのため、Oracle Databaseが検出するものとは異なります。ブロック破損は、物理的ブロック破損と論理的ブロック破損の2つに分類されます。

「物理的破損」および「論理的破損」も参照してください。

停止または減速

停止または減速は、リソースやロックの競合が原因でデータベースまたはアプリケーションがトランザクションを処理できない場合に発生します。認識される停止は、システム・リソースの不足が原因で起こります。

人的エラー

データベース内のデータを論理的に破損または使用不可能の状態にする意図的でない、または悪意のある操作が行われた場合に発生する停止。人的エラーによる停止から受けるサービス・レベルの影響は、影響を受けたデータの量および重大性によって大きく異なります。

論理的破損

ブロックの内容が論理的に一貫していない状態。論理的破損の例として、行の一部や索引エントリの破損があげられます。

論理ユニット番号(LUN)

同じSCSI IDを持つ最大8つのデバイス(論理ユニット)を区別するために、SCSIバスで使用される3ビットの識別子。

書込み欠落

永続記憶域で実際には書込みI/Oが発生していないのに、サブシステムがブロック書込みの完了を確認したときに発生する可能性のあるデータ破損のもう1つの形。I/OサブシステムからOracle Databaseにはエラーは報告されません。

MAA環境

Oracle RACを使用したOracle Database 11gとOracle Data Guardを使用したOracle Database 11gの両方の機能とメリットが継承されるため、計画外停止と計画停止の両方に対して、最も包括的なソリューション・セットを提供するアーキテクチャ。

MAA環境は、Oracle RACプライマリ・データベースの存在するサイトと、ロジカル・スタンバイ・データベースとフィジカル・スタンバイ・データベースの両方のホストとなるクラスタ、または少なくとも1つのフィジカルまたはロジカル・スタンバイ・データベースが存在するもう1つのサイトで構成されます。

管理性目標

管理性目標はRPOやRTOよりも主観的であり、組織で使用できるスキル・セットや管理リソースの客観的な評価、および組織が高可用性アーキテクチャのすべての要素を正常に管理できる程度に起因します。管理性目標を理解すれば、組織で実現が可能と思われる事項と実現が実用的である事項とを区別する際に役立ちます。

ネットワーク・サーバー・プロセス

プライマリ・データベースのData Guardネットワーク・サーバー・プロセス(LNSnプロセスともいう)は、スタンバイ・データベースのRFSプロセスへのネットワーク送信を実行します。宛先ごとに1つのネットワーク・サーバー・プロセスがあります。

Oracle Active Data Guardオプション

Oracle Active Data Guardオプションのライセンスを購入していない場合、フィジカル・スタンバイ・データベースは、REDO Applyがアクティブなとき、読取り専用アクセスに対して開くことができます。この機能はActive Data Guardといい、スタンバイ・データベースでブロック変更トラッキングも可能で、その結果、スタンバイで増分バックアップを実行できます。

注意: Active Data Guardオプションは、他のドキュメントではリアルタイム問合せと呼ばれる場合もあります。

物理的破損

データベースがブロックをまったく認識しない状態。チェックサムは無効になり、ブロック内はすべてゼロになるか、またはブロックのヘッダーとフッターが一致しません。メディア破損とも呼ばれます。

リカバリ・ポイント目標(RPO)

組織に損害を与えずに、ITベースのビジネス・プロセスで失うことのできる最大データ量。RPOは、一般的に、ビジネス・プロセスまたは組織の許容データ損失量に相当します。このデータ損失は、通常、5時間または2日分のデータ損失というように、時間に換算して測定されます。

リカバリ時間目標(RTO)

組織に重大な物質的損失を与えずに、ITベースのビジネス・プロセスを停止できる最大時間。RTOは、一般的に、ビジネス・プロセスまたは組織の許容停止時間に相当します。

投資利益率(ROI)

投資利益率(収益率)は、金融や経済での投資効率の評価に使用されます。

サイト障害

イベントが原因で、すべてまたは大部分のアプリケーションが処理を停止したか、または使用不可のサービス・レベルまで減速した場合に発生します。サイト障害は、データ・センターでのすべての処理か、またはデータ・センターでサポートされているアプリケーションのサブセットに影響する可能性があります。

ストレージ障害

データベース・コンテンツの一部またはすべてが格納されている記憶域が停止またはアクセス不可能になり、使用できない状態になったときに発生する停止。

総所有コスト(TCO)

顧客および企業管理者が直接費と間接費を評価するのに役立つ金銭上の推定。完全な原価計算の形態として多くの業界で使用されています。

一時的なロジカル・スタンバイ・データベース

一時的なロジカル・スタンバイ・データベースでは、現在のフィジカル・スタンバイ・データベースを一時的にロジカル・スタンバイに変換して、ローリング・データベース・アップグレードを実行し、停止時間を最小限に抑えて再利用できます。

索引
A  B  C  D  E  F  G  H  I  L  M  N  O  P  R  S  T  U  V  W

数字

24x365, 1.1

64ビット・システム

32ビットからの移行, 4.1.2.1

A

アクセス制御

セキュリティ, 3.14

Active Data Guard

「Oracle Active Data Guardオプション」を参照

アクティブ・セッション履歴(ASH)

一時的なパフォーマンス問題のレポート, 6.1

ADD COLUMN

列のデフォルト値, 4.5.5

アドバイザ・フレームワーク, 6.1 ALTER DATABASE RECOVER MANAGED STANDBY文

リアルタイム問合せの有効化, 5.4.1

分析

高可用性要件の特定, 2

アプリケーション

仮想IPアドレスの定義, 7.1.2

オンライン・メンテナンスおよびオンライン・アップグレード, 4.5

個別データベース・パッチの適用, 4.1.3 アーキテクチャ

選択, 7.2, 7.2

CPU, 3.6

障害, 1.1

グリッド・コンピューティング, 5.1

MAA, 7

管理性, 2.2.5

複数のスタンバイ・データベース, 7.1.5.2

Oracle Application Server, 7.2, 7.3, 7.3.1

Oracle Clusterware, 7.1.2

Oracle ClusterwareおよびOracle Data Guard, 7.1.5.3, 7.1.6

Oracle Data Guard, 7.1.5

Oracle Data Guardスタンバイ・ハブ, 7.1.5.2, 7.1.5.3

Oracle Database, 7.1.1

Oracle RAC, 7.1.4

Oracle RACおよびOracle Data Guard, 7.1.8

拡張クラスタ上のOracle RAC, 7.1.4.1

Oracle RAC One Node, 7.1.3

Oracle RAC One NodeおよびOracle Data Guard使用のOracle Database, 7.1.7

推奨, 7.2

要件, 1.1, 2.1, 2.3

ロードマップ, 1.5

同じプロセッサ・プラットフォーム, 4.1.2

単一スタンバイ・データベース, 7.1.5, 7.1.5.1

ASM

「Oracle Automatic Storage Management(Oracle ASM)」を参照

監査

セキュリティの制御, 3.14

認証

セキュリティの制御, 3.14

自動ブロック修復, 3.8.9, 3.20 自動フェイルオーバー

Oracle Data Guard, 7.1.5.1

自動メンテナンス・タスク, 6.1 自動共有メモリー管理

動的メモリー割当て, 4.2.1

自動ワークロード・リポジトリ(AWR), 6.1 可用性

概要, 1.1

中断, 1.3

ロードマップ, 1.5

「高可用性」も参照

B

トランザクションの取消し, 3.8.3

バックアップ

高速リカバリ領域, 3.10

プライマリ・データベースからのオフロード, 3.6.1

Oracle Secure Backup, 3.13

オブジェクト間, 4.5.6 ブロック破損

修復, 3.20

ブロック・リカバリ

時間の短縮, 3.20

フラッシュバック・ログの使用, 3.8.9

フラッシュバック・ログを使用したブロック・リカバリ, 3.8.9 制限的なリカバリ, 3.2 Bourneシェル・スクリプト

physru, 3.6.3

予算計画, 2.3.1 ビジネス影響分析

内部ナレッジ管理システムの例, 2.2.1

半導体製造業者の例, 2.2.1

ビジネス・パフォーマンス計画, 2.3.1

C

変更の保証, 6

チェックポイント

ファスト・スタート・リカバリ, 3.2

正しい高可用性アーキテクチャの選択, 7.2 クライアント・フェイルオーバー, 3.19 Cluster Ready Services(CRS)

アップグレード時の停止時間の回避, 4.1.4

クラスタ

拡張, 7.1.4.1

Oracle Clusterware, 7.1.2

コールド・クラスタ・フェイルオーバー, 7.1.2, 7.1.6

Oracle Clusterwareの使用, 7.1.2

Oracle ClusterwareおよびData Guard使用, 7.1.6

コンポーネント

Oracle Restartと統合, 3.3

圧縮REDOデータ

Oracle Data Guard, 7.1.5

コンピュータ障害, 1.4 破損

予防と検出, 3.21

修復, 3.20

コスト

定量化, 2.2.2

CPUアーキテクチャ, 3.6 CREATE TRIGGER文

句, 4.5.4

crosseditionトリガー, 4.5.1.3

D

データ破損, 1.4

自動検出および修復, 3.20

検出, 3.21

予防と検出のパラメータ, 3.21

データ分散

Oracle GoldenGate, 3.7

データの暗号化, 3.14 Data Guard

「Oracle Data Guard」を参照

データの統合

Oracle GoldenGate, 3.7

データ保護

最大化, 1.2

データ・リカバリ・アドバイザ, 3.12 データ変換, 3.7.1 データ型の制限

拡張データ型サポート(EDS)による解決, 4.1.9.1, 4.1.9.4

データ型

EDSによる高度なサポート, 3.6.3

データベース・リプレイ, 6.2 データベース・サーバー・グリッド, 5.1

概要, 5.2

データベース・ストレージ・グリッド, 5.1

概要, 5.3

データベースのアップグレード

トランスポータブル表領域の使用, 4.1.9.2

データベース

Oracle個別パッチの適用, 4.1.3

チェックポイント, 3.2

動的再構成, 4.2.1

セキュリティ, 3.14

サーバー・グリッド, 5.1

許容データ損失量, 2.2.4 DBA_FLASHBACK_TRANSACTION_STATEビュー, 3.8.3 DBFSコンテンツ・ストア, 3.18 DBMS_FLASHBACK.TRANSACTION_BACKOUT()プロシージャ, 3.8.3 WAITオプションを使用したDDL, 4.5.3 依存性, 4.5.6 DISABLE句

FOLLOWS句

CREATE TRIGGER文, 4.5.4

障害時リカバリ・ソリューション

Oracle Application Server, 7.3.1

ディスク・グループ

Oracle ASMによる管理, 3.9

停止時間

原因, 1.4

コスト, 1.3, 2.2.2

Oracle GoldenGateおよびOracle Data Guardを使用した最小化, 4.1.9.3

軽減, 1.3

ソリューションの概要

計画, 4.1

計画外, 3.1

「計画外停止時間」も参照 動的再構成, 4.2.1

E

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

crosseditionトリガー, 4.5.1.3

ビューの編集, 4.5.1.2

エディション, 4.5.1.1

ENABLE句

CREATE TRIGGER文, 4.5.4

暗号化

データ, 3.14

エンディアン形式のプラットフォーム

異なるプラットフォームへの移行時の停止時間の回避, 4.1.11

同じプラットフォームへの移行時の停止時間の回避, 4.1.10

Exadataセル, 3.16

「Oracle Exadata Storage Server Software」も参照

EXCLUDE STANDBYオプション

RMAN RECOVER BLOCKコマンド, 3.20

拡張クラスタ

アーキテクチャ, 7.1.4.1

拡張データ型サポート(EDS)

ローリング・アップグレード, 3.6.3

拡張データ型サポート(EDS)

パッチ・セットおよびデータベースのアップグレード, 4.1.9

F

フェイルオーバー

高速, 7.1.5.1

複数のスタンバイ・データベース

アーキテクチャ, 7.1.5.2

単一のスタンバイ・データベース・アーキテクチャ, 7.1.5.1 障害グループ

Oracle ASMによる管理, 3.9

Oracle ASM, 3.9

障害

コンピュータ, 1.4

確率, 7.2

サイト, 1.4

ストレージ, 1.4

高速アプリケーション通知(FAN)

ハードウェアのアップグレード, 4.1.1

オペレーティング・システムのアップグレード, 4.1.1

高速接続フェイルオーバー

プールされていない接続, 3.4.2

高速ミラー再同期

Oracle ASM, 3.9

高速リカバリ領域

概要, 3.10

利点, 3.10

Data Guard構成, 7.1.5

ファスト・スタート・フェイルオーバー

単一スタンバイ・データベース・フェイルオーバー, 7.1.5.1

ファスト・スタート・リカバリ

使用の利点, 3.2

フォルト診断インフラストラクチャ, 6.1 フラッシュバック・ログ

ブロック・リカバリ, 3.8.9

フラッシュバック機能で使用, 3.8

フラッシュバック・テクノロジ

フラッシュバック・ログを使用したブロック・リカバリ, 3.8.9

「Oracle Flashbackテクノロジ」も参照

forward crosseditionトリガー, 4.5.1.3 停止の頻度, 7.2, 7.2 FUSE(Filesystem in Userspace)API

データベース・ファイルシステム用クライアント(CDF)の使用, 3.18

G

グリッド・コンピューティング, 5.1

データベース・サーバー・グリッド, 5.1

データベース・ストレージ・グリッド, 5.1

グリッド

サーバーおよびストレージ, 5.1

成長計画, 2.3.1

H

停止または減速, 1.4

ハードウェアのアップグレード

停止時間の回避, 4.1.1

FANの使用, 4.1.1

高可用性

24x365, 1.1

概要, 1.1, 1.1

分析フレームワーク, 2.1

アプリケーション, 7.3.1

アーキテクチャ, 1.1, 2.2.5, 7, 7.2

ビジネス影響分析, 2.2.1

要件の特定, 2

重要性, 1.2

最大化, 1.2

Oracle Application Server, 7.3

Oracle Database, 7.1

計画停止時間, 4.1

計画, 2.3.1

管理性目標の設定, 2.2.5

単一インスタンス・データベース, 3.3

ソリューション, 1.1

計画外停止時間, 3

「可用性」も参照

高可用性機能

Oracle Database, 7.1.1

ハブ・アンド・スポーク・デプロイメント, 3.7.1 人的エラー, 1.4

I

索引

不可視, 4.5.7

インテリジェントなインフラストラクチャ, 6, 6.1 インターブロック破損, 1.4 インターコネクト

Oracle RAC, 7.1.4

イントラブロック破損, 1.4 不可視索引, 4.5.7 I/Oリソース管理

Oracle Storage Grid, 5.3

L

ロード・バランシング・アドバイザ, 3.4.2

論理的破損, 1.4

ロジカル・スタンバイ・データベース

概要, 3.6.5

利点, 3.6.5

一時的な, 3.6.3, 3.6.3

LogMinerユーティリティ

概要, 3.15

書込み欠落, 1.4

M

データの変更, 4.5.1.1

管理性

目標, 2.2.5

最適化, 6

オーバーヘッド(MO), 2.2.5, 7.2

手動ブロック修復, 3.20 最大可用性アーキテクチャ

「Oracle Maximum Availability Architecture(MAA)」を参照

メディア破損

物理的破損, 1.4

メモリー

自動管理, 4.2.2

メモリー・アドバイザ, 6.1 MEMORY_MAX_TARGET初期化パラメータ, 4.2.2 MEMORY_TARGET初期化パラメータ, 4.2.2 メタデータ

依存性, 4.5.6

ストレージの移行

停止時間の回避, 4.1.6

移行

32ビット・システムから64ビット・システムへ, 4.1.2.1

Oracle Exadata Storage Server Software, 4.1.7

記憶域, 4.1.6

ミラー化

Oracle ASMネイティブ, 3.9

マルチマスター・レプリケーション, 3.7.1 複数のスタンバイ・データベース

Data Guardハブ, 7.1.5.3

フェイルオーバー, 7.1.5.2

一時的なロジカル・スタンバイの使用, 3.6.3, 3.6.3

N

ノード

仮想IPアドレス, 7.1.2

O

オブザーバ

ファスト・スタート・フェイルオーバー, 7.1.5.1

個別パッチ, 4.1.3 オンライン・データベース再配置ユーティリティ, 7.1.3 オンライン・メンテナンス

アプリケーション, 4.5

表のオンライン再定義, 4.3 オンライン再編成

概要, 4.3

表のオンライン再定義, 4.5.8 OPatchユーティリティ

Oracle RACのパッチ・アップグレード, 4.1.3

オペレーティング・システム

Oracle Clusterwareの要件, 7.1.2

アップグレード, 4.1.1

アップグレード中のFANの使用, 4.1.1

Oracle Active Data Guard

スタンバイ・データベース

利点, 3.6.2

Oracle Active Data Guardオプション, 5.4.1

ASHサンプルの収集, 6.1

Oracle Application Server

高可用性アーキテクチャ, 7.3.1

セキュリティ, 7.3.1

Oracle Automatic Storage Management(Oracle ASM)

概要, 3.9

利点, 3.9

ファイルの分散, 4.2.3

障害グループ, 3.9

高速ミラー再同期, 3.9

ネイティブ・ミラー化, 3.9

ストレージの移行, 4.1.5

アップグレード, 4.1.5

データベース・ストレージ・グリッドの使用, 5.3

Oracle Automatic Storage Managementクラスタ・ファイルシステム(Oracle ACFS), 3.9, 7.1.1 Oracle Call Interface(OCI), 3.4.2 Oracle Clusterware

概要, 7.1.2

サード・パーティ・クラスタウェアに対する利点, 7.1.2

アップグレード時の停止時間の回避, 4.1.4

利点, 7.1.2

コールド・クラスタ・フェイルオーバー, 7.1.2

Data Guard使用の構成, 7.1.6

Oracle Data Guard

概要, 3.6

利点, 3.6, 7.1.5

利点, 3.6

Oracle Clusterware使用の構成, 7.1.6

Oracle GoldenGate使用の構成, 3.7.2, 4.1.9.3

ハブ・アーキテクチャ, 7.1.5.3

複数のスタンバイ・データベース・アーキテクチャ, 7.1.5.2

単一のスタンバイ・データベース・アーキテクチャ, 7.1.5.1

システムとクラスタのアップグレード, 4.1.2

Oracle Data Provider for .NET(ODP.NET), 3.4.2 Oracle Database

基本のアーキテクチャ, 7.1.1

Data Guard使用, 7.1.5

Oracle Clusterware使用(コールド・クラスタ・フェイルオーバー), 7.1.2

Oracle ClusterwareおよびOracle Data Guard使用, 7.1.6

Oracle RACの使用, 7.1.4

Oracle RACおよびOracle Data Guard使用 - MAA, 7.1.8

拡張クラスタ上のOracle RAC使用, 7.1.4.1

Oracle Database File System(DBFS), 3.18, 7.1.5 Oracle Database Resource Managerのインスタンス・ケージング7.1.3 Oracle Enterprise Manager Grid Control, 6, 6.3 Oracle Exadata Database Machine, 3.17 Oracle Exadata Storage Server Software, 3.16

Sun Oracle Database Machineとの組合せ, 3.17

移行, 4.1.7

アップグレード, 4.1.8

Oracle Flashback Data Archive, 3.8.10 Oracle Flashback Database, 3.8.8 Oracle Flashback Drop, 3.8.6 Oracle Flashback Query, 3.8.1 Oracle Flashback Table, 3.8.5 Oracle Flashbackテクノロジ, 3.8 Oracle Flashback Transaction, 3.8.3 Oracle Flashback Transaction Query, 3.8.4 Oracle Flashback Version Query, 3.8.2 Oracle GoldenGate, 3.7

概要, 3.7

Oracle Streamsとの比較, 3.7

停止時間を最小限に抑えるための構成, 4.1.9.3

Oracle Data Guard使用の構成, 3.7.2

ローリング・アップグレード, 4.5.2

Oracle個別パッチ, 4.1.3

適用, 4.1.3

停止時間の回避, 4.1.3

Oracle Management Agents

Oracle Enterprise Manager Grid Control, 6.3

Oracle Management Repository

Oracle Enterprise Manager Grid Control, 6.3

Oracle Management Service (OMS)

Oracle Enterprise Manager Grid Control, 6.3

Oracle Maximum Availability Architecture(MAA)

概要, 1.5

アーキテクチャ, 7

利点, 7.1.8

ロードマップ, 1.5

Oracle Real Application Clusters One Node, 7.1.3

オンライン・データベース再配置ユーティリティ, 7.1.3

「Oracle RAC One Node」を参照

Oracle Real Application Clusters(Oracle RAC)

概要, 7.1.4

Oracle個別データベース・パッチの適用, 4.1.3

自動冗長インターコネクト, 7.1.4

利点, 3.4.2

拡張クラスタ, 7.1.4.1

オペレーティング・システムとハードウェアのアップグレード, 4.1.1

ストレージ・エリア・ネットワーク(SAN), 7.1.4.1

Oracle Restart, 3.3 Oracle Secure Backup

概要, 3.13

利点, 3.13

Oracle Streams, 3.7

Oracle GoldenGateとの比較, 3.7

Oracle UCPランタイム接続ロード・バランシング, 3.4.2 Oracle VM

ドメイン・ライブ・マイグレーション, 5.5

Oracle RAC One Node使用, 7.1.3

停止

頻度, 7.2, 7.2

タイプ, 1.4

P

パフォーマンス

一時的な問題に対処するためのASHサンプリング, 6.1

物理的破損, 1.4 フィジカル・スタンバイ・データベース

利点, 3.6.1

ASHサンプルの収集, 6.1

リアルタイム問合せ, 5.4.1

スナップショット・スタンバイ, 3.6.4

一時的なロジカル・スタンバイ・データベース, 3.6.3

physruシェル・スクリプト, 3.6.3 計画アクティビティ

障害の確率, 7.2

計画停止時間

オンライン・パッチの適用, 4.1.3.1

リカバリ時間, 7.2

計画停止

Oracle GoldenGateおよびOracle Data Guardを使用した最小化, 4.1.9.3

プラットフォームの移行

トランスポータブル・データベースの使用, 4.1.10.1

ポリシー管理

セキュリティ, 3.14

優先付け

高可用性の投資, 2.2.2

確率

計画外アクティビティおよび計画アクティビティにおける様々な障害, 7.2

プログラム・グローバル領域(PGA)

自動管理, 4.2.2

R

リアルタイム問合せ, 5.4.1

ASHサンプルの収集, 6.1

再構成

データベースの動的, 4.2.1

Recovery Manager(RMAN)

概要, 3.11

利点, 3.11

リカバリ・ポイント目標(RPO)

概要, 2.2.4, 7.2

リカバリ時間目標(RTO)

概要, 2.2.3, 7.2

リカバリ時間

計画停止時間, 7.2

データ・ブロック破損による停止時間の短縮, 3.20

計画外停止時間, 7.2

冗長インターコネクト, 7.1.4 再配置

オンライン・データベース, 7.1.3

レプリケーション

Oracle GoldenGate, 3.7

Oracle Streams, 3.7

リストア・ポイント

Oracle Flashback, 3.8.7

投資利益率(ROI), 2.2.6, 7.2

最適化, 5

reverse crosseditionトリガー, 4.5.1.3 RMAN RECOVER BLOCKコマンド

データ・ブロック破損の修復, 3.20

最大可用性アーキテクチャ(MAA)のロードマップ, 1.5 ロールバック

トランザクション, 3.8.3

ローリング・アップグレード

Oracle GoldenGate, 4.5.2

拡張データ型サポート(EDS)によるデータ型のサポート, 3.6.3

physruシェル・スクリプトの使用, 3.6.3

一時的なロジカル・スタンバイの使用, 3.6.3, 3.6.3

行レベルのセキュリティ

仮想プライベート・データベース, 3.14

実行時接続ロード・バランシング, 3.4.2

S

安全な通信

Grid Control環境の層, 6.3

Secure Sockets Layer(SSL)

安全な通信の有効化, 6.3

Grid Controlでの使用, 6.3

SecureFile LOB, 3.18 セキュリティ

概要, 3.14

利点, 3.14

ファイアウォールで保護されている環境内の層と層の間, 6.3

データの暗号化, 3.14

Oracle Application Server, 7.3.1

Oracle ASM, 3.9

RMAN, 3.11

セグメント・アドバイザ, 6.1 サーバー・グリッド, 5.1 サーバー生成済のアラート, 6.1 サーバー

Oracle Clusterwareの要件, 7.1.2

品質保証契約(SLA), 2.1 単一のスタンバイ・データベース・アーキテクチャ

フェイルオーバー, 7.1.5.1

単一インスタンス・データベース

Oracle Restart, 3.3

サイト障害, 1.4 SLA, 2.1 スナップショット・スタンバイ・データベース

概要, 3.6.4

スナップショット・スタンバイ・データベース

利点, 3.6.4

SQLアクセス・アドバイザ, 6.1 SQL Apply

アップグレード, 4.1.9, 4.1.9.1

拡張データ型サポート(EDS)の使用, 4.1.9.1

ロジカル・スタンバイ・データベースの使用, 3.6.5

SQLパフォーマンス・アナライザ, 6.2 SQLチューニング・アドバイザ, 6.1 SSL

「Secure Sockets Layer(SSL)」を参照

スタンバイ・データベース

アクティブ, 5.4

Active Data Guardオプション, 5.4.1

利点, 3.6

ハブ構成例, 7.1.5.3

ロジカル・スタンバイ, 3.6.3, 3.6.3

複数スタンバイ・アーキテクチャ, 7.1.5.2

単一スタンバイ・アーキテクチャ, 7.1.5.1

スナップショット・スタンバイ・データベース, 3.6.1

一時的なロジカル・スタンバイ・データベース, 3.6.1

スタンバイ・リーダー・ファーム, 5.4.2 ストレージ

障害, 1.4, 3.9

グリッド, 5.1

移行, 4.1.6

Oracle ASMによる保護, 3.9

ストレージ・エリア・ネットワーク(SAN)

拡張クラスタ, 7.1.4.1

システム・グローバル領域(SGA)

自動管理, 4.2.2

システムのアップグレード

停止時間の回避, 4.1.1

T

表

編集可能, 4.5.1.2

テープ・バックアップ

Oracle Secure Backupの使用, 3.13

Thinクライアントのウォッチドッグ

ファスト・スタート・フェイルオーバーのオブザーバ, 7.1.5.1

総所有コスト(TCO), 2.2.6, 7.2 トランザクション

フラッシュバック・トランザクションによる取消し, 3.8.3

一時的なロジカル・スタンバイ・データベース

概要, 3.6.3

利点, 3.6.3

physruシェル・スクリプト, 3.6.3

トランスポータブル・データベース

プラットフォーム移行用, 4.1.10.1

計画外停止時間, 4.4

トランスポータブル表領域

計画外停止時間, 4.4

データベースのアップグレード, 4.1.9.2

U

UNDOアドバイザ, 6.1

UNDOデータ

フラッシュバック機能で使用, 3.8

計画外アクティビティ

障害の確率, 7.2

計画外停止時間

原因, 1.4

リカバリ時間, 7.2

ソリューションの概要, 3.1

トランスポータブル・テクノロジ, 4.4

交信可能なスタンバイ・データベース, 3.6.4 アップグレード

アプリケーション, 4.5

クラスタ, 4.1.2

データベース, 4.1.9

ハードウェア, 4.1.1

オペレーティング・システム, 4.1.1, 4.1.2

Oracle ASM, 4.1.5

Oracle Clusterware, 4.1.4

Oracle Exadata Storage Server Software, 4.1.8

Oracle Real Application Clusters(Oracle RAC), 4.1.1

パッチ, 4.1.3

Oracle GoldenGateでのローリング, 4.5.2

crosseditionトリガーの使用, 4.5.1.3

トランスポータブル表領域の使用, 4.1.9.2

ロジカル・スタンバイ・データベースの使用(SQL Apply), 3.6.3, 3.6.3

V

V$DATABASE_BLOCK_CORRUPTIONビュー, 3.21

仮想IP(VIP)アドレス

アプリケーションの定義, 7.1.2

Oracle Clusterwareによる管理, 3.4.1

仮想プライベート・データベース

セキュリティ, 3.14

仮想化

Oracle VMのドメイン・ライブ・マイグレーションの使用, 5.5

W

WAITオプション

DDLの指定, 4.5.3

Webスケーラビリティ

スタンバイ・リーダー・ファームの使用, 5.4.2

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2013, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

制限付権利

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション（人的傷害を発生させる可能性があるアプリケーションを含む）への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。