45 ソフトウェア・メンテナンスのベスト・プラクティス

Oracle Maximum Availability Architecture(MAA)は、業務を保護しながら中断を最小限に抑えるように設計された、Oracleソフトウェアを維持するための包括的で実績のあるフレームワークを提供します。

定期的なソフトウェア・メンテナンスは、次の場合に不可欠です:

  • ソフトウェアのセキュリティを強化し、新たに発見された脆弱性に対処する
  • テスト済およびサポートされているリリースによる安定性と信頼性を向上させる
  • 新しいデータベース、インフラストラクチャおよびオペレーティング・システム・コンポーネントと互換性を維持する
  • 最も効果的なOracleサポート診断および解決ツールへのアクセスを保証する
  • 最新の修正および機能拡張を利用できるように維持する

このドキュメントでは、MAAソフトウェア・メンテナンスのベスト・プラクティスについて説明します:

  • Oracle Database
  • Oracle Grid Infrastructure (GI)
  • Oracle Exadata Database Machine

このガイドラインは、更新が必要になるタイミングの検出、推奨されるターゲット・バージョンの選択、必要なソフトウェアの取得、サービスの中断を最小限に抑えた更新の適用など、メンテナンス・ライフサイクル全体に対応します。

ソフトウェア・メンテナンスは、次のトピックで詳細に説明されている3つの概要フェーズで構成されています:

  1. ソフトウェアの更新が必要になるタイミングの検出
  2. 推奨ソフトウェアの取得
  3. ソフトウェア更新の適用

ここで説明するMAAソフトウェア・メンテナンスのベスト・プラクティスに従うことで、業務の中断を最小限に抑えながら、データベース環境の安全性、回復性、高可用性を維持できます。

ソフトウェアの更新が必要になるタイミングの検出

組織のビジネス要件に適合するソフトウェア・メンテナンス・ポリシーを定義し、ソフトウェアが古くなった時期を事前に検出することは、セキュリティ、安定性およびコンプライアンスを維持するために重要です。Oracleでは、OracleツールとキュレートされたMy Oracle Support (MOS)リソースの両方を使用して、検出とアラートを自動化することをお薦めします。

主なプラクティス

  • コンプライアンス、リスク許容度、更新頻度に関するビジネス要件にあわせて組織のソフトウェア・メンテナンス・ポリシーを定義します。
  • Oracleツールを活用してソフトウェア・ヘルスを判断し、ソフトウェア・メンテナンス・ポリシーと一致するOracleの公式推奨事項を満たすためにソフトウェア・メンテナンスが必要になるか、推奨されるタイミングを決定します。OUAと統合されたDBCAまたはFPPでヘルス・チェックを自動化して、ポリシーに対応した一貫した推奨事項とステータスを提供します。
  • 個別修正をトリガーするクリティカルおよび重要なアドバイザ通知のしきい値を設定します。
  • ビジネスにとって重要なコンポーネント(Data Guardなど)の機能固有の推奨事項を監視します。

ソフトウェア・メンテナンス・ポリシーの定義

コンプライアンス要件、リスク許容度、およびサービス・レベル合意(SLA)を反映した、文書化されたソフトウェア・メンテナンス・ポリシーを確立します。ビジネス要件または動作要件が変更されるたびに、メンテナンス・ポリシーを確認します。

包括的なソフトウェア更新ポリシーでは、次のような指示を定義する必要があります:

  • 適用頻度: プ予防的ソフトウェア更新が適用される頻度(月次、四半期、半期、年次など)。Oracleは通常、毎月または四半期ごとに予防的更新をリリースします。

  • 更新ラグ: 最新の予防的更新(N)を適用するか、前の更新(N-1またはN-2)を適用するか。たとえば、Nは、使用可能な最新の予防的更新をインストールすることを意味します。N-1は、最新の予防的更新の1つ前の更新をインストールすることを意味します。

  • 通知レベル: 次の予防的更新の前に個別の修正の適用をトリガーする、新しく公開された問題の重大度。レベルにはクリティカルと重要が含まれています。クリティカルな監視と重要な監視のどちらを選択するかは、ビジネス・リスクの許容度と運用の優先順位によって異なります。

    • クリティカル: 重要な問題にすぐに対処します。例はMOSノート1270094.1にリストされています。

    • 重要: クリティカルな問題と重要な問題の両方にすぐに対処します。Oracle Databaseの例はMOSノート555.1にリストされています。

  • 推奨領域: ソフトウェアの推奨が監視される特定のOracle製品のコンポーネントまたは機能。ビジネスの成功に不可欠な推奨領域を特定します。推奨領域では、評価対象の基本ソフトウェアの推奨事項を超えてソフトウェアの推奨事項が拡張されます。たとえば、Data Guardは、Oracle Databaseの基本推奨事項を拡張する推奨領域です。

Oracle DatabaseおよびGrid Infrastructureソフトウェア

Oracle DatabaseおよびOracle Grid Infrastructureには、セキュリティ、安定性および変更率のバランスをとる、定義済の繰返し可能なソフトウェア・メンテナンス・ポリシーが必要です。ポリシーでは、予防的更新を適用する頻度(適用頻度)、操作を許可する最新リリースよりどの程度遅れているか(更新ラグ)、および個別アクションがトリガーされる欠落している推奨修正の重大度を指定する必要があります。

Oracleでは、単一インスタンス・システムの場合はDBCAによって調整されるアウトオブプレース・ゴールド・イメージベースの更新の使用を、クラスタ環境の場合はFPPの使用をお薦めします。Oracle Update Advisorでは、ポリシーに対応した推奨事項とすぐにデプロイ可能なイメージが提供されます。このアプローチでは、ソフトウェア・ベースラインを標準化し、リスクと停止時間を削減し、MAAの高可用性の原則に沿ったロールバックを簡素化します。

ポリシー・シナリオ

次の表に、ソフトウェア・メンテナンス目標と、目標の達成に使用される適用頻度および更新ラグ・ポリシー・ディレクティブの例を示します。

適用頻度 説明
四半期 四半期ごとに更新
半期 年2回更新
毎年 年1回更新
毎月 毎月更新
月次長期RU 長期RUでの毎月更新
更新ラグ 説明
N 最新のRUのインストール
N-1 前の(N-1) RUのインストール
N-2 前の(N-2) RUのインストール
適用頻度 更新ラグN 更新ラグN-1 更新ラグN-2
四半期 サポート対象 サポート対象 サポート対象
半期 サポート対象 サポート対象 サポート対象
毎年 サポート対象 サポート対象外1 サポート対象外1
毎月 サポート対象 サポート対象 サポート対象外2
月次長期RU サポート対象 サポート対象 サポート対象外3

脚注:

11年以上前のソフトウェアで動作する可能性があるため、サポート対象外。

2月次更新は1つ前のRUのみ拡張するため、サポート対象外。

3月次更新は1つ前の長期RUのみ拡張するため、サポート対象外。

ポリシーの例

次のポリシー例は、最も一般的な顧客目標を示しています。

  • ポリシーの例1: 適用頻度 = 四半期、更新ラグ = N
  • ポリシーの例2: 適用頻度 = 四半期、更新ラグ = N-1
  • ポリシーの例3: 適用頻度 = 月次、更新ラグ = N-1
  • ポリシーの例4: 適用頻度 = 月次長期RU、更新ラグ = N-1

ポリシーの例1: 適用頻度 = 四半期、更新ラグ = N

これは、最も一般的なデフォルトのポリシーです。リリース時に四半期ごとに最新のリリース更新(RU)を採用し、約3か月間そのRUを運用して繰り返します。このアプローチは、セキュリティと安定性に関する修正をラグなしで最新の状態に維持します。

ポリシー・サマリー:

  • 3か月間最新のRUを維持します
  • 新しいRUが四半期ごとにリリースされる場合(1月、4月、7月および10月)、新しいRUをインストールします
日付 リリース済RU インストール済RU
     
7月25日 19.28 19.28
8月25日   19.28
9月25日   19.28
10月25日 19.29 19.28 ➞ 19.29
11月25日   19.29
12月25日   19.29
1月26日 19.30 19.29 ➞ 19.30
2月26日   19.30
3月26日   19.30
4月26日 19.31 19.30 ➞ 19.31
5月26日   19.31
6月26日   19.31
7月26日 19.32 19.31 ➞ 19.32
     
     

次のポリシー例1は、Oracle Database 19cの四半期ごとのRUリリースと、28か月間のリリース月を示しています。これは、その四半期に新しくリリースされた各RUを採用し、約3か月間そのRUを運用し、リリース時に次のRUに進む、四半期ごとのラグのないポリシーを示しています。


更新ラグ = Nの四半期更新のグラフ

ポリシーの例2: 適用頻度 = 四半期、更新ラグ = N-1

保守的な頻度を好む場合は、このポリシーを選択します。前の四半期のRUを各サイクルにインストールし、そのRUで約3か月間運用してから次の前のRUに進むことで、最新のRUから1つ前のRUを維持します。これにより、四半期ごとの予測可能な頻度を維持しながら、早期導入のリスクが軽減されます。

ポリシー・サマリー:

  • 3か月間N-1のRUを維持します
  • 新しいRUが四半期ごとにリリースされる場合(1月、4月、7月および10月)、次のN-1のRUをインストールします
日付 リリース済RU インストール済RU
7月25日 19.28 19.27
8月25日   19.27
9月25日   19.27
10月25日 19.29 19.27 ➞ 19.28
11月25日   19.28
12月25日   19.28
1月26日 19.30 19.28 ➞ 19.29
2月26日   19.29
3月26日   19.29
4月26日 19.31 19.29 ➞ 19.30
5月26日   19.30
6月26日   19.30
7月26日 19.32 19.30 ➞ 19.31

ポリシーの例3: 適用頻度 = 月次、更新ラグ = N-1

このポリシーは、1つのRU (N-1)を遅らせることによって最新のRUに更新することで発生する新しい問題への潜在的な危険性を最小限に抑えながら、四半期間で毎月最新の推奨MRPを適用します。所定のRUで約1四半期運用し、各月にそのRUの現在のMRPを適用します。新しい四半期RUがリリースされたら、次の四半期の前の(N-1) RUに移行し、そのRUの月次MRPを続行します。

ポリシー・サマリー:

  • 3か月間RUを維持します
  • 前の(N-1) RUの最新のMRPを毎月インストールします
  • 新しいRUが四半期ごとにリリースされる場合(1月、4月、7月、10月)、そのRUの前の(N-1) RUと最新のMRPをインストールします。

MRP詳細:

  • MRPは、特定のRUに加えて適用される累積月次バンドルであり、RUバージョンを変更しません。MRPはLinux x86-64にのみ適用されます。
  • 表のMRPラベル(MRP3、MRP4など)は、RUリリース後の月次累積バンドルでの3番目、4番目などを示します。
日付 リリース済RU インストール済RU
10月25日 19.29 19.28 + MRP3
11月25日 19.28 + MRP3 ➞ 19.28 + MRP4
12月25日 19.28 + MRP4 ➞ 19.28 + MRP5
1月26日 19.30 19.28 + MRP5 ➞ 19.29 + MRP3
2月26日 19.29 + MRP3 ➞ 19.29 + MRP4
3月26日 19.29 + MRP4 ➞ 19.29 + MRP5
4月26日 19.31 19.29 + MRP5 ➞ 19.30 + MRP3
5月26日 19.30 + MRP3 ➞ 19.30 + MRP4
6月26日 19.30 + MRP4 ➞ 19.30 + MRP5
7月26日 19.32 19.30 + MRP5 ➞ 19.31 + MRP3

次のポリシー例3は、Oracle Database 19cの四半期ごとのRUリリースと月次MRPリリース、および28か月間のリリース月を示しています。これは、1つ遅れているRUを残して、毎月最新のMRPをそのRUに適用し、次の四半期リリースのN‑1 RUに移行する、毎月のN‑1ポリシーを示します。


適用ラグn-1の月の更新のグラフ

ポリシーの例4: 適用頻度 = 月次長期RU、更新ラグ = N-1

このポリシーは、長期間のRU基盤(長期RU)を希望するお客様を対象としており、月次MRPを使用しています。指定の長期RUを約12か月間維持し、毎月最新のMRPを適用します。次の長期RUが(毎年)使用可能になったら、年次変更期間中に前の(N-1)長期RUに進み、その新しい長期RUで月次MRPを続行します。

詳細は、MOSノート3106469.1を参照してください。

ポリシー・サマリー:

  • 長期RUを12か月間維持します
  • 前の(N-1)長期RUの最新のMRPを毎月インストールします
  • 前の(N-1)長期RUと、そのRUの最新のMRPを年次変更期間中に毎年インストールします。
日付 リリース済RU インストール済RU
1月26日 19.30 19.28 + MRP5 ➞ 19.28 + MRP6
2月26日 19.28 + MRP6 ➞ 19.28 + MRP7
3月26日 19.28 + MRP7 ➞ 19.28 + MRP8
4月26日 19.31 19.28 + MRP8 ➞ 19.28 + MRP9
5月26日 19.28 + MRP9 ➞ 19.28 + MRP10
6月26日 19.28 + MRP10 ➞ 19.28 + MRP11
7月26日 19.32 (長期RU) 19.28 + MRP11 ➞ 19.28 + MRP12
8月26日 19.28 + MRP12 ➞ 19.28 + MRP13
9月26日 19.28 + MRP13 ➞ 19.28 + MRP14
10月26日 19.33 19.28 + MRP14 ➞ 19.28 + MRP15
11月26日 19.28 + MRP15 ➞ 19.28 + MRP16
12月26日 19.28 + MRP16 ➞ 19.28 + MRP17
1月27日 19.34 19.28 + MRP17 ➞ 19.28 + MRP18
2月27日 19.28 + MRP18 ➞ 19.32 + MRP7
3月27日 19.32 + MRP7 ➞ 19.32 + MRP8
4月27日 19.35 19.32 + MRP8 ➞ 19.32 + MRP9
5月27日 19.32 + MRP9 ➞ 19.32 + MRP10
6月27日 19.32 + MRP10 ➞ 19.32 + MRP11
7月27日 19.36 (長期RU) 19.32 + MRP11 ➞ 19.32 + MRP12
8月27日 19.32 + MRP12 ➞ 19.32 + MRP13
9月27日 19.32 + MRP13 ➞ 19.32 + MRP14
10月27日 19.37 19.32 + MRP14 ➞ 19.32 + MRP15
11月27日 19.32 + MRP15 ➞ 19.32 + MRP16
12月27日 19.32 + MRP16 ➞ 19.32 + MRP17
1月28日 19.38 19.32 + MRP17 ➞ 19.32 + MRP18
2月28日 19.32 + MRP18 ➞ 19.36 + MRP7

次のポリシー例4のグラフは、Oracle Database 19cの四半期ごとのRUリリースと月次MRPリリース、および38か月間のリリース月を示しています。これは月次の長期RU、N‑1ポリシーを示しています。このポリシーでは、月次MRPを使用して約1年間、指定された長期RUで実行し、毎年前の長期RUに移行し、月次MRPを続行します。


適用ラグn-1の月次長期RU更新のグラフ

ソフトウェア・ヘルスの判定

ソフトウェア・メンテナンス・ポリシーが確立されると、インストールされたソフトウェアをポリシーとOracleの公式推奨に照らして評価し、ソフトウェア・ヘルスを判断します:

  • インストールされているソフトウェアがOracleの推奨される予防的更新に遅れているかどうかを判定します。
  • Oracleによって発表されたクリティカルな修正または重要な修正が、基本製品ソフトウェア(Oracle Databaseなど)に欠落しているかどうかを判定します。
  • Oracleによって発表されたクリティカルな修正または重要な修正が、特定のOracle製品のコンポーネントまたは機能(Data Guard for Oracle Databaseなど)に欠落しているかどうかを判定します。

適用頻度よりも頻繁に(毎週など)ソフトウェア・ヘルスを評価して、新たに推奨されたクリティカルな修正または重要な修正が公開された直後に特定します。

Oracle DatabaseおよびGrid Infrastructureソフトウェア

Oracleでは、Oracle Update Advisor (OUA)と統合された自動化ツールを使用して、Oracle DatabaseおよびOracle Grid Infrastructureのソフトウェア・ヘルスを評価することをお薦めします。このアプローチにより、手動による追跡が減り、一貫性が向上します。

Database Configuration Assistant (DBCA/DBCACTL)やフリート・パッチ適用およびプロビジョニング(FPP)などの自動ツールは、OUAと統合されている場合、インストール済のソフトウェアを定義済のメンテナンス・ポリシーとOracleの公式推奨に照らして評価し、ソフトウェアのヘルス・ステータスを判定します。OUAと統合された自動化ツールを使用することで、欠落しているクリティカルな修正または重要な修正の特定が大幅に簡素化されます。

ソフトウェアのヘルス・ステータス

ステータス アクション
緑

アクションは不要です

インストールされたソフトウェアは、ポリシーに基づいてOracleの推奨事項を満たしています。
黄

更新をお薦めします

インストールされたソフトウェアに重要な修正が欠落しているか、Oracleの推奨事項が1サイクル遅れています。
赤

更新が必要です

インストールされたソフトウェアにクリティカルな修正が欠落しているか、Oracleの推奨事項が1サイクルより多く遅れています。

例

次に例を示します。

  • インストールされているソフトウェアは、Oracle Databaseリリース更新23.8です。Oracle Databaseリリース更新23.9は、リリースおよび推奨された最新バージョンです。したがって、インストールされているRUは最新のRUに1つ遅れたRUです。
  • ポリシーを指定しない場合、デフォルトが使用されます(適用頻度 = 四半期、更新ラグ = ラグなし)。

デフォルト・ポリシーを使用したDBCAの例

$ dbca -managePatches -checkPatchStatus -silent
   "softwareHealth" : "YELLOW",
   "comment" : "One cycle behind your policy.",
   "recommendedVersion" : "23.9"

デフォルト・ポリシーを使用したFPPの例(FPPサーバー・モードを使用)

$ rhpctl evaluate patch -image DB238000
Software health status: "YELLOW"
Software health comment: "One cycle behind your policy."
Software Type: "DB"
Current version: "23.8.0.25.4"
Recommended version: "23.9"

半年ごとの適用頻度を使用したDBCACTLの例

$ dbcactl -managePatches -checkPatchStatus -applyFrequency SEMI_ANNUAL
  "softwareHealth" : "GREEN"

詳細は、Oracle Update Advisorを使用した更新エクスペリエンスの合理化を参照してください。

代替/補足方法

自動評価ツールを使用していない場合、管理者は次を使用して推奨事項とヘルス・ステータスを手動で追跡します:

  • Exachk – Exachkを定期的に実行し、推奨されるソフトウェア・チェックを確認します。
  • MOSドキュメント - 予防的ソフトウェア更新リースの通知、クリティカルな修正、推奨される修正、および置換の更新について、優先されるMOSノートを予防的に監視します。

詳細は、「推奨ソフトウェアの取得」を参照してください。

Exadataソフトウェア

Exadata環境では、Oracleは次のことをお薦めします:

  • Exachk – Exachkを実行し、推奨されるソフトウェア・チェックを確認します。
  • MOSドキュメント - 予防的ソフトウェア更新リースの通知、クリティカルな修正、推奨される修正、および置換の修正について、優先されるMOSノートを予防的に監視します。

詳細は、「推奨ソフトウェアの取得」を参照してください。

推奨ソフトウェアの取得

適切なOracleソフトウェア・バージョンおよびパッチを選択してデプロイすることは、可用性、セキュリティおよびサポートに不可欠です。Oracleの自動化ツールまたは検証されたMOSリソースを使用して、適切なターゲットを決定し、セキュアでポリシーに準拠したソフトウェアを取得します。

主なプラクティス

  • 可能な場合は、自動化ツール(Oracle Update Advisorを使用したDBCA、FPP)を使用して、手動エラーを最小限に抑えます。
  • 自動化が実現できない環境では、Exachkの出力と関連するMOSノートを注意深く参照してください。
  • Oracle提供のデジタル署名およびチェックサムを使用して、ダウンロードしたアーティファクトを常に検証します。

DatabaseおよびGrid Infrastructure (オンプレミス)

推奨されるアプローチ – Oracle Update Advisorを使用したDBCAまたはFPP

Oracle Update Advisor機能を使用したゴールド・イメージとして推奨ソフトウェアを取得します。ゴールド・イメージを使用して、推奨されるアウトオブプレース・イメージベースの方法で更新を実行します。

  1. 推奨ソフトウェア(ポリシーに一致し、必要なすべてのパッチを含む)を含むゴールド・イメージを生成します。
  2. 推奨ゴールド・イメージをダウンロードします。

ゴールド・イメージは自動的に調整されます:

  • Oracleの推奨リリース更新、および必要な個別パッチやクリティカル・パッチを含めます。
  • パッチの競合を自動的に解決し、指定された場合は顧客固有のパッチを保持または追加します。

例

DBCAの例

$ dbca -managePatches -generateGoldImage -silent
$ dbca -managePatches -downloadGoldImage -goldImageDownloadLocation /u01/swdepot -silent

FPPの例(FPPサーバー・モードを使用)

$ rhpctl evaluate patch -image DB238000 -generateimage -importtoimage DB239000

機能固有のデータベースの推奨事項(手動プロセスのみ)

  • Data GuardやData Pumpなどの追加機能については、現在、Oracle Update Advisorは機能固有の推奨事項を提供していません。
  • MOSノート2781612.2を参照して、Data GuardやData Pumpなどのコア・データベース機能以外のデータベース機能の追加の個別推奨パッチを確認します。

コア・データベース・ソフトウェアに手動の方法を使用する場合:

別の方法として、関連するMOSノートを確認し、Exachkを実行して、ゴールド・イメージまたは個別推奨パッチをダウンロードします。

  • 関連するMOSノートを確認し、推奨されるソフトウェアを特定します。
    • 推奨リリース、リリース更新(RU)および月次推奨パッチ(MRP)については、MOSノート888.1を確認します
    • クリティカルな問題の推奨される更新については、MOSノート1270094.1を確認します
    • 重要な問題の推奨される更新については、MOSノート555.1を確認します
    • エラー修正のサポート終了日については、MOSノート742060.1を確認します
  • Exachkを実行し、推奨されるソフトウェア・チェックを確認します。
    • 推奨リリースおよびリリース更新(RU)については、MAAスコアカードのセクションを確認します
    • 推奨されるクリティカルな問題の更新については、クリティカルな問題のセクションを確認します
    • 重要な問題の推奨される更新については、重要なバグ修正チェックを確認します
  • ソフトウェア・メンテナンス・ポリシーに準拠するように推奨事項を調整します。
  • MOSノート2915366.2に従って、DatabaseおよびGrid Infrastructureソフトウェア・ホームのゴールド・イメージをリクエストおよびダウンロードし、インベントリと推奨ソフトウェアを事前に候補パッチとして手動で特定します。

Exadata (オンプレミス)

関連するMOSノートを確認し、Exachkを実行して、推奨される更新をダウンロードします。

  • 関連するMOSノートを確認し、推奨されるソフトウェアを特定します。
    • 推奨されるExadataソフトウェアについては、MOSノート888828.1を確認します。
    • クリティカルな問題の推奨される更新については、MOSノート1270094.1を確認します
    • 重要な問題の推奨される更新については、MOSノート556.1を確認します
  • Exachkを実行し、推奨されるソフトウェア・チェックを確認します。
    • 推奨リリースおよびリリース更新(RU)については、MAAスコアカードのセクションを確認します
    • 推奨されるクリティカルな問題のパッチについては、クリティカルな問題のセクションを確認します
    • 重要な問題の推奨される更新については、重要なバグ修正を確認します
  • ソフトウェア・メンテナンス・ポリシーに準拠するように推奨事項を調整します。
  • MOSノート888828.1に従って、Exadataの計算ノード、ストレージ・サーバーおよびスイッチの推奨される更新をMOSから直接ダウンロードします。

ソフトウェア更新の適用

適切に計画され、テストされ、適切に実行されたソフトウェア更新は、稼働時間を最大化し、ビジネスの中断を最小限に抑えるために重要です。可能なかぎり、Oracleでは、安全なロールバックと迅速な問題解決を確実にするために、アウトオブプレースのゴールド・イメージベースのパッチ適用(特にクラスタ化されたシステム)をお薦めしています。

主なプラクティス

  • ソフトウェアを更新する前に、Exachk/Orachkを実行し、推奨されるベスト・プラクティスに従わない構成を修正します。
  • クライアント・フェイルオーバーのベスト・プラクティスに従って、データベース・インスタンスの接続を中断するローリング更新中のアプリケーション・レベルの影響を軽減します。詳細は、「アプリケーションの継続的な可用性」を参照してください。
  • 本番に類似したワークロードおよび構成を使用して、非本番環境で更新およびロールバック・プロセスをテストします。
  • Data Guard Standby-First Patch適用アプローチを使用して、ミッション・クリティカルなシステムを更新する際のリスクとプライマリ・データベースの影響を最小限に抑えます。詳細は、MOSノート1265700.1を参照してください。
  • ソフトウェア変更の直前に、システムおよびデータベースのバックアップを取得します。
  • ソフトウェアを変更する前に、常に検証およびバックアップし、実績のあるロールバック計画を用意してください。
  • フリート・パッチ適用およびプロビジョニング(FPP)またはDatabase Configuration Assistant (DBCA)の自動化を使用して、一貫性を確保し、手動エラーを削減します。
  • スタンドアロン/非クラスタ・システムのアウトオブプレースのゴールド・イメージベースのデータベース更新には、DBCAを使用します。
  • FPPは、Oracle RACやExadataなどのクラスタ環境での調整された、アウトオブプレース、ローリング、ゴールド・イメージベースのDatabaseおよびGrid Infrastructureの更新に使用します。
  • 特定のパッチ・タイプまたは中断を最小限に抑える必要がある状況に対してのみ、オンライン/インプレース更新を適用します。詳細は、MOSノート761111.1を参照してください。

ソフトウェア更新方法の選択: 利点とトレードオフ

表45-1 クラスタ化されていないシステム(スタンドアロン・ホスト)のデータベース・ソフトウェア

方法 利点/トレードオフ

アウトオブプレース(ゴールド・イメージ)とDBCA

(推奨)
  • 高速、シンプル、簡単なロールバック
  • 追加のディスク領域が必要
$ dbca -moveDatabase -sourceDB <dbname> -silent
OPatchを使用したインプレース(パッチ)
  • 最小限の余分なディスク領域
  • リスクが高い、パッチの競合、適用/ロールバックが遅い
OPatchを使用したオンライン・インプレース(パッチ)
  • データベースの停止時間またはデータベース接続の中断なし
  • サポートされているパッチ(MRP/個別パッチ)に制限

表45-2 クラスタ・システム(Oracle RAC/Exadata)のデータベース・ソフトウェア

方法 利点/トレードオフ

アウトオブプレース(ゴールド・イメージ)、FPPを使用したRACローリング

(推奨)
  • 高速、シンプル、完全なクラスタ・オーケストレーション、簡単なロールバック
  • 追加のディスク領域が必要
$ rhpctl move database –sourcewc <src> –patchedwc <dest>
インプレース(パッチ)、OPatch/OPatchAutoを使用したRACローリング
  • 最小限の余分なディスク領域、データベースの停止時間なし
  • リスクが高い、パッチの競合、適用/ロールバックが遅い、複雑なロールバック
FPPを使用したオンライン・インプレース(パッチ)
  • データベースの停止時間またはデータベース接続の中断なし
  • サポートされているパッチ(MRP/個別パッチ)に制限
FPPを使用した非ローリング
  • すべての更新を一度に適用し、計画メンテナンス時間を短縮
  • データベース全体の停止時間

表45-3 クラスタ・システム(Oracle RAC/Exadata)のGrid Infrastructureソフトウェア

方法 利点/トレードオフ

アウトオブプレース(ゴールド・イメージ)、FPPを使用したRACローリング

(推奨)
  • 高速、シンプル、完全なクラスタ・オーケストレーション、簡単なロールバック
  • 追加のディスク領域が必要
$ rhpctl move gihome –sourcewc <src> –destwc <dest>
停止時間なしのアウトオブプレース(ゴールド・イメージ)、FPPを使用したRACローリング
  • データベース接続の中断なし
  • 追加のディスク領域が必要
\
$ rhpctl move gihome –sourcewc <src> –destwc <dest> -tgip
インプレース(パッチ)、OPatch/OPatchAutoを使用したRACローリング
  • 最小限の余分なディスク領域
  • リスクが高い、パッチの競合、適用/ロールバックが遅い、複雑なロールバック

表45-4 Exadataシステム・ソフトウェア

方法 利点/トレードオフ

patchmgrまたはFPPを使用したローリング更新

(推奨)

  • ストレージ・サーバー
  • データベース・サーバー
  • ネットワーク・ファブリック・スイッチ
  • データベースの停止時間なし、シンプルで完全なシステム・オーケストレーション
$ patchmgr --dbnodes <group_file> --repo <repo>
 --upgrade --target_version <version> --rolling

patchmgrまたはFPPを使用したライブ更新

  • データベース・サーバー
  • データベース接続の中断なし、セキュリティの問題に対処するための部分的な更新をサポート
  • 未処理の作業更新項目はオンラインで完了できず、システムの再起動が必要
$ patchmgr --dbnodes <group_file> --repo <repo> --upgrade
 --target_version <version> --rolling --live-update-target full

patchmgrまたはFPPを使用した非ローリング

  • ストレージ・サーバー
  • データベース・サーバー
  • ネットワーク・ファブリック・スイッチ
  • すべての更新を一度に適用し、計画メンテナンス時間を短縮
  • システム全体の停止時間