Oracle Exadata Database Service on Cloud@Customerシステムのパッチ適用および更新
Oracle Exadata Database Service on Cloud@Customerシステムの更新およびパッチ適用について学習
- 「ユーザー管理メンテナンス更新の実行」
- 「Oracle Exadata Database Service on Cloud@Customerシステムのパッチ適用および更新」
コンソール、APIまたはCLIを使用して、Exadataデータベース仮想マシンおよびデータベース・ホームでパッチ適用操作を実行する方法について学習します。 - 「Oracle Exadata Database Service on Cloud@Customerシステムの手動によるパッチ適用および更新」
このトピックでは、クラウド自動化の外部にあるOracle Exadata Database Service on Cloud@Customerの様々なコンポーネントにパッチを適用および更新する手順について説明します。dbaascli
を使用したパッチ適用および更新の詳細は、「dbaascliを使用したOracle Grid InfrastructureおよびOracle Databasesへのパッチ適用」を参照してください。
親トピック: How-toガイド
ユーザー管理メンテナンス更新の実行
- 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ノートを参照してください: Exadata Cloud ServiceおよびExadata Cloud at Customer Gen 2でのデータベース四半期パッチの適用方法(ドキュメントID 2701789.1)。
パッチ適用操作中に継続的なサービスを実現する方法の詳細は、「MAAソリューションの継続的サービスのアプリケーション・チェックリスト」ホワイト・ペーパーを参照してください。
- 「VMクラスタおよびデータベース・ホームのパッチ適用と更新」
コンソールまたはAPIを使用してVMクラスタ・グリッド・インフラストラクチャ(GI)およびデータベース・ホームでパッチ適用操作を実行する方法について学習 - 「ゲストVMオペレーティング・システムの更新」
OCIコンソールおよびAPIから、Oracle Exadata Database Service on Cloud@Customer VMクラスタ・ノードのオペレーティング・システム・イメージを自動で更新する方法について学習します。 - 「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 Databasesのアップグレード」
コンソールおよびAPIを使用して、Exadataデータベース・インスタンスをOracle Database 19cおよびOracle Database 23aiにアップグレードする方法について学習します。
関連トピック
VMクラスタおよびデータベース・ホームのパッチ適用と更新
コンソールまたはAPIを使用してVMクラスタ・グリッド・インフラストラクチャ(GI)およびデータベース・ホームでパッチ適用操作を実行する方法について学習
- 「VMクラスタGIおよびデータベース・ホームのパッチ適用と更新について」
- 「Oracle Exadata Database Service on Cloud@Customerシステムのパッチ適用および更新の前提条件」
CPSホストでOracleによってダウンロードされ、使用可能な最新のクラウド・パッチをチェックして適用します。 - 「VMクラスタGIおよびデータベース・ホームへのパッチ適用および更新のためのコンソールの使用」
コンソールを使用して、VMクラスタおよびデータベース・ホームでのパッチ操作の履歴を表示し、パッチを適用し、パッチ操作のステータスを監視する方法について学習します。 - 「APIを使用したVMクラスタおよびデータベース・ホームへのパッチ適用および更新」
様々なAPI機能を使用して、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クラスタおよびデータベース・ホームのパッチ適用と更新
VMクラスタGIおよびデータベース・ホームへのパッチ適用および更新のためのコンソールの使用
コンソールを使用して、VMクラスタおよびデータベース・ホームでのパッチ操作の履歴を表示し、パッチを適用し、パッチ操作のステータスを監視する方法について学習します。
Oracleでは、事前チェック・アクションを使用して、VMクラスタまたはデータベース・ホームが適用するパッチの要件を満たしていることを確認することをお薦めします。
- 「コンソールを使用したGrid Infrastructureの更新の実行」
VMクラスタにGrid Infrastructureの更新を適用する方法について学習します。 - 「コンソールを使用したデータベース・ホームでの更新操作の実行」
データベース・ホームにパッチを適用する方法について学習します。 - 「コンソールを使用した更新履歴の表示」
各更新履歴エントリは、試行されたパッチ操作を表し、操作が成功したか失敗したかを示します。 失敗したパッチ操作を再試行できます。 操作を繰り返すと、新しいパッチ履歴エントリが作成されます。 - 「コンソールを使用した別のホームへのデータベースの移動」
目的のバージョンのOracle Databaseを実行しているデータベース・ホームにVMクラスタ・データベースを移動することで、そのバージョンを更新できます。
親トピック: VMクラスタおよびデータベース・ホームのパッチ適用と更新
コンソールを使用したGrid Infrastructureの更新の実行
VMクラスタにGrid Infrastructureの更新を適用する方法について学習します。
パッチ・リストには、操作のステータスが表示されます。 事前チェックの実行中、パッチ・ステータスはChecking
を示します。 パッチの適用中、パッチ・ステータスはApplying
を示し、VMクラスタ・ステータスはUpdating
を示します。 パッチ適用中、VMクラスタとそのリソースに対するライフサイクル操作は一時的に使用できません。 パッチ適用が正常に完了すると、パッチのステータスがApplied
に変わり、VMクラスタのステータスがAvailable
に変わります。 「更新履歴」をクリックすると、個々のパッチ操作の詳細を表示できます。 Grid Infrastructureのパッチ適用はローリング方式で行われ、ノードごとに行われ、クラスタ・リソースは各ノードで停止および再起動されます。
コンソールを使用したデータベース・ホームでの更新操作の実行
データベース・ホームにパッチを適用する方法について学習します。
パッチ・リストには、操作のステータスが表示されます。 事前チェックの実行中、パッチ・ステータスはChecking
を示します。 パッチが適用されている間、パッチのステータスはApplying
と表示され、データベース・ホームおよびその中のデータベースのステータスはUpdating
と表示され、VMクラスタおよびそのリソースに対するライフサイクル操作は一時的に使用できません。 パッチはローリング方式、ノード単位でデータベース・ホームに適用され、ホーム内の各データベースは停止されてから再起動されます。 これにより、一時的なサービス中断が発生する可能性があります。 パッチ適用が正常に完了すると、パッチのステータスがApplied
に変わり、データベース・ホームのステータスがAvailable
に変わります。 「更新履歴」をクリックすると、個々のパッチ操作の詳細を表示できます。
コンソールを使用した更新履歴の表示
各更新履歴エントリは、試行されたパッチ操作を表し、操作が成功したか失敗したかを示します。 失敗したパッチ操作を再試行できます。 操作を繰り返すと、新しいパッチ履歴エントリが作成されます。
コンソールの更新履歴ビューには、dbaascli
などのコマンドライン・ツールを使用して適用されたパッチは表示されません。
- 「コンソールを使用したVMクラスタの更新履歴の表示」
VMクラスタに適用されたパッチの履歴を表示する方法について説明します。 - 「コンソールを使用したデータベース・ホームの更新履歴の表示」
データベース・ホームに適用されたパッチの履歴を表示する方法について説明します。
コンソールを使用したVMクラスタの更新履歴の表示
VMクラスタに適用されたパッチの履歴を表示する方法について説明します。
そのVMクラスタのパッチ操作の履歴が、そのデータベース・ホームでのパッチ操作の履歴とともに表示されます。
親トピック: コンソールを使用した更新履歴の表示
コンソールを使用したデータベース・ホームの更新履歴の表示
データベース・ホームに適用されたパッチの履歴を表示する方法について説明します。
そのデータベース・ホームのパッチ操作の履歴が、そのデータベース・ホームが属するVMクラスタのパッチ操作の履歴とともに表示されます。
親トピック: コンソールを使用した更新履歴の表示
コンソールを使用した別のホームへのデータベースの移動
目的のバージョンのOracle Databaseを実行しているデータベース・ホームにVMクラスタ・データベースを移動することで、そのバージョンを更新できます。
データベースはローリング方式で移動されます。 データベース・インスタンスが停止され、現在のホームでノードごとにノードされ、宛先ホームで再起動されます。 データベースの移動中、データベース・ホームおよびデータベース・ステータスは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クラスタ、データベース・システムまたはデータベース・ホームがそのパッチの要件を満たしていることを確認します。 事前チェックが正常に行われない場合、パッチは適用されず、事前チェックが失敗したためにパッチを適用できないというメッセージが表示されます。 計画更新の前に実行できる個別の事前チェック操作も使用できます。
- 「サポートされるソフトウェアのバージョンと更新の制限」
Exadataイメージ・リリース23.1.0.0.0 (Oracle Linux 8ベースのイメージ)に更新するための最小要件: - 「コンソールを使用したゲストVMオペレーティング・システムの更新」
ゲストVMオペレーティング・システムをコンソールで更新するには、必要なフィールドの値を提供する準備をしてください。 - 「コンソールを使用した失敗したゲストVMオペレーティング・システム更新のロールバックまたは再試行」
ゲストVMオペレーティング・システムをコンソールで更新するには、必要なフィールドの値を提供する準備をしてください。 - 「APIを使用したゲストVMオペレーティング・システムの更新」
ゲストVMオペレーティング・システムを更新するAPIコールのリストを確認します。
サポートされるソフトウェアのバージョンと更新の制限
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オペレーティング・システムをコンソールで更新するには、必要なフィールドの値を提供する準備をしてください。
ノート:
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オペレーティング・システムをコンソールで更新するには、必要なフィールドの値を提供する準備をしてください。
親トピック: ゲストVMオペレーティング・システムの更新
APIを使用したゲストVMオペレーティング・システムの更新
ゲストVMオペレーティング・システムを更新するAPIコールのリストを確認します。
APIの使用およびリクエストの署名の詳細は、REST APIおよびセキュリティ資格証明を参照してください。 SDKについては、ソフトウェア開発キットとコマンドライン・インタフェースを参照してください。
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 Grid Infrastructureのアップグレードについて」
VMクラスタのOracle Grid Infrastructure (GI)をアップグレードするには、インスタンス内のすべてのコンピュート・ノードをアップグレードします。 アップグレードはローリング方式で実行され、一度にアップグレードされるノードは1つのみです。 - 「コンソールを使用したOracle Grid Infrastructureアップグレードの管理」
コンソールを使用して、Oracle Grid Infrastructure (GI)をアップグレードする前に事前チェックを実行し、GIアップグレード操作を実行できます。 - 「APIを使用したOracle Grid Infrastructureアップグレードの管理」
Oracle Grid Infrastructureアップグレードを管理するためのAPIコールのリストを確認します。
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クラスタの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クラスタではサポートされていません。APIを使用したOracle Grid Infrastructureアップグレードの管理
Oracle Grid Infrastructureアップグレードを管理するためのAPIコールのリストを確認します。
APIの使用およびリクエストの署名の詳細は、REST APIおよびセキュリティ資格証明を参照してください。 SDKについては、ソフトウェア開発キットとコマンドライン・インタフェースを参照してください。
ListVmClusterUpdates
GetVmClusterUpdate
ListVmClusterUpdateHistoryEntries
GetVmClusterUpdateHistoryEntry
UpdateVmCluster
APIの完全なリストは、「データベース・サービスAPI」を参照してください。
Oracleデータベースのアップグレード
コンソールおよびAPIを使用して、Exadataデータベース・インスタンスをOracle Database 19cおよびOracle Database 23aiにアップグレードする方法について学習します。
アップグレードは、ターゲット・ソフトウェア・バージョンを使用するデータベース・ホームにExadataデータベースを移動することで行われます。 Oracle Databaseリリースおよびソフトウェア・サポートのタイムラインについては、「現在のデータベース・リリースのリリース・スケジュール(ドキュメントID 742060.1)」を参照してください。
- 「Oracle Databasesをアップグレードするための前提条件」
Exadata Cloud@Customer Oracle Databaseインスタンスをアップグレードするための前提条件のリストを確認します。 - 「Oracle Databaseのアップグレードについて」
データベースをアップグレードする前に、次の手順に従ってデータベースをアップグレード用に準備します。 - 「データベース・サービスによるアップグレード操作の実行方法」
アップグレード・プロセス中にデータベース・サービスが実行する内容について理解します。 - 「Oracle Databaseのロールバックアップグレード失敗」
アップグレードが正常に完了しない場合は、ロールバックを実行するオプションがあります。 - 「Oracle Databaseのアップグレード後」
アップグレードが成功したら、次の点に注意してください: - 「コンソールを使用したOracle Databaseアップグレードの管理」
Oracleでは、事前チェック処理を使用して、データベースがアップグレード操作の要件を満たしていることを確認することをお薦めします。 - 「APIを使用したOracle Databasesのアップグレード」
Oracle DatabasesをアップグレードするAPIコールのリストを確認します。
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 Databaseドキュメント」を参照してください。
Oracle Databaseのアップグレードについて
データベースをアップグレードする前に、次の手順に従ってデータベースをアップグレード用に準備します。
- データベースのアップグレードには、データベースのダウンタイムが含まれます。 アップグレードをスケジュールするときは、この点に注意してください。
- Oracleでは、本番データベースをアップグレードする前に、データベースをバックアップし、テスト・システムまたはクローニングされたバージョンのデータベースで新しいソフトウェア・バージョンをテストすることをお薦めします。 オンデマンド手動バックアップの作成の詳細は、「bkup_apiユーティリティを使用してオンデマンド・バックアップを作成」を参照してください。
- Oracleでは、アップグレードの実行を計画する前に軽減が必要な問題を検出できるように、アップグレードを試行する前に、データベースのアップグレード事前チェック操作を実行することをお薦めします。 事前チェック操作はデータベースの可用性に影響せず、都合のよいときにいつでも実行できます。
- データベースでData Guardを使用している場合、まずプライマリまたはスタンバイのいずれかをアップグレードできます。
- 自動バックアップ操作が行われている間は、アップグレード操作を実行できません。 アップグレードの前に、Oracleでは自動バックアップを無効にし、手動バックアップを実行することをお薦めします。 詳細は、「bkup_apiユーティリティを使用してオンデマンド・バックアップを作成」および「自動バックアップ構成のカスタマイズ」を参照してください。
- アップグレード後、アップグレード前に取得された自動バックアップを使用して、データベースを以前の時点にリストアすることはできません。
- バージョン11.2ソフトウェアを使用するデータベースをアップグレードする場合、結果のバージョン19cデータベースは非コンテナ・データベース(非CDB)になります。
データベース・サービスによるアップグレード操作の実行方法
アップグレード・プロセス中にデータベース・サービスが実行する内容について理解します。
- 自動事前チェックを実行します。 これにより、システムが緩和が必要な問題を特定し、アップグレード操作を停止できます。
- 保証付きリストア・ポイントを設定し、アップグレード失敗時にフラッシュバックを実行できます。
- 目的のターゲット・ソフトウェア・バージョンを使用するユーザー指定のOracle Databaseホームにデータベースを移動します。
- Database Upgrade Assistant (DBUA)ソフトウェアを実行してアップグレードを実行します。
親トピック: Oracle Databasesのアップグレード
Oracle Databaseのロールバックアップグレード失敗
アップグレードが正常に完了しない場合は、ロールバックを実行するオプションがあります。
失敗の詳細がコンソールの「データベースの詳細」ページに表示され、失敗の原因となる問題を分析および解決できます。
ロールバックによって、データベースがアップグレード前の状態にリセットされます。 アップグレード中およびアップグレード後に行われたデータベースへのすべての変更は失われます。 ロールバック・オプションは、アップグレード操作の失敗後にデータベースのデータベースの詳細ページに表示されるバナー・メッセージに示されます。 詳細は、「コンソールを使用した失敗したデータベース・アップグレードのロールバック」を参照してください。
親トピック: Oracle Databasesのアップグレード
Oracle Databaseのアップグレード後
アップグレードが成功したら、次の点に注意してください:
- アップグレード前に自動バックアップを無効にした場合、データベースの自動バックアップが有効になっていることを確認します。 詳細は、「自動バックアップ構成のカスタマイズ」を参照してください。
- Oracle Databaseを編集
新しいOracle Databaseソフトウェアのバージョンを反映するパラメータ。 詳細は、「Oracle Databaseの互換性とは」を参照してください。COMPATIBLE
- データベースで
database_name.env
ファイルを使用する場合は、ファイルの変数が19cデータベース・ホームを指すように更新されていることを確認します。 これらの変数は、アップグレード・プロセス中に自動的に更新される必要があります。 - 非コンテナ・データベースをOracle Databaseバージョン19cにアップグレードする場合、変換後にデータベースをプラガブル・データベースに変換できます。 データベースをプラガブル・データベースに変換する手順については、「非CDBをPDBに変換する方法(ドキュメントID 2288024.1)」を参照してください。
- 古いデータベース・ホームが空で、再利用されない場合は削除できます。 詳細は、「コンソールを使用したOracle Databaseホームの削除」を参照してください。
コンソールを使用したOracle Databaseアップグレードの管理
Oracleでは、事前チェック処理を使用して、データベースがアップグレード操作の要件を満たしていることを確認することをお薦めします。
APIを使用したOracle Databasesのアップグレード
Oracle DatabasesをアップグレードするAPIコールのリストを確認します。
APIの使用およびリクエストの署名の詳細は、REST APIおよびセキュリティ資格証明を参照してください。 SDKについては、ソフトウェア開発キットとコマンドライン・インタフェースを参照してください。
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ゲストVMでオペレーティング・システム・コンポーネントを更新するために使用できる標準のExadataツールおよび手法について学習します。
関連トピック
ソフトウェアの手動更新
サマー・タイムと一部の定期パッチまたは個別パッチでは、ソフトウェアに手動でパッチを適用する必要があります。
- 夏時間(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アップグレード・ガイド」でパッチ・セットの更新および要件に関する情報を参照してください。
ゲスト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システムのすべての仮想マシン上のオペレーティング・システムの更新」
データベース・サーバー仮想マシン(VM)のオペレーティング・システムを更新するには、patchmgr
ツールを使用します。 - 「追加のオペレーティング・システム・パッケージのインストール」
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
です。 - 各ノードは、他のノードを更新するための駆動システムとして使用されます。
- 環境の詳細を収集します。
- SSHを使用して、
opc
ユーザーとしてnode1に接続します。詳細な手順については、「SSHを使用したコンピュート・ノードへの接続」を参照してください。
root
ユーザー・コマンド・シェルを起動します。sudo su -
- 次のコマンドを実行して、現在のExadataソフトウェア・バージョンを確認します。
imageinfo -ver
たとえば:# imageinfo -ver 19.2.13.0.0.200428
grid
ユーザーに切り替えて、クラスタ内のすべてのノードを識別します。su - grid
olsnodes
たとえば:olsnodes node1 node2
- SSHを使用して、
- 駆動システムを構成します。
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 | | . . + . | | ... | +-----------------+
- 公開キーをターゲット・ノードに配布し、このステップを確認します。 この例では、ターゲット・ノードは
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
- ターゲット・ノード(この例では
node2
)で、node1
のルート公開キーをルートauthorized_keys
ファイルに追加します。cat /tmp/id_rsa.node1.pub >> ~root/.ssh/authorized_keys
- 駆動システム(この例では
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。 patchmgr
バンドルを解凍します。ダウンロードしたバージョンによって、ZIPファイルの名前が異なる場合があります。
cd
/root/patch/18.1.4.0.0.180125.3
unzipdbserver.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/fwverifypatchmgr
ユーティリティを含むディレクトリで、更新する仮想マシンのリストを含む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
- パッチ適用前チェック操作を実行します。
./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). - 現在のシステムをバックアップします。
./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).
- ターゲット仮想マシンからすべてのカスタム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は、更新プロセス中に自動的に処理されます。
- システムをバージョン12.1.2.3から更新する場合。4.170111および事前チェックの結果には
- 更新を実行します。 更新プロセスが中断されないようにするには、コマンド
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)
- 更新操作が完了したら、更新された仮想マシン上のExadataソフトウェアのバージョンを確認します。
imageinfo -ver 18.1.4.0.0.180125.3
- この手順のステップ2から7を繰り返し、更新された仮想マシンを駆動システムとして使用して残りの仮想マシンを更新します。 この更新例では、
node2
を使用してnode1
を更新します。 root
として、各仮想マシンでuptrack-install
コマンドを実行して、使用可能なksplice
更新をインストールします。uptrack-install --all -y
uptrack-install --all -y
関連トピック
親トピック: ゲストVMオペレーティング・システムの手動更新
追加のオペレーティング・システム・パッケージのインストール
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メンテナンス・ガイド」を参照してください。
親トピック: ゲストVMオペレーティング・システムの手動更新