1. 高可用性概要およびベスト・プラクティス
  2. 『Oracle Database高可用性概要』
  3. 可用性を最大化するための運用前提条件

7 可用性を最大化するための運用前提条件

MAAの実装を成功させるには、次の運用ベスト・プラクティスを使用します。

高可用性およびパフォーマンスに関するサービス・レベル合意の理解

高可用性(HA)およびパフォーマンスに関するサービス・レベル合意(SLA)を理解して文書化します。

SLAを満たす高可用性アーキテクチャの実装および検証

高可用性およびパフォーマンスのサービス・レベル要件に関する合意事項がある場合は、次の作業を行います。

テスト・プラクティスおよび環境の構築

次のことを検証または自動化して、高可用性SLAが必ず実現されるようにする必要があります。

  • すべてのソフトウェア更新およびアップグレード・メンテナンス・イベント
  • すべての修復操作(各種の計画外停止のための修復操作を含む)
  • バックアップ、リストアおよびリカバリ操作

障害時リカバリとデータ保護のためにOracle Data Guardを使用する場合は、次のことをお薦めします。

  • 定期的にスイッチオーバー操作を実行するか、アプリケーションおよびデータベースの完全なフェイルオーバー・テストを実行します
  • アプリケーションおよびData Guardのスイッチオーバーを定期的に実行して、エンドツーエンドのロール・トランジション手順を検証します

よいテスト環境や適切なテスト・プラクティスは、本番環境で最高の安定性と可用性を達成するための重要な前提条件です。テスト環境であらゆる変更を完全に検証することで、本番システムで同じ変更を適用する前に、問題を事前に検知して防止および回避することができます。

実際の作業には次のようなものがあります。

テストおよびQAの環境の構成

テスト環境は、本番MAA環境のレプリカ(MAAのGoldリファレンス・アーキテクチャを使用するなど)にする必要があります。テスト・システムが、実装する予定のMAAサービス・レベルで運用される標準のリファレンス・アーキテクチャと同一でない場合は、トレードオフがあります。本番を模倣したワークロードで、機能、パフォーマンスおよび可用性テストを実行することをお薦めします。可用性とパフォーマンスSLAが各変更後も維持されているかを評価し、本番環境に変更を適用している間になにか失敗した場合に、明確なフォールバックまたは修復プロシージャの準備が整っていることを確認します。

適切に構成されたテスト・システムによって、多くの問題を回避できます。変更が検証されるのは同等の本番およびスタンバイ・データベース構成で、これには完全なデータ・セットが含まれ、本番を模倣するためのワークロード・フレームワーク(たとえば、Oracle Real Application Testing)が使用されるためです。

テスト・システムの廃止によってコストを削減しようとしないでください。この決断は後々、本番アプリケーションの安定性と可用性に影響を及ぼすことになります。テストおよびQAのためにシステム・リソースのサブセットのみを使用すると、次の表に示されているトレードオフがあります(MAAのGoldリファレンス・アーキテクチャの例です)。

表7-1 各種のテストおよびQA環境のトレードオフ

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

本番システムとスタンバイ・システムの完全レプリカ

検証:

  • すべてのソフトウェアの更新およびアップグレード
  • すべての機能テスト
  • 本番スケールにおける完全パフォーマンス
  • 完全な高可用性および障害時リカバリのテスト

本番システムの完全レプリカ

検証:

  • すべてのソフトウェアの更新およびアップグレード
  • すべての機能テスト
  • 本番スケールにおける完全パフォーマンス
  • 完全な高可用性からスタンバイ・システムをマイナスしたもの

検証不可:

  • 障害時リカバリのテスト
  • スタンバイREDO適用または読取り専用ワークロードのパフォーマンスのテスト
  • REDO転送のパフォーマンス、およびREDO転送による本番システム・リソースへの影響
  • データベースのローリング・アップグレード、スナップショット・スタンバイなどのスタンバイ・データベースを使用するユースケース。

スタンバイ・システム

検証:

  • ほとんどのソフトウェア更新の変更
  • すべての読取り専用機能テスト
  • 完全なパフォーマンス - Data Guardスナップショット・スタンバイを使用する場合。ただし、フェイルオーバーが必要な場合はリカバリ時間が長くなる可能性があります
  • リソース管理およびスケジューリング - スタンバイ・データベースとテスト・データベースが同じシステムに存在する場合は必要となります

