Exadata Database Machineを使用した Oracle Maximum Availability Architectureのデプロイ Oracle ホワイト・ペーパー | 2017 年 6 月

Exadata Database Machine を使用した Oracle Maximum Availability Architecture のデプロイ

目次

概要 1

Exadata MAA アーキテクチャ 2

初期デプロイメント 4

Exadata 固有の HA の利点 7

ハードウェア・コンポーネント 7

冗長データベース・サーバー 7

冗長ストレージ 8

冗長接続 9

冗長電源 9

ソフトウェア・コンポーネント： 9

ファームウェアとオペレーティング・システム 9

データベース・サーバー層 10

ストレージ層 10

高パフォーマンス 10

その他の Exadata HA 機能と利点 10

デプロイメント後の Exadata MAA 構成 15

データベースのアーカイブ・ログ・モードと強制ロギングの有効化 16

ファスト・リカバリ領域 16

Oracle フラッシュバック・テクノロジー 17

フラッシュバック・データベース 17

より粒度の高い修復のためのその他の Oracle フラッシュバック・テクノロジー 18

バックアップ、リストア、リカバリ 18

Oracle Data Guard と Oracle Active Data Guard 19

データ破損に対する包括的な保護 20

プライマリ・データベースでの設定 21

Data Guard フィジカル・スタンバイ・データベースでの設定 21

Exadata Database Machine を使用した Oracle Maximum Availability Architecture のデプロイ

アプリケーション・クライアント - フェイルオーバーのベスト・プラクティス 21

MAA のベスト・プラクティスの自動検証 - exachk 22

Exadata OVM HA 構成の追加の考慮事項 22

データベース統合のベスト・プラクティス 23

Exadata MAA における運用のベスト・プラクティス 23

テスト環境の重要性 25

結論 26

付録 1：Exadata MAA の停止とソリューションのマトリックス 27

計画外停止 27

計画メンテナンス 29

Standby-First Patch - Data Guard によるリスクの軽減と停止時間の短縮 30

1 | Exadata Database Machine を使用した Oracle Maximum Availability Architecture のデプロイ

概要

Oracle Maximum Availability Architecture（Oracle MAA）の運用および構成に関するベスト・プラクティスを Oracle Exadata Database Machine と統合すると（Exadata MAA）、ｵﾝプレミスまたはクラウドの Oracle Database 用のもっとも包括的な高可用性ソリューションが提供されます。

Exadata Database Machine、Exadata Cloud Machine（ExaCM）、および Exadata Cloud Service（ExaCS）は、ソフトウェア、サーバー、ストレージ、およびネットワーキングを統合した成熟したシステムで、これらすべての要素が、データベースおよびアプリケーションの最高の可用性とパフォーマンスを実現するように Oracle MAA のベスト・プラクティスに従って事前構成されています。あらゆる業種の公的機関および民間企業のミッション・クリティカルなアプリケーションが Exadata MAA を利用しています。すべての Exadata システムはハードウェアとソフトウェアが統合されており、オラクル社内および世界中のミッション・クリティカルなお客様による広範な可用性テストを通過してきました。このグローバルなコミュニティの体験から得た教訓は、あらゆる Exadata 環境に利益をもたらすさらなる機能拡張につながっています。

このホワイト・ペーパーは、データベース管理者、システム管理者、ストレージ管理者、エンタープライズ・アーキテクトなどの技術者を対象とし、Exadata Database Machine を迅速にデプロイして効率的に運用するための Exadata MAA のベスト・プラクティスに関する知識を提供することを目的としています。このホワイト・ペーパーは、次の 4 つの主要領域に分かれています。

» Exadata MAA のアーキテクチャ

» 初期デプロイメント

» Exadata HA 固有の利点

» デプロイメント後：Exadata MAA 構成

» Exadata MAA における運用のベスト・プラクティス

このホワイト・ペーパーに記載されている Exadata MAA のベスト・プラクティスを補足する資料として、次のものがあります。

» My Oracle Support Note 757552.1。Oracle MAA の継続的な検証テストと本番環境でのデプロイメントで得られた最新情報をお客様に提供するために、Oracle Development によって頻繁に更新されています。

» Exadata ヘルス・チェック（exachk）およびそれに関連する Oracle Exadata 評価レポートと Oracle MAA スコア・カード。このツールは四半期ごとに更新されます。

» 追加の Oracle MAA のベスト・プラクティス関連の資料。www.oracle.com/goto/maa で公開されている特定の領域またはトピックの具体的な技術的側面について、深く掘り下げて説明しています。

2 | Exadata Database Machine を使用した Oracle Maximum Availability Architecture のデプロイ

Exadata MAAアーキテクチャ

Exadata MAA アーキテクチャ（図 1）はあらゆる種類の計画外停止に対応できるように設計されており、高可用性（HA）とデータ保護機能の両方を提供します。また、Exadata MAA ではオンラインまたはローリング方式でメンテナンスを実行できるため、計画停止時間も最小化されます。Exadata MAA が対応している潜在的な停止と計画メンテナンスの範囲については、このホワイト・ペーパーの付録 1「Exadata MAA の停止とソリューションのマトリックス」に詳述しています。Exadata により、エンド・ツー・エンドのアプリケーション可用性を達成し、さまざまなハードウェアとソフトウェアの機能停止による一時停止時間をほぼゼロにする方法の実例については、Exadata MAA のテクニカル・ビデオ 1で説明している障害テストを参照してください。また、可用性およびデータ保護の一連の要件に従ったブループリントを示した Oracle MAA リファレンス・アーキテクチャも参照してください。

図1：Oracle Exadata Database Machineの基本構成

Exadata MAA のアーキテクチャである"ゴールド・リファレンス・アーキテクチャ"は、次の主要要素で構成されています。

» 本番 Exadata システム（プライマリ）。本番システムは、データウェアハウス、OLTP、または統合データベース環境のパフォーマンス要件およびスケールアウト要件を満たすため、必要に応じて、1 台の Exadata で柔軟に構成されるか、相互接続された 1 台以上の Exadata Database Machine で構成されます。

1 http://vimeo.com/esgmedia/exadata-maa-tests

3 | Exadata Database Machine を使用した Oracle Maximum Availability Architecture のデプロイ

» プライマリ Exadata Database Machine のレプリカであるスタンバイ Exadata システム。Oracle Data Guard を使用することで、プライマリ・システム上でホストされる本番データベースの厳密な物理レプリカである同期されたスタンバイ・データベースが維持されます。これにより、計画外停止のためにプライマリ・システムが使用できない場合でも、最適なデータ保護と高可用性が提供されます。スタンバイの Exadata システムは、プライマリ・サイトの障害からスタンバイを分離することでディザスタ・リカバリ（DR）を行うために、ほとんどの場合、地理的に異なる場所か別のデータセンターに配置されます。スタンバイ・システムをプライマリと同じ容量で構成することで、スイッチオーバーまたはフェイルオーバー操作後もパフォーマンス品質保証契約に適合することが保証されます。

'スタンバイ'という用語は、Data Guard によってプライマリ・データベースとの同期が維持されるデータベースを指すために使用されますが、スタンバイ・ロールにあるスタンバイ・データベースはアイドル状態にあるわけではありません。高可用性、データ保護、およびディザスタ・リカバリ以外の目的にもスタンバイ・データベースを利用することで、高い投資収益率が実現されます。たとえば、次のような選択肢があります。

» Oracle Active Data Guard を使用すると、ユーザーは読取り専用問合せやレポート、高速増分バックアップをプライマリ・データベースから物理的なスタンバイ・データベースに移動させ、実行できます。これにより、スタンバイ自体が本番システムとしてオンライン状態になるため、あらゆるワークロードのパフォーマンスが向上します。また、プライマリ・データベースまたはスタンバイ・データベースでデータ・ブロックの破損が検出されると、Oracle Active Data Guard はユーザーに影響を与えることなく自動的に修正を実行するため、可用性も向上します。Oracle Database 12c の新機能である Active Data Guard により、本番データベースのパフォーマンスを低下させずにリモート・ロケーションへのデータ損失ゼロのフェイルオーバーが可能です。また、データベース・ローリング・アップグレードを大幅に簡素化する新しい自動化機能も利用可能です。

» Data Guard スナップショット・スタンバイを使用すると、セカンダリ・システム上のスタンバイ・データベースを使用して、障害からの保護を提供するだけでなく、最終的な本番前テストを実施することもできます。Oracle Real Application Testing をスナップショット・スタンバイと併せて使用して、実際の本番ワークロードをプライマリで取得し、スタンバイ・データベースで再生できます。これにより、実際の本番ワークロードを使用する本番システムのレプリカという理想的なテスト・シナリオを作成し、本番規模での徹底的なテストを実施できます。

» Data Guard Standby-First Patch（My Oracle Support Note 1265700.1）または Data Guard のデータベース・ローリング・アップグレードを使用すると、計画メンテナンス中の停止時間を短縮し、リスクを軽減できます。これは、このホワイト・ペーパーで後ほど示す Exadata MAA における運用のベスト・プラクティスの主要な要素です。

Data Guard は 1 つの構成で最大 30 のスタンバイ・データベースをサポートする能力を備えています。ますます多くのお客様が、この柔軟性を利用してローカル（HA 用）とリモート（DR 用）の両方の Data Guard スタンバイをデプロイするようになっています。ローカルの Data Guard スタンバイ・データベースにより、Exadata 内部の HA 機能が補完されます。スタンバイ・データベースでは、プライマリ・サイトが引き続き運用可能であっても、想定外の出来事や人為的エラーによって本番データベースが使用できなくなった場合に、追加の HA レイヤーを提供します。ネットワーク待機時間が短いため、フェイルオーバーが必要な場合にローカル・スタンバイへの同期レプリケーションでデータ損失が発生することはなく、新しいプライマリ・データベースに対して迅速にアプリケーション・クライアントをリダイレクトできます。

4 | Exadata Database Machine を使用した Oracle Maximum Availability Architecture のデプロイ

» プライマリおよびスタンバイの Exadata システムから独立した開発用またはテスト用の Exadataシステム。このシステムでは、本番アプリケーションのサポートに使用される多数の開発用またはテスト用データベースがホストされます。このテスト・システムには、本番環境を完全に反映したテスト構成を作成する目的で、独自のスタンバイ・システムが備わっている場合もあります。以下を実現するためには、本番システムと同様のテスト・システムを構成することが理想的です。

» 本番ワークロードを再現できるワークロード・フレームワーク（Real Application Testing など）の使用。

» 本番環境に変更を反映する前の、テスト環境での変更の検証（変更による影響とフォールバック手順の評価を含む）。

» 運用およびリカバリのベスト・プラクティスの検証。

Exadata 12.1.2.1.0 以降では、Exadata はテスト環境および開発環境の作成に使用できるスペース効率に優れたデータベース・スナップショットもサポートします。

一部のユーザーは、これらのアクティビティをスタンバイの Exadata システムに集約することでコストを削減しようと試みます。この判断は、コスト、運用の容易さ、柔軟性のトレードオフに対するビジネス上の意思決定に委ねられます。スタンバイの Exadata システムを使用して、その他の開発データベースやテスト・データベースもホストする場合、本番ニーズに備えてシステム・リソースを温存するには、フェイルオーバー時に特別な対策が必要になります。たとえば、障害の発生したシステムが修復されて本番環境に戻るまで、クリティカルでないテスト作業や開発作業を遅らせる必要があります。

Exadata MAA アーキテクチャは高可用性を実現するために必要な基盤を提供します。同様に重要となるのが構成と運用に関するプラクティスです。これについては次の項で説明します。

初期デプロイメント

Exadata は、ソフトウェア、サーバー、およびストレージによる統合システムで、事前に最適化されて構成されており、Exadata MAA を実装可能な状態で出荷されます。この項では、事前に構成されている設定と、初期デプロイメントに適用される HA のベスト・プラクティスを中心に説明します。

Exadata の納品前に、Oracle Exadata Deployment Assistant 構成ツール（config.sh）を実行、使用環境に固有の構成設定値を入力、構成ファイルを生成、およびデータセンターと運用上の基準に従ってインストール・テンプレートを再確認することが重要です。ネットワーク管理者およびデータベース管理者と協力して、Oracle Exadata Deployment Assistant 構成ツールに入力するのに適切なネットワークとデータベースの構成設定値を判断します。

