9 データを保持する再プロビジョニングを使用したOracle Database Applianceのアップグレード
Oracle Database Applianceソフトウェアを中間リリースにアップグレードせずに、Oracle Database Applianceリリース12.1.2.12、12.2.1.4、18.3、18.5、18.7および18.8から最新リリースに直接アップグレードする方法を理解します。
- データを保持する再プロビジョニングを使用したアップグレードについて
アプライアンスを中間リリースにアップグレードせずに、Oracle Database Applianceリリース12.1.2.12、12.2.1.4、18.3、18.5、18.7および18.8から最新リリースにアップグレードする方法を理解します。 - ステップ1: データを保持する再プロビジョニングを使用したアップグレードのためのノードのデタッチ
Oracle Database Applianceリリース12.1.2.12、12.2.1.4、18.3、18.5、18.7および18.8から最新リリースへのアップグレードのステップ1では、Oracle Database Applianceノードをデタッチします。 - ステップ2: データを保持する再プロビジョニングを使用したアップグレードのためのノードの再イメージ化
Oracle Database Applianceリリース12.1.2.12、12.2.1.4、18.3、18.5、18.7および18.8から最新リリースへのOracle Database Applianceのアップグレードのステップ2。 - ステップ3: データを保持する再プロビジョニング方法を使用したノードのプロビジョニング
Oracle Database Applianceリリース12.1.2.12、12.2.1.4、18.3、18.5、18.7および18.8から最新リリースへのOracle Database Applianceのアップグレードのステップ3。
データを保持する再プロビジョニングを使用したアップグレードについて
アプライアンスを中間リリースにアップグレードせずに、Oracle Database Applianceリリース12.1.2.12、12.2.1.4、18.3、18.5、18.7および18.8から最新リリースにアップグレードする方法を理解します。
Oracle Database Applianceリリース12.1.2.12、12.2.1.4、18.3、18.5、18.7および18.8からアップグレードする場合は、最終的にアプライアンスにパッチを適用して最新リリースに更新できるように、中間リリースにアップグレードする必要があります。このプロセスにはアップグレード・パスの多くのステップが含まれ、パッチ適用の時間とアプリケーションの停止時間が長くなる可能性があります。データを保持する再プロビジョニングを使用して、アプライアンスを最新リリースに直接アップグレードできます。
データを保持する再プロビジョニングを使用したアップグレードについて
データを保持する再プロビジョニングにより、アプライアンス上のストレージおよびデータベースを変更せずに、すでにデプロイされているOracle Database Applianceシステムを再プロビジョニングできます。通常のアップグレード・プロセスよりもこの方法が優れている点は、アップグレード・パスが非常に短いことです。これは、ソース・システムの情報を保存し、サーバー・データ・アーカイブ・ファイルとして取得することによって実現されます。その後、アプライアンスをOracle Database Applianceリリース19.20以降などの目的のバージョンに再イメージ化します。保存されたメタデータを使用してシステムを直接再プロビジョニングし、すべてのデータベースを戻します。
- アップグレード・ユーティリティは、非アクティブになっているデータベースの検出などの事前チェックをシステムで実行し、アプライアンスをアップグレードする前に警告します。これらの失敗に事前に対処できるため、アプライアンスの再プロビジョニング時に問題が発生しません。
- ノードをデタッチする最初のステップでは、VLAN、CPUおよびOracle AFDの設定に関する情報など、システムに関する情報が収集されて保持されます。これらの設定は再イメージ化後に移行され、このプロセスの3番目のステップでこれらの設定が再プロビジョニングされます。
- デプロイメントは、最初はOracle Database Applianceリリース12.1.2.12、12.2.1.4または18.xです。ただし、再プロビジョニング・プロセスの後、ソフトウェアがOracle Database Applianceリリース19.20にアップグレードされ、デプロイメントが、必要に応じて新しい機能を使用して、自動的に開始されます。たとえば、データベース・ソフトウェアはOracle ACFSベースのストレージにインストールされます。
- アプライアンスを中間リリースにアップグレードせずに、最新のOracle Database Applianceリリースに直接アップグレードできます。
アップグレード・プロセスのためのデータを保持する再プロビジョニングのステップ
- アプライアンスのソース・バージョンのOracle Database Applianceアップグレード・ユーティリティを使用したノードのデタッチ: このステップでは、データベース、リスナー、ネットワークおよびその他の構成詳細に関するメタデータがアーカイブ・ファイル(サーバー・データ・アーカイブ・ファイル)に保存されます。次に、ステップ2での再イメージ化の準備を整えるために、システムで実行されているサービスが停止およびアンインストールされます。
サーバー・データ・アーカイブ・ファイルは、ノードが正常にデタッチされた後に生成されます。アップグレードするアプライアンス以外の場所にサーバー・データ・アーカイブ・ファイルを保存し、これらのファイルをアプライアンスにコピーして、ステップ3でシステムをリストアする必要があります。
- Oracle Database Appliance ISOイメージを使用したノードの再イメージ化: この手順は、アプライアンスのプロビジョニングに似ています。このステップでは、アップグレード先のOracle Database Applianceリリースでオペレーティング・システムおよびDCSソフトウェアを設定します。
- データを保持する再プロビジョニング方法を使用したノードのプロビジョニング: このステップでは、ネットワーク、オペレーティング・システムのユーザーおよびグループを再構成し、Oracle Grid Infrastructureをインストールして、ライセンス済CPUコアを構成します。その後、このステップでは、ステップ1でデタッチする前と同じ状態にデータベースを再プロビジョニングします。データベースが再起動され、Oracle Grid Infrastructureクラスタに追加されます。
各ステップの手順の詳細は、この章の後続のトピックで説明します。
アプライアンスのカスタマイズとアップグレード後の永続性
- カスタムRPM: アプライアンスにOracle Linux Yumリポジトリからカスタム・オペレーティング・システムがインストールされている場合、事前チェック・レポートにこれらのカスタムRPMがリストされます。これらのRPMをアンインストールしてから、アップグレード・プロセスの次のステップに進む必要があります。アップグレード後に、必要に応じてこれらのカスタムRPMを再インストールできます。
- STIGおよびCISスクリプトによって適用される修正: システムはアップグレードの進行中に再イメージ化されるため、セキュリティ技術導入ガイド(STIG)およびCenter for Internet Security (CIS)ベンチマークに準拠するようにアプライアンスに適用された修正は失われます。最新のISOイメージで再イメージ化すると、オペレーティング・システムがOracle Linux 7にアップグレードされます。次に、STIGおよびCISスクリプトを再実行する必要があります。
- Oracle ASR: Oracle ASRは、再プロビジョニング・プロセス中にリストアされません。再プロビジョニング・プロセスの後に、コマンド
odacli configure-asr
を使用して、最新のRPMでOracle ASRを手動で構成できます。
ステップ1: データを保持する再プロビジョニングを使用したアップグレードのためのノードのデタッチ
Oracle Database Applianceリリース12.1.2.12、12.2.1.4、18.3、18.5、18.7および18.8から最新リリースへのアップグレードのステップ1では、Oracle Database Applianceノードをデタッチします。
重要:
このトピックのコマンドは、記載されているとおりの順序で実行してください。重要:
このプロセスを開始する前に、データベースのバックアップを作成したことを確認します。このプロセス中にノードが再イメージ化されるため、バックアップがアプライアンスの外部の場所に格納されていることを確認します。警告:
odaupgradeutil detach-node
コマンドの実行前または実行後にcleanup.plを実行しないでください。cleanup.plを実行すると、ストレージ上のすべてのOracle ASMディスク・グループが消去され、Oracle Database Applianceシステムを再プロビジョニングできません。
警告:
これらのファイルは必ず、Oracle Database Applianceシステムの外部の場所に保存してください。このプロセスのステップ2でアプライアンスを再イメージ化した後、システムを再プロビジョニングするためにこれらのファイルが必要になります。これらのファイルがないと、ステップ3でシステムを再プロビジョニングできず、Oracle ASMディスク・グループに格納されているすべてのデータが失われます。重要:
ソース・バージョンでDCSソフトウェアが実行されている場合、odaupgradeutil
コマンドではDCSメタデータは編集されません。これは、データベースなどのリソースが構成解除されても、コマンドodacli list-databases
では引き続きそのステータスがCONFIGURED
として表示されることを意味します。ただし、実際には、データベース・サービスは停止し、リスナーはアクティブではなくなります。これらは、データベース・ホームからsrvctl
コマンドを使用して確認できます。これは予期された動作です。
ステップ2: データを保持する再プロビジョニングを使用したアップグレードのためのノードの再イメージ化
Oracle Database Applianceリリース12.1.2.12、12.2.1.4、18.3、18.5、18.7および18.8から最新リリースへのOracle Database Applianceのアップグレードのステップ2。
警告:
ノードの再イメージ化の前後にcleanup.plを実行しないでください。cleanup.plを実行すると、ストレージ上のすべてのOracle ASMディスク・グループが消去され、Oracle Database Applianceシステムを再プロビジョニングできません。- Oracle Database Applianceリリース19.20のベア・メタルISOイメージをダウンロードし、「Oracle Database Applianceベア・メタル・システムの再イメージ化」のトピックの説明に従ってアプライアンスを再イメージ化します。
- 「ネットワークのplumb」のトピックの説明に従って、ネットワークをplumbします。
重要:
高可用性システムの場合、serverarchive_node0_hostname.zip
およびserverarchive_node1_hostname.zip
には、ファイルconfigure-firstnet.rsp
が含まれています。単一ノード・システムの場合、serverarchive_hostname.zip
にはファイルconfigure-firstnet.rsp
が含まれています。configure-firstnet.rsp
ファイルには、システムの再イメージ化後にodacli configure-firstnet
を実行するときに指定する必要がある値が含まれています。ファイルconfigure-firstnet.rsp
を抽出し、任意のテキスト・エディタを使用してファイルを開き、ファイルに保存されているIPアドレスを指定します。
ステップ3: データを保持する再プロビジョニング方法を使用したノードのプロビジョニング
Oracle Database Applianceリリース12.1.2.12、12.2.1.4、18.3、18.5、18.7および18.8から最新リリースへのOracle Database Applianceのアップグレードのステップ3。
警告:
Oracle Database Applianceリリース19.20以降でシステムを再イメージ化した直後にファームウェアを更新します。ファームウェアの更新に失敗すると、再プロビジョニング・ステップ中にエラーが発生する可能性があります。警告:
コマンドodacli restore-node -g
を実行する前に、cleanup.plを実行しないでください。cleanup.plを実行すると、ストレージ上のすべてのOracle ASMディスク・グループが消去され、すべてのデータベースをそのまま保持してOracle Database Applianceシステムを再プロビジョニングすることができなくなります。ただし、コマンドodacli restore-node -g
を少なくとも1回実行し、再プロビジョニングのプロセスが開始されると、クリーン・アップは再プロビジョニングの試行に固有となり、Oracle ASMディスク・グループは消去されません。コマンドodacli restore-node -g
が失敗した場合、cleanup.plを使用してそのステップの失敗をクリーン・アップできます。このような場合は、コマンドodacli restore-node -g
を再試行して、プロビジョニングを完了する必要があります。
警告:
アプライアンスの再イメージ化後は、ブラウザ・ユーザー・インタフェース(BUI)にログインしないでください。odacli restore-node -g
コマンドを実行すると、oda-admin
ユーザーのパスワードの入力を求められます。odacli restore-node -g
およびodacli restore-node -d
コマンドが正常に完了した後に、このパスワードを使用してBUIにログインします。odacli restore-node -g
およびodacli restore-node -d
操作を完了する前に、BUIを起動しないでください。