機械翻訳について
  1. Oracle Exadata Database Service on Cloud@Customer管理者ガイド
  2. How-toガイド
  3. Oracle Exadata Database Service on Cloud@Customerシステムのパッチ適用および更新

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

Oracle Exadata Database Service on Cloud@Customerシステムの更新およびパッチ適用について学習

親トピック: How-toガイド

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

最適な動作順序でセキュアな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システムのパッチ適用および更新

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

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

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

Exadata Cloud@Customerにデータベースの四半期パッチを適用する方法の詳細および例は、My Oracle Supportノートを参照してください: Exadata Cloud ServiceおよびExadata Cloud at Customer Gen 2でのデータベース四半期パッチの適用方法(ドキュメントID 2701789.1)。

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

関連トピック

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

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

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

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

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

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

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

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

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

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

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

Oracleでは、事前チェック・アクションを使用して、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. 表示される「更新」ページで、「Grid Infrastructureの更新」セクションに移動します。
  6. 「Oracle Grid Infrastructureバージョン」の下で、「更新の表示」をクリックします。
  7. VMクラスタに使用可能なパッチのリストを確認します。

    「Oracle Grid Infrastructureソフトウェア・イメージ」タブには、クラスタへのパッチ適用に使用できる一般利用可能なOracle Grid Infrastructureソフトウェア・イメージが表示されます。 パッチ適用に使用できるOracleイメージの更新タイプは「パッチ」です。

    「カスタムGrid Infrastructureソフトウェア・イメージ」タブでは、事前に作成したGrid Infrastructureソフトウェア・イメージを選択できます。

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

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

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

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

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

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

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

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

    「カスタム・データベース・ソフトウェア・イメージ」タブでは、事前に作成したデータベース・ソフトウェア・イメージを選択できます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

そのデータベース・ホームのパッチ操作の履歴が、そのデータベース・ホームが属する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. 移動操作を確認します。

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

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

様々な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オペレーティング・システムの更新

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

この自動化された機能により、VMクラスタのパッチ適用が簡素化および高速化され、パッチ適用はエラーが減少し、Patch Managerを使用する必要がなくなります。

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

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

サポートされるソフトウェアのバージョンと更新の制限

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

ノート:

これらは最小要件にすぎません。 Grid InfrastructureまたはOracle Database(あるいはその両方)をExadataの23.1要件を満たすように更新する場合は、最小ではなく、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月)にアップグレードする必要があります。 これは、ストレージ・サーバーとデータベース・サーバーの両方に適用されます。
    • Exadata VMクラスタ・イメージに対するマイナー・バージョン更新の実行に加えて、現在インストールされているバージョンが19.2以上である場合、新しいメジャー・バージョンに更新できます。 たとえば、VMクラスタがバージョン20の場合、バージョン21に更新できます。
    • 最新の4 (NからN-3)または複数のメジャー・バージョンのVMクラスタ・イメージは、コンソールから適用できます。
  • 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システム・ソフトウェア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
  • Exadataインフラストラクチャのメンテナンス操作が24時間以内に開始するようにスケジュールされている場合、Exadataイメージ更新機能は使用できません。
  • VMクラスタがExadata Database Service Guest VM OS 23.1にアップグレードされると、Exadata Cloud@CustomerインフラストラクチャでExadata System Softwareバージョン22.1.16以降が実行されている場合は、新しいVMまたは新しいデータベース・サーバーをこのVMクラスタに追加できます。

    ノート:

    Exadata System Software 23.1 for Exadata Cloud@Customer Infrastructureへのアップグレードは、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 System Software 23.1 for Exadata Cloud@Customer Infrastructureへのアップグレードは、2024年2月の更新サイクルで使用可能になります。

  1. ナビゲーション・メニューを開きます。 Oracle Databaseの下で、Exadata Database Service on Cloud@Customerをクリックします。
  2. コンパートメントを選択します。
    選択したコンパートメントのVMクラスタのリストが表示されます。
  3. クラウドVMクラスタのリストで、パッチを適用するクラスタの名前をクリックして、クラスタの詳細を表示します。
  4. 「バージョン」セクションの「更新が使用可能です」の右側にある「更新の表示」をクリックして、更新ページを表示します。
  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. 「更新」ページから「Exadataイメージ更新の適用」することもできます。
    1. 「バージョン」セクションの「更新が使用可能です」の右側にある「更新の表示」をクリックして、「更新」ページを表示します。
    2. アクション・アイコン(3つのドット)をクリックし、「Exadata OSイメージ更新の適用」オプションを選択します。
APIを使用したゲストVMオペレーティング・システムの更新

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

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コンソールまたは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では、アップグレードを正常に実行できない問題を特定して解決するために、アップグレード事前チェックを実行することをお薦めします。
  • 関連する「作業リクエスト」を表示して、アップグレード操作の進捗状況を監視できます。
  • Exadataインフラストラクチャのメンテナンス操作が24時間以内に開始するようにスケジュールされている場合、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. 「更新の表示」をクリックして、使用可能なパッチおよびアップグレードのリストを表示します。
  6. Oracle Grid Infrastructure (GI)アップグレードがリストされている行の最後にあるアクション・アイコン(3つのドット)をクリックし、「事前チェックの実行」をクリックします。
  7. 「確認」ダイアログで、事前チェック操作を開始するようにアップグレードすることを確認します。
コンソールを使用したVMクラスタのOracle Grid Infrastructureのアップグレード

ノート:

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

ノート:

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

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

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

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

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

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

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

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

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

アップグレードは、ターゲット・ソフトウェア・バージョンを使用するデータベース・ホームにExadataデータベースを移動することで行われます。 Oracle Databaseリリースおよびソフトウェア・サポートのタイムラインについては、「現在のデータベース・リリースのリリース・スケジュール(ドキュメントID 742060.1)」を参照してください。

関連トピック

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

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

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

  • 19cにアップグレードするには、Oracle Linux 7が最低限の要件であり、23aiにアップグレードするには、Oracle Linux 8が最低限の要件です。 オペレーティング・システムを手動で更新する手順は、「OCIでExadata Cloud Serviceの18から19にExadataシステム・ソフトウェア(DomU)を更新する方法」を参照してください。
  • 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 Database 19cまたはOracle Cloud Infrastructureで使用可能なOracle Database 23aiの4つの最新バージョンを使用する、使用可能なOracle Databaseホームが必要です。 データベース・ホームの作成の詳細は、「コンソールを使用したExadata Cloud@CustomerでのOracle Databaseホームの作成」を参照してください。 パッチ適用要件に基づいてOracle公開ソフトウェア・イメージまたは「カスタム・データベース・ソフトウェア・イメージ」を使用して、データベース・ホームを作成できます。
  • アップグレードされるコンテナ・データベース内のすべてのプラガブル・データベースをオープンできることを確認する必要があります。 アップグレード中にシステムによってオープンできないプラガブル・データベースは、アップグレードに失敗する可能性があります。
アップグレードするには、Oracleデータベースに次の設定が構成されている必要があります:
  • データベースはアーカイブ・ログ・モードである必要があります。
  • データベースでフラッシュバックを有効にする必要があります。

これらの設定の詳細は、データベースのリリース・バージョンの「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にアップグレードする場合、変換後にデータベースをプラガブル・データベースに変換できます。 データベースをプラガブル・データベースに変換する手順については、「非CDBをPDBに変換する方法(ドキュメント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 version: ドロップダウン・セレクタには、データベースが使用している現在のソフトウェア・バージョンからのアップグレードと互換性のあるOracle Databaseバージョンのみが表示されます。 ターゲット・ソフトウェアのバージョンは、データベースの現行バージョンより高くする必要があります。

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

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

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

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

    このリンクは、更新されていないデータベースでは表示されません。

    「更新履歴」ページが表示されます。 このページに表示される表には、データベースで実行される事前チェックおよびアップグレード操作が表示されます。

APIを使用したOracle Databasesのアップグレード

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

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ソリューションの継続的サービスのアプリケーション・チェックリスト」ホワイト・ペーパーを参照してください。

関連トピック

親トピック: 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 Support Servicesを使用して適切なパッチを特定および適用します。

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

関連トピック

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

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

Oracle Exadata Database Service on Cloud@CustomerゲストVMでオペレーティング・システム・コンポーネントを更新するために使用できる標準の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ドキュメント2730739.1を参照してください。

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

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

  • Exadata以外の駆動システム

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

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

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

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

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

  • システムには、node1およびnode2という2つの仮想マシンがあります。
  • ターゲットの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. 駆動システム(この例ではnode1)の/root/patchにpatchmgrをダウンロードします。

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

      詳細は、dbnodeupdate.shおよびdbserver.patch.zipも参照してください: DBNodeUpdateユーティリティおよびpatchmgrを使用したExadata Database Serverソフトウェアの更新: 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ではカスタマイズを最小限に抑えることをお薦めします。

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

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