Oracle Exadata Deployment Assistant 構成ツールに入力する際、次の構成可能なデプロイメント・オプションを指定することを推奨します。

1. Define Customer Networks 画面で、「Bonded for the Client network」を選択します。

» 初期構成時にクライアント・アクセス・ネットワーク用にチャネル・ボンディングを構成すると、Linux ボンディング・モジュールがアクティブ-バックアップ・モード（モード=1）で構成されます。別のボンディング・ポリシーの方が望ましい場合は、初期構成の後にボンディング・モジュールを再構成できます。詳しくは、『Oracle® Exadata Database Machineインストレーションおよび構成ガイド』を参照してください。

5 | Exadata Database Machine を使用した Oracle Maximum Availability Architecture のデプロイ

2. 次のようなストレージ停止シナリオで、最善の保護を実現しながら操作を最大限に容易にするため、Oracle MAA では、クラスタ構成画面の Disk Group Details セクションで、すべてのディスク・グループ（DATA および RECO）で Oracle Automatic Storage Management（Oracle ASM）に高冗長性を選択することを推奨しています。

» 二重のパートナー・ディスク障害 2：ディスク障害に続いて発生した 2 番目のパートナー・ディスク障害によるクラスタおよび Oracle ASM ディスク・グループの損失を防止します。

» パートナーExadata Storage Server がオフラインの場合のディスク障害：ストレージ・サーバーがオフラインになっているときに、ストレージ・サーバーのパートナー・ディスクで障害が発生した場合に、クラスタおよび Oracle ASM ディスク・グループの損失を防止します。ストレージ・サーバーがオフラインになる理由としては、ストレージ・サーバーに対するローリング・パッチ適用などの計画メンテナンスや、ストレージ・サーバーの障害があります。

» ディスク障害発生後のディスク・セクター破損：ディスク・セクター破損の可能性があり、計画保守またはディスク障害のためにパートナー・ストレージ・ディスクが使用できない場合のデータ損失を防止します。

『Oracle Exadata Storage Server Software ユーザーズ・ガイド』の「最大可用性を実現するOracle ASM の概要」の項にあるように、高冗長性ディスク・グループには 3 つ以上のストレージ・セルが必要になります。また、Exadata Software 12.1.2.3.0 以降では、各データベース・サーバーに 2 つの追加のクォーラム・ディスクを作成し、ストレージ・サーバーが 4 つ以下の高冗長性ディスク・グループ内に Oracle 投票ファイルを配置できます。また、ディスク障害やセル・ストレージ障害の場合、Oracle ASM は、十分な空き領域があれば、自動的にリバランスして冗長性を回復します。後述の exachk による Exadata ヘルス・チェックでは、Oracle ASM に最小限の空き領域があるかどうか、構成がチェックされます。

» 注：デフォルトの Exadata インストール推奨設定は、DATA 高冗長性と RECO 標準冗長性です。この構成により、DATA 内に存在する基本的なデータベース・ファイルに対して最善のデータ保護と冗長性を実現すると同時に、十分な利用可能容量を確保できます。RECO ディスク・グループが失われた場合やアクセス不能になった場合には、高可用性を維持するために トレ ード オフ とし て追 加の 運用 上の ステッ プが 必要に なり ます 。『 Configuration Prerequisites and Operational Steps for Higher Availability for a RECO disk group or Fast Recovery Area Failure』（Doc ID 2059780.1）を参照してください。

3. アラート画面で、「Enable Email Alerting」または「Enable SNMP Alerting」を選択して、SMTP、SNMP、またはその両方でストレージ・サーバーとデータベース・サーバーのアラートを受信します。

4. Oracle Configuration Manager 画面で、「Enable Oracle Configuration Manager」を選択して、構成情報を収集し、その情報を Oracle リポジトリにアップロードします。これにより Oracle Support Services では、問題のトラブルシューティングの際に迅速に分析できます。

2 Oracle ASM 冗長レベルによっては、各ディスクのパートナー・ディスクが個別の Exadata ストレージ・セル内に配置されます。一方のディスクで

書込みエラーまたは読取りエラーが発生した場合、Oracle ASM は Partnership Status Table（PST）に問い合わせて、そのディスクの中でオンライン

のパートナーがあるかどうかを確認します。オフライン状態のパートナーが多すぎる場合は、Oracle ASM によりディスク・グループのマウント解除

が強制的に実行されます。ディスクのパートナー設定について、詳しくは『Oracle Automatic Storage Management 管理者ガイド』を参照してくだ

さい。

6 | Exadata Database Machine を使用した Oracle Maximum Availability Architecture のデプロイ

5. Auto ServiceRequest 画面で、「Enable Auto Service Request (ASR)」を選択して、特定の Oracle Exadata ラック・ハードウェアで障害が発生した場合にサービス・リクエストが自動的に開始されるようにします。

6. Grid Control Agent ページの Grid Control Agent 画面で、「Enable Oracle Enterprise Manager Grid Control Agent information」を選択します。

Oracle Exadata Deployment Assistant 構成ツールにより、Oracle Exadata Deployment Assistant デプロイメント・ツール（install.sh）で使用する構成ファイルが作成されます。納品時、Oracle システムのエンジニアは、ハードウェアを検証し、輸送中に破損したコンポーネントがないかどうか最終チェックを行います。次に、Oracle Advanced Support Services または Consulting Services が、指定された構成ファイルを使用して Oracle Exadata Deployment Assistant デプロイメント・ツールを実行します。

ハードウェアが到着してから数日以内に、次のようにシステムおよびデータベースの稼働準備が完全に整います。

» 仕様どおりに機能して動作することが検証されたハードウェア、InfiniBand ネットワーク、および Exadata ストレージ・セル。

» My Oracle Support Note 888828.1 で説明されている、推奨およびサポートされるオペレーティング・システム、ファームウェア、Oracle のソフトウェアおよびパッチ。Oracle Advanced Support Services または Consulting Services により、My Oracle Support Note 1270094.1 での説明に従って追加の修正プログラムが適用される可能性があります。Support Note に最近変更が加えられた場合には、若干異なる可能性もあります。

» Oracle ASM のディスク・グループ DATA、RECO、および DBFS で構成された Exadata ストレージ・グリッド。DATA および RECO ディスク・グループは、Oracle Exadata Deployment Assistantで事前に選択した Oracle ASM 冗長性オプションを使用して構成されます。Exadata VM クラスタを作成する場合には、ディスク・グループがさらに作成されます。

» データベースと Exadata ストレージ・サーバー間のすべての通信で使用する InfiniBand ネットワークを含むネットワーク・インフラストラクチャ。このネットワークは、クライアントと管理アクセスの両方で構成されます。

» My Oracle Support Note 757552.1 で説明されている Exadata MAA の構成設定を使用して事前に構成 さ れ た 、 Oracle Real Application Clusters （ Oracle RAC ） デ ー タ ベ ー ス と Oracle Grid Infrastructure。Exadata 仮想システム（Exadata OVM）をデプロイする場合は、各 OVM RAC クラスタ（ユーザー・ドメイン）は一意の管理ドメインに配置されます。Oracle Exadata Deployment Assistant により、デフォルトでこのように設定されます。デプロイメント後に新しい Exadata OVM クラスタを作成する場合は、Exadata のメンテナンス・ガイドにある追加の指示を参照してください。

» Oracle Exadata Deployment Assistant 構成ツールで対応するオプションを選択した場合は、ストレージ・サーバーとデータベース・サーバーの電子メール・アラート、Oracle Enterprise Manager Grid Control（初期構成ファイル）、Auto Service Request、および Oracle Configuration Manager 基本設定が Exadata Database Machine で自動的に構成されます。

7 | Exadata Database Machine を使用した Oracle Maximum Availability Architecture のデプロイ

Exadata固有のHAの利点

Exadata は、FAN、PDU、バッテリ、スイッチ、ディスク、フラッシュ、データベース・サーバー、マザーボード、DIMM などのあらゆるハードウェア障害の発生時に、アプリケーションおよびデータベースのエンド・ツー・エンドの可用性を実現および達成するように設計および事前構成されています。毎日実行される数百回の統合 HA テストを含む広範なエンジニアリング・テストと統合テストにより、システムのあらゆる面が検証されます。次の項では、Exadata に固有の HA 特性について説明します。

ハードウェア・コンポーネント

ハードウェアとコンポーネントに関する次の冗長性は、ExadataSL6、X6-2、X5-2、X4-2、X3-2、X3-8、X2-2、X4-8、X3-8、X2-8、および以降の Exadata 世代のすべてのモデルに共通です。

冗長データベース・サーバー

Exadata は、業界標準の Oracle Database サーバーが複数事前構成された状態でお客様サイトに届けられ、各サーバーでは Database 12c Release 1（12.1）、Oracle Database 12c Release 2（12.2）、または Oracle Database 11g Release 2（11.2）と Oracle RAC が実行されます。オラクルのエンジニアリング・チームとテスト・チームが、高可用性とスケーラビリティを実現するようにファームウェア、ソフトウェア、ハードウェアの構成をチューニングして事前構成します。データベース・サーバーはクラスタ化されており、高帯域幅で待機時間が短い InfiniBand ネットワーク経由で各サーバーと通信します。この構成により、データベース・サーバーや Oracle RAC インスタンスの障害による影響を最小限に抑えられるため、アプリケーションの障害耐性が強くなっています。

これまでは、データベース・ノードの障害によって一般的なデータベース・ノードが排除されると、データベース・ノード停止の宣言前であっても、CSS misscount で待機することになりました（ほとんどのシステムにおいて、デフォルトで 30 または 60 秒）。その間はクラスタ全体がフリーズし、アプリケーションが一時停止します。Grid Infrastructure 12.1.0.2 BP7 以降、および Exadata においてのみ、超高速で安全なノード排除によって一時停止の時間を 2 秒未満に短縮するため、InfiniBand（IB）サブネット・マネージャと IB ネットワークが利用されます。

図 2 に示すテスト結果を見ると、4 ノードの RAC Exadata 構成の Exadata ノード障害中にアプリケーションの一時停止は発生していませんが、アプリケーションのスループットが低下し、応答時間が 2 秒増加しているのが分かります。Exadata 以外のシステムの場合、お客様は、30 秒間または60 秒間のアプリケーションの一時停止を観測することになります。

さらに、Exadata の広帯域低遅延のフラッシュおよびストレージ GRID を使用する場合、お客様は、データベースの初期化パラメータ FAST_START_MTTR_TARGET をチューニングして、インスタンスとノード障害全体によるアプリケーションの一時停止時間をさらに短縮することができます。データベースのパラメータに変更を加える場合は、本番システムで変更する前に、同等のテスト・システムでパフォーマンスへの影響を評価することを推奨します。

8 | Exadata Database Machine を使用した Oracle Maximum Availability Architecture のデプロイ

図2：データベース・ノードの電源障害

冗長ストレージ

データベース・サーバーのディスク・ドライブ、Exadata Storage Server のディスク・ドライブ、Exadata Storage Server のフラッシュ、Oracle Exadata Storage Server（Exadata セル）などのExadata ストレージ・コンポーネントは、すべて冗長性を備えています。Exadata Storage Server はOracle ASM によって管理され、ハード・ディスク、フラッシュ・ディスク、フラッシュ・カード、およびストレージ・サーバー全体の障害に対処できるように構成されています。Exadata Storage Server は、ネットワークからアクセス可能なストレージ・デバイスで、Oracle Exadata Storage Server ソフトウェアが事前にインストールされています。データベースのデータ・ブロックとメタデータはセル全体でミラー化されており、Exadata ディスクまたは Exadata セルでの障害によってデータや可用性が失われることのないようにしています。ディスク・ドライブはホット・プラグ可能です。

Exadata ストレージのハードウェアとソフトウェアは、ストレージ障害時のアプリケーションの一時停止時間が最小限に抑えられるように設計されており、Exadata HARD と Exadata ディスク・スクラビングによって広範なデータ保護機能を提供します。他のプラットフォームでの従来のストレージ障害と比較すると、ディスク、フラッシュ、またはストレージ・サーバーの障害でのExadata のアプリケーションの影響は著しく低く抑えられています。たとえば、Exadata ストレージの障害によるアプリケーションのブラックアウトおよび一時停止の時間は 1 秒未満であるのに対し、Oracle データベースとアプリケーションが実行されている他のストレージの場合は数秒から数分になっています。

9 | Exadata Database Machine を使用した Oracle Maximum Availability Architecture のデプロイ

図3：ストレージ障害

冗長接続

デュアルポートの Quad Data Rate（QDR）Host Channel Adapter（HCA）を使用した冗長なInfiniBand ネットワーク接続と冗長スイッチが事前に構成されています。Linux チャネル・ボンディングを使用したデータベース・サーバーへのクライアント・アクセスのためにネットワークの冗長性を構成することが推奨されており、デプロイメント時に構成できます。

Exadata システム内部でのネットワーク・タイプの障害の場合、観測されるアプリケーションの一時停止時間は、通常、0 秒から 10 秒未満です。

冗長電源

Exadata では、冗長型の配電ユニット（PDU）を使用して高可用性を実現しています。PDU では個別の電源を使用でき、次の機器に対する冗長電源を提供します。

» Oracle Database ノード

» Exadata ストレージ・セル

» InfiniBand スイッチ

» Cisco ネットワーク・スイッチ

Oracle Database ノード、Exadata ストレージ・セル、InfiniBand スイッチおよび Cisco スイッチの電源は、すべてホットスワップに対応しています。

ソフトウェア・コンポーネント：

次に示すのは標準の Oracle ソフトウェア・コンポーネントで、Exadata Database Machine 向けに明示的に最適化および検証されています。

ファームウェアとオペレーティング・システム

すべてのデータベースと Exadata ストレージ・サーバーには、検証済みのファームウェアとオペレーティング・システム・ソフトウェアがパッケージ化されて事前にインストールされています。

10 | Exadata Database Machine を使用した Oracle Maximum Availability Architecture のデプロイ

データベース・サーバー層

Grid Infrastructure（Oracle Clusterware と Oracle ASM）と Oracle RAC ソフトウェアがインストールされており、推奨されるソフトウェア・バージョンのパッチがデプロイメント時に適用されているため、アプリケーションではインスタンス障害やノード障害に自動的に対処でき、アプリケーションの一時停止がほとんど、またはまったく発生しません。付録 1 で説明されているように、Grid Infrastructure のすべてのパッチとデータベースのほとんどのパッチはローリング方式で適用できます。

ストレージ層

» ハード・ディスク、フラッシュ・ディスク、フラッシュ・カード、Exadata セルの障害に対処

» ローリング方式でソフトウェアの変更を適用

» Exadata ストレージ・セルには Oracle Hardware Assisted Resilient Data（Oracle HARD）が搭載されているため、物理ディスクに書き込まれる前に、データ・ブロック・アドレス、チェックサム、マジック・ナンバーなどの Oracle ブロック・データ構造を独自のレベルで検証できます。Exadata による HARD 検証は自動的に実行されます（チェックサム検証を有効にするには、DB_BLOCK_CHECKSUM を設定する必要があります）。HARD チェックでは、Oracle ASM ディスクのリバランス操作やディスク障害を含むすべてのケースが透過的に処理されます。

高パフォーマンス

Oracle Development チームは、OLTP アプリケーションとデータウェアハウス・アプリケーションのパフォーマンスを高めることに焦点を合わせており、Exadata に設定されるデフォルト構成を最適化してきました。場合によっては、Exadata システムの世代が異なると、デフォルト設定も異なります。これらの設定は、オラクル・ラボと本番デプロイメントの両方においてさまざまなワークロードで実施された大規模なパフォーマンス・テストの結果です。

Exadata SL6 には業界をリードする SPARC M7 プロセッサが使用されており、このプロセッサはExadata SL6 をもっとも高速かつセキュアな Exadata Database Machine としている独自の Software in Silicon 機能を搭載しています。また、検証済みのデフォルト構成に対しては、Oracle RAC、Oracle ASM、Oracle Recovery Manager、Oracle Flashback、Data Guard を含む総合的な Oracle MAA 環境での障害注入テストも実施されています。

その他のExadata HA機能と利点

Exadata 固有の HA 機能と利点の概要については、表 1 を参照してください。これらの機能について詳しくは、『Oracle Exadata Database Machine システム概要』、『Oracle Exadata Database Machine メンテナンス・ガイド』、『Oracle Exadata Storage Server Software ユーザーズ・ガイド』などの Exadata ドキュメントを参照してください。

11 | Exadata Database Machine を使用した Oracle Maximum Availability Architecture のデプロイ

表1：HAの機能と利点

領域 機能 HA の利点 依存関係

HA の一時停止

時間の短縮 短時間でのノード検出とフェイ

ルオーバー ノード障害検出時間が 60 秒前後からわずか

2 秒以下に短縮されます。 Grid Infrastructure 12.1.0.2 BP7 以上

アプリケーションへの影響が少

ない状態で Exadata ストレージ

の障害を自動検出

自動検出とリバランス。アプリケーションへ

の影響は 1～2 秒の遅延 Exadata ソフトウェアのリリースごとに継続

的に改善。

アプリケーションへの影響が少

ない状態で Exadata ネットワー

クの障害を自動検出

自動検出とフェイルオーバー。

アプリケーションへの影響は 0～5 秒の遅延

Exadata ソフトウェアのリリースごとに継続

的に改善

インスタンス障害での一時停止

時間を短縮 Exadata のフラッシュとストレージ GRID は

帯域幅が広く待機時間が短いため、データ

ベース初期化パラメータ

FAST_START_MTTR_TARGETを短く設定

し、アプリケーションに影響を与えずに、イ

ンスタンス障害やノード障害が発生した場合

のアプリケーションの一時停止時間を短縮で

きます。

Exadata データベース・ソフトウェアのリ

リースごとに継続的に改善

3 台以上のストレージ・セルに

よる、Oracle ファイルおよび

クラスタウェア投票ファイル用

の高冗長性の利点

5 台未満のストレージ・サーバーで Oracle投票ファイルを高冗長性ディスク・グループ

に配置し、Oracle データベースと Oracle ク

ラスタの両方でデータ保護と冗長性の利点を

完全に活用できます。

高冗長性ディスク・グループを作成すると、

Oracle Exadata デプロイメントによって自

動的に実行されます。

Exadata 12.1.2.3.0 以降

AD/ゾーンの 障害

ストレッチ・クラスタ Exadata 上での Oracle 12.2 Extended Clusters により、局所的なサイト障害の場合

も可用性が保たれ、HA の利点を拡張して活

用できます。これは、分離サイトや可用性ド

メイン（独立した電源、冷却、リソースを備

える“防火セル”と呼ばれることがある）が、

1 つのデータセンター内または 2 つの都市に

分かれたデータセンター間にある場合に特に

有益です。Oracle Extended ClusterをExadata で適切に構成すれば、アプリケー

ションとデータベースは完全なサイト障害に

も耐えられます。また、その他の Exadataストレージ・セルや Exadata データベー

ス・サーバーの障害にも持ちこたえることが

できます。

Exadata 12.2.1.1.0 以降

データ保護とセ

キュリティ ハード・ディスクの自動的な スクラブと修復

ハード・ディスクがアイドル状態のときに、

ハード・ディスクの検査と修復が自動的かつ

定期的に実行されます。ハード・ディスクで

問題のあるセクターが見つかると、Exadataから Oracle ASM に対して自動的にリクエス

トが送信され、別のミラー・コピーからの

データ読込みによって問題のあるセクターが

修復されます。ハード・ディスク・スクラブ

はデフォルトで 2 週おきに実行されます。

アダプティブ・スクラビングによって、問題

のあるセクターが検出された場合のディス

ク・スクラビングの頻度を自動的に変更でき

ます。現在のスクラビング・ジョブでハー

ド・ディスクに問題のあるセクターが見つ

かった場合は、Oracle Exadata Storage Server ソフトウェアによって、そのディス

クのフォローアップ・スクラビング・ジョブ

が 1 週間以内にスケジューリングされます。

そのディスクのスクラビング・ジョブで問題

のあるセクターが見つからない場合は、

hardDiskScrubInterval 属性で指定されている

スクラビング・スケジュールにスケジュール

がフォールバックされます。

Database および GI 11.2 または 12c Exadata 11.2.3.3 以降

Exadata 12.1.2.3.0 以降

12 | Exadata Database Machine を使用した Oracle Maximum Availability Architecture のデプロイ

領域 機能 HA の利点 依存関係

Exadata H.A.R.D. Exadata Hardware Assisted Resilient Data（HARD）により、物理ディスクに書き込ま

れる前に、データ・ブロック・アドレス、

チェックサム、マジック・ナンバーなどの

Oracle ブロック・データ構造が独自のレベ

ルで検証されます。Exadata による HARD検証は自動的に実行されます。HARD チェッ

クでは、Oracle ASM ディスクのリバランス

操作やディスク障害を含むすべてのケースが

透過的に処理されます。

DB_BLOCK_CHEKSUM =

TYPICAL または TRUE（すべての Exadata HARD チェックを有効にする場合）。

Software in Silicon： メモリ保護

SPARC M7 の Security in Silicon 機能は、プ

ロセッサによってメモリ参照が行われるたび

に、パフォーマンス・オーバーヘッドを生じ

させずに常に検証チェックを実行します。

Security in Silicon は、悪意のあるソフト

ウェアによるバッファ・オーバーフロー攻撃

を検出するのに役立ち、不正なメモリ・アク

セスを Oracle Database などのアプリケー

ションによって識別および防止することも可

能になります。

Exadata SL 12.1.2.4.0 以降

セキュア消去 データベース・サーバーとストレージ・サー

バーの両方のデータをすべて消去し、

InfiniBandスイッチ、イーサネット・スイッ

チ、および配電ユニットをデフォルト設定に

戻します。Oracle Exadataマシンを廃棄また

は用途変更する場合に、この機能を使用しま

す。セキュア消去を使用すると、マシンのあ

らゆるコンポーネントのデータとメタデータ

のすべてのトレースが完全に消去されます。

Exadata 12.2.1.1.0 以降

サービス品質 読取り操作の I/O 待機時間の制限

読取り I/O の待機時間が予想より大幅に長い

場合に、読取り I/O 操作が別のセルにリダイ

レクトされます。このため、デバイス・ドラ

イバ、コントローラ、ファームウェアの問

題、障害があるまたは停止しているディスク

やフラッシュ、問題のあるストレージ・セク

ターなどによる、読取り I/O のハングや大幅

な速度低下に対応できます。

Exadata 11.2.3.3.1 以降の Oracle Databaseおよび GI 11.2.0.4 BP8 以降

書込み操作の I/O 待機時間の制限

待機時間の長い書込み I/O 操作が、別の正常

なフラッシュ・デバイスにリダイレクトされ

ます。このため、書込み I/O のハングや大幅

な速度低下に対応できます。

Exadata 12.1.2.1.0 以降の Oracle Databaseおよび GI 11.2.0.4 BP8 以降

ライトバック・フラッシュ・キャッシュ が有効

Exadata セルの I/O タイムアウ

トのしきい値 I/Oタイムアウトのしきい値を設定できるた

め、長時間実行されている I/Oをキャンセルし

て別の有効なミラー・コピーにリダイレクトで

きます。

Exadata 11.2.3.3.1以降の Oracle Databaseお

よび GI 11.2.0.4 BP8以降

予測障害のあるディスク・ド

ロップによるヘルス要素 Exadataセルでハード・ディスクが予測障害状

態になると、Exadataによって Oracle ASMリ

バランスが自動的にトリガーされ、ディスクか

らデータが再配置されます。Oracle ASMでは

まず正常なミラーからの読取りをリバランスし

て、冗長性をリストアします。他のすべてのミ

ラーが使用できない状態の場合は、Oracle ASMリバランスによって、障害発生が予測さ

れたディスクからデータが読み取られます。こ

のため、可能な場合は障害発生が予測される

ディスクからのリバランス読取りを防ぎ、リバ

ランス・プロセス中のデータ冗長性を最大限に

保ちながら、最適な状態でリバランスを実行し

ます。

Exadata Storage 11.2.3.3 以降

13 | Exadata Database Machine を使用した Oracle Maximum Availability Architecture のデプロイ

領域 機能 HA の利点 依存関係

低パフォーマンス・ディスクの

識別と自動除去 作業はすべてのディスクに対して均等に分散

されるため、低パフォーマンス・ディスクは

すべてのディスクのパフォーマンスに影響し

ます。低パフォーマンスのディスクが検出さ

れた場合は、アクティブな構成から除外され

ます。Exadata によって、内部パフォーマン

ス・テストが実行されます。ディスクの問題

が一時的なものでありテストに合格した場合

は、ディスクが構成に戻されます。ディスク

がテストに合格せず、低パフォーマンスの

マークが付けられた場合は、ディスク交換の

ため、自動サービス・リクエスト（ASR）の

サービス・リクエストが開始されます。この

機能は、ハード・ディスクとフラッシュ・

ディスクの両方に適用されます。

Exadata Storage 11.2.3.2 以降

I/O リソース管理 I/O Resource Management（IORM）によ

り、プラガブル・データベースまたは物理

データベースごとに、ディスクおよびフラッ

シュの IOPS、およびフラッシュ・キャッ

シュの最小および最大フラッシュ・キャッ

シュ・サイズを管理します。

フラッシュおよびフラッシュ・キャッシュ領

域のリソース管理用の I/O リソース管理の場

合：

Exadata Storage 12.1.2.1.0 以上および

Exadata X2 世代以上のハードウェア

ネットワーク・リソース管理 ネットワーク・リソース管理では、

InfiniBand ファブリックにより重要なデータ

ベース・ネットワーク・メッセージに自動的

かつ透過的に優先順位を付け、待機時間が重

要とされる操作の応答時間が短縮されるよう

にします。優先順位付けは、InfiniBand ファ

ブリック全体を通して確実に実行されるよう

にするため、データベース、データベースの

InfiniBand アダプタ、Exadata ソフトウェ

ア、Exadata InfiniBand アダプタ、および

InfiniBand スイッチで実装されます。

Oracle RAC キャッシュ・フュージョン・

メッセージなどの待機時間の影響を受けやす

いメッセージは、バッチ、レポート、および

バックアップ・メッセージより優先されま

す。トランザクション処理の待機時間を短く

するために、ログ・ファイルの書込み操作に

もっとも高い優先順位が与えられます。

Exadata Storage 11.2.3.3

Oracle Database 11.2.0.4 以上

IB スイッチ・ファームウェア・リリース

2.1.3-4 以上

領域 機能 HA の利点 依存関係

セル間リバランスによるフラッ

シュ・キャッシュ内の値の保持 ハード・ディスクで予測障害または実際の障

害が発生し、データをそこからリバランスし

て取り出すことが必要になると、このハー

ド・ディスクに存在するデータの一部がフ

ラッシュ・ディスクにキャッシュされるた

め、短い待機時間と広い帯域幅でこのデータ

にアクセスできるようになります。アプリ

ケーションの現在のパフォーマンス SLA を

維持するには、セル間オフロード・リバラン

ス時のハード・ディスク上のさまざまな領域

のキャッシュ・ステータスを尊重しつつ、

データをリバランスすることが重要です。

セル間リバランス機能により、以前のリリー

スと比較して、ディスク障害やディスクの交

換によるリバランス実行中のアプリケーショ

ン・パフォーマンスが著しく向上します。

Exadata Storage 12.1.2.2.0 以上

Oracle Database および Grid Infrastructure 12.10.2 BP11 以上

パフォーマンス Exadata Smart Flash Logging Exadata Smart Flash Logging により、特に

OLTP ワークロードなどのデータベース・パ

フォーマンスにとって重要な REDO書込み

の待機時間が短くなるようにします。待機時

間を短くするためにハード・ディスクとフ

ラッシュの両方に REDOが書き込まれま

す。この場合のフラッシュは、REDOロ

グ・データの一時ストア（キャッシュ）とし

て使用され、書込みの待機時間が一貫して短

く保たれ、コストの高い書込み異常値が防止

されます。

Exadata Storage 11.2.2.4 以上

EFは Exadata X5世代以上でのみ使用可能で

す。

14 | Exadata Database Machine を使用した Oracle Maximum Availability Architecture のデプロイ

フラッシュ・デバイスは動作速度が時折遅く

なることがあるため、Exadata Smart Flash Logging は Extreme Flash（EF）構成でも必

要とされます。EFの異常値を防止するた

め、複数のフラッシュ・ドライブを選択して

書き込む場合には、REDO書込みを慎重に

選択してください。

アクティブなボンディング・

ネットワーク Exadata サーバーは、InfiniBand カードの両

方のポートでアクティブなボンディングによ

り構成できます。アクティブなボンディング

により、以前のリリースのアクティブなパッ

シブ・ボンディングと比較して、ネットワー

クの帯域幅を大幅に広げることができます。

これは、ネットワーク・トラフィックの送信

時に InfiniBand の両方のポートが同時に使用

されるからです。

Exadata X4 世代以上のハードウェア

Exadata Storage 11.2.3.3 以上

Exadata Smart Write Back Flash Cache

Exadata Smart Flash Cache では、頻繁にア

クセスされるデータが高速ソリッドステー

ト・ストレージに透過的かつインテリジェン

トにキャッシュされます。

Exadata Storage 11.2.3.2 以上

セルの再起動後の永続性 これにより、データベースの問合せおよび書

込みの応答時間やスループットが改善されま

す。フラッシュ・キャッシュで問題が発生す

ると、その操作は、フラッシュ上のミラー化

されたコピーに透過的にフェイルオーバーし

ます。ユーザーの介入は不要です。Exadata Smart Flash Cache は、停電、シャットダウ

ン操作、セルの再起動などがあっても永続性

を保ちます。フラッシュ・キャッシュのデー

タは、セルの再起動後にディスクから読み取

ることによって再び取り込まれることはあり

ません。サーバーからの書込み操作は、フ

ラッシュ・キャッシュに対して直接行われま

す。これにより、ディスクでのデータベース

I/O 操作の数が削減されます。

領域 機能 HA の利点 依存関係

Data Guard の REDO Applyによりパフォーマンスが 6 倍以上

に向上

Data Guard の REDO Applyのパフォーマン

スは、Exadata Smart Flash Cache および

I/O とネットワークの全体的な帯域幅の恩恵

を享受しており、OLTP ワークロードの場合

に観測される REDO Applyの速度は最大で

300MB/秒に、バッチ帯域幅とロード帯域幅

の場合は最大で 800MB/秒に到達します。従

来のストレージのボトルネックはネットワー

クやストレージ I/O の帯域幅となっており、

このため REDO Applyのパフォーマンスは

一般に 50MB/秒未満に抑えられてきまし

た。

速度は、社内の MAA テストとお客様の本番

環境で観測された値です。速度は、データ

ベースの統合量と使用可能なシステム帯域幅

に応じて異なります。

領域 機能 HA の利点 依存関係

管理 Exadata ストレージ・セル、

Exadata データベース・ノー

ド、および InfiniBand スイッチ

へのパッチ適用

Patchmgrユーティリティ（および

dbnodeupdate.sh）により、オンラインとオ

フラインの両方の状態で、Exadata ストレー

ジ・セル、Exadata データベース・ノード、

および InfiniBand スイッチにパッチを適用す

る場合のパッチ適用処理を調整および自動化

できます。

Patchmgr は Exadata ストレージ・セルをサ

ポート dbnodeupdate.sh は Exadata データベー

ス・ノードをサポート Patchmgrは、Oracle Exadata Storage 11.2.3.3.0 以上で InfiniBand スイッチをサ

ポートするように拡張

Patchmgrは、Exadata Storage 12.1.2.2.0 ソ

フトウェアで Exadata データベース・ノー

ドのパッチ適用オーケストレーションをサ

ポートするように拡張

15 | Exadata Database Machine を使用した Oracle Maximum Availability Architecture のデプロイ

フラッシュおよびディスクのラ

イフ・サイクル管理のアラート ディスク障害と交換による Oracle ASM リバ

ランス操作を監視します。管理サーバーは、

リバランス操作が正常に完了した場合、また

はエラーが発生した場合にアラートを送信し

ます。ステータス管理を簡素化します。

Oracle Database リリース 12.1.0.2 BP4 以

降、Oracle Exadata Storage Server ソフト

ウェア・リリース 12.1.2.1.0 以上。

セル・アラートの概要 Oracle Exadata Storage Server ソフトウェ

アは、Exadata セル上のすべての未解決のア

ラートの概要を定期的に電子メールで送信し

ます。未解決アラートの電子メール・メッ

セージには、セルでの未解決の問題すべての

概要が簡潔に記載されています。

Oracle Exadata Storage Server ソフトウェ

ア・リリース 11.2.3.3.0 以上

ストレージ・サーバー・ディス

クを削除する場合の LED 通知 ストレージ・サーバーのディスクの削除が必

要になると、サーバーの青い LED 灯が点灯

します。青い LED 灯により、メンテナンス

が必要なサーバーのディスクを見分けやすく

しています。

Oracle Exadata Storage Server ソフトウェ

ア・リリース 11.2.3.2.0 以上

交換するハード・ディスク の削除

管理者が Exadata セルからハード・ディス

クを削除するための簡単なコマンド。このコ

マンドでは、ディスク・グループが強制的に

マウント解除されることなく、そのハード・

ディスク上のグリッド・ディスクを Oracle ASM から安全にオフラインにすることがで

きるかどうかをチェックします。確認できる

と、簡単に交換できるように、ディスク上の

サービス LED が点灯します。

Oracle Exadata Storage Server ソフトウェ

ア・リリース 11.2.3.3.0 以上

交換する BBU の削除 管理者がオンラインで BBU（バッテリ・

バックアップ・ユニット）交換を開始するた

めの簡単なコマンド。このコマンドにより、

コントローラがライトスルー・キャッシュに

切り替えられ、BBU の交換中に電源が失わ

れてもデータ損失が発生しないように守られ

ます。

Exadata X3 および X4 世代のみ。Exadata X5 世代のディスク・コントローラ HBA に

は、BBU の代わりに、スーパーキャパシ

タ・ベースの 1GB ライト・キャッシュが搭

載されています。

Oracle Exadata Storage Server ソフトウェ

ア・リリース 11.2.3.3.0 以上

偽のディスク障害の最小化また

は解消 I/O は自動的に正常なドライブにリダイレク

トされます。対象の正常ではないディスクで

は、電源が入れ直されます。そのドライブ

は、正常な状態に戻ると、再び有効にされ、

再同期化されます。電源を入れ直しても正常

な状態に戻らない場合、そのドライブは削除

されます。誤検知のディスク障害を解消し、

データの冗長性が保持されるようにして、運

用上の管理の手間を減らし、削除リバランス

を防止します。

シャーシでの電源の入れ直しをサポートする

必要があるため、X5 Storage 以上 大容量ハード・ディスクと Extreme Flash SSD にのみ関連

Exadata AWR とアクティブ・

レポート AWR レポートの Exadata フラッシュ・

キャッシュ・パフォーマンス統計セクション

の内容が拡張されています。1）Columnarフラッシュ・キャッシュと Keep キャッシュ

のサポートが追加されました。2）Exadataストレージ・セルの統計情報をデータベース

の統計情報と一緒に要約したセクションがフ

ラッシュ・キャッシュ・パフォーマンス・サ

マリーに追加されました。

AWR レポートの Exadata フラッシュ・ログ

統計セクションに、ディスクおよびフラッ

シュへの最初の書込みに関する統計情報が含

められるようになりました。

Oracle Exadata Storage Server ソフトウェ

ア・リリース 12.1.2.2.0 以上。

Oracle Database リリース 12.1.0.2 バンド

ル・パッチ 11 以降

デプロイメント後のExadata MAA構成

オラクルは、以前の Oracle 構成を利用した初期化設定を使用しないように強く推奨しています。はじめに Exadata で提供されたデフォルト構成を使用してから、必要に応じてチューニングを行ってください。ほとんどのお客様は、SGA 関連の設定を除いて、デプロイメント後にデータベースのパラメータをチューニングする必要性をあまり感じません。統合用にデータベースを追加する場合は、Oracle MAA のホワイト・ペーパー『データベース統合のための高可用性ベスト・プラクティ

16 | Exadata Database Machine を使用した Oracle Maximum Availability Architecture のデプロイ

ス』3または『Exadata Database Machine 上でのデータベース統合に関するベスト・プラクティス』4の説明に従って、システム・リソースを調整する必要があります。

以降の項では、Oracle MAA 構成でのベスト・プラクティスの概要を示します。詳しくは、Oracleのドキュメント『Oracle Database 高可用性ベスト・プラクティス 11g』5または『Oracle Database高可用性ベスト・プラクティス 12c』6を参照してください。以下の項では、ベスト・プラクティス・ドキュメントに含まれる詳細の概要を示します。

データベースのアーカイブ・ログ・モードと強制ロギングの有効化

アーカイブ・ログ・モードとデータベース強制ロギングは、すべての変更を REDO 内に取得し、データベース・リカバリ処理中に適用するために欠かせない前提条件です。データベースのアーカイブ・ロギングとデータベースの強制ロギングを有効にして、NOLLOGGING 処理の発生を防止します。

SQL> ALTER DATABASE ARCHIVELOG;

SQL> ALTER DATABASE FORCE LOGGING;

別の表領域へのリカバリを必要としないデータを分離できる場合、任意で、表領域レベルのロギング属性を設定することができます。詳しくは、テクニカル・ホワイト・ペーパー『Oracle Data Guard：Oracle Exadata Database Machine のディザスタ・リカバリ』7の「ETL 操作中のオーバーヘッドと REDO 量の削減」を参照してください。

ファスト・リカバリ領域

ファスト・リカバリ領域（FRA）は Oracle 管理のディスク領域であり、バックアップ・ファイルとリカバリ・ファイル用の一元管理されたディスク・ロケーションです。

次の 2 つのデータベース初期化パラメータを設定することで、FRA が定義されます。

DB_RECOVERY_FILE_DEST パラメータは、ファスト・リカバリ領域の場所を指定します。RECOディスク・グループを使用します。また、最良のパフォーマンスを得るには、外部ストレージではなく Exadata ストレージ・グリッドを利用することを推奨します。

DB_RECOVERY_FILE_DEST_SIZE パラメータは、リカバリ領域に作成されたデータベース・リカバリ・ファイルが使用する合計領域のハード・リミットをバイト単位で指定します。

3 https://www.oracle.com/technetwork/jp/database/availability/maa-consolidation-2186395-ja.pdf 4 https://www.oracle.com/technetwork/jp/database/features/availability/exadata-consolidation-522500-ja.pdf 5 https://docs.oracle.com/cd/E16338_01/server.112/b65088/toc.htm 6 https://docs.oracle.com/cd/E57425_01/121/HABPT/toc.htm 7 https://www.oracle.com/technetwork/jp/database/features/availability/maa-wp-dr-dbm-130065-ja.pdf

17 | Exadata Database Machine を使用した Oracle Maximum Availability Architecture のデプロイ

Oracleフラッシュバック・テクノロジー

Oracle フラッシュバック・テクノロジーにより、おもに人為的エラーによって引き起こされるデータベースの論理的破損を修復する高速なポイント・イン・タイム・リカバリを実現できます。Oracle フラッシュバック・テクノロジー・スイートは、最適レベルの粒度での修復を可能にし、データ損失を最小限に抑えながら可能な限り最速でサービスの再開を実現します。以下の項では、各フラッシュバック・テクノロジーでのベスト・プラクティスの概要を示します。詳しくは、Oracle Database 高可用性のドキュメントの『Oracle Database 高可用性ベスト・プラクティス 11g』8または『Oracle Database 高可用性ベスト・プラクティス 12c』9で、「人為的エラーからのリカバリ」の項を参照してください。

フラッシュバック・データベース

フラッシュバック・データベースはフラッシュバック・ログを使用して、Oracle Database 全体を過去のある時点に'巻き戻し'ます。フラッシュバック・データベースは、論理的破損からの高速なポイント・イン・タイム・リカバリで使用されます。この破損は、おもに人為的エラーによって引き起こされ、本番データベースの広範囲に損傷を与えます。また、Data Guard によるフェイルオーバー後に、障害の発生したプライマリ・データベースを新しいスタンバイ・データベースとして素早く回復することで、コストと時間のかかるバックアップからのリストア処理を回避できます。詳しくは、『Oracle Data Guard 概要および管理 11g』10または『Oracle Data Guard 概要および管理12c』11で、「フラッシュバック・データベースを使用した障害が発生したプライマリのスタンバイ・データベースへの変換」を参照してください。また、高速フォールバックのため、ソフトウェアの変更を含む大きな変更を実施する際には、事前に Oracle Flashback Database 保証付きリストア・ポイントを作成します。

プライマリとスタンバイの両方のデータベースで次のコマンドを発行して、フラッシュバック・データベースを有効にします。

ALTER DATABASE FLASHBACK ON;

Oracle Database 11.2.0.3 以降のリリースには、大幅なパフォーマンス強化が施されており、プライマリ・データベースに対するフラッシュバック・ロギングの影響、特にロード処理と初期のフラッシュバック割当てへの影響が軽減されています。これにより、パフォーマンスへの影響を最小限に抑えて、OLTP アプリケーションとデータウェアハウス・アプリケーションでフラッシュバック・データベースを使用可能にしています。Oracle MAA テストでは、Oracle Database Release 11.2.0.2以降をフラッシュバック・データベースを有効にして使用して、ロード速度 3 TB/時を達成しています。この速度は、Exadata の広い I/O 帯域幅と、11.2.0.2 リリースでの最適化、および MAA 構成ベスト・プラクティスによって達成されたものです。

» フラッシュバック・データベースのベスト・プラクティスについては、My Oracle Support Note 565535.1 に記載されています。

» ローカル・エクステント管理表領域を使用します。

» ダイレクト・ロードを実行する前に、表を切り捨てる代わりにオブジェクトを再作成します。

8 https://docs.oracle.com/cd/E16338_01/server.112/b65088/outage.htm#i1010215 9 https://docs.oracle.com/cd/E57425_01/121/HABPT/outage.htm#i1010215 10 https://docs.oracle.com/cd/E16338_01/server.112/b56302/scenarios.htm#i1049997 11 https://docs.oracle.com/cd/E57425_01/121/SBYDB/scenarios.htm#GUID-1163448F-6B18-4A44-AA8D-7CDF0D1360FB

18 | Exadata Database Machine を使用した Oracle Maximum Availability Architecture のデプロイ

より粒度の高い修復のためのその他のOracleフラッシュバック・テクノロジー

よりきめ細かい修復レベルを実現するその他の Oracle フラッシュバック・テクノロジーとして、フラッシュバック問合せ、フラッシュバック・バージョン問合せ、フラッシュバック・トランザクション、フラッシュバック・トランザクション問合せ、フラッシュバック表、フラッシュバック・ドロップがあります。

フラッシュバック・ドロップでは、リサイクル・ビンを構成する必要があります。その他すべての機能で自動 UNDO 管理が使用されているため、必要な UNDO 保存期間（またはどれだけ過去にさかのぼってリカバリする必要があるか）を保証するには、十分なディスク領域を割り当てる必要があります。適切な UNDO 保存期間の保証を構成するには、以下を実施します。

» UNDO 保存期間（秒）を指定する際、UNDO_RETENTION 初期化パラメータを、Oracle のフラッシュバック処理が確実に実行されるのに必要な検出期間の少なくとも 2 倍に設定します。

Oracle Active Data Guard を使用して読取り専用ワークロードをスタンバイ・データベースにオフロードしている場合は、UNDO 保存期間の設定に関する追加のガイダンスについて、『Oracle Active Data Guard Oracle Data Guard 11g』12の 16 ページにある「ORA-01555 エラーの回避」の項の説明を参照してください。

バックアップ、リストア、リカバリ

Oracle Database のバックアップ・テクノロジー、および Oracle Zero Data Loss Recovery Appliance（Recovery Appliance）や ZFS Storage Appliance などのアプライアンスを利用して、Exadata Database Machine からデータベースのバックアップとリストアを行うことができます。

Recovery Appliance には、任意のプラットフォームで実行されている Oracle Database の包括的なバックアップ検証機能とデータ保護機能が搭載されており、データベースのバックアップとリカバリのための Oracle の戦略的ソリューションとなっています。Recovery Appliance を使用するお客様は、増分バックアップを永続的に使用し、重複排除、圧縮、および検証を Exadata データベース・ホストから Recovery Appliance にオフロードすることにより、バックアップ時間枠を短縮し、データベースへの影響を軽減できます。もっとも重要な点として、Recovery Appliance により、管理者が指定したリカバリ時間内の任意の時点に、確実かつ迅速にデータベースをリストアすることが可能になります。

ZFS Storage Appliance は、低コストのローカル・ディスク・バックアップおよびリストア・ソリューションであり、構成に応じて 10 TB/時以上の速度で Oracle データベースのバックアップとリストアを処理する能力を備えています。

12 http://www.oracle.com/technetwork/jp/database/maa-wp-11gr1-activedataguard-131362-ja.pdf

19 | Exadata Database Machine を使用した Oracle Maximum Availability Architecture のデプロイ

Exadata ストレージへの直接のバックアップおよびリストアでは、バックアップ/リストア速度が最速になります。次の一連の Oracle MAA テクニカル・ホワイト・ペーパーには、さらに詳しい情報が記載されています。

» 『Oracle Exadata Database Machine のバックアップおよびリストアの構成と運用のベスト・プラクティス』

» MAA Best Practices - Zero Data Loss Recovery Appliance

» 『Oracle Exadata Database Machine - バックアップとリカバリのサイジング：テープ・バックアップ』13

Oracle Data GuardとOracle Active Data Guard

Oracle Data Guard は Maximum Availability Architecture（MAA）で規定されたディザスタ・リカバリ・ソリューションであり、Exadata 上にあるミッション・クリティカル・データベースを保護します。また Data Guard を使用すると、障害によって予想外に本番データベースへ影響が及んだ場合にも可用性を維持し、計画メンテナンス中の停止時間を最小化できます。Oracle Data Guard はOracle Database の Enterprise Edition ライセンスに含まれています。

Oracle Active Data Guard には、基本的な Data Guard の機能を拡張する次の機能があります（Oracle Active Data Guard の拡張機能にアクセスするには、追加のライセンスが必要です）。

» フィジカル・スタンバイ・データベースは、プライマリから受信した更新を適用する間、読取り専用でオープンされます。これによって、読取り専用ワークロードを同期スタンバイ・データベースにオフロードできるため、プライマリ・データベースの能力とパフォーマンスを向上できます。ここで注目すべき点は、Active Data Guard のスタンバイ・データベースに対する読取り専用問合せでは、プライマリ・データベース上で実行されている問合せと同じ読取り一貫性が保証されるということです。その他の DBMS ベンダーから提供されている物理的なレプリケーション・ソリューションで、このレベルの読取り一貫性を実現できるものはありません。

» フィジカル・スタンバイ・データベースで Oracle RMAN のブロック・チェンジ・トラッキングを有効化できるため、プライマリ・データベースから高速増分バックアップをオフロードできます。

» Active Data Guard 構成では、自動ブロック修復機能が有効化されています。プライマリまたはスタンバイで物理的なブロック破損が検出されると、その他のデータベースの正しいコピーを使用して、アプリケーションやユーザーに影響を与えることなく自動的にその物理的なブロック破損が修復されます。

Data Guard は、次の理由から、Exadata MAA によって使用されるディザスタ・リカバリ・ソリューションとなっています。

» Data Guard の提供するデータ保護機能は、ストレージのリモート・ミラー化よりも優れています 14。

» Data Guard は非常に効率的な物理的レプリケーション・プロセスであり、すべての Oracle データ型と Oracle Database 機能をサポートしているため、論理的なレプリケーションよりも簡単で、パフォーマンスも優れています。

13 https://www.oracle.com/technetwork/jp/database/availability/maa-exadata-backup-methodology-495297-ja.pdf 14 https://www.oracle.com/technetwork/jp/database/availability/dataguardvsstoragemirroring-2082185-ja.pdf

20 | Exadata Database Machine を使用した Oracle Maximum Availability Architecture のデプロイ

» Data Guard により、Standby-First Patch Apply を使用して、停止時間を最小限に抑えながらリスクのない簡単な方法で Oracle のパッチをインストールできます。対象のパッチには、Oracle Exadata Database Machine にバンドルされたパッチ、Oracle Exadata Storage Server ソフトウェアのパッチ、Patch Set Updates（PSU）、Critical Patch Updates（CPU）、Patch Set Exception（PSE）などがあります。Standby-First Patch Apply は、My Oracle Support Note 1265700.1 で説明されているように、Oracle Database Enterprise Edition Release 2（11.2）リリース 11.2.0.1以降の認定ソフトウェア・パッチの場合にサポートされています。

» Data Guard は、Data Guard を使用したデータベース・ローリング・アップグレードまたはActive Data Guard 12c 以降の単純な DBM ROLLING 機能 15を使用して、新しい Oracle パッチ・セット（例：11.1.0.7～11.2.0.4 または 12c）または将来的な Oracle Database のリリースにアップグレードする場合の、データベースのローリング・アップグレードをサポートしています。

» Oracle Active Data Guard を使用すると、スタンバイ・システムがスタンバイ・ロールの間、プライマリ・システムから読取り専用ワークロードをオフロードでき、自動ブロック修復によって可用性が向上し、Active Data Guard Far Sync を使用してどのような距離でもデータ損失ゼロで保護できるため、スタンバイ・システムへの投資において高い投資回収率を実現できます。

Data Guard を構成する場合の最適なデータ保護と可用性を実現するための一連のベスト・プラクティスについて詳しくは、Oracle Database 11g16 、Oracle Database 12c17、または最新の Data Guard お よ び MAA ベ ス ト ・ プ ラ ク テ ィ ス の ド キ ュ メ ン ト（http://www.oracle.com/technetwork/jp/database/features/availability/oracle-database-maa-best-practices-155386-ja.html）を参照してください。

データ破損に対する包括的な保護

Oracle Database には包括的なデータベース認識型機能が搭載されており、重大な停止時間やデータ損失を招く可能性のあるデータ破損を防止するか、または自動的に検出および修正します。データ破損は、データ・ブロックが有効な Oracle Database 形式になっていないか、データ・ブロックのコンテンツが内部で一貫していない場合に発生します。ハードウェアまたはソフトウェアの欠陥の結果として破損する可能性もあります。

ここからは、データ破損に対して最適な保護を実現するため、Exadata MAA で推奨される初期化設定について説明します。推奨設定では、パフォーマンスへの影響を最小限に抑えることを優先したデフォルト設定と比べて、保護することにより重きが置かれています。推奨される初期化設定の値がデフォルト値と異なる場合は、推奨設定を手動で構成する必要があります。完全に保護するには、Data Guard スタンバイ・データベースが必須です。

オラクルは、My Oracle Support Note 1302539.1 の内容を読み、追加の背景情報、新しい破損の防止および検出に関するヒント、および潜在的なパフォーマンス・トレードオフに対する重要な見通しを理解しておくことを強く推奨します。このトレードオフを行うには、本番環境の稼働開始前に、アプリケーション・ワークロードのパフォーマンス・テストを実施する必要があります。

15 https://docs.oracle.com/cd/E57425_01/121/SBYDB/dbms_rolling_upgrades.htm#GUID-647FF758-5B53-44AE-BB80-B6FA506F09C7 16 https://docs.oracle.com/cd/E16338_01/server.112/b65088/config_dg.htm#CEGEADFC 17 https://docs.oracle.com/cd/E57425_01/121/HABPT/config_gg.htm#CEGJGDCI

21 | Exadata Database Machine を使用した Oracle Maximum Availability Architecture のデプロイ

プライマリ・データベースでの設定

» DB_BLOCK_CHECKSUM=FULL（Exadata でのデフォルトは TYPICAL）

» DB_BLOCK_CHECKING=FUL（Exadata でのデフォルトは OFF）

» 一部のアプリケーションでは、パフォーマンスへの影響があるため、プライマリに対してDB_BLOCK_CHECKING=MEDIUM または FULL を設定することはできません。さまざまな論理ブロック破損からスタンバイを保護するために、最小のプラクティスとして、フィジカル・スタンバイに対して DB_BLOCK_CHECKING=MEDIUM または FULL を設定することを推奨します。

» DB_LOST_WRITE_PROTECT=TYPICAL（Exadata でのデフォルトは TYPICAL）

» おもに人為的エラーによって引き起こされる論理的な破損に対して高速なポイント・イン・タイム・リカバリを実行し、フェイルオーバー後にプライマリ・データベースを素早く復旧するため、フラッシュバック・テクノロジーを有効化します。

Data Guardフィジカル・スタンバイ・データベースでの設定

» DB_BLOCK_CHECKSUM=FULL

» DB_BLOCK_CHECKING=FULL

» DB_LOST_WRITE_PROTECT=TYPICAL

» DB_BLOCK_CHECKING=FULL を設定することにより、スタンバイで最大限のデータ破損検出/防止が可能になりますが、REDO Apply のパフォーマンスは大幅に低下することがあります。REDO Apply のパフォーマンスは、特に Exadata のライトバック・フラッシュ・キャッシュを使用する場合に非常に高速であるため、ほとんどのお客様は DB_BLOCK_CHECKING=FULL または MEDIUMをスタンバイに設定することで、必要となる REDO Apply の速度と可用性のサービス・レベルを維持できます。

» おもに人為的エラーによって引き起こされる論理的な破損に対して高速なポイント・イン・タイム・リカバリを実行し、フェイルオーバー後にプライマリ・データベースを素早く復旧するため、フラッシュバック・テクノロジーを有効化します。

» Oracle Active Data Guard を使用して自動ブロック修復機能を有効化します（Data Guard 11.2 以降）。

» 追加のバックアップ検証で Oracle Recovery Appliance を使用します。

アプリケーション・クライアント - フェイルオーバーのベスト・プラクティス

計画外停止や計画メンテナンス作業によって本番データベースの可用性に影響が及ぶような状況において、高いアプリケーション可用性を達成できるのは、アプリケーションが透過的に対応し、フェイルオーバーを実行する場合に限られます。検出の自動化について詳しくは、Oracle Database 11g18または Oracle Database 12c19の『高可用性 Oracle Database でのクライアント・フェイルオーバーのベスト・プラクティス』を参照してください。

18 http://www.oracle.com/technetwork/database/features/availability/maa-wp-11gr2-client-failover-173305.pdf 19 https://www.oracle.com/technetwork/jp/database/availability/client-failover-2280805-ja.pdf

22 | Exadata Database Machine を使用した Oracle Maximum Availability Architecture のデプロイ

MAAのベスト・プラクティスの自動検証 - exachk

Exadata MAA のヘルス・チェック（exachk）では、Exadata のベスト・プラクティスが将来に向けて進化するのに伴って、現行の構成検証のプロセスが自動化されています。exachk は、新しい構成ベスト・プラクティス、ソフトウェアの推奨事項、および新しいすべての重要アラートに関する情報を反映して、四半期ごとに更新されます。My Oracle Support Note 1070954.1 から最新バージョンの exachk をダウンロードし、exachk レポートに記載されている構成、ソフトウェア、またはハードウェアの追加の推奨事項に従うことを推奨します。

Exadata OVM HA構成の追加の考慮事項

Exadata OVM 高可用性には、次のような追加の考慮事項があります。

1. ノード障害時の VIP とクライアントのフェイルオーバーを有効にするように PingTarget を設定します。

» pingtarget パラメータは、Grid Infrastructure のリソース ora.net1.network 用に定義し、値をクライアント・ネットワーク・ゲートウェイの IP アドレスに設定する必要があります。クライアント・ネットワークが ora.net1.network に基づいていない場合は、ora.netX.network リソース（ここで、X>1）を使用し、それに応じて pingtarget を設定します。

» pingtarget が適切に定義されていない OVM 環境では、ボンディング・インタフェースbondeth0 の両方のスレーブ・インタフェースで障害が発生している特定の RAC クラスタ・ノードで、完全なクライアント・ネットワーク障害が発生すると、VIP リソースは存続しているノードにフェイルオーバーせず、クライアント接続が長時間ハングすることになります。pingtarget が設定されていると、VIP は正常なクラスタ・ノードにフェイルオーバーし、障害の発生したノードへのクライアント接続は即座にリセットされます。

» 次のコマンドを使用して pingtarget を設定します。

<$GI_HOME>/bin/srvctl modify network -netnum 1 -pingtarget <IP of the

gateway of the client network>

» 次のコマンドを使用して pingtarget を検証します。

<$GI_HOME>/bin/srvctl config network

2. Exadata OVM のセットアップおよびメンテナンスについては、『Exadata Database Machine メンテナンス・ガイド』を参照してください。

23 | Exadata Database Machine を使用した Oracle Maximum Availability Architecture のデプロイ

データベース統合のベスト・プラクティス

Exadata は Oracle のデータウェアハウスおよび OLTP データベース・ワークロード向けに最適化されており、バランスのとれたデータベース・サーバーとストレージ・グリッド・インフラストラクチャによってデータベース統合に理想的なプラットフォームとなっています。Oracle データベース、ストレージ、およびネットワークのグリッド・アーキテクチャに Oracle のリソース管理を組み合わせることで、その他の仮想化戦略（ハードウェアや OS の仮想化など）よりも単純で柔軟なデータベース統合アプローチが提供されます。Exadata では、さらに分離が必要な場合、仮想マシンもサポートしています。

Exadata のデータベース統合のベスト・プラクティスについては、次の Oracle MAA ホワイト・ペーパーを参照してください。

» 『データベース統合のための高可用性ベスト・プラクティス』20

» 『Exadata Database Machine 上でのデータベース統合に関するベスト・プラクティス』21

» 『Oracle Exadata Database Machine 統合：データベースとロールの分離』22

Exadata MAAにおける運用のベスト・プラクティス

Exadata の導入を成功させるためには、運用に関する次のベスト・プラクティスに従う必要があります。

» 高可用性およびパフォーマンスの品質保証契約（SLA）を文書化し、品質保証契約にマッピングする停止/ソリューション・マトリックスを作成します。

リカバリ時間目標（RTO）とリカバリ・ポイント目標（RPO）を決定するには、ビジネスへの影響と、システム停止やデータ損失によって生じるコストを理解することが基本となります。RTOは停止時間の許容値を表すのに対し、RPO はデータ損失の許容量を表します。また、RTO と RPOは、停止の種類ごとに値が異なる可能性もあります。たとえば、サーバー障害とディスク障害の場合、通常の RTO/RPO は 0 になります。完全なサイト障害では、RTO/RPO の値が大きくなるとともに、パフォーマンス SLA の厳格さが低くなります。こうなる理由は、潜在的な停止発生頻度と、HA/DR の実装コストまたは複雑性との間のトレードオフを管理するためです。

Exadata MAA 環境で計画する必要がある停止の範囲については、付録 1 の「Exadata MAA の停止とソリューションのマトリックス」で説明されています。停止の種類ごとに、検出と修復の手順を文書化することが重要です。場合によっては、Oracle ソフトウェア・インフラストラクチャを利用して自動レスポンスを構成します。また、場合によっては、Oracle ソフトウェア・インフラストラクチャで自動通知を利用できますが、解決には手動の操作が必要です。すべての場合において、検出と修復の各手順で SLA を満たすことができることを検証する必要があります。スループット要件や応答時間要件などのパフォーマンスに関する SLA が遵守されることを保証するために、パフォーマンスの監視と迅速な対応を実装する場合も、同様のプロセスを実施します。

20 https://www.oracle.com/technetwork/jp/database/availability/maa-consolidation-2186395-ja.pdf 21 https://www.oracle.com/technetwork/jp/database/features/availability/exadata-consolidation-522500-ja.pdf 22 https://www.oracle.com/technetwork/jp/database/availability/maa-exadata-consolidated-roles-459605-ja.pdf

24 | Exadata Database Machine を使用した Oracle Maximum Availability Architecture のデプロイ

» HA とパフォーマンスの SLA を検証します。単純なデータベース・ノード、データベース・インスタンス、データベース障害、およびセル・ストレージ障害注入テストを実行して、自動の、自動化された、または手動の修復ソリューションすべてを含む予期される HA 応答を検証します。アプリケーションの RTO 要件と RPO 要件が満たされていることを確認します。アプリケーションのパフォーマンスが、コンポーネント障害のさまざまなシナリオで許容できるレベルであることを確認します。たとえば、ノード障害、Exadata ストレージ・セルの障害、および Data Guardのロール移行の後もパフォーマンスの SLA を引き続き満たしていることを検証します。

» My Oracle Support Note 888828.1 で推奨されているように、Exadata とデータベース・ソフトウェアを定期的（少なくとも 1 年に 1 回など）にアップグレードします。

Exadata には、その時点で最新の推奨 HA ソフトウェアとシステム・コンポーネントが搭載されています。デプロイ後は、定期的に exachk を実行する必要があります。また、Oracle MAA スコア・カードの Exadata ソフトウェア保守のベスト・プラクティスの項を参照して、既存のExadata ソフトウェアが推奨値の範囲内になっているかどうか評価します。exachk 内のソフトウェア保守チェックでは、使用環境に関連している重大なソフトウェア問題が検出されると、ユーザーにアラートが送信されます（必ず、実行する前に最新バージョンの exachk をダウンロードしてください）。

次の exachk がリリースされるまでの間に、すぐに対処する必要のある新しい重大な問題がExadata で見つかり、解決され、その問題に関する情報が My Oracle Support Note 1270094.1 で公開されることがあります。Exadata の重大な問題について新しく公開されたアラートの通知をMy Oracle Support から自動的に受け取るには、Oracle Exadata Storage Server ソフトウェア製品の Hot Topics 電子メールを構成します。

安定性を保つのにもっとも有効な方法の 1 つは、ソフトウェア・パッチの本番前検証とテストを実施することです。手順の概略は次のとおりです。

» パッチとアップグレードに関するドキュメントを確認します。

» 計画停止時間を最小限に抑えるか、または不要にするため、ローリング・アップグレードを行う機会があるかどうか検討します。

» 対象パッチが、My Oracle Support Note 1265700.1 で Standby-First Patch として認定されているかどうかを確認します。

» Grid Infrastructure ソフトウェア・ホームとデータベース・ソフトウェア・ホームのすべての変更では、フォールバックを容易にするため、『Oracle Database 高可用性ベスト・プラクティス』の 14.2.4.3 項「ホーム外ソフトウェアのインストールとパッチ適用」23での説明に従って、ホーム外のソフトウェア・インストールとパッチ適用を使用します。

» テスト環境でアプリケーションを検証し、機能性、パフォーマンス、可用性に対する要件を満たしているか、または上回っていることを確認します。手順を自動化し、必ずフォールバック手順を文書化してテストしてください。

» 変更を本番システムに反映する前に、必要に応じて Data Guard のスタンバイ・データベース上で、すべての変更に対する最終的な本番前検証を実行します。

» 本番環境に変更を反映します。

23 https://docs.oracle.com/cd/E16338_01/server.112/b65088/schedule_outage.htm#sthref945

25 | Exadata Database Machine を使用した Oracle Maximum Availability Architecture のデプロイ

» My Oracle Support Note 1070954.1 での説明に従って、Exadata MAA ヘルス・チェック（exachk）を実行します。環境や構成に関する問題を検出するために、ソフトウェア・パッチを適用する前後、データベース・アップグレードを行う前後、または少なくとも月 1 回、最新リリースのexachk をダウンロードしてテスト環境と本番環境で実行します。このチェックはソフトウェアとハードウェアを検証して、MAA、Oracle RAC、もしくは Exadata ハードウェアおよびソフトウェア構成に関する新規または既存のベスト・プラクティスを実施する必要がある場合、警告を通知します。MAA スコア・カードが MAA 構成チェックおよびベスト・プラクティスに追加されています。データベース・アップグレード前後の構成上の問題を予防的に検出するためのアップグレード・モジュールが追加されています。

» Data Guard のロール移行を実行し、リストア操作とリカバリ操作を検証します。アプリケーションと Data Guard のスイッチオーバーを定期的に実行し、すべてのロール移行手順を十分に検証します。ロール移行テストは、少なくとも四半期に 1 回は実施することを推奨します。Data Guardのドキュメントの他に、MAA OTN の Web サイトで、『ロール移行のベスト・プラクティス：Oracle Data Guard および Oracle Active Data Guard』24などの Data Guard ロール移行のベスト・プラクティスを参照してください。同様に、すべてのリストア操作とリカバリ操作を検証し、バックアップおよび手順が有効であることを確認してください。

» Exadata の監視と Auto Service Request25を構成します。OTN の Web サイト Enterprise Managerでの説明に従って、監視のベスト・プラクティスを組み込みます。

» このホワイト・ペーパーに記載されているさまざまなベスト・プラクティス参照情報に加えて、オラクルでは、Exadata に関係する技術情報をマスター・ノートとして My Oracle Support Note 757552.1 にまとめています。

テスト環境の重要性

十分な能力を備えたテスト・システム・インフラストラクチャへの投資は、Exadata MAA にとって不可欠です。Exadata のテスト・システムのデプロイに関する各種戦略の利点とトレードオフについては、表 2 を参照してください。

24 https://www.oracle.com/technetwork/jp/database/availability/maa-roletransitionbp-2621582-ja.pdf 25 https://www.oracle.com/jp/support/premier/auto-service-request.html

26 | Exadata Database Machine を使用した Oracle Maximum Availability Architecture のデプロイ

表2：さまざまなテスト環境とQA環境におけるトレードオフ

テスト環境 利点とトレードオフ

本番 Exadata のフル・レプリカ すべてのパッチとソフトウェア変更点が検証されます。すべての機能テストが検証されます。

本番規模での完全なパフォーマンス検証が実施されます。

レプリカにスタンバイ・システムが含まれる場合には特に、完全な HA 検証が実施されます。

スタンバイ Exadata ほとんどのパッチとソフトウェア変更点が検証されます。すべての機能テストが検証されます。

Data Guard スナップショット・スタンバイを使用している場合は完全なパフォーマンス検証が実

施されますが、フェイルオーバーが必要な場合はリカバリ時間が長くなります。

ロール移行の検証。

リソースの管理とスケジューリングが必要です。

共有 Exadata ほとんどのパッチとソフトウェア変更点が検証されます。すべての機能テストが検証されます。

本番環境と同様の十分なシステム・リソースを割り当てられる場合は、この環境がパフォーマン

ス・テストに適している可能性があります。

ただし通常は、パフォーマンスのテスト/検証に適さない本番システム・リソースのサブセットです。

リソース・スケジューリングが必要です。

小規模な Exadata システムまたは Exadataスナップショットを備えた Exadata

すべてのパッチとソフトウェア変更点が検証されます。すべての機能テストが検証されます。本

番規模でのパフォーマンス・テストが実施されません。

フルスケールの高可用性評価が制限されます。

Exadata スナップショットのストレージ効率は非常に優れています。

古い Exadata システム ほとんどのパッチとソフトウェア変更点が検証されます。

ファームウェアのパッチ・テストが制限されます。

一部の新しいハードウェア機能によって制限される場合を除き、 すべての機能テストが検証されます。

本番規模のパフォーマンス・テストが制限されます。

フルスケールの高可用性評価が制限されます。

Exadata 以外のシステム データベースとグリッド・インフラストラクチャのソフトウェアおよび更新のみが検証されます。

データベースの汎用的な機能テストが検証されます。

Exadata 固有のソフトウェア機能（HCC、IORM、ストレージ索引など）のテストが制限されます。

本番規模のパフォーマンス・テストが大幅に制限されます。

高可用性評価が制限されます。

結論

Exadata MAA は、Oracle Database 向けにパフォーマンスと可用性に優れたプラットフォームを提供する統合ソリューションです。このテクニカル・ホワイト・ペーパーでは、すべての Exadata Database Machine によって提供される事前構成された HA 機能を中心に、Exadata MAA の利点すべてを活用するために管理者が利用できる製品到着後の構成および運用上のベスト・プラクティスについて説明しています。

27 | Exadata Database Machine を使用した Oracle Maximum Availability Architecture のデプロイ

付録1：Exadata MAAの停止とソリューションのマトリックス

計画外停止

以下の表 3 に示す停止とソリューションのマトリックスは、オラクルが実施する広範な高可用性テストの一例です。Oracle MAA で推奨されるソリューションは、停止の種類ごとに、予想されるアプリケーション・リカバリ時間（RTO）と一緒に提供されます。この場合、アプリケーションのパフォーマンス SLA を満たす十分なシステム・リソースを使用することができ、使用可能なサービスにアプリケーションが透過的にフェイルオーバーするように構成されていることが前提です。運用準備が整っていること、およびアプリケーションのパフォーマンス SLA が満たされていることを評価するため、Exadata MAA テスト・システムで実際のワークロードを（Real Application Testing とDatabase Replay を使用して）実行しながら、主要な障害（インスタンス障害、ノード障害、ディスク障害、セル障害、論理障害、ハングなど）をシミュレーションすることを推奨します。優先順位列には、発生確率、運用準備の重要性、顧客テストの重要性に基づいて、（Oracle テストの優先順位ではなく）提案されるテスト優先順位が反映されます。ほとんどの停止でデータベース停止時間はゼロとなり、あらゆる接続に関するアプリケーションの一時停止も最小限で済みます。別のハードウェアまたはストレージ・ベンダーと比較する場合は、同じ同等の障害を注入し、両方の環境で同じワークロードを繰り返します。Exadata によってエンド・ツー・エンドのアプリケーション可用性を達成する方法と、さまざまなハードウェアとソフトウェアの機能停止による一時停止をほ ぼ ゼ ロ に す る 方 法 の 実 例 に つ い て は 、 Exadata MAA の ビ デ オ（http://vimeo.com/esgmedia/exadata-maa-tests）を参照してください。

手動または自動のいずれのフェイルオーバーをデプロイする場合でも、個々のコンポーネントがデータベースの可用性に与える影響を理解し、エンド・ツー・エンド・アプリケーションのフェイルオーバー時間や一時停止を評価します。表には、『Oracle Database 高可用性ベスト・プラクティス 11g』の第 13 章「計画外の停止からのリカバリ」26へのリンクが含まれています。Oracle Database 12c を使用している場合は、『Oracle Database 高可用性ベスト・プラクティス 12c』で公開されている停止マトリックス 27を参照してください。

計画外停止の後に十分なシステム・リソースが残されている場合、アプリケーションの影響は、以下の表に示すように非常に小さくなります。

表3：計画外停止とソリューションのマトリックス

停止の種類 障害注入プロセス Exadata MAA 優先順位

サイト障害 数秒～5 分 28

スタンバイ・データベースによるデータベース・

フェイルオーバー サイト全体のフェイルオーバー

アプリケーション・フェイルオーバー

LOW BUT WORTH TESTING FOR DR READINESS

クラスタ全体障害または 本番の Exadata Database Machine 障害

秒単位～5 分

スタンバイ・データベースによるデータベース・

フェイルオーバー サイト全体のフェイルオーバー

アプリケーション・フェイルオーバー

LOW BUT WORTH TESTING FOR DR READINESS

26 https://docs.oracle.com/cd/E16338_01/server.112/b65088/outage.htm#i1005910 27 https://docs.oracle.com/cd/E57425_01/121/HABPT/outage.htm#i1005910 28 記載されたリカバリ時間は、データベースと既存接続のフェイルオーバーにかかる時間です。ネットワーク接続が変更され、他のサイト固有の

フェイルオーバー・アクティビティにより全体的なリカバリ時間が長くなる可能性があります。

28 | Exadata Database Machine を使用した Oracle Maximum Availability Architecture のデプロイ

停止の種類 障害注入プロセス Exadata MAA 優先順位

コンピュータ障害（ノー

ド）または RAC データベー

ス・ノード障害（ハード

ウェア障害、RAC ノード排

除、再起動、またはマザー

ボード障害の影響のシミュ

レーション）

1. データベース・ノードのプ

ラグを引き抜くか、強制的

に電源をオフにします

2. 30 秒以上待ちます

3. 必要に応じて、電源を復元

してデータベース・ノード

の電源をオンにします

4. データベース・ノードが完

全に起動するまで待ちます

クラスタの検出、クラスタの再構成、およびイン

スタンス・リカバリのための短いアプリケーショ

ン停止時間。Exadata の場合、Grid Infrastructure 12.1.0.2 BP7 以上でクラスタ検出に要する時間は

2 秒です。

計画外の停止の場合に Oracle RAC リカバリに

よって自動的に管理されます

HIGH

データベース・インスタン

ス障害

または RAC データベース・

インスタンス障害

バックグランド・プロセスに

対して kill -11 PMON を実行

するか、ターゲット・インス

タンスに対して shutdown abort を実行します

影響を受ける接続でのアプリケーション停止時間

が短くなります。障害の発生したインスタンスの

影響を受ける接続について、クラスタの再構成

（1 秒）とインスタンス・リカバリによる一時停

止あり（Exadata ライトバック・フラッシュ・

キャッシュを使用する Exadata では大幅に高速

化）。データベース停止時間なし 29。

計画外の停止の場合に Oracle RAC リカバリに

よって自動的に管理されます

HIGH

Exadata Storage Server 障害（ストレージ・ヘッド障

害のシミュレーション）

1. ストレージ・セルのプラグ

を引き抜くか、強制的に電

源をオフにします

2. Oracle ASMディスク修理タ

イマーより長く待ちます

InfiniBandファブリック高速検出メカニズムを使用

する場合、セル・ストレージ遅延は 1秒未満で、ア

プリケーションへの影響が小さくなります。

LOW

Exadata ディスク取出しと

その後の取付け 1. ディスクを取り出して 10

秒以上待ちます

2. 同じディスク・ドライブを同

じスロットに取り付けます

Exadata ライトバック・フラッシュ・キャッシュ

を使用する場合、アプリケーションの一時停止が

ゼロになります。Exadata および Oracle ASM は

ストレージ障害に対応し、I/O を迅速にミラーに

リダイレクトして、サービス・レベルへの影響を

最小限に抑えます。

Oracle では、ユーザーによる正常なディスクの取

出しと実際に障害が発生したディスクを区別でき

ます。ディスクの取出しと取付けの場合は、差分

変更のための単純な Oracle ASM 再同期が実行さ

れます。

LOW

Exadata ディスク障害 次のシミュレーション・コマ

ンドを使用します。

1. alter physicaldisk <disk controller:disk slot #> simulate failuretype=fail

2. 1 分待ちます

3. alter physicaldisk <disk controller:disk slot #> simulate failuretype=fail

実際のディスク障害の場合は、障害の発生した

ディスクがすぐに除去され、その後、サービス・

レベルに影響を及ぼすことなく Oracle ASM リバ

ランスが実行されます。

Exadata セル 11.2.3.2.0 以降では、青の LED ライ

トにより、障害の発生したディスクを交換できる

ことが示されます。

HIGH

29 データベースは引き続き使用可能ですが、障害の発生したシステムに接続しているアプリケーション部分は一時的に影響を受けます。

29 | Exadata Database Machine を使用した Oracle Maximum Availability Architecture のデプロイ

停止の種類 障害注入プロセス Exadata MAA 優先順位

Exadata フラッシュ・ディ

スクまたはフラッシュ DOM障害

1. フラッシュ・ディスクを物

理的に取り出すことはでき

ません。シミュレーショ

ン・コマンド：alter physicaldisk <physicaldisk name of flash module> simulate failuretype=fail

2. 1 分待ちます

3. 終了シミュレーション・コ

マンド：alter physicaldisk <physicaldisk name of flash module> simulate failuretype=none

ライトバック・フラッシュ・キャッシュと古い

データの高速修復を使用する場合、アプリケー

ションへの影響は小さくなります。

MEDIUM

コンピュータまたは

Exadata セル・ストレー

ジ・サーバーの電源障害、

PDU 障害、または電源供給

喪失

1.いずれかの PDU の電源を

抜きます 冗長電源障害によるアプリケーション一時停止なし。 LOW

人為的エラー 30 分未満 30

人為的エラーからのリカバリ

HIGH

ハングまたは速度低下 計画外停止に対するソリューションについては、

『Oracle Database高可用性概要』を参照してくだ

さい

アプリケーション・フェイルオーバー

HIGH

計画メンテナンス

表 4 に、テストとパッチ適用に関するベスト・プラクティスに従ってから Exadata の計画メンテナンスを実行するための適切な方法を示します。表には、『Oracle Database 高可用性ベスト・プラクティス 11g』の第 14 章「計画メンテナンスの停止時間の短縮」31の詳細説明へのリンクが含まれています。Oracle Database 12c を実行しているお客様は、『Oracle Database 高可用性ベスト・プラクティス 12c』32を参照してください。Exadata 計画メンテナンスの概要については、まず Oracle Exadata Software Planned Maintenance のプレゼンテーションを参照してください。また、詳しくは、My Oracle Support Note 888828.133または『Oracle Exadata Database Machine メンテナンス・ガイド』を参照してください。運用準備が整っていること、およびアプリケーションのパフォーマンス SLA が満たされていることを評価するため、Exadata MAA テスト・システムで実際のワークロードを（Real Application Testing と Database Replay を使用して）実行しながら、主要な計画メンテナンス（Oracle データベースまたは Grid Infrastructure の保守アップグレード、Exadata プラットフォーム・ソフトウェアのアップグレード）に重点を置いて作業することを推奨します。予想停止時間の列には、テストおよびリハーサル済みのメンテナンス作業における、プライマリ・データベースへの一般的な影響が表示されます。通常は、まずテスト環境ですべての計画メンテナンス作業を検証します。

30 人為的エラーからのリカバリ時間は、おもに検出時間によって決まります。DML や DLL の悪意のあるトランザクションを数秒で検出できる場合、

適切にリハーサルしていれば、通常は適切なトランザクションを数秒でフラッシュバックできます。参照や整合性に関する制限事項も考慮する必要

があります。 31 https://docs.oracle.com/cd/E16338_01/server.112/b65088/schedule_outage.htm#BABBGGBG 32 https://docs.oracle.com/cd/E57425_01/121/HABPT/outage.htm#i1005910 33 https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=888828.1

30 | Exadata Database Machine を使用した Oracle Maximum Availability Architecture のデプロイ

Standby-First Patch - Data Guardによるリスクの軽減と停止時間の短縮

（Exadata プラットフォーム、Oracle Grid Infrastructure、Oracle Database の）ソフトウェア更新やパッチ適用などのすべての計画メンテナンス操作では、まず Standby-First Patch のガイドラインと適格性評価を使用して、Data Guard スタンバイ・システムへの更新を実行することを推奨します。詳しくは、My Oracle Support Note 1265700.1 を参照してください。ソフトウェア更新をこの方法で実行すれば、プライマリ・データベースへの影響はありません。

計画メンテナンス後に十分なシステム・リソースがあれば、次の表のとおり、アプリケーションへの影響は非常に軽微です。

表4：プライマリ・サイトでの計画停止に対するソリューション

計画メンテナンス 推奨される Oracle ソリューション プライマリ・データベースの予想停止時間 頻度 Oracle Grid Infrastructure（Oracle GI）のパッチ・

セット、メンテナンス、また

はメジャー・リリース・アッ

プグレード

Oracle Grid Infrastructure のローリング・パッ

チ・アップグレード（詳しくは、プラット

フォーム別の Oracle Clusterware インスト

レーション・ガイドを参照） 参考資料：

• Oracle DatabaseおよびGrid Infrastructureのパッチ適用

• システム・メンテナンスのための自動

ワークロード管理

データベースの停止時間なし、サービスの再

配置によりアプリケーションへの影響はゼロ

または最小限

1 年以上

Oracle Database のパッチ・

セット、メンテナンス、また

はメジャー・リリース・アッ

プグレード

Data Guard（一時ロジカル・スタンバイ）ま

たは GoldenGate を使用した Oracle Database のローリング・アップグレー

ド Data Guard が該当しない場合や、アクティ

ブ-アクティブ・レプリケーションを使用した

より短い停止時間が要求される場合は、

Oracle GoldenGate を検討してください 参考資料：

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

Data Guard では 5 分未満。GoldenGate では

停止時間なし

1 年以上

Oracle Grid Infrastructure や

Oracle Database に対する四

半期ごとの Exadata データ

ベース・バンドル・パッチ

（Oracle Database 12c のエ

ンジニアド・システムおよび

Database In-Memory用の

データベース・パッチ、また

は Exadata for Oracle Database 11g の四半期ごと

のデータベース・パッチな

ど）の適用

opatch およびアウトオブプレース・パッチ適

用を使った Oracle RAC ローリング・パッチ・

インストール 参考資料：

• Oracle DatabaseおよびGrid Infrastructureのパッチ適用

• システム・メンテナンスのための自動

ワークロード管理

データベースの停止時間なし。 サービスの再配置によるアプリケーションへ

の影響はゼロまたは最小限

3～12 か月

31 | Exadata Database Machine を使用した Oracle Maximum Availability Architecture のデプロイ

計画メンテナンス 推奨される Oracle ソリューション プライマリ・データベースの予想停止時間 頻度 Oracle Grid Infrastructure ま

たは Oracle Database への

Oracle 暫定パッチまたは診断

パッチの適用

opatch またはオンライン・パッチを使用した

Oracle RAC ローリング・パッチの インストール 参考資料：

• Oracle DatabaseおよびGrid Infrastructureのパッチ適用、および オンライン・パッチ

• システム・メンテナンスのための自動

ワークロード管理

データベースの停止時間なし、サービスの再

配置によりアプリケーションへの影響はゼロ

または最小限

必要に応じて

Exadata プラットフォーム・

ソフトウェア更新：データ

ベース・サーバー・ソフト

ウェアの四半期ごとの更新ま

たは新規リリース

Oracle RAC のローリング・アップグレードと

サービスの再配置 参考資料：

• システム・メンテナンスのための自動

ワークロード管理

• Exadata Maintenance Guide

• Oracle Exadata Software Planned Maintenanceのプレゼンテーション

データベースの停止時間なし、サービスの再

配置によりアプリケーションへの影響はゼロ

または最小限

四半期ごとの更

新：3～12 か月 新規リリース：

1～2 年

Exadata プラットフォーム・

ソフトウェア更新：ストレー

ジ・サーバー・ソフトウェア

の四半期ごとの更新または新

規リリース

patchmgrによる Exadata Storage Server ソフトウェアのローリング更新 参考資料：

• Exadata Maintenance Guide

停止時間なし

四半期ごとの更

新：3～12 か月 新しいリリー

ス：1～2 年

Exadata プラットフォーム・

ソフトウェア更新：

InfiniBand スイッチ・ソフト

ウェア

patchmgrによる Exadata InfiniBand スイッ

チ・ソフトウェアのローリング更新 参考資料：

• Exadata Maintenance Guide』を参照

データベースの停止時間なし、 アプリケーションの一時停止は短時間

1～2 年

Exadata プラットフォーム・

ソフトウェア更新：配電盤

（PDU） キーボード、ビデ

オ、マウス（KVM）

『Oracle Exadata Database Machine メンテナ

ンス・ガイド』を参照

データベース停止時間なし、 アプリケーションへの影響なし

1～2 年（必要

に応じて）

サイト保守

データベース・スイッチオーバーを使用した

サイト、ハードウェアおよびソフトウェアの

メンテナンス サイト全体のフェイルオーバー、アプリケー

ション・フェイルオーバー

5 分未満

必要に応じて

データベース・オブジェクト

の再編成または再定義

DBMS_REDEFINITION を使用したオンライン

のオブジェクト再編成（データの再編成と再

定義を参照）

停止時間なし

必要に応じて

データベース・プラット

フォームまたは場所のメンテ

ナンス

データベースのプラットフォームまたはロ

ケーションの移行

5 分未満

必要に応じて

Oracle Corporation, World Headquarters

500 Oracle Parkway

Redwood Shores, CA 94065, USA

海外からのお問い合わせ窓口

電話：+1.650.506.7000

ファクシミリ：+1.650.506.7200

C O N N E C T W I T H U S

blogs.oracle.com/oracle

facebook.com/oracle

twitter.com/oracle

oracle.com

Copyright © 2016, Oracle and/or its affiliates.All rights reserved.本文書は情報提供のみを目的として提供されており、ここに記載される内容は予告なく変更されることがあります。本文書は、その内容に誤りがないことを保証するものではなく、また、口頭による明示的保証や法律による黙示的保証を含め、商品性ないし特定目的適合性に関する黙示的保証および条件などのいかなる保証および条件も提供するものではありません。オラクルは本文書に関するいかなる法的責任も明確に否認し、本文書によって直接的または間接的に確立される契約義務はないものとします。本文書はオラクルの書面による許可を前もって得ることなく、いかなる目的のためにも、電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません。 Oracle および Java は Oracle およびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。 Intel および Intel Xeon は Intel Corporation の商標または登録商標です。すべての SPARC 商標はライセンスに基づいて使用されるSPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMD ロゴおよび AMD Opteron ロゴは、Advanced Micro Devices の商標または登録商標です。UNIX は、The Open Group の登録商標です。0615 Exadata Database Machine を使用した Oracle Maximum Availability Architecture のデプロイ 2017 年 6 月