この記事はGlen HawkinsによるFrom Green Lights to Gold Tiers: Operationalizing Software Health for MAA Resilienceを日本語に翻訳したものです。

2026年3月23日

はじめに：”稼働中”だけでは不十分な理由

多くのDBAは、データベースが”稼働している”かどうかで成功を定義します。しかし、Oracle Maximum Availability Architecture (MAA)の文脈では、可用性は単なる二択の状態ではなく、レジリエンスの指標です。 Oracle Update Advisorに関する前回の投稿で強調したとおり、”ソフトウェアの健全性(Software Health)”こそがこのレジリエンスの土台です。

Oracle Update Advisor(OUA)の観点では、ソフトウェアの健全性が「赤」または「黄」である場合、どれほど堅牢なMAAアーキテクチャであってもリスクにさらされています。この記事では、継続的な可用性を確保するために、ソフトウェア保守戦略をMAAのティア(MAAベストプラクティスでここで定義)と整合させる方法を解説します。

1. 健全性ステータスをMAAのSLAにマッピング

Oracle Update Advisorは、選択したポリシーに基づいてシンプルな信号機ステータス(緑、黄、赤)を提供します。 たとえば月次ポリシー(月次更新を望むお客様)であれば、月次のMonthly Recommended Patches(MRP)適用と一致します。 四半期ごとのRelease Update(RU)やMRPに関する選択ポリシーとの一致に加えて、MRPおよび/またはRUに加えて、重大(critical)または重要(important)な更新の未適用によってもステータスは影響を受けます。 OUAステータスとMAAの間に直接的な対応関係はありませんが、これらのステータスがMAAリスクにどう反映されるのかを示すと、次のとおりです。

  • 緑(同期済み): 安定性やデータベースの可用性に深刻な影響を与える既知の重大なバグから保護されています。MAAのティアに関わらず、ソフトウェア健全性は最適な状態です。
  • 黄(ポリシーに応じてRUまたはMRPが1つ遅れ): 保守負債(Maintenance Debt)ゾーンに入りつつあります。Data GuardやRACは稼働しているかもしれませんが、性能問題、ブラウンアウト(brownouts)、エッジケースの障害を防ぐ最新の安定性修正が適用されていません。アプリケーションの重要度によっては、Silver MAA以上で問題になる可能性があります。
  • 赤(旧バージョン): お客様のMAA SLA(ティアに関係なく)は実質的に損なわれています。Gold/Platinum/Diamondのように冗長性を高めても、新しいRelease Update(RU)ですでに修正済みの既知ソフトウェア欠陥やセキュリティ脆弱性を完全に守ることはできません。

2. Out-of-Placeの利点：計画メンテナンスを高速化する

26aiのドキュメントでは、ゴールド・イメージを用いたホーム外(Out-of-Place)パッチ適用アウトを強く推奨しています。まだゴールド・イメージを使用していない場合は、ソフトウェア更新時に活用できるよう、戦略を切り替えるタイミングです。これは重要なMAAベストプラクティスとされています。

  • ダウンタイムの削減: データベース稼働中に、ゴールド・イメージから新しいOracle Homeを作成・準備できるため、メンテナンス時間を長時間かかるの適用(apply)ではなく、簡単な切り替え(switch)に短縮できます。
  • リスクゼロのロールバック: ソフトウェア更新で問題が発生した場合でも、以前のOracle Homeへほぼ即時に戻せます。これは、RTOをほぼゼロに近づけるPlatinumまたはDiamondティアの目標に合致します。

3. ティア別の保守ポリシー

すべてのデータベースが「N」バージョン(最新)にする必要はありません。FPP、DBCA、またはAutoUpgrade(26.2以降)経由のOracle Update Advisorを使用して、MAAティアに合うポリシーを設定してください。

  • Bronze/Silver：最新機能より安定性を優先し、「RUを1つ遅らせる(N-1)」を選択する場合があります。
  • Gold/Platinum/Diamond：「N(最新)」を目標にするか、現在のRUに加えてMonthly Recommended Patches(MRP)を適用し、サイト全体の障害につながる前に影響の大きいバグへ対処すべきです。

ミッションクリティカルな安定性 + 月次のタイムリーな更新における推奨デフォルト設定(どのMAAティアにも適用可能ですが、特にミッションクリティカル環境向け)

ミッションクリティカルな環境(どのMAAティアであっても)において、タイムリーな(月次の)安定性/セキュリティ更新プログラムを受け取りつつ、”ポリシー面”で最も安全かつ安定した状態を維持するには、1つ前の長期リリース更新(Long Term RU)を使用したMonthly – Long Term Release Update(M-LTRU)が最適です(ただし、更新期間に重複がない場合は、現在のLTRUを使用します)。

  • ポリシー設定: 適用頻度=月次LTRU, アップデート差分=N-1
  • 年次のLTRU切り替え頻度: お客様は通常、年1回(多くは1,2月ごろ)LTRUを切り替え、新しいLTRUはリリース後およそ6か月経ってから採用
  • MRPによる月次アップデート: MRPを毎月インストールして、最小限かつ安定性およびセキュリティを重視の更新で最新の状態を維持します。一般的には、採用済みの(1つ前の)LTRUに対してMRP7～MRP18を適用
  • 次のLTRUを取り込むための準備期間: 新しいLTRUのMRP1～MRP6の期間を、将来の切り替えに向けた検証・準備の準備期間として利用(新しいLTRUは、約1年分の変更が蓄積されている可能性があるため)
  • 重要な重複の現実: MRPは18か月分ありますが、前のLTRUと現行LTRUの間で、MRPには約6か月の重複期間があるためRU更新間隔を18か月空けられると捉えるべきではありません。

このアプローチでは、可用性、サービス停止、セキュリティリスクに影響を与える可能性が最も高い修正プログラムを毎月最新の状態に保ちながら、予測可能な年間「メジャー」アップデート導入ポイントを設定できます。アップデートポリシーに関しては、多くのサポートオプションが用意されていることにご留意ください。たとえば、同様のLTRUアプローチを採用しつつ、6か月の遅延をなくすことも可能です。

さまざまなポリシー選択肢の詳細は、MAA Software Maintenance Best Practicesをご確認ください。

4. FPPでフリートを自動化する

大規模なミッションクリティカル・フリートを管理するお客様(多くの場合”Gold MAA以上”に該当)にとって、手動による健全性チェックは不可能です。Oracle Update AdvisorとFleet Patching and Provisioning(FPP)の統合により、次が可能になります。

  • 数千ものデータベースにまたがる健全性ギャップを即座に特定する。
  • 推奨される”ゴールド・イメージ”を自動的にダウンロードして展開する。
  • 環境を標準化することで、フェイルオーバー失敗の主因となる”snowflake”構成を排除し、環境を標準化する。

フリート管理を行っていないお客様向けに、OUAはDBCAおよびAutoUpgradeとも統合されており、ソフトウェア健全性に関するベストプラクティスおよびガイドラインを確実に遵守するための追加オプションを提供します。

結論：健全性は可用性の前提条件

Maximum HealthなしにMaximum Availabilityは実現できません。Oracle Update Advisorを用いて”緑”ステータスを維持し、Out-of-Placeパッチ適用のワークフローを採用することで、ソフトウェア保守をリスクの高い作業から、MAA戦略の戦略的コンポーネントへと変革できます。

今日からソフトウェア健全性の更新を効率化したいですか？

Oracleでは、お使いのOracleゴールドイメージ・ソリューションに対する複数レベルの統合により、お客様環境内でOracle Update Advisorを容易にご利用いただけます。

  • FPP経由またはDBCA経由でOracle Update Advisorを実行し、”ゴールドティア”のアーキテクチャが”赤”の健全性ソフトウェアで動いていないか確認してください。

さらに、AutoUpgrade 26.2以降も利用できます。これはOracle Update Advisorと統合してゴールド・イメージを生成しますが、現時点ではソフトウェア推奨機能はまだ提供されていません。