データ保持再プロビジョニング: 一般
データ保持再プロビジョニング・プロセスに関する一般的なFAQをご確認ください。
Oracle Database ApplianceデプロイメントでOracle Database Applianceリリース18.8が実行されています。システムをOracle Linux 8およびOracle Database Applianceリリース19.24に直接アップグレードできますか。
いいえ。番号18.8より前のリリースを使用しているアプライアンスは、Oracle Database Applianceリリース19.20ドキュメント・ライブラリにある『Oracle Database Applianceデプロイメントおよびユーザーズ・ガイド』のデータ保持再プロビジョニングを使用したOracle Database Applianceのアップグレードの章で説明されているステップを使用して、まずOracle Database Applianceリリース19.20以降にアップグレードする必要があります。Oracle Linux 7を実行しているシステムをOracle Databaseリリース19.20以降にアップグレードした後、Oracle Linux 8にアップグレードできます。
データ保持再プロビジョニングを使用したアップグレードに通常必要な時間はどれくらいですか。
合計停止時間は、システム構成や作成されたデータベースやDBシステムなどのリソース数など、いくつかの要因によって異なります。24個のSSDディスクと32個のコアが使用可能なOracle Database Appliance X9-2-HA、およびベア・メタル・システム上に3つのOracle Database 19cデータベースおよび2つのOracle Database Applianceリリース19.18 DBシステムを備えたX9-2M単一ノード・システムの場合、ベア・メタル・システムとDBシステムを19.18から19.22にアップグレードする時間は、高可用性システムの場合で約4時間、単一ノード・システムの場合で約2時間30分です。
Oracle Database ApplianceをOracle Linux 8にアップグレードする際にインプレース・アップグレードではなくデータ保持再プロビジョニングを使用するのはなぜですか?
Linuxオペレーティング・システムのアップグレード・ユーティリティであるLeappは、Oracle Linux 7システムからOracle Linux 8へのインプレース・アップグレードを実行するフレームワークです。Leappでは、アップグレードの実行前に、アップグレードするシステムに対して一連のアップグレード前チェックが実行されます。これらのアップグレード前チェックでは、システムに特定の要件が課されます。たとえば、Leappでは、実際のアップグレードを実行する前に、YUMリポジトリにアクセスして最新のOracle Linux 7リリースに更新する必要があり、ロックされたパッケージのクリア、セキュア・ブートおよびFIPSモードの無効化、Unbreakable Enterprise Kernel 6のカーネル、NFSエクスポートのアンマウントなどが想定されています。Oracle Database Applianceは、セキュアなエンジニアド・システムであるため、採用されている設計上の選択肢では、Oracle Database Applianceソフトウェア・スタックと統合するためにLeappソフトウェアの拡張が必要になります。たとえば、Oracle Database Applianceでは、RPMパッケージ・バージョンで非常に特異的な一連のRPMロックが使用され、YUMリポジトリへのアクセスは想定されておらず、FIPSサポートが有効になっており、Unbreakable Enterprise Kernel 6は使用されず、NFSを介してOracle Database ApplianceリポジトリがDBシステムにエクスポートされます。また、各Oracle Database ApplianceシステムにLeappについて異なる一連の問題(阻害要因とも呼ばれる)があることがあり、それにより、すべてのユーザーのアップグレード・エクスペリエンスを一致させることが難しくなります。それに対して、データ保持再プロビジョニングで採用されているクリーン・インストールの手法では、Oracle Database Applianceのアプライアンス原則を引き続きサポートしながら、統一されたアップグレード・エクスペリエンスが提供されます。
LEAPの詳細は、Leappの使用によるシステムのアップグレードのトピック(https://docs.oracle.com/en/operating-systems/oracle-linux/8/leapp/leapp-AboutLeapp.html)を参照してください
Oracle Database Applianceのベア・メタル・システムおよびDBシステムをOracle Linux 8にアップグレードする前のデータベースについて、サポートされている最小バージョンを教えてください。
- 19.18.0.0.230117以降: データベースをOracle Linux 8環境で再起動できます。
- 21.8.0.0.221018 (DBシステムのみ): 21cデータベースを含むDBシステムは、Oracle Linux 8ベア・メタルOracle Linux 7で再起動できます。21cデータベースを含むDBシステムは、Oracle Linux 8のDBシステムにアップグレードでき、21cデータベースを保持できます。
デプロイメントはOVMであり、Oracle Database Applianceリリース19.13を使用しています。データ保持再プロビジョニング・プロセスを使用してシステムをOracle Linux 8にアップグレードできますか?
いいえ。Oracle Database Applianceリリース19.20ドキュメント・ライブラリにある『Oracle Database Applianceデプロイメントおよびユーザーズ・ガイド』のOracle Database Appliance上の仮想化プラットフォームからKVMへの移行の章で説明されているステップを使用して、まずアプライアンスをOracle Database Applianceリリース19.18以降にアップグレードする必要があります。DCSソフトウェアとOracle Linux 7があるシステムをOracle Databaseリリース19.18以降にアップグレードした後、Oracle Linux 8にアップグレードできます。
Oracle Linux 7からOracle Linux 8にシステムをアップグレードするときにODABRを使用できますか。
https://support.oracle.com/rs?type=doc&id=2466177.1にあるMy Oracle SupportノートODA (Oracle Database Appliance): ODABRシステム・バックアップ/リストア・ユーティリティを参照してください。このノートには、ODABRはOracle Linux 7からOracle Linux 8へのシステムのアップグレードには役立たない可能性があると記載されています。ODABRの主な用途は、システムへのパッチ適用中に変更されたLVMスナップショットおよびバックアップ・データ・ブロックを作成することです。データ保持再プロビジョニングは、Oracle Database Applianceシステムのオペレーティング・システムのOracle Linux 7からOracle Linux 8へのアップグレードを編成し、Oracle Linux 8 ISOイメージを使用してシステムの再イメージを作成します。再イメージ化中に、LVMが再初期化され、ブート・ドライブ上のスナップショットが失われます。共有ストレージ上のデータベース・ホームおよびデータベース・ファイルは、この再イメージ化によって失われることはありません。
データ保持再プロビジョニングを使用してOracle Database Applianceのベア・メタル・システムをアップグレードするにはどのくらい時間がかかりますか?
Oracle Database Appliance X9-2-HAのアップグレードにかかる時間は、次のとおりです:
表1-3 Oracle Database Applianceベア・メタル・システムへのパッチの適用にかかる時間
| 更新するコンポーネント | 更新にかかる時間(h:mm:ss) |
|---|---|
| ベア・メタル・システムのインフラストラクチャ更新 |
|
| DBシステムのインフラストラクチャ更新 |
|
| アップグレード前レポート | 0:04:16 |
| ノード・デタッチ操作 | 0:27:14 |
| Oracle Linux 8のISOイメージを使用した再イメージ化、1つ目のネットワークの構成、サーバーzipでのリポジトリの更新、およびOracle Grid Infrastructureクローンでのリポジトリの更新 | 1:30:00 |
| Oracle Grid Infrastructure、データベース、Oracle KVMおよびDBシステムのリストア |
|
| DBシステムのアップグレード |
|
| 合計所要時間 | 約04:00:30 |
デプロイメント内のデータベースでサポート対象リリースが使用されていません。ベア・メタル・システムをOracle Linux 8にアップグレードするにはどうすればよいですか?
- 18.14.0.0.210420
- 12.2.0.1.220118
- 12.1.0.2.220719
- 11.2.0.4.210119
データ保持再プロビジョニング・プロセスを使用したアップグレード時にリストアされないのはどのようなカスタマイズですか?
ユーザー・プロファイル、カーネル・パラメータ、追加インストールされたRPM、またはデータベース上に追加作成されたサービスに対するカスタマイズは、データ保持再プロビジョニングを使用したアップグレードの間にはリストアされません。
追加のオペレーティング・システムRPMがシステムにインストールされています。これらは、データ保持再プロビジョニングの一部としてリストアされますか。
いいえ。データ保持再プロビジョニング・プロセスでは、最新のOracle Database Appliance ISOイメージを使用した再イメージ化が行われるため、オペレーティング・システムRPMの以前のカスタマイズ、またはオペレーティング・システム内のサービスの設定または構成のカスタマイズが失われます。これらのRPMをアンインストールしてから、アップグレード・プロセスの次のステップに進む必要があります。アップグレード後に、必要に応じてこれらのカスタムRPMを再インストールできます。
システム上にVLANを構成しました。これらのVLANはアップグレードされたシステム上で構成されますか。
はい。
odacli detach-nodeコマンドを実行する前にデータベースのバックアップを作成する必要がありますか?
データベース・ファイルはOracle ASMディスク・グループにそのまま残され、再プロビジョニングの成功後にデータベースを起動するために使用されます。ただし、データベース・バックアップは安全対策として取得する必要があります。
2-JBOD構成があります。データ保持再プロビジョニングはこの構成でサポートされていますか。
はい。
ソース・データベースで追加のオプション(ASOなど)を有効にしています。これらのオプションは保持されますか。
ソース・データベース・ホームがルート・ファイル・システム上にある場合、Oracleソフトウェアの一部であるオプションは保持されません。odacli restore-node -dコマンドのプロセスの一環として、デフォルト・オプションを使用して新しいデータベース・ホームが作成されます。ソース・データベース・ホームがOracle ACFSファイル・システム上にある場合、データベース・ホームは削除されないため、オプションは保持されます。
データ保持再プロビジョニングでソース・バージョンとしてサポートされているのはどのOracle Database Applianceリリースですか?
ソース・バージョンは、Oracle Database Applianceリリース19.17以上である必要があります。DCSソフトウェアとOracle Grid Infrastructureは、Oracle Database Applianceリリース19.17のベア・メタル・システム上にある必要があります。ベア・メタル・システムで実行されているDBシステムについても同じ要件が存在します。なお、Oracle Database Applianceリリース19.20.0.1は、Oracle Linux 8ですでに実行されているため、有効なソース・バージョンではありません。
データ保持再プロビジョニングの再イメージ化処理後、データベース監査データはどうなりますか。
データベースの監査データは、データベース表、オペレーティング・システム・ファイルまたはSYSLOGのいずれかです。データベース表のデータのみが保持されます。システムの再イメージ化を開始する前に、ルート・ファイル・システムに存在する監査データを保存する必要があります。
ソースODAバージョンのノードをデタッチした後でcleanup.plを実行できますか。
いいえ。アップグレード・プロセス中は、cleanup.plは実行しないでください。このユーティリティは、Oracle ASMディスク・グループを消去してから、データベースをリストアすることはできません。コマンドodacli restore-node -gの実行に失敗した場合は、cleanup.plを使用して、Oracle ASMディスク・グループの保持中にシステムをクリーン・アップできます。cleanup.plをDPRモードで実行し、-nodprオプションは使用しないでください。
データベース・ホームに存在するすべてのファイルは保持およびリストアされますか。
ローカル・データベース・ホームは、再イメージ化の間に削除されます。これらのデータベース・ホームにあるファイル(TDEウォレットなど)は保持されません。
Oracle Database Applianceリリース19.24に再プロビジョニングした後に、ルート・ファイル・システムにデータベース・ホームを作成できますか?
いいえ。データベース・ホームはOracle ACFSでのみ作成できます。
Oracle ACFSのデータベース・ホームおよびデータベース・クローンには、どのくらいの領域が必要ですか。
Oracle ACFSボリュームにあるデータベース・ホームの場合、データベース・ホームは保持され、これらのホーム内のすべてのファイルが保持されます。Oracle ACFSにあるデータベース・クローンの場合、合計150 GBが必要です。データベース・ホームに必要な領域は15 GBであり、リストアするデータベース・ホームの数を乗算した値です。領域の可用性は、odacli create-preupgradereport事前チェックによってソースでも検証されます。
Oracle Grid InfrastructureクローンとOracle Databaseクローンを一緒に解凍する必要がありますか。
いいえ。コマンドodacli restore-node -gを実行する前に、Oracle Grid Infrastructureのクローンのみを解凍することをお薦めします。コマンドodacli restore-node -gが正常に実行されると、Oracle Grid Infrastructureクローンが、150 GBの領域があるOracle ACFSに移動されます。
いずれかの操作中にノードが再起動しますか。
コマンドodacli restore-node -gでは、ノードは再起動されません。再イメージ化の後にodacli update-serverコマンドを実行すると、ノードが再起動されます。
データ保持再プロビジョニングを使用した再プロビジョニング後に、-erasedataまたは-fを使用したクリーン・アップが失敗するのはなぜですか。
データ保持再プロビジョニング環境では、デフォルトのクリーン・アップ・モードは、データ保持再プロビジョニング・モードです。このモードでは、コマンドodacli restore-node -gを再試行できるように、Oracle ASMディスクを消去せずにアプライアンスをクリーン・アップします。このモードは、コマンドodacli update-repositoryがサーバー・アーカイブを生成するステップを完了した後に有効になります。このモードでは、-erasedataまたは-fオプションの使用はサポートされません。
-nodprオプションで通常のクリーン・アップを強制します:cleanup.pl -nodpr -erasedata / -fBUIで「Data Preserving Reprovisioning」タブが表示されるのはいつですか?
DCSインフラストラクチャがOracle Database Applianceリリース19.24にアップグレードされた後にのみ、BUIの左側のナビゲーション・リストに「Data Preserving Reprovisioning」タブが表示されます。
BUIの「Data Preserving Reprovisioning」画面で一部のタブが無効になっているのはなぜですか?
- Re-provision
- Restore Databases
- Restore VM Instances
- Restore DB Systems
- Upgrade DB Systems
「Re-provision」タブは常に有効ですが、タブ2から5は、アプライアンスがOracle Database Applianceリリース19.24に再イメージ化された後のみ有効になります。
BUIを使用してアプライアンスを再イメージ化できますか?
いいえ。Oracle ILOMコンソールを使用してアプライアンスを再イメージ化する必要があります。ノードをデタッチすると、BUIで、サーバー・アーカイブ・ファイルのコピーをアプライアンスの外部の場所に保存するよう求めるメッセージが表示され、その後、再イメージ化に進みます。
ネットワーク・インタフェースでLACPを有効にしてある場合に実行が必要なステップはありますか?
アプライアンスの再イメージ化の後に、odacli configure-firstnetコマンドを実行してLACPを有効にする必要があります。