検証不可:

  • ロール・トランジションと障害時リカバリのテスト
  • データベースのローリング・アップグレード、スナップショット・スタンバイなどのスタンバイ・データベースを使用するユースケース。

共有システム・リソース

検証:

  • ほとんどのソフトウェア更新の変更
  • すべての機能テスト

検証不可:

本番の模倣に十分なシステム・リソースを割当てできれば、この環境はパフォーマンス・テストに適している場合があります。ただし、通常は、環境に本番システム・リソースのサブセットが含まれ、パフォーマンスの検証には欠落が生じます。リソース管理およびスケジューリングが必要です。スタンバイまたは障害時リカバリのテストは、不可または制限付きである場合があります。

システム・リソースの小規模バージョンまたはサブセット

検証:

  • すべてのソフトウェア更新の変更
  • すべての機能テスト
  • 限定的な、完全スケールの高可用性評価

検証不可:

  • 本番スケールにおけるパフォーマンス・テスト
  • スタンバイまたは障害時リカバリのテストは、不可または制限付きである場合があります。

異なるハードウェアまたはプラットフォームのシステム・リソース(同一オペレーティング・システム)

検証:

  • ソフトウェア更新の変更の一部
  • 限定的な、ファームウェア・パッチ適用テスト
  • ハードウェアの新機能で制限されていないかぎり、すべての機能テスト
  • 限定的な、本番スケールのパフォーマンス・テスト
  • 限定的な、完全スケールの高可用性評価
  • スタンバイまたは障害時リカバリのテストは、不可または制限付きである場合があります。

関連項目:

『Oracle Databaseテスト・ガイド』

本番前の検証ステップの実行

ハードウェア、ソフトウェア、データベース、アプリケーションまたはすべての変更を本番前に検証およびテストすることは、安定性を維持するために重要です。上位レベルの本番前検証のステップは次のとおりです。

  1. パッチまたはアップグレードのドキュメントや、対象の変更に関連するドキュメントを確認します。SLAで停止時間をゼロまたは最小限にすることが必要な場合、ローリング・アップグレードの実行の可能性を評価します。計画済停止時間を最小化または排除するローリング・アップグレードの機会を評価します。パッチまたは変更がStandby-First Patchに適格かどうか評価します。

    ノート:

    Standby-First Patchを使用すると、プライマリ・データベースは以前のソフトウェア・リリースのまま、パッチを最初にフィジカル・スタンバイ・データベースに適用できます(この適用対象は特定のソフトウェア・アップデートのタイプで、メジャー・リリース・アップグレードには適用されません。パッチ・セットおよびメジャー・リリースにはData Guardの一時ロジカル・スタンバイおよびDBMS_ROLLINGの方法を使用してください)。変更作業が終了したら、スタンバイ・データベースへのスイッチオーバーを実行します。フォールバックは必要な場合にスイッチオーバーすることです。もう1つの方法として次のステップに進み、本番環境に変更を適用することもできます。詳細は、My Oracle Supportのノート1265700.1(https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1265700.1)『Oracle Patchの保証 - Data Guard Standby-First Patch適用』を参照してください。

  2. テスト環境でアプリケーションを検証し、機能、パフォーマンスおよび可用性の要件を変更が満たしている、または上回っていることを確認します。手順を自動化して、フォールバック手順の文書化およびテストも確認します。これには、テストでパッチ適用の前後に取得されたメトリックを、本番システムで取得されたメトリックと比較することが必要です。Real Application Testingは、本番システムでワークロードを取得し、それをテスト・システムで再現するために使用できます。AWRとSQLパフォーマンス・アナライザは、パッチによって引き起こされたパフォーマンスの向上または低下を評価するために使用できます。

    本番環境を模倣するテスト・システムで新規ソフトウェアを検証し、機能、パフォーマンスおよび可用性の要件を変更が満たしている、または上回っていることを確認します。パッチまたはアップグレードの手順を自動化して、フォールバックを確認します。このステップを一通り実施することで、パッチまたはアップグレードの実施中および実施後における最も致命的な問題を回避できます。

  3. 部門で決められているセキュリティ上の制約にも準拠しながら、アプリケーションを包括的に検証するには、Oracle Real Application Testingおよびテスト・データ管理機能を使用します。Oracle Real Application Testing (個別のデータベース・オプション)を使用すると、Oracle Databaseを現実的な環境でテストできます。Oracle Real Application Testingでは、本番環境にデプロイメントを行う前に、本番環境のワークロードを取得し、こららのワークロードに対するシステムの変更の影響を評価することで、システム変更が原因で不安定になるリスクを最小限にします。Oracle Real Application Testingの主要コンポーネントは、SQLパフォーマンス・アナライザおよびデータベース・リプレイです。テストするシステム変更の性質とその影響、およびテストを実行するシステムの種類に応じて、テストの実行にいずれかまたは両方のコンポーネントを使用できます。

    現実的な環境でテストを行う場合、テスト環境の本番ではないユーザーに機密データが公開されてしまうリスクがあります。Oracle Databaseのテスト・データの管理機能では、テスト・データに対してデータ・マスキングおよびデータ・サブセット化を実行し、このリスクを最小限にできます。

  4. 適用可能な場合、すべての変更の最終的な本番前検証をData Guardスタンバイ・データベースで実行してから、それを本番に適用してください。適用可能な場合、Data Guard環境で変更を適用します。

  5. 本番環境で変更を適用します。

関連項目:

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

『Oracle Data Guard概要および管理』のスナップショット・スタンバイ・データベースへのフィジカル・スタンバイ・データベースの変換および既存のフィジカル・スタンバイ・データベースを使用したローリング・アップグレードの実行

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

Oracle Patchの保証 - Data Guard Standby-First Patch適用(Doc ID 1265700.1)

セキュリティ・ベスト・プラクティスの設定および使用

適切なセキュリティ基準のないシステムまたはデータベースに配置された企業データは、深刻なリスクに直面している可能性があります。明確に定義されたセキュリティ・ポリシーは、システムに対する不正アクセスを遮断し、企業の機密情報を破壊行為から保護するのに役立ちます。適切なデータ保護により、セキュリティの侵害によるシステム停止の可能性を抑制できます。

関連項目:

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

変更管理手順の確立

システムの安定性を維持し、テスト・システムまたはMAAサービスレベル層の基本アーキテクチャのいずれかで厳密に評価されるまで変更がプライマリ・データベースに適用されないように、変更を管理および制御する手順を設けます。

変更をレビューし、変更管理チームからフィードバックと承認を取得します。

推奨されているソフトウェア更新およびセキュリティ更新の定期的な適用

最新または最近のバージョンでソフトウェアをメンテナンスすると、ソフトウェア・セキュリティの向上、リソース使用率と安定性の向上、新しい関連ソフトウェアとの継続した互換性、問題に対する最適なサポートと迅速な解決、新しく検出された問題に対する修正を受信する機能など、多くの利点があります。

すべてのソフトウェアを定期的に更新してください。次の慣例に従うことをお薦めします。

  • 新しいメジャー・ソフトウェア・リリースへのアップグレード計画、および現行リリースの予防的更新のインストール計画を作成するために、ご使用のMAA環境が依存しているすべてのソフトウェアについて、リリースおよびサポート・タイムラインを把握します。

    たとえば、Oracle Databaseのリリースおよびサポート・タイムラインは、My Oracle Supportノート742060.1「現在のデータベース・リリースのリリース・スケジュール」で確認できます。

  • 現行リリースの予防的ソフトウェア更新が終了する前に、新しいメジャー・ソフトウェア・リリースにアップグレードします。

  • 現行リリースの予防的ソフトウェア更新の提供が開始されたら、それらをインストールします(通常は毎月または四半期単位)。

    ただし、ビジネス要件によって、特定の予防的更新の導入を遅らせるかスキップすることに決まる場合があります。このような場合は、現在実行中のソフトウェアに最新の予防的更新がリリースされてからそれを適用するまでの期間が12か月より長くならないようにすることをお薦めします。

  • My Oracle Supportアラートで公開された重大な問題については、できるだけ早くリアクティブ・ソフトウェア・パッチ(個別パッチとも呼ばれる)をインストールします。

  • 本番システムにあるソフトウェアを更新する前に、ソフトウェア更新プロセスを検証し、テスト・システムでソーク・テストを実行します。

  • Oracleのヘルス・チェック・ツールであるOrachkとExachkを使用して、Oracleソフトウェアのアップグレードと予防的更新のアドバイス、重大な問題のソフトウェア更新の推奨事項、パッチ適用とアップグレードの事前チェック、データベースとシステムのヘルス・チェック、およびMAAの推奨事項が提供されるようにします。

    Orachkでは、非エンジニアド・システムおよびOracle Database Applianceがサポートされています。Exachkでは、エンジニアド・システムであるOracle Exadata Database MachineおよびOracle Zero Data Loss Recovery Applianceがサポートされています。

関連項目:

Oracle DatabaseおよびGrid Infrastructureの場合:

  • My Oracle Supportノート742060.1の「現在のデータベース・リリースのリリース・スケジュール」
  • My Oracle Supportノート888.1の「データベース・プロアクティブ・パッチ・プログラムのプライマリ・ノート」
  • My Oracle Supportノート555.1の「Oracle Database 19cの重要な推奨個別パッチ」

エンジニアド・システム(Exadata Database MachineおよびZero Data Loss Recovery Appliance)の場合:

  • My Oracle Supportノート888828.1の「Exadata Database MachineおよびExadata Storage Serverのサポートされているバージョン」
  • My Oracle Supportノート1270094.1の「Exadataの重大な問題」
  • My Oracle Supportノート556.1の「Oracle Exadata: ExadataおよびLinuxの推奨されている重要な修正」
  • My Oracle Supportノート1070954.1の「Oracle Exadata Database MachineのExachk」

非エンジニアド・システムの場合:

  • My Oracle Supportノート2550798.1の「Autonomous Health Framework (AHF) - TFAおよびOrachk/Exachkの組込み」

障害時リカバリ環境の確立

ソース・データベースまたはプライマリ・データベースと同じパフォーマンスおよびHA特性を実現するには、障害時リカバリ環境またはターゲットを対称にするか、本番システムと同様に構成する必要があります。

障害時リカバリ・ターゲットがスタンバイ・データベースまたはOracle GoldenGateレプリカの場合、同じパフォーマンスを実現するには、対称または同様のデータベース・コンピュートCPU、メモリーおよびスループットが必要です。同様に、ストレージで、同じIOPS、スループットおよびレスポンス時間に対応できる必要があります。

データベース統合とコスト効率のために他のアプリケーションまたはデータベースによって障害時リカバリ・ターゲットが使用される場合は、他の同時ワークロードでの許容可能なパフォーマンスを確保するためにリソースがさらに必要になります。

障害時リカバリの慣例の確立と検証

RTOやRPOなどの障害時リカバリ・サービス・レベル要件を満たしているか確認するには、障害時リカバリ検証が必要です。

スタンバイ・データベースとしてOracle GoldenGateレプリカを使用している場合でも、Zero Data Loss Recovery Appliance (リカバリ・アプライアンス)、ZFS Storage、または別のサード・パーティのデータベース・バックアップを利用している場合でも、操作およびデータベース管理チームは、事前に設定したしきい値に従って、プライマリ・データベースの停止またはパフォーマンス低下時にいつでもデータベースとアプリケーションをフェイルオーバーまたは復元できるよう十分に準備しておくことが重要です。関係するチームは、それらを検出し、必要に応じてフェイルオーバーまたはリストアすることを決断できる必要があります。障害前に効率的に準備できると、全体的な停止時間が大幅に短縮されます。

Data GuardまたはOracle GoldenGateを高可用性、障害時リカバリ、データ保護のために使用する場合、3～6か月ごとに定期的なアプリケーションとデータベースのスイッチオーバーの操作を実行するか、完全なアプリケーションおよびデータベースのフェイルオーバー・テストを実行することをお薦めします。

バックアップを使用して障害時リカバリ・ソリューションを検証するには、定期的なRMANクロス・チェック、RMANバックアップ検証および完全なデータベースのリストアとリカバリが必要です。リカバリ・アプライアンスで固有のバックアップ・チェックと検証が自動的に実行されますが、定期的なリストアとリカバリのテストを行うこともお薦めします。

関連項目: ロール・トランジション、アセスメントおよびチューニング

エスカレーション管理手順の確立

修復を妨げないためのエスカレーション管理手順を確立します。ほとんどの修復ソリューションは、適切に実施されていればMAAソリューションで自動的かつ透過的です。問題が発生するのは、プライマリ・データベースまたはシステムが可用性またはパフォーマンスのSLAに適合せず、フェイルオーバー手順がData Guardの一部のフェイルオーバー・シナリオのように自動で行われるのではない場合です。適切なエスカレーション・ポリシーが施行されず、決定が迅速に行われないと、停止時間が長引く可能性があります。

可用性が最優先である場合は、まずフェイルオーバー操作と修復操作を実行してから、アプリケーション・サービスが再構築された後に、根本原因分析(RCA)用のログおよび情報の収集に進みます。簡易なデータ収集には、トレース・ファイル・アナライザ・コレクタ(TFA)を使用します。

関連項目:

MAAのWebページ(http://www.oracle.com/goto/maa)

Oracle Supportのノート1513912.2『TFAコレクタ - 拡張診断収集のツール』(1513912.2)を参照してください。

高可用性のための監視およびサービス・リクエスト・インフラストラクチャの構成

高可用性環境を維持するには、停止時間が発生する前に、パフォーマンスおよび高可用性に関連したしきい値を検出し、それに対応する監視インフラストラクチャを構成する必要があります。

また、可能な場合は、ユーザーが操作しなくても、Oracleが障害を検出し、フィールド・エンジニアを派遣して、障害が発生したディスク、フラッシュ・カード、ファン、電源などのハードウェア・コンポーネントを置き換えることができます。

データベース・ヘルス・チェックの定期的な実行

Oracleデータベース・ヘルス・チェックは、ハードウェアおよびソフトウェアの構成とベスト・プラクティスに対するMAA準拠を評価するように設計されています。

Oracleヘルス・チェック・ツールはすべて、Oracle Grid Infrastructure、Oracle Databaseを評価し、自動MAAスコアカードを提供するか、または主要なアーキテクチャおよび構成の設定が失敗に対する耐性がない、または高速リカバリに対応していない場合にその強調部分を確認します。Exadata Database MachineなどのOracleの設計されたシステムには、数百の追加のソフトウェア、エラーおよび構成のチェックが存在します。

Oracleでは、定期的に(たとえば、Exadata Database Machineの場合毎月)最新のデータベース・ヘルス・チェックのダウンロードと実行、および主要なFAILURES、WARNINGS、およびINFOメッセージへの対処をお薦めしています。エンジニアド・システム(Oracle Exadata Database MachineやOracle Zero Data Loss Recovery Applianceなど)にはExachkを使用し、非エンジニアリング・システムおよびOracle Database ApplianceにはOrachkを使用します。

さらに、計画メンテナンス・アクティビティの前と後に、ヘルス・チェックを実行することもお薦めします。

次を評価する必要があります。

  • 計画内メンテナンス・ウィンドウより前の既存のまたは新しい重要なヘルス・チェック・アラート

  • 既存のソフトウェアまたは重要なソフトウェアの推奨事項

  • テスト後の計画内メンテナンス・ウィンドウへの新しい推奨事項の追加

関連項目:

My Oracle Supportのノート1268927.2 (https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1268927.2)『ORAchk - Oracleスタックのヘルス・チェック』を参照してください。

My Oracle Supportのノート1070954.1 (https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1070954.1)『Oracle Exadata Database MachineのexachkまたはHealthCheck』を参照してください。

監視の構成

Exadataフリートを監視するための最適なルートを決定する際には、監視しているフリートのデプロイ方法(オンプレミス、Cloud@Customer、Oracle Cloud Infrastructure)と、監視の配置先またはデプロイ可能な場所を検討する必要があります。

  • オンプレミス

    オンプレミスのExadataを含むフリートの場合、Enterprise Managerは、3つのデプロイメント・タイプすべてにわたる職責について必要な監視を含んでおり、MAAのベスト・プラクティスです。

  • クラウド

    現在はEnterprise Managerやオンプレミスの監視デプロイメント・オプションがない、Cloud@CustomerまたはOCI(あるいはその両方)のみでのフリートの場合は、OCI Observability & Managementサービスで、基本的および高度な監視と管理性のための様々なオプションが提供されます。

Oracle Enterprise Managerの監視の構成

Exadataフリートにオンプレミス・デプロイメントが含まれている場合に、停止時間が発生する可能性を防ぐには、Enterprise Managerと、パフォーマンスと高可用性に関連したしきい値を検出しそれに対応する監視インフラストラクチャを、構成し使用する必要があります。

監視インフラストラクチャを使用すると、ユーザーは高可用性を監視しやすくなり、次の作業も実行できます。

  • システム、ネットワーク、アプリケーション、データベースおよびストレージの統計の監視

  • パフォーマンスおよびサービスの統計の監視

  • システムまたはアプリケーションの問題の初期警告インジケータとなる、パフォーマンスおよび高可用性のしきい値の作成

  • パフォーマンスおよび可用性アドバイスの提供

  • 確立されたアラート、ツール、およびデータベース・パフォーマンス

  • 設計されたシステムのハードウェア障害のアラートの受信

Enterprise Managerでは、オンプレミス、Cloud@CustomerおよびOCIにデプロイされたExadataおよびデータベースについて、監視と管理が提供されます。

高可用性を実現するようにEnterprise Managerを構成して、管理性ソリューションが監視対象システムと同じくらい高可用性になるようにします。

HAの構成の詳細は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。Enterprise Managerのその他のMAAベスト・プラクティスは、http://www.oracle.com/goto/maaを参照してください。

Oracle Observability and ManagementサービスをEnterprise Managerとともに使用すると、さらにExadata管理性機能が提供されます。詳細は、次の項を参照してください。

OCI Observability and Managementサービスの監視の構成

ExadataフリートにCloud@CustomerまたはOCIデプロイメント(あるいはその両方)のみが含まれており、現在はEnterprise Managerやオンプレミスの監視デプロイメント・オプションがない場合は、Oracle Cloudターゲットの監視と管理を提供するために連携する、サービスのOCI Observability and Managementプラットフォームを構成し使用する必要があります。

パフォーマンス、高可用性およびヘルスに関する基本的なデフォルト・メトリックおよびイベントは、OCIコンソールで使用できます。詳細は、次のドキュメントを参照してください。

高度なメトリックおよび管理機能は、データベース管理サービスで使用できます。

高度な分析機能は、オペレーション・インサイト・サービスで使用できます。

関連項目: Oracle Cloud Observability and Management Platform

自動サービス・リクエスト・インフラストラクチャの構成

Enterprise Managerによる監視インフラストラクチャに加え、Oracleでは、障害を検出し、フィールド・エンジニアを派遣し、障害が発生したハードウェアをユーザーの関与なく交換できます。

たとえば、Oracle Automatic Service Request (ASR)は安全かつスケーラブルな、ユーザーがインストール可能なソフトウェア・ソリューションで、これは機能として使用できます。このソフトウェアは、特定のハードウェア障害が発生したときに、Oracleのサーバーおよびストレージ・システムの自動ケース生成を使用することで、問題をより早く解決します。

関連項目: Oracle Automatic Service Request (ドキュメントID 1185493.1)

容量計画の演習

容量計画の演習を定期的に実行して、現在のハードウェア・リソースで既存のワークロードおよび予測されている拡大に対応できるようにします。

データベース統合では、新しいデータベースを既存のシステムに移行または追加する前に、この演習を行う必要があります。

なお、同時ワークロードは相互に干渉する可能性があり、予測不可能な動作を引き起こすことがあるため、パフォーマンスとHAのテストが必要になる場合があります。

データベース・マルチテナント・コンテナ・データベース、データベース・リソース管理、またはExadata統合の慣例を使用すると、既存のシステム・リソースを最適化し、想定どおりになるようにワークロード使用量を制限できます。

最新のMAAベスト・プラクティスの確認

MAAソリューションには、Oracleテクノロジのすべてのスタックが含まれているため、MAAのページで、Oracle Database、Oracle Cloud、Oracle Exadata、Zero Data Loss Recovery Appliance、Oracle Fusion Middleware、Oracle Applications UnlimitedおよびOracle Enterprise ManagerのMAAベスト・プラクティスを参照できます。

MAAソリューションおよびベスト・プラクティスは、http://www.oracle.com/goto/maaで継続的に開発および公開されています。