Oracle Cloud Infrastructureドキュメント

Oracle Exadata Database Service on Cloud@Customerシステムのパッチ適用および更新

Oracle Exadata Database Service on Cloud@Customerシステムを更新およびパッチ適用する方法について学習します

親トピック: ハウツー・ガイド

ユーザー管理メンテナンス更新の実行

最適な作業指示でセキュアなOracle Exadata Database Service on Cloud@Customerシステムをメンテナンスするには、次のタスクを定期的に実行する必要があります:
  • VMクラスタ仮想マシンのOracle Grid InfrastructureおよびOracle Databaseソフトウェアにパッチを適用します。詳細および手順は、Exadata Cloud@Customerシステムのパッチ適用および更新を参照してください。
  • VMクラスタ仮想マシンのオペレーティング・システムを更新します。詳細および手順は、ゲストVMオペレーティング・システムの更新およびOracle Clusterwareの構成および管理を参照してください。

Oracle Exadata Database Service on Cloud@Customerシステムのパッチおよび更新

コンソール、APIまたはCLIを使用して、Exadataデータベース仮想マシンおよびデータベース・ホームでパッチ適用操作を実行する方法について学習します。

dbaascliユーティリティを使用したシステムへのパッチ適用の詳細および手順は、Oracle Exadata Database Service on Cloud@Customerシステムの手動によるパッチおよび更新を参照してください。

Exadata Cloud@Customerに四半期ごとのデータベース・パッチを適用する方法の詳細および例は、My Oracle Supportノート: How to Apply Database Quarterly Patch on Exadata Cloud Service and Exadata Cloud at Customer Gen 2 (Doc ID 2701789.1)を参照してください。

パッチ適用操作時の継続的サービスの実現に関する詳細なガイダンスは、『MAAソリューションの継続的サービスのアプリケーション・チェックリスト』(ホワイト・ペーパー)を参照してください。

関連トピック

親トピック: Oracle Exadata Database Service on Cloud@Customerシステムのパッチ適用および更新

VMクラスタおよびデータベース・ホームのパッチ適用および更新

コンソールまたはAPIを使用して、VMクラスタのGrid Infrastructure (GI)およびデータベース・ホームでパッチ適用操作を実行する方法について学習します

親トピック: Oracle Exadata Database Service on Cloud@Customerシステムのパッチおよび更新

VMクラスタのGIおよびデータベース・ホームのパッチ適用および更新について

VMクラスタにパッチを適用すると、VMクラスタ内の各VMゲストのコンポーネントが更新されます。VMクラスタへのパッチ適用によってGrid Infrastructure (GI)が更新され、データベース・ホームへのパッチ適用によってそのホームのデータベースで共有されているOracle Databaseソフトウェアが更新されます。

使用可能なパッチの詳細は、My Oracle Supportノート(https://support.oracle.com/epmos/faces/DocContentDisplay?id=2333222.1)を参照してください。

次のベスト・プラクティスを検討してください:
  • システムへのパッチ適用には再起動が必要なため、ユーザーへの影響が最小限に抑えられるときに、操作を一度に実行することを計画してください。
  • パッチを適用する前にデータベースをバックアップすることをお薦めします。データベースのバックアップの詳細は、Exadata Database Service on Cloud@Customerでのデータベースのバックアップおよびリカバリの管理を参照してください。
  • Oracleでは、Oracle Grid Infrastructure RUバージョンが最新のデータベースRUバージョンから6か月以内になっていることをお薦めします。データベース・バージョンを更新する場合は、可能な場合はGIバージョンも更新する必要があります。
  • データベースにパッチを適用して、現在のホームのデータベース・バージョン以外のバージョンにするには、ターゲット・バージョンを実行しているデータベース・ホームにデータベースを移動します。コンソールを使用した別のホームへのデータベースの移動を参照してください。
Oracle Exadata Database Service on Cloud@Customerシステムのパッチおよび更新の前提条件

CPSホストでOracleによってダウンロードされ、使用可能になっている最新のクラウド・パッチを確認して適用します。

パッチ適用の失敗を回避するため、次の条件が満たされていることを確認してください:
  • データベース・ホスト・ファイル・システムの/u01ディレクトリに、パッチ適用プロセスを実行するための15 GB以上の空き領域があります。
  • Oracle ClusterwareがVMクラスタで稼働中です。
  • VMクラスタのすべてのノードが稼働中です。
VMクラスタのGIおよびデータベース・ホームのパッチ適用および更新に対するコンソールの使用

コンソールを使用して、VMクラスタおよびデータベース・ホームでのパッチ操作の履歴の表示、パッチの適用、およびパッチ操作のステータスのモニターを行う方法について学習します。

事前チェック・アクションを使用して、適用するパッチの要件をVMクラスタまたはデータベース・ホームが満たしていることを確認することをお薦めします。

親トピック: VMクラスタおよびデータベース・ホームのパッチ適用および更新

コンソールを使用したGrid Infrastructureの更新の実行

VMクラスタにGrid Infrastructure更新を適用する方法について学習します。

  1. ナビゲーション・メニューを開きます。「Oracle Database」で、「Exadata Database Service on Cloud@Customer」をクリックします。
    デフォルトでVMクラスタが選択されています。
  2. コンパートメントを選択します。
    選択したコンパートメントに対するVMクラスタのリストが表示されます。
  3. VMクラスタのリストで、パッチ操作を実行するVMクラスタをクリックします。
  4. 表示されたVMクラスタの詳細ページで、「更新」をクリックします。
  5. VMクラスタの使用可能なパッチのリストを確認します。

    Oracle Grid Infrastructureソフトウェア・イメージは、クラスタへのパッチ適用に使用できるOracle Grid Infrastructureソフトウェア・イメージです。パッチ適用に使用できるOracleイメージの更新タイプは、「パッチ」です。

    カスタムGrid Infrastructureソフトウェア・イメージは、事前に作成したGrid Infrastructureソフトウェア・イメージです。

    「コンパートメントの選択」セレクタを使用して、データベース・ソフトウェア・イメージを含むコンパートメントを指定します。

    「リージョン」フィルタを使用して、別のリージョンで作成されたソフトウェア・イメージにアクセスします。

  6. 目的のパッチの「アクション」アイコン(3つのドット)をクリックし、次のいずれかのアクションをクリックします:
    • 事前チェック: 前提条件をチェックして、パッチを正常に適用できることを確認します。パッチを適用する前にこの操作を実行することを強くお薦めします。事前チェックによってクラスタの可用性が影響を受けることはなく、すべて正常に動作し続けます。
    • Grid Infrastructure更新の適用:選択したパッチを適用します。
  7. 要求されたら確認します。

パッチ・リストに操作のステータスが表示されます。事前チェックの実行中、パッチのステータスは「チェック中」と表示されます。パッチの適用中、パッチのステータスは「適用中」と表示され、VMクラスタのステータスは「更新中」と表示されます。パッチ適用中は、VMクラスタとそのリソースに対するライフサイクル操作が一時的に利用できなくなります。パッチ適用が正常に完了すると、パッチのステータスは「適用済」に変わり、VMクラスタのステータスは「使用可能」に変わります。個々のパッチ操作の詳細を表示するには、「更新履歴」をクリックします。Grid Infrastructureへのパッチ適用はノードごとにローリング方式で行われ、クラスタ・リソースは各ノードで停止および再起動されます。

コンソールを使用したデータベース・ホームでの更新操作の実行

データベース・ホームにパッチを適用する方法について学習します。

  1. ナビゲーション・メニューを開きます。「Oracle Database」で、「Exadata Database Service on Cloud@Customer」をクリックします。
    デフォルトでVMクラスタが選択されています。
  2. コンパートメントを選択します。
    選択したコンパートメントに対するVMクラスタのリストが表示されます。
  3. VMクラスタのリストで、データベース・ホームが存在するVMクラスタをクリックします。
  4. 「データベース・ホーム」をクリックします。
  5. データベース・ホームのリストで、パッチ操作を実行するデータベース・ホームをクリックします。
  6. 「更新」をクリックします。
  7. データベース・ホームの使用可能なパッチのリストを確認します。

    Oracle Databaseソフトウェア・イメージは、データベースの更新に使用できる一般利用可能なOracle Databaseソフトウェア・イメージです。パッチ適用に使用できるOracleイメージの更新タイプは、「パッチ」です。

    カスタム・データベース・ソフトウェア・イメージは、事前に作成したデータベース・ソフトウェア・イメージです。

    「コンパートメントの選択」セレクタを使用して、データベース・ソフトウェア・イメージを含むコンパートメントを指定します。

    「リージョン」フィルタを使用して、別のリージョンで作成されたソフトウェア・イメージにアクセスします。

  8. 目的のパッチの「アクション」アイコン(3つのドット)をクリックし、次のいずれかのアクションをクリックします:
    • 事前チェック: 前提条件をチェックして、パッチを正常に適用できることを確認します。パッチを適用する前にこの操作を実行することを強くお薦めします。事前チェックによってクラスタの可用性が影響を受けることはなく、すべて正常に動作し続けます。
    • データベース更新の適用:選択したパッチを適用します。
  9. 要求されたら確認します。

パッチ・リストに操作のステータスが表示されます。事前チェックの実行中、パッチのステータスは「チェック中」と表示されます。パッチの適用中、パッチのステータスは「適用中」、データベース・ホームおよびそれに含まれるデータベースのステータスは「更新中」と表示され、VMクラスタとそのリソースに対するライフサイクル操作は一時的に利用できなくなります。パッチは、ノードごとにローリング方式でデータベース・ホームに適用され、ホーム内の各データベースは停止されてから再起動されます。これにより、一時的なサービス中断が発生する可能性があります。パッチ適用が正常に完了すると、パッチのステータスは「適用済」に変わり、データベース・ホームのステータスは「使用可能」に変わります。個々のパッチ操作の詳細を表示するには、「更新履歴」をクリックします。

コンソールを使用した更新履歴の表示

各更新履歴エントリは、試行されたパッチ操作を表し、操作が成功したか失敗したかを示します。失敗したパッチ操作は再試行できます。操作を繰り返すと、新しいパッチ履歴エントリが作成されます。

コンソールの更新履歴ビューには、dbaascliなどのコマンドライン・ツールを使用して適用されたパッチは表示されません。

親トピック: VMクラスタのGIおよびデータベース・ホームのパッチ適用および更新に対するコンソールの使用

コンソールを使用したVMクラスタの更新履歴の表示

VMクラスタに適用されたパッチの履歴を表示する方法について学習します。

  1. ナビゲーション・メニューを開きます。「Oracle Database」で、「Exadata Database Service on Cloud@Customer」をクリックします。
    デフォルトでVMクラスタが選択されています。
  2. コンパートメントを選択します。
    選択したコンパートメントに対するVMクラスタのリストが表示されます。
  3. VMクラスタのリストで、目的のVMクラスタをクリックします。
  4. 「更新履歴」をクリックします。

そのVMクラスタのパッチ操作の履歴が、データベース・ホームでのパッチ操作の履歴とともに表示されます。

コンソールを使用したデータベース・ホームの更新履歴の表示

データベース・ホームに適用されたパッチの履歴を表示する方法について学習します。

  1. ナビゲーション・メニューを開きます。「Oracle Database」で、「Exadata Database Service on Cloud@Customer」をクリックします。
    デフォルトでVMクラスタが選択されています。
  2. コンパートメントを選択します。
    選択したコンパートメントに対するVMクラスタのリストが表示されます。
  3. VMクラスタのリストで、データベース・ホームが存在するVMクラスタをクリックします。
  4. 「データベース・ホーム」をクリックします。
    データベース・ホームのリストが表示されます。
  5. データベース・ホームのリストで、目的のデータベース・ホームをクリックします。
  6. 「更新履歴」をクリックします。

そのデータベース・ホームのパッチ操作の履歴が、それが属するVMクラスタでのパッチ操作の履歴とともに表示されます。

コンソールを使用した別のホームへのデータベースの移動

目的のバージョンのOracle Databaseを実行しているデータベース・ホームに移動することで、VMクラスタ・データベースのバージョンを更新できます。

  1. ナビゲーション・メニューを開きます。「Oracle Database」で、「Exadata Database Service on Cloud@Customer」をクリックします。
    デフォルトでVMクラスタが選択されています。
  2. コンパートメントを選択します。
    選択したコンパートメントに対するVMクラスタのリストが表示されます。
  3. VMクラスタのリストで、移動するデータベースが存在するVMクラスタをクリックします。
  4. 「データベース・ホーム」をクリックします。
  5. データベース・ホームのリストで、目的のデータベース・ホームをクリックします。
  6. 「データベース」をクリックします。
  7. データベースのリストで、目的のデータベースをクリックします。
  8. 「アクション」をクリックし、「データベースの移動」を選択します。
  9. ターゲット・データベース・ホームを選択します。
  10. 「移動」をクリックします。
    データベースは、現在のホームで停止された後、宛先のホームで再起動されます。
  11. 移動操作を確認します。

データベースはローリング方式で移動されます。データベース・インスタンスは、ノードごとに現在のホームで停止された後、宛先のホームで再起動されます。データベースが移動されている間、データベース・ホームおよびデータベースのステータスは「更新中」と表示されます。「データベース・バージョン」の下に表示されるデータベース・ホームの場所は、「データベースの移動中」と表示されます。操作が完了すると、「データベース・ホーム」が現在のホームで更新されます。Datapatchは、データベースの移動の一部として自動的に実行され、新しいデータベース・ホームで、個別パッチを含むすべてのパッチのパッチ後のSQLアクションを完了します。データベースの移動操作が失敗した場合、データベースのステータスは「失敗」と表示され、「データベース・ホーム」フィールドに失敗の理由に関する情報が表示されます。

APIを使用したVMクラスタおよびデータベース・ホームのパッチ適用および更新

様々なAPI機能を使用して、Oracle Exadata Database Service on Cloud@Customerシステムへのパッチ適用を管理します。

APIの使用およびリクエストの署名の詳細は、「REST API」および「セキュリティ資格証明」を参照してください。SDKについては、「ソフトウェア開発キットとコマンドライン・インタフェース」を参照してください。

次のAPI操作を使用して、VMクラスタ、データベース・ホームおよびデータベースへのパッチ適用を管理します。

VMクラスタ:

  • UpdateVmCluster

データベース・ホーム:

  • CreateDbHome
  • UpdateDbHome
  • DeleteDbHome

データベース:

  • CreateDatabase
  • UpdateDatabase
  • DeleteDatabase

UpdateVMClusterを使用して、VMクラスタ上のOracle Grid Infrastructureにパッチを適用します。UpdateDbHomeを使用して、データベース・ホームのデータベース・ソフトウェアにパッチを適用します。UpdateDatabaseを使用してデータベースを別のデータベース・ホームに移動し、ターゲット・データベース・ホームと同じバージョンにデータベースを更新します。

データベース・サービスのAPIの完全なリストは、「データベース・サービスAPI」を参照してください。

ゲストVMオペレーティング・システムの更新

Oracle Exadata Database Service on Cloud@Customer VMクラスタ・ノード上で、OCIコンソールおよびAPIから自動的にオペレーティング・システム・イメージを更新する方法について学習します。

この自動化された機能により、VMクラスタのパッチ適用が簡略化および高速化され、パッチ適用のエラーが少なくなり、パッチ・マネージャを使用する必要がなくなります。

パッチを適用すると、Exadata Cloud@Customer VMクラスタ、データベース・システムまたはデータベース・ホームがそのパッチの要件を満たしていることを確認するために事前チェック操作が実行されます。事前チェックが成功しなかった場合、パッチは適用されず、事前チェックが失敗したためにパッチを適用できないというメッセージが表示されます。計画更新の前に実行できる個別の事前チェック操作も使用できます。

親トピック: Oracle Exadata Database Service on Cloud@Customerシステムのパッチおよび更新

サポートされているソフトウェア・バージョンおよび更新の制限

Exadataイメージ・リリース23.1.0.0.0 (Oracle Linux 8ベースのイメージ)に更新するための最小要件:

ノート

これらは最小要件にすぎません。Exadata 23.1の要件を満たすようにGrid InfrastructureまたはOracle Database(あるいはその両方)を更新する場合、最低限ではなく、使用可能な最新バージョンのGrid InfrastructureおよびOracle Databaseに更新することをお薦めします。
  • Exadataイメージ(ゲストOS): Exadataイメージ・リリース22.1.0 (2022年5月)または21.2.10 (2022年3月)21.2.10より古いバージョンを実行しているシステムでは、23.1.0.0.0に更新する前に、まず22.1.0 (2022年5月)以上または21.2.10 (2022年3月)以上にアップグレードする必要があります。これは、ストレージ・サーバーとデータベース・サーバーの両方に適用されます。
    • 現在インストールされているバージョンが19.2以上である場合、Exadata VMクラスタ・イメージに対してマイナー・バージョン更新を実行する以外に、新しいメジャー・バージョンに更新できます。たとえば、VMクラスタがバージョン20の場合は、バージョン21に更新できます。
    • VMクラスタ・イメージの各メジャー・バージョンの最新4バージョン(NからN-3)以上のマイナー・バージョンは、コンソールを通じて適用できます。
  • Oracle Grid Infrastructure: Exadataイメージ・リリース23.1.0.0.0では、次の最小または新しいOracle Grid Infrastructureバージョンがサポートされます。
    • リリース19c: バージョン19.15、2022年4月リリース更新(RU)以降(デフォルト)
    • リリース21c: バージョン21.6、2022年4月リリース更新(RU)以降
  • Oracle Database: Exadata System Software 23.1では、新しいデータベース・インストールに対して次の最小バージョン以降がサポートされています。
    • リリース19c: バージョン19.15、2022年4月リリース更新(RU)以降(デフォルト)
    • Market Driven Support (市場主導型サポート)またはQuarterly Updates (四半期更新)例外承認の下でサポートされているその他のデータベース・リリース:
      • リリース12.2.0.1、リリース更新(RU) 12.2.0.1.220118 (2022年1月)
      • リリース12.1.0.2、バンドル・パッチ12.1.0.2.220719 (2022年7月) - パッチ30159782が必要です
      • リリース11.2.0.4、バンドル・パッチ11.2.0.4.210119 (2021年1月) - パッチ30159782、パッチ33991024が必要です
  • 今後24時間以内に開始するようにスケジュールされたExadataインフラストラクチャ・メンテナンス操作がある場合、Exadataイメージの更新機能は使用できません。
  • VMクラスタをExadata Database Service Guest VM OS 23.1にアップグレードすると、Exadata Cloud@CustomerインフラストラクチャでExadata System Softwareバージョン22.1.16以降が実行されている場合、このVMクラスタに新しいVMまたは新しいデータベース・サーバーを追加できます。
    ノート

    Exadata Cloud@CustomerインフラストラクチャのExadata System Software 23.1へのアップグレードは、2024年2月の更新サイクルで使用可能になります。
コンソールを使用したゲストVMオペレーティング・システムの更新

コンソールを使用してゲストVMオペレーティング・システムを更新するには、必要なフィールドに値を指定する準備をします。

ノート

VMクラスタがExadata Database Service Guest VM OS 23.1にアップグレードされると、Exadata Cloud@CustomerインフラストラクチャでExadata System Softwareバージョン22.1.16以降が実行されている場合、このVMクラスタに新しいVMまたは新しいデータベース・サーバーを追加できます。

Exadata Cloud@CustomerインフラストラクチャのExadata System Software 23.1へのアップグレードは、2024年2月の更新サイクルで使用可能になります。

  1. ナビゲーション・メニューを開きます。「Oracle Database」で、「Exadata Database Service on Cloud@Customer」をクリックします。
  2. コンパートメントを選択します。
    選択したコンパートメントに対するVMクラスタのリストが表示されます。
  3. クラウドVMクラスタのリストで、パッチを適用するクラスタの名前をクリックして、クラスタの詳細を表示します。
  4. 「更新(OS)」をクリックします。
  5. 使用可能なソフトウェア更新のリストを確認し、適用するオペレーティング・システム・パッチを見つけます。
  6. 目的のパッチがリストされた行の最後にある「アクション」アイコン(3つのドット)をクリックし、次のいずれかのアクションをクリックします:
    • 事前チェックの実行。事前チェックは、前提条件をチェックして、パッチを正常に適用できることを確認します。Oracleでは、パッチを適用する前に事前チェック操作を実行することを強くお薦めします。その理由は、データベースの内容は常に変化する可能性があり、パッチの実行の直前に実行する事前チェックでは、前回の事前チェックで検出されなかったエラーが見つかる可能性があるためです。
      ノート

      事前チェックが失敗すると、最後の事前チェックに失敗したことを示すメッセージが「Exadata OSイメージ更新の適用」ダイアログに表示されます。Oracleでは、事前チェックを再度実行することをお薦めします。OSパッチがリストされた行の最後にある「アクション」アイコン(3つのドット)をクリックして、ダイアログを表示します。
    • Exadata OSイメージ更新の適用。このリンクでは、パッチの適用に使用する「Exadataイメージ更新の適用」ダイアログが表示されます。このダイアログには、パッチ適用対象のデータベース・システムの名前、データベースの現在のバージョン、およびパッチ適用後のデータベースの新しいバージョンが表示されます。プロセスを開始するには、「Exadata OSイメージ更新の適用」をクリックします。
    • OCIDのコピー。これにより、Oracle Cloud IDがコピーされます。これは、パッチのトラブルシューティング時に使用したり、またはサポートへの連絡時に提供したりできます。
      ノート

      パッチの実行中:
      • 「事前チェックの実行」および「OSイメージ更新の適用」は使用できません。パッチが完了すると、これらのアクションを再度使用できます。
      • このVMクラスタを含むExadataインフラストラクチャで、パッチ適用操作と競合するメンテナンスがスケジュールされている場合、パッチは失敗し、理由を説明するメッセージが表示されます。インフラストラクチャ・メンテナンスが完了したら、パッチ操作を再度実行します。
  7. 要求されたら確認します。
コンソールを使用した、失敗したゲストVMオペレーティング・システムの更新のロールバックまたは再試行

コンソールを使用してゲストVMオペレーティング・システムを更新するには、必要なフィールドに値を指定する準備をします。

  1. ナビゲーション・メニューを開きます。「Oracle Database」で、「Exadata Database Service on Cloud@Customer」をクリックします。
  2. コンパートメントを選択します。
    選択したコンパートメントに対するVMクラスタのリストが表示されます。
  3. VMクラスタのリストで、パッチを適用するクラスタの名前をクリックしてクラスタの詳細を表示します。

    更新の適用に失敗した場合は、「VMクラスタの詳細」ページに、オプション「ロールバック」および「適用の再試行」のバナーが表示されます。

    適切なオプションを選択します。

    1. 「適用の再試行」をクリックします。

      「Exadata OSイメージ更新の適用」ダイアログが表示され、「Exadataイメージ更新の適用」および「事前チェックの実行」オプションが表示されます。

      適切なオプションを選択します。

      (または)

    2. 「ロール・バック」をクリックします。

      「ロールバック操作の確認」ダイアログが表示されます。

      確認するには「ロールバック」をクリックします。

  4. 「更新(OS)」ページからExadataイメージ更新を適用することもできます。
APIを使用したゲストVMオペレーティング・システムの更新

APIコールのリストを確認して、ゲストVMオペレーティング・システムを更新します。

APIの使用およびリクエストの署名の詳細は、REST APIおよびセキュリティ資格証明を参照してください。SDKについては、ソフトウェア開発キットとコマンドライン・インタフェースを参照してください。

次のAPI操作を使用して、VMクラスタ内のOracle Grid Infrastructureをアップグレードし、クラスタの更新履歴を表示します:
  • ListVmClusterUpdates
  • GetVmClusterUpdate
  • ListVmClusterUpdateHistoryEntries
  • GetVmClusterUpdateHistoryEntry
  • UpdateVmCluster

APIの完全なリストは、データベース・サービスAPIを参照してください。

Oracle Exadata Database Service on Cloud@Customer VMクラスタ上のOracle Grid Infrastructureのアップグレード

Oracle Cloud Infrastructure ConsoleまたはAPIを使用してOracle Exadata Database Service on Cloud@Customer VMクラスタ上のOracle Grid Infrastructureをアップグレードする方法について学習します。

アップグレードにより、最新のOracle Databaseソフトウェアを使用するOracle Databaseホームおよびデータベースをプロビジョニングできます。

親トピック: Oracle Exadata Database Service on Cloud@Customerシステムのパッチおよび更新

Oracle Grid Infrastructureのアップグレードについて

VMクラスタ上のOracle Grid Infrastructure (GI)のアップグレードには、インスタンス内のすべてのコンピュート・ノードのアップグレードが含まれます。アップグレードはローリング方式で実行され、一度に1つのノードのみがアップグレードされます。

  • Oracleでは、アップグレードの事前チェックを実行して、アップグレードの成功を妨げる問題を特定して解決することをお薦めします。
  • 関連付けられた作業リクエストを表示することで、アップグレード操作の進行状況をモニターできます。
  • 今後24時間以内に開始するようにスケジュールされたExadataインフラストラクチャ・メンテナンス操作がある場合、GIのアップグレード機能は使用できません。
  • アップグレード中は、ノードの起動、停止または再起動、CPUのスケーリング、データベース・ホームまたはデータベースのプロビジョニングまたは管理、データベースのリストア、IORM設定の編集などの他の管理操作を実行することはできません。GIのアップグレード中のVMクラスタでは、次のData Guard操作は許可されません:
    • Data Guardの有効化
    • スイッチオーバー
    • VMクラスタを使用したデータベースへのフェイルオーバー(別のVMクラスタでスタンバイへのフェイルオーバー操作が可能)
コンソールを使用したOracle Grid Infrastructureアップグレードの管理

コンソールを使用して、Oracle Grid Infrastructure (GI)をアップグレードする前に事前チェックを実行し、GIアップグレード操作を実行できます。

コンソールを使用したアップグレード前のVMクラスタの事前チェック

  1. ナビゲーション・メニューを開きます。「Oracle Database」で、「Exadata Database Service on Cloud@Customer」をクリックします。
  2. コンパートメントを選択します。
    選択したコンパートメントに対するVMクラスタのリストが表示されます。
  3. クラウドVMクラスタのリストで、パッチを適用するクラスタの名前をクリックして、クラスタの詳細を表示します。
  4. 「更新」をクリックします。
  5. Oracle Grid Infrastructure (GI)アップグレードがリストされた行の最後にある「アクション」アイコン(3つのドット)をクリックし、「事前チェックの実行」をクリックします。
  6. 「確認」ダイアログで、アップグレードを確認して事前チェック操作を開始します。
コンソールを使用したVMクラスタのOracle Grid Infrastructureのアップグレード

ノート

  • Grid Infrastructureを23aiにアップグレードする場合は、ASMディスク・グループごとに、compatible.rdbmsの値が19.0.0.0以降に設定されていることを確認します。
  • Grid Infrastructureを19cから23aiにアップグレードするための最小要件:
    • Exadata System Software 23.1.8を実行しているExadataゲストVM
    • Exadataシステム・ソフトウェア23.1.xを実行しているExadataインフラストラクチャ
ノート

現在、19cから23aiへのGrid Infrastructureのアップグレードは、単一ノードのVMクラスタではサポートされていません。
  1. ナビゲーション・メニューを開きます。「Oracle Database」で、「Exadata Database Service on Cloud@Customer」をクリックします。
  2. コンパートメントを選択します。
    選択したコンパートメントに対するVMクラスタのリストが表示されます。
  3. クラウドVMクラスタのリストで、パッチを適用するクラスタの名前をクリックして、クラスタの詳細を表示します。
  4. 「更新」をクリックします。
  5. Oracle Grid Infrastructure (GI)アップグレードがリストされた行の最後にある「アクション」アイコン(3つのドット)をクリックし、「Grid Infrastructureのアップグレード」をクリックします。
  6. 「Grid Infrastructureのアップグレード」ダイアログで、「Grid Infrastructureのアップグレード」をクリックして、GIのアップグレードを確認します。

    事前チェックを実行していない場合は、このダイアログで「事前チェックの実行」をクリックして、アップグレード前にクラウドVMクラスタを事前チェックできます。

APIを使用したOracle Grid Infrastructureアップグレードの管理

APIコールのリストを確認して、Oracle Grid Infrastructureアップグレードを管理します。

APIの使用およびリクエストの署名の詳細は、REST APIおよびセキュリティ資格証明を参照してください。SDKについては、ソフトウェア開発キットとコマンドライン・インタフェースを参照してください。

次のAPI操作を使用して、VMクラスタ内のOracle Grid Infrastructureをアップグレードし、クラスタの更新履歴を表示します:
  • ListVmClusterUpdates
  • GetVmClusterUpdate
  • ListVmClusterUpdateHistoryEntries
  • GetVmClusterUpdateHistoryEntry
  • UpdateVmCluster

APIの完全なリストは、データベース・サービスAPIを参照してください。

Oracle Databaseのアップグレード

コンソールおよびAPIを使用して、Exadataデータベース・インスタンスをOracle Database 19cおよびOracle Database 23aiにアップグレードする方法について学習します。

アップグレードは、ターゲット・ソフトウェア・バージョンを使用するデータベース・ホームにExadataデータベースを移動することで実行できます。Oracle Databaseリリースおよびソフトウェアのサポート・タイムラインについては、Release Schedule of Current Database Releases (Doc ID 742060.1)を参照してください。

関連トピック

親トピック: Oracle Exadata Database Service on Cloud@Customerシステムのパッチおよび更新

Oracle Databaseをアップグレードするための前提条件

Exadata Cloud@Customer Oracle Databaseインスタンスをアップグレードするための前提条件のリストを確認します。

  • 19cにアップグレードするには、Oracle Linux 7が最小要件であり、23aiにアップグレードするには、Oracle Linux 8が最小要件です。オペレーティング・システムを手動で更新する手順は、How to update the Exadata System Software (DomU) to 19 from 18 on the Exadata Cloud Service in OCIを参照してください。
  • Oracle Grid Infrastructureのバージョンは、19cまたは23ai for Oracle Database 19cです。ただし、Oracle Grid Infrastructureは、Oracle Database 23aiのバージョン23aiである必要があります。Oracle Cloud InfrastructureコンソールまたはAPIを使用してGrid Infrastructureをアップグレードする手順は、Exadata Grid Infrastructureのアップグレードを参照してください。Grid Infrastructureでパッチが使用可能な場合、Oracleでは、データベースのアップグレードを実行する前にそれらを適用することをお薦めします。
  • Oracle Cloud Infrastructureで使用可能な4つの最新バージョンのOracle Database 19cまたはOracle Database 23aiを使用する使用可能なOracle Database Homeが必要です。データベース・ホームの作成の詳細は、コンソールを使用したExadata Cloud@CustomerでのOracle Databaseホームの作成を参照してください。パッチ適用要件に基づいて、Oracle公開版ソフトウェア・イメージまたはカスタム・データベース・ソフトウェア・イメージを使用して、データベース・ホームを作成できます。
  • アップグレード対象のコンテナ・データベース内のすべてのプラガブル・データベースをオープンできることを確認する必要があります。アップグレード中にシステムによってオープンできないプラガブル・データベースが原因で、アップグレードが失敗することがあります。
アップグレードするには、Oracle Databaseが次の設定で構成されている必要があります:
  • データベースはアーカイブ・ログ・モードである必要があります。
  • データベースはフラッシュバックが有効になっている必要があります。

これらの設定についてさらに学習するには、データベースのリリース・バージョンのOracle Databaseドキュメントを参照してください。

Oracle Databaseのアップグレードについて

データベースをアップグレードする前に、次の手順をよく理解して、アップグレード用のデータベースを準備します。

  • データベースのアップグレードには、データベースの停止時間が含まれます。アップグレードをスケジュールするときは、この点に注意してください。
  • Oracleでは、本番データベースをアップグレードする前に、データベースをバックアップして、テスト・システムまたはデータベースのクローン・バージョンで新しいソフトウェア・バージョンをテストすることをお薦めします。オンデマンド手動バックアップの作成の詳細は、bkup_apiユーティリティを使用したオンデマンド・バックアップの作成を参照してください。
  • Oracleでは、アップグレードの実行を計画する前に軽減が必要な問題を検出できるように、アップグレードを試行する前にデータベースのアップグレード事前チェック操作を実行することをお薦めします。事前チェック操作は、データベースの可用性に影響せず、都合のよいときにいつでも実行できます。
  • データベースでData Guardを使用している場合は、プライマリまたはスタンバイのいずれかを最初にアップグレードできます。
  • 自動バックアップ操作の進行中は、アップグレード操作を実行できません。アップグレードの前に、Oracleでは、自動バックアップを無効にして手動バックアップを実行することをお薦めします。詳細は、bkup_apiユーティリティを使用したオンデマンド・バックアップの作成および自動バックアップ構成のカスタマイズを参照してください。
  • アップグレード後は、アップグレード前に取得した自動バックアップを使用してデータベースを以前の時点にリストアすることはできません。
  • バージョン11.2ソフトウェアを使用するデータベースをアップグレードする場合、結果のバージョン19cデータベースは、非コンテナ・データベース(非CDB)になります。
データベース・サービスによるアップグレード操作の実行方法

アップグレード・プロセス中のデータベース・サービスの動作をよく理解します。

  • 自動事前チェックを実行します。これにより、システムでは軽減が必要な問題を識別し、アップグレード操作を停止できます。
  • 保証付きリストア・ポイントを設定し、アップグレードが失敗した場合にフラッシュバックを実行できるようにします。
  • データベースを、目的のターゲット・ソフトウェア・バージョンを使用するユーザー指定のOracle Databaseホームに移動します。
  • Database Upgrade Assistant (DBUA)ソフトウェアを実行して、アップグレードを実行します。
Oracle Databaseのアップグレードの失敗のロールバック

アップグレードが正常に完了しない場合、ロールバックを実行できます。

失敗の詳細がコンソールの「データベース詳細」ページに表示され、失敗の原因となった問題を分析して解決できます。

ロールバックによって、データベースはアップグレード前の状態にリセットされます。アップグレード中およびそれ以降に行われたデータベースに対する変更は、すべて失われます。ロールバック・オプションは、アップグレード操作の失敗後にデータベースの「データベース詳細」ページに表示されるバナー・メッセージで提供されます。詳細は、コンソールを使用したデータベース・アップグレードの失敗のロールバックを参照してください。

Oracle Databaseのアップグレード後

アップグレードが成功したら、次に注意してください:

  • アップグレード前に自動バックアップを無効にした場合は、データベースの自動バックアップが有効になっていることを確認します。詳細は、自動バックアップ構成のカスタマイズを参照してください。
  • Oracle Databaseを編集します 
    COMPATIBLE
    このパラメータが新しいOracle Databaseソフトウェア・バージョンを反映するようにします。詳細は、Oracle Databaseの互換性の概要を参照してください。
  • データベースでdatabase_name.envファイルを使用する場合は、19cデータベース・ホームを指すようにファイル内の変数が更新されていることを確認します。これらの変数は、アップグレード・プロセス中に自動的に更新されます。
  • 非コンテナ・データベースをOracle Databaseバージョン19cにアップグレードする場合は、変換後にデータベースをプラガブル・データベースに変換できます。データベースをプラガブル・データベースに変換する手順は、How to Convert Non-CDB to PDB (Doc ID 2288024.1)を参照してください。
  • 古いデータベース・ホームが空で、再利用されない場合は削除できます。詳細は、コンソールを使用したOracle Databaseホームの削除を参照してください。
コンソールを使用したOracle Databaseアップグレードの管理

Oracleでは、事前チェック・アクションを使用して、データベースがアップグレード操作の要件を満たしていることを確認することをお薦めします。

コンソールを使用したOracle Databaseアップグレードの事前チェックの実行またはアップグレードの実行

  1. ナビゲーション・メニューを開きます。「Oracle Database」で、「Exadata Database Service on Cloud@Customer」をクリックします。
  2. コンパートメントを選択します。
    選択したコンパートメントに対するVMクラスタのリストが表示されます。
  3. VMクラスタのリストで、アップグレードするデータベースを含むVMクラスタの名前をクリックします。
  4. 「VMクラスタ詳細」ページのデータベースのリストで、アップグレードするデータベースの名前をクリックして、「データベース詳細」ページを表示します。
  5. 「アクション」メニューをクリックし、「アップグレード」を選択します。
  6. 「データベースのアップグレード」ダイアログで、次を選択します:
    • Oracle Databaseバージョン: ドロップダウン・セレクタには、データベースが使用している現在のソフトウェア・バージョンからのアップグレードと互換性のあるOracle Databaseバージョンのみがリストされます。ターゲット・ソフトウェア・バージョンは、データベースの現在のバージョンより上位である必要があります。

    • ターゲット・データベース・ホーム: データベースのデータベース・ホームを選択します。データベース・ホームのリストは、最新バージョンのOracle Database 19cソフトウェアを使用しているホームに制限されます。データベースを新しいデータベース・ホームに移動すると、データベースが新しいデータベース・ホームのメジャー・リリース・バージョンおよびパッチ適用レベルにアップグレードされます。

  7. 次のいずれかをクリックします。
    • 事前チェックの実行: このオプションでは、アップグレードを実行する前に軽減が必要なデータベースの問題を識別するために、アップグレードの事前チェックが開始されます。
    • データベースのアップグレード: このオプションでは、アップグレード操作が開始されます。Oracleでは、データベースで事前チェックを正常に実行した後にのみ、アップグレードを実行することをお薦めします。
コンソールを使用したデータベース・アップグレードの失敗のロールバック

  1. ナビゲーション・メニューを開きます。「Oracle Database」で、「Exadata Database Service on Cloud@Customer」をクリックします。
  2. コンパートメントを選択します。
    選択したコンパートメントに対するVMクラスタのリストが表示されます。
  3. VMクラスタのリストで、アップグレードに失敗したデータベースを含むVMクラスタの名前をクリックします。
  4. アップグレードに失敗したデータベースを検索し、その名前をクリックして詳細を表示します。
  5. このデータベースでは、詳細ページの上部に「ロールバック」ボタンを含むバナーが表示され、アップグレードの失敗の原因となった問題の詳細が示されます。
  6. 「ロールバック」をクリックします。
  7. 「ロールバックの確認」ダイアログで、以前のOracle Databaseバージョンへのロールバックを開始することを確認します。
コンソールを使用したデータベースのアップグレード履歴の表示

  1. ナビゲーション・メニューを開きます。「Oracle Database」で、「Exadata Database Service on Cloud@Customer」をクリックします。
  2. コンパートメントを選択します。
    選択したコンパートメントに対するVMクラスタのリストが表示されます。
  3. VMクラスタのリストで、アップグレードするデータベースを含むVMクラスタの名前をクリックします
  4. 「VMクラスタ詳細」ページのデータ・リストで、アップグレード履歴を表示するデータベースの名前をクリックします。
  5. 「データベース詳細」ページで、「更新履歴」をクリックします。
APIを使用したOracle Databaseのアップグレード

APIコールのリストを確認して、Oracle Databaseをアップグレードします。

APIの使用およびリクエストの署名の詳細は、REST APIおよびセキュリティ資格証明を参照してください。SDKについては、ソフトウェア開発キットとコマンドライン・インタフェースを参照してください。

次のAPIを使用して、データベースのアップグレードを管理します:
  • getDatabaseUpgradeHistoryEntry
  • ListDatabaseUpgradeHistoryEntries
  • UpgradeDatabase

APIの完全なリストは、データベース・サービスAPIを参照してください。

Oracle Exadata Database Service on Cloud@Customerシステムの手動によるパッチ適用および更新

この項では、クラウド自動化外でOracle Exadata Database Service on Cloud@Customerの様々なコンポーネントにパッチを適用して更新する手順について説明します。dbaascliを使用したパッチ適用および更新の詳細は、「dbaascliを使用したOracle Grid InfrastructureおよびOracle Databasesへのパッチ適用」を参照してください。

ノート

パッチ適用操作時の継続的サービスの実現に関する詳細なガイダンスは、『MAAソリューションの継続的サービスのアプリケーション・チェックリスト』(ホワイト・ペーパー)を参照してください。
  • ソフトウェアの手動更新
    夏時間、および一部の定期パッチまたは個別パッチでは、状況により、ソフトウェアに手動でパッチを適用する必要があります。
  • ゲストVMオペレーティング・システムの手動更新
    Oracle Exadata Database Service on Cloud@Customerゲスト・仮想マシンでオペレーティング・システム・コンポーネントを更新するために使用できる標準のExadataツールおよび手法について学習します。

関連トピック

親トピック: Oracle Exadata Database Service on Cloud@Customerシステムのパッチ適用および更新

ソフトウェアの手動更新

夏時間、および一部の定期パッチまたは個別パッチでは、状況により、ソフトウェアに手動でパッチを適用する必要があります。

Oracle DatabaseおよびOracle Grid Infrastructureソフトウェアの定期的なパッチ適用を実行するには、Oracle Exadata Database Service on Cloud@Customerが提供する機能を使用することをお薦めします。ただし、状況によっては、Oracle DatabaseまたはOracle Grid Infrastructureソフトウェアに手動でパッチを適用する必要があります:
  • 夏時間(DST)のパッチ適用: ローリング方式では適用できないため、Oracle Database DST定義のパッチは、Exadata Database Service on Cloud@Customerの定期パッチ・セットに含まれていません。Oracle Database DST定義にパッチを適用する必要がある場合は、手動で行う必要があります。My Oracle Support Doc ID 412160.1を参照してください。
  • 非定期パッチまたは個別パッチ適用: 定期パッチ・セットに含まれないパッチを必要とする問題が発生した場合は、Oracleサポート・サービスと連携して適切なパッチを識別および適用します。

Oracle Databaseへのパッチ適用に関する一般的な情報は、使用しているリリースの『Oracle Databaseアップグレード・ガイド』のパッチ・セットの更新および要件に関する情報を参照してください。

ゲストVMオペレーティング・システムの手動更新

Oracle Exadata Database Service on Cloud@Customerゲスト・仮想マシンでオペレーティング・システム・コンポーネントを更新するために使用できる標準のExadataツールおよび手法について学習します。

データベース・サーバー仮想マシン(VM)でオペレーティング・システム環境に対するパッチおよび更新を管理することは、ユーザーの責任です。詳細は、『Oracle Exadata Database Machineメンテナンス・ガイド』でExadata Database Machineサーバーの更新について参照してください。

関連トピック

親トピック: Oracle Exadata Database Service on Cloud@Customerシステムの手動パッチおよび更新

オペレーティング・システム更新の準備

Oracle Exadata Database Service on Cloud@Customerのオペレーティング・システム更新を準備するには、このタスクのチェックリストを確認します。

オペレーティング・システムを更新する前に、次の各準備タスクを実行します:

最新のソフトウェア更新を特定します。更新を開始する前に、使用する最新のソフトウェアを特定するために、My Oracle Supportノート2333222.1でExadata Cloud Serviceソフトウェア・バージョンを確認してください。

Oracle Exadata Database Service on Cloud@Customerシステムのすべての仮想マシンでのオペレーティング・システム更新

データベース・サーバー仮想マシン(VM)でオペレーティング・システムを更新するには、patchmgrツールを使用します。

ノート

My Oracle Supportのパッチ・ダウンロード権限を持たないユーザーは、Exadata Cloud@Customer Gen 2ユーティリティのexadata_updates.shを使用して、Exadata patchmgr更新ユーティリティおよびExadataシステム・ソフトウェアの最新リリースを入手できます。詳細は、My Oracle Support Doc 2730739.1を参照してください。

patchmgrユーティリティは、1つ以上の仮想マシンの更新全体をリモートで管理し、Oracle Exadata Database Service on Cloud@Customerシステムの再起動前、再起動中および再起動後のステップを含みます。

ユーティリティは、いずれかのOracle Exadata Database Service on Cloud@Customer仮想マシンから実行することも、Oracle Linuxを実行している別のサーバーから実行することもできます。ユーティリティを実行するサーバーは、駆動システムと呼ばれます。駆動システムを使用して、それ自体を更新することはできません。したがって、駆動システムが、更新するVMクラスタ内の仮想マシンの1つである場合は、patchmgrユーティリティを2回以上実行する必要があります。次のシナリオは、更新を実行する際の一般的な方法を示しています:

  • Exadata以外の駆動システム

    システムの更新を実行する最も簡単な方法は、個別のOracle Linuxサーバーを使用してすべての仮想マシンを1回の操作で更新することです。

  • Exadata仮想マシンの駆動システム

    1つの仮想マシンを使用して、VMクラスタ内の残りの仮想マシンの更新を駆動できます。その後、更新されたノードのいずれかを使用して、元の駆動システムで更新を駆動できます。たとえば、4つの仮想マシン(node1、node2、node3およびnode4)があるハーフ・ラック・システムの更新について検討します。最初に、node1を使用してnode2、node3およびnode4の更新を駆動できます。次に、node2を使用してnode1の更新を駆動できます。

駆動システムでは、更新される各仮想マシンへのrootユーザーのSSHアクセスが必要です。

次の手順は、次を想定した例に基づいています:

  • システムには、2つの仮想マシン(node1およびnode2)があります。
  • ターゲットExadataソフトウェア・バージョンは、18.1.4.0.0.180125.3です。
  • 一方のノードは、他方のノードを更新するための駆動システムとして使用されます。
  1. 環境の詳細を収集します。
    1. SSHを使用して、opcユーザーとしてnode1に接続します。

      詳細な手順は、SSHを使用したコンピュート・ノードへの接続を参照してください。

    2. rootユーザー・コマンド・シェルを起動します
      sudo su -
    3. 次のコマンドを実行して、現在のExadataソフトウェア・バージョンを確認します。
      imageinfo -ver
      例:
      # imageinfo -ver 19.2.13.0.0.200428
    4. gridユーザーに切り替えて、クラスタ内のすべてのノードを識別します。
      su - grid
      olsnodes
      例:
      olsnodes
node1
node2
  2. 駆動システムを構成します。
    1. node1でrootユーザーに再度切り替えて、SSHキー・ペア(id_rsaおよびid_rsa.pub)が存在するかどうかを確認します。存在しない場合は生成します。
      ls /root/.ssh/id_rsa*
ls: cannot access /root/.ssh/id_rsa*: No such file or directory

ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
93:47:b0:83:75:f2:3e:e6:23:b3:0a:06:ed:00:20:a5 root@node1.example.com
The key's randomart image is:
+--[ RSA 2048]----+
|o..     + .      |
|o.     o *       |
|E     . o o      |
| . .     =       |
|  o .   S =      |
|   +     = .     |
|    +   o o      |
|   . .   + .     |
|      ...        |
+-----------------+
    2. 公開キーをターゲット・ノードに配布して、このステップを確認します。この例では、ターゲット・ノードはnode2のみです。
      scp -i ~root/.ssh/id_rsa.pub opc@node2:/tmp/id_rsa.node1.pub
      ls -al /tmp/id_rsa.node1.pub
-rw-r--r-- 1 opc opc 442 Feb 28 03:33 /tmp/id_rsa.node1.pub
      date
Wed Feb 28 03:33:45 UTC 2018
    3. ターゲット・ノード(この例ではnode2)で、node1のルート公開キーをルートauthorized_keysファイルに追加します。
      cat /tmp/id_rsa.node1.pub >> ~root/.ssh/authorized_keys
    4. patchmgrを、駆動システム(この例ではnode1)の/root/patchにダウンロードします。

      patchmgrバンドルは、My Oracle SupportパッチID 21634633を使用してOracleサポートからダウンロードできます。Exadataシステム・ソフトウェア・リリースをインストールするには、常に使用可能な最新のExadata patchmgr更新ユーティリティを入手してください。

      詳細は、dbnodeupdate.sh and dbserver.patch.zip: Updating Exadata Database Server Software using the DBNodeUpdate Utility and patchmgr (My Oracle Support Doc ID 1553103.1)も参照してください。

    5. patchmgrバンドルを解凍します。

      ZIPファイルの名前は、ダウンロードしたバージョンによって異なる場合があります。 

      cd /root/patch/18.1.4.0.0.180125.3
unzip dbserver.patch.zip
Archive:  p21634633_181400_Linux-x86-64.zip   creating: dbserver_patch_5.180228.2/
creating: dbserver_patch_5.180228.2/ibdiagtools/
inflating: dbserver_patch_5.180228.2/ibdiagtools/cable_check.pl
inflating: dbserver_patch_5.180228.2/ibdiagtools/setup-ssh
inflating: dbserver_patch_5.180228.2/ibdiagtools/VERSION_FILE
extracting: dbserver_patch_5.180228.2/ibdiagtools/xmonib.sh
inflating: dbserver_patch_5.180228.2/ibdiagtools/monitord
inflating: dbserver_patch_5.180228.2/ibdiagtools/checkbadlinks.pl
creating: dbserver_patch_5.180228.2/ibdiagtools/topologies/
inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/VerifyTopologyUtility.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/verifylib.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/Node.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/Rack.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/Group.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/Switch.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/topology-zfs
inflating: dbserver_patch_5.180228.2/ibdiagtools/dcli
creating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/
inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/remoteScriptGenerator.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/CommonUtils.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/SolarisAdapter.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/LinuxAdapter.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/remoteLauncher.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/remoteConfig.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/spawnProc.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/runDiagnostics.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/OSAdapter.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/SampleOutputs.txt
inflating: dbserver_patch_5.180228.2/ibdiagtools/infinicheck
inflating: dbserver_patch_5.180228.2/ibdiagtools/ibping_test
inflating: dbserver_patch_5.180228.2/ibdiagtools/tar_ibdiagtools
inflating: dbserver_patch_5.180228.2/ibdiagtools/verify-topology
inflating: dbserver_patch_5.180228.2/installfw_exadata_ssh
creating: dbserver_patch_5.180228.2/linux.db.rpms/
inflating: dbserver_patch_5.180228.2/md5sum_files.lst
inflating: dbserver_patch_5.180228.2/patchmgr
inflating: dbserver_patch_5.180228.2/xcp
inflating: dbserver_patch_5.180228.2/ExadataSendNotification.pm
inflating: dbserver_patch_5.180228.2/ExadataImageNotification.pl
inflating: dbserver_patch_5.180228.2/kernelupgrade_oldbios.sh
inflating: dbserver_patch_5.180228.2/cellboot_usb_pci_path
inflating: dbserver_patch_5.180228.2/exadata.img.env
inflating: dbserver_patch_5.180228.2/README.txt
inflating: dbserver_patch_5.180228.2/exadataLogger.pm
inflating: dbserver_patch_5.180228.2/patch_bug_26678971
inflating: dbserver_patch_5.180228.2/dcli
inflating: dbserver_patch_5.180228.2/patchReport.py
extracting: dbserver_patch_5.180228.2/dbnodeupdate.zip
creating: dbserver_patch_5.180228.2/plugins/
inflating: dbserver_patch_5.180228.2/plugins/010-check_17854520.sh
inflating: dbserver_patch_5.180228.2/plugins/020-check_22468216.sh
inflating: dbserver_patch_5.180228.2/plugins/040-check_22896791.sh
inflating: dbserver_patch_5.180228.2/plugins/000-check_dummy_bash
inflating: dbserver_patch_5.180228.2/plugins/050-check_22651315.sh
inflating: dbserver_patch_5.180228.2/plugins/005-check_22909764.sh
inflating: dbserver_patch_5.180228.2/plugins/000-check_dummy_perl
inflating: dbserver_patch_5.180228.2/plugins/030-check_24625612.sh
inflating: dbserver_patch_5.180228.2/patchmgr_functions
inflating: dbserver_patch_5.180228.2/exadata.img.hw
inflating: dbserver_patch_5.180228.2/libxcp.so.1
inflating: dbserver_patch_5.180228.2/imageLogger
inflating: dbserver_patch_5.180228.2/ExaXMLNode.pm
inflating: dbserver_patch_5.180228.2/fwverify
    6. patchmgrユーティリティを含むディレクトリで、更新する仮想マシンのリストを格納するdbs_groupファイルを作成します。ステップ1でolsnodesコマンドの実行後にリストされたノードを含めます(駆動システムを除く)。この例では、dbs_groupにnode2のみが含まれています。
      cd /root/patch/18.1.4.0.0.180125.3/dbserver_patch_5.180228
cat dbs_group
node2
  3. パッチ適用の事前チェック操作を実行します。
    ./patchmgr -dbnodes dbs_group -precheck -iso_repo zipped_iso_file -target_version target-version -nomodify_at_prereq
    ノート

    次のステップで実行するバックアップに影響を与える可能性のあるシステムへの変更を防ぐために、-nomodify_at_prereqオプションを指定して事前チェック操作を実行します。そうしないと、必要な場合にバックアップによってシステムを元の状態にロールバックできない可能性があります。

    出力は次の例のようになります:

    ./patchmgr -dbnodes dbs_group -precheck -iso_repo /root/patch/18.1.4.0.0.180125.3/exadata_ol6_18.1.4.0.0.180125.3_Linux-x86-64.zip -target_version 18.1.4.0.0.180125.3 -nomodify_at_prereq
 
************************************************************************************************************
NOTE    patchmgr release: 5.180228 (always check MOS 1553103.1 for the latest release of dbserver.patch.zip)
NOTE
WARNING Do not interrupt the patchmgr session.
WARNING Do not resize the screen. It may disturb the screen layout.
WARNING Do not reboot database nodes during update or rollback.
WARNING Do not open logfiles in write mode and do not try to alter them.
************************************************************************************************************
2018-02-28 21:22:45 +0000        :Working: DO: Initiate precheck on 1 node(s)
2018-02-28 21:24:57 +0000        :Working: DO: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:26:15 +0000        :SUCCESS: DONE: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:26:47 +0000        :Working: DO: dbnodeupdate.sh running a precheck on node(s).
2018-02-28 21:28:23 +0000        :SUCCESS: DONE: Initiate precheck on node(s).
  4. 現在のシステムをバックアップします。
    ./patchmgr -dbnodes dbs_group -backup -iso_repo zipped_iso_file -target_version target-version -allow_active_network_mounts
    ノート

    システムに変更が行われる前に、この時点でバックアップを取得するようにしてください。

    出力は次の例のようになります:

    ./patchmgr -dbnodes dbs_group -backup -iso_repo /root/patch/18.1.4.0.0.180125.3/exadata_ol6_18.1.4.0.0.180125.3_Linux-x86-64.zip -target_version 18.1.4.0.0.180125.3 -allow_active_network_mounts
 
************************************************************************************************************
NOTE    patchmgr release: 5.180228 (always check MOS 1553103.1 for the latest release of dbserver.patch.zip)
NOTE
WARNING Do not interrupt the patchmgr session.
WARNING Do not resize the screen. It may disturb the screen layout.
WARNING Do not reboot database nodes during update or rollback.
WARNING Do not open logfiles in write mode and do not try to alter them.
************************************************************************************************************
2018-02-28 21:29:00 +0000        :Working: DO: Initiate backup on 1 node(s).
2018-02-28 21:29:00 +0000        :Working: DO: Initiate backup on node(s)
2018-02-28 21:29:01 +0000        :Working: DO: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:30:18 +0000        :SUCCESS: DONE: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:30:51 +0000        :Working: DO: dbnodeupdate.sh running a backup on node(s).
2018-02-28 21:35:50 +0000        :SUCCESS: DONE: Initiate backup on node(s).
2018-02-28 21:35:50 +0000        :SUCCESS: DONE: Initiate backup on 1 node(s).
  5. ターゲット仮想マシンからすべてのカスタムRPMを削除します。カスタムRPMは事前チェックの結果でレポートされます。これには、システムのプロビジョニング後に手動でインストールされたRPMが含まれます。
    • バージョン12.1.2.3.4.170111からシステムを更新するときに、事前チェックの結果にkrb5-workstation-1.10.3-57.el6.x86_64が含まれる場合は、これを削除します。このアイテムは、このバージョンではカスタムRPMとみなされます。
    • exadata-sun-vm-computenode-exactまたはoracle-ofed-release-guestは削除しないでください。この2つのRPMは、更新プロセス中に自動的に処理されます。
  6. 更新を実行します。更新プロセスが中断しないようにするには、コマンドnohupを使用します。例:
    nohup ./patchmgr -dbnodes dbs_group -upgrade -nobackup -iso_repo zipped_iso_file -target_version target-version -allow_active_network_mounts &

    出力は次の例のようになります:

    nohup ./patchmgr -dbnodes dbs_group -upgrade -nobackup -iso_repo /root/patch/18.1.4.0.0.180125.3/exadata_ol6_18.1.4.0.0.180125.3_Linux-x86-64.zip -target_version 18.1.4.0.0.180125.3 -allow_active_network_mounts &
 
************************************************************************************************************
NOTE    patchmgr release: 5.180228 (always check MOS 1553103.1 for the latest release of dbserver.patch.zip)
NOTE
NOTE    Database nodes will reboot during the update process.
NOTE
WARNING Do not interrupt the patchmgr session.
WARNING Do not resize the screen. It may disturb the screen layout.
WARNING Do not reboot database nodes during update or rollback.
WARNING Do not open logfiles in write mode and do not try to alter them.
*********************************************************************************************************
2018-02-28 21:36:26 +0000        :Working: DO: Initiate prepare steps on node(s).
2018-02-28 21:36:26 +0000        :Working: DO: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:37:44 +0000        :SUCCESS: DONE: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:38:43 +0000        :SUCCESS: DONE: Initiate prepare steps on node(s).
2018-02-28 21:38:43 +0000        :Working: DO: Initiate update on 1 node(s).
2018-02-28 21:38:43 +0000        :Working: DO: Initiate update on node(s)
2018-02-28 21:38:49 +0000        :Working: DO: Get information about any required OS upgrades from node(s).
2018-02-28 21:38:59 +0000        :SUCCESS: DONE: Get information about any required OS upgrades from node(s).
2018-02-28 21:38:59 +0000        :Working: DO: dbnodeupdate.sh running an update step on all nodes.
2018-02-28 21:48:41 +0000        :INFO   : node2 is ready to reboot.
2018-02-28 21:48:41 +0000        :SUCCESS: DONE: dbnodeupdate.sh running an update step on all nodes.
2018-02-28 21:48:41 +0000        :Working: DO: Initiate reboot on node(s)
2018-02-28 21:48:57 +0000        :SUCCESS: DONE: Initiate reboot on node(s)
2018-02-28 21:48:57 +0000        :Working: DO: Waiting to ensure node2 is down before reboot.
2018-02-28 21:56:18 +0000        :Working: DO: Initiate prepare steps on node(s).
2018-02-28 21:56:19 +0000        :Working: DO: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:57:37 +0000        :SUCCESS: DONE: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:57:42 +0000        :SEEMS ALREADY UP TO DATE: node2
2018-02-28 21:57:43 +0000        :SUCCESS: DONE: Initiate update on node(s)
  7. 更新操作が完了したら、更新された仮想マシン上のExadataソフトウェアのバージョンを確認します。
    imageinfo -ver
18.1.4.0.0.180125.3
  8. 更新された仮想マシンを駆動システムとして使用して、この手順のステップ2から7を繰り返し、残りの仮想マシンを更新します。この更新例では、node2を使用してnode1を更新します。
  9. rootとして、各仮想マシンでuptrack-installコマンドを実行して、使用可能なkspliceの更新をインストールします。
    uptrack-install --all -y
    uptrack-install --all -y
追加のオペレーティング・システム・パッケージのインストール

Oracle Exadata Database Service on Cloud@Customerの追加のオペレーティング・システム・パッケージをインストールする前に、次のガイドラインを確認します。

カーネルまたはInfiniBand固有のパッケージを変更しないかぎり、Oracle Exadata Database Service on Cloud@Customerでオペレーティング・システム・パッケージをインストールおよび更新できます。ただし、インストール、テスト、動作保証、エラー解決などのOracleテクニカル・サポートは、インストールするOracle以外のソフトウェアには適用されません。

また、Oracle Exadataソフトウェア更新とは別にパッケージを追加または更新すると、Oracle Exadataソフトウェア更新の適用時にこれらのパッケージの追加または更新によって問題が発生する可能性があることに注意してください。追加のソフトウェア・パッケージによって、Oracle Exadataの更新を中断する可能性のある新しい依存関係が追加されるため、問題が発生することがあります。そのため、カスタマイズは最小限に抑えることをお薦めします。

追加のパッケージをインストールする場合は、それらのパッケージの削除および再インストールを自動化するスクリプトを用意することをお薦めします。Oracle Exadataの更新後、追加のパッケージをインストールする場合は、追加のパッケージにも互換性があることと、それらのパッケージが引き続き必要であることを確認します。

詳細は、『Oracle Exadata Database Machineメンテナンス・ガイド』を参照してください。

DOMUアップグレード用の追加のExadata以外のソフトウェア・パッケージに関連する依存関係の問題の解決

Oracleが提供するパッケージを超えてExadata以外のソフトウェア・パッケージをインストールし、OracleがインストールしたRPM間の競合のためにDOMUアップグレード中に事前チェックが失敗した場合、次の手順を使用して競合を解決し、アップグレードを続行できます。

メジャーOracle Linuxバージョンを変更しない更新の場合、この統合機能により、Exadataデータベース・サーバー更新の一部として追加のExadata以外のソフトウェア・パッケージを更新できます。このようなExadata以外のソフトウェア・パッケージがシステムに存在する場合に発生する可能性のあるパッケージ依存関係の問題の処理を簡素化します。

事前チェックを繰り返し実行して、追加のExadata以外のソフトウェア・パッケージに関連する依存関係の問題を識別および解決できます。必要な更新が理解されると、Exadataデータベース・サーバーの更新を自信を持って実行し、単一の調整された操作で追加のパッケージを更新できます。

Exadata以外のソフトウェア・パッケージの一時YUMリポジトリの設定をトリガーするために、ターゲット・サーバー上に構成ファイルが存在することを確認します。

  • ファイルの場所: /etc/exadata/additional-packages.txt
  • 所有権および権限:このファイルは、rootユーザーのみが所有および変更できる必要があります。

ファイルが存在する場合は、必要な非Exadataソフトウェア・パッケージに関する情報を収集し、一時的なYUMリポジトリを設定および有効化するために使用されます。ファイルが存在しない場合、リポジトリは構成されません。

/etc/exadata/additional-packages.txtに、他の場所(通常は共有マウント上)にある構成ファイルを指すシンボリック・リンクを作成することもできます。

ファイル・フォーマット

ファイルには、Exadata以外のソフトウェア・パッケージのリストが含まれ、各エントリが新しい行に含まれている必要があります。サポートされている形式は次のとおりです。

  • http(s)://path/to/package.rpm: RPMファイルへの完全なURL
  • /full/path/to/package.rpm: ローカルRPMファイルへの絶対パス
  • repo:package.rpm: 既存のYUMリポジトリ内のパッケージへの参照
ノート

  • repo:形式を使用する場合は、参照されるリポジトリがターゲット・サーバーのYUM構成で定義されていることを確認します。
  • ローカル・ファイルは、標準のローカル・ディレクトリ、NFSマウントまたはACFSマウントに配置できます。
例: additional-packages.txt

/u01/elfutils-debuginfod-client-0.190-2.el8.x86_64.rpm
/u01/elfutils-libelf-devel-0.190-2.el8.x86_64.rpm
/u01/keyutils-libs-devel-1.5.10-9.0.1.el8.x86_64.rpm
https://example.com/packages/krb5-devel-1.18.2-28.0.1.el8_10.x86_64.rpm
https://example.com/packages/memstrack-0.2.5-2.el8.x86_64.rpm
/u01/pigz-2.4-4.el8.x86_64.rpm
/u01/sssd-nfs-idmap-2.9.4-3.0.1.el8_10.x86_64.rpm
https://example.com/packages/timedatex-0.5-3.el8.x86_64.rpm
https://example.com/packages/zlib-devel-1.2.11-25.el8.x86_64.rpm