1. データベース・アップグレード・ガイド
  2. Oracle DatabaseアップグレードでのAutoUpgradeの使用
  3. AutoUpgradeおよびOracle Databaseの構成オプション

AutoUpgradeおよびOracle Databaseの構成オプション

AutoUpgradeを実行すると、データベースのタイプ(Oracle Database、Oracle ASMを備えたOracle DatabaseスタンドアロンまたはOracle RAC)が判別され、そのタイプのデータベースのアップグレードが実行されます

親トピック: Oracle DatabaseアップグレードでのAutoUpgradeの使用

非CDBからPDBへのアップグレードのガイドラインおよび例

変換前に、データファイルおよびデータベースをバックアップし、ソースのOracle Databaseリリースに関するガイドラインに従います。

変換に失敗した場合にリカバリできるようにするために、AutoUpgradeを使用して非CDBのアップグレードおよび変換を実行する前に、アップグレード計画に時間をかけてバックアップ戦略を実装してください。

アップグレード計画のガイドライン

非CDBからPDBへの変換とアップグレードのプロセスはリカバリできません。適切なアップグレードと変換、および予期しない停止時間を減らすために、分析フェーズ中に見つかったエラー状態に対処することをお薦めします。

構成ファイル内でtarget_pdb_copy_optionを使用してデータ・ファイルのコピーを作成する場合は、既存のデータベースをバックアップとして使用できます。これは安全なオプションですが、さらに時間とディスク領域が必要になります。AutoUpgrade構成ファイルのtarget_pdb_copy_optionを設定していない場合、データベース変換は、既存のデータベース・ファイルで使用されているファイルの場所およびファイル名と同じものを使用します。潜在的なデータ損失を防ぐには、データをバックアップし、AutoUpgradeを起動する前にファイル配置計画を検討するようにします。

非CDBからマルチテナント・アーキテクチャへのGRPとアップグレード

  • アップグレード中に、AutoUpgradeは、AutoUpgradeデプロイ・ワークフローのアップグレード・ステージのコンテキストでのみ使用可能な保証付きリストア・ポイント(GRP)を作成します。潜在的なデータ損失に備えて、AutoUpgradeを起動する前にバックアップ計画を実装する必要があります。
  • 非CDBからマルチテナント・アーキテクチャへのデータベース変換は、AutoUpgradeの排出ステージで実行されます。このステージが完了した後、AutoUpgradeによって作成されたGRPは削除され、AutoUpgradeのrestoreコマンドを使用してデータベースをリストアすることはできません。以前の非CDBのOracleデータベース・リリースへのリカバリが必要な場合は、データベースを手動でリカバリする準備が必要です。

例4-4 マルチテナント・アーキテクチャを使用した非CDBからOracle Database 19cへのアップグレードおよび変換

デプロイ変換およびアップグレード・ワークフロー中に、AutoUpgradeはGRPを作成し、事前修正ステージを実行します。事前修正ステージ完了までのデプロイ・ワークフローのいずれかの部分が失敗した場合、AutoUpgradeはデプロイメントの開始時に作成されたGRPにデータベースをリストアできます。

ただし、事前修正ステージが完了すると、アップグレードされたデータベースはターゲット・リリースのOracle Databaseコンテナ・データベース(CDB)に接続されて変換が完了します。非CDBがCDBに接続されるとすぐに、GRPは有効でなくなり削除されます。

接続の間になんらかの問題が発生し、構成ファイル内でtarget_pdb_copy_optionを使用してデータ・ファイルのコピーを作成しなかった場合、AutoUpgradeはデータベースをリカバリおよびリストアできないことに留意してください。その場合は、データベースを手動でリストアする必要があります。

親トピック: AutoUpgradeおよびOracle Databaseの構成オプション

Oracle Grid Infrastructure管理構成のAutoUpgradeプロセス・フロー

AutoUpgradeがOracle RAC、Oracle RAC One NodeまたはOracle Restartを検出すると、すべてのOracle RACインスタンスに必要なアップグレード・ステップの実行に進みます。

AutoUpgradeを起動すると、OracleデータベースがOracle Grid Infrastructureで構成されるときに、Oracle Real Application Clusters (Oracle RAC)のクラスタ・メンバー・ノードのメンバー、Oracle RAC One Node構成、またはスタンドアロン・サーバー(Oracle Restart)構成のためのOracle Grid Infrastructureのいずれかとして検出されます。

ノート:

このアップグレード・オプションを選択すると、AutoUpgradeがデータベース・インスタンスおよびシステム構成のアップグレードを完了している間に、クラスタ・データベースの停止時間が必要になります。Oracle Enterprise Managerを使用する場合は、アップグレード後に再構成する必要があります。

AutoUpgradeは、Oracle DatabaseがOracle Clusterwareリソースであることを検出すると、次のステップを順番に実行します。

  1. AutoUpgradeは、データベース、またはOracle RACデータベースのすべてのインスタンスを停止します。
  2. AutoUpgradeは、Oracle RAC、Oracle RAC One NodeまたはOracle Restartの各サービスを無効にします。
  3. Oracle ClusterwareリソースがOracle RACの場合、AutoUpgradeは、Oracle Clusterware内のすべてのOracle RACデータベース・クラスタ・メンバー・ノードのクラスタ・メンバーシップを無効にします。
  4. AutoUpgradeは、Oracle Databaseインスタンスを起動します。
    • インスタンスがOracle RACクラスタ・メンバーである場合、アップグレード・モードでローカルのOracle Databaseインスタンスを起動し、クラスタ・パラメータをFALSEに設定します。
    • インスタンスが単一インスタンスのOracle Databaseの場合は、アップグレード・モードでインスタンスを起動します。
  5. AutoUpgradeは、ローカルのOracle Database Oracleホーム・バイナリを新しいOracle Databaseリリース・バイナリにアップグレードします。
  6. AutoUpgradeは、ローカルのOracle Databaseホームからsrvctl upgrade databaseを実行し、Oracle RACの場合はOracle RACサービスの構成を新しいリリースにアップグレードします。
  7. AutoUpgradeは、srvctl enable databaseを使用して、データベースのOracle Grid Infrastructureサービスを有効にします。Oracle RACの場合は、アップグレードされたOracle RACデータベースをクラスタ・メンバー・ノードとしてOracle RACクラスタに追加します。
  8. AutoUpgradeは、更新されたパラメータと、リリース・アップグレードの影響を受けない環境に対して以前に設定したパラメータ・オプションを使用して、サーバー・パラメータ・ファイル(SPFILE)を再作成します。
  9. Oracle DatabaseがOracle RACクラスタのメンバーであった場合、AutoUpgradeは、すべてのクラスタ・メンバーがアップグレードされてクラスタに追加され、各クラスタ・メンバー・ノードでSPFILEが再作成されるまで、他の各クラスタ・メンバー・ノードでこのプロセスを繰り返します。
  10. AutoUpgradeは、Oracle Databaseを起動します。Oracle RACの場合は、クラスタ上のOracle Real Application Clustersのすべてのインスタンスを起動します。

ノート:

スタンドアロン・サーバー(Oracle Restart、Oracle RAC One NodeまたはOracle RAC Database)のOracle Grid InfrastructureでAutoUpgradeを起動する前に、アップグレード先のOracle Databaseリリースと同じリリースまたはそれより新しいリリースにOracle Grid Infrastructureをアップグレードする必要があります。

親トピック: AutoUpgradeおよびOracle Databaseの構成オプション

AutoUpgradeを使用したアップグレードのためのOracle RACの要件

AutoUpgradeでOracle Real Application Clusters (Oracle RAC)またはOracle RAC One Nodeデータベースをアップグレードできるかどうかを判断するには、ユースケース要件を確認します。

Oracle RACデータベースでAutoUpgradeを使用するための要件

AutoUpgradeを使用して、Oracle RACまたはOracle Real Application Clusters One Nodeシステムのアップグレードを実行できます。ただし、システムが次の要件のすべてを満たしている必要があります。

  • LinuxまたはUNIXベースのシステムである必要があります。Microsoft Windowsシステムはサポートされていません。
  • 新しいOracle Databaseリリースにアップグレードするためのアップグレード要件を満たしている必要があります。
  • サーバー制御(SRVCTL)ユーティリティを使用して登録および管理する必要があります。

データベース管理者がAutoUpgradeを使用するために必要なタスク

データベース管理者は、次のタスクを完了する必要があります。

  • アップグレードによる問題によるデータ損失を防ぐために、適切なバックアップ計画を作成します。
  • 必要に応じて、ローカルのtnsnames.oraリスナーとSCANリスナーの両方に対して、リスナーおよびTransparent Network Substrate (TNS)ファイルを構成します。
  • Oracle Walletの証明書および管理(必要な場合)を構成し、自動ログインを構成します。

関連項目

親トピック: AutoUpgradeおよびOracle Databaseの構成オプション

AutoUpgradeを使用したOracle RACのアップグレードの準備

アップグレード前に収集する必要がある情報およびその他のアップグレード準備のガイドラインを確認します。

Oracle Real Application Clusters (Oracle RAC)のアップグレードにAutoUpgradeを使用するには、Oracle Automatic Storage Management (Oracle ASM)もアップグレードされるため、アップグレードの前に必要な情報を収集し、アップグレード中に情報を指定する準備が整っていることを確認します。

AutoUpgradeおよびOracle RACのスコープ制限

  • AutoUpgradeは、Oracle Grid InfrastructureのOracle Clusterwareコンポーネントのアップグレードを実行しません。AutoUpgradeを起動してOracle RACデータベースをアップグレードする前に、新しいリリースへのOracle Grid Infrastructureのアップグレードを正常に完了する必要があります。

AutoUpgradeを使用したアップグレード前のファイル・システムの準備

AutoUpgradeは、Oracle ASMで共有されるPFILEファイルおよびSPFILEファイルを識別できます。AutoUpgradeは、SPFILEをアップグレードの一部として再作成します。Oracle ASMを使用してクラスタ上でファイルを共有する場合、この手順を完了する必要はありません。

親トピック: AutoUpgradeおよびOracle Databaseの構成オプション

AutoUpgradeパッチ適用

AutoUpgradeは、アウトオブプレース・パッチ適用を使用して、Oracle Databaseリリースにパッチを適用し、新しいリリース更新または月次推奨パッチにすることができます。

AutoUpgradeパッチ適用により、リリース更新(RU)および月次推奨パッチ(MRP)を適用できます。このAutoUpgradeプロシージャを使用すると、事前チェック、再開、リストアおよびOracle RAC管理のAutoUpgrade機能を利用して、複数のRUまたはMRP適用を1つのシームレスな操作で実行できます。AutoUpgradeパッチ適用により、企業へのOracle Database更新のデプロイを簡略化できます。

親トピック: AutoUpgradeおよびOracle Databaseの構成オプション

AutoUpgradeによるAutoUpgradeパッチ適用の実行方法

AutoUpgradeパッチ適用により、AutoUpgradeアップグレード・プロセスがパッチ適用まで拡張され、1つのコマンドを使用して複数のデータベースに対してアウトオブプレース・パッチ適用を実行できるようになります。

AutoUpgradeの最新リリースでは、AutoUpgradeパッチ適用プロシージャは、アプトオブプレース・パッチ適用を使用して、リリース更新(RU)、月次推奨パッチ(MRP)および個別パッチに対して実行できます。AutoUpgradeを使用して以前のRUまたはMRPからパッチを適用すると、AutoUpgradeの簡潔性、信頼性およびリカバリ性がパッチ適用プロセスにまで拡張されます。その結果、パッチ適用は実行しやすくなり、パッチのデプロイ中に発生する可能性のある問題からのリカバリも簡単になります。

パッチ適用を実行するためにAutoUpgradeの構成ファイルに設定する必要のある追加のパラメータまたはオプションはありません。ソースおよびターゲットのOracleホームを指定するだけで、AutoUpgradeはデータベースに変更を適用します。ソースとターゲットのOracleホームが同じOracle Databaseリリースである場合(19.11から19.13など)、AutoUpgradeは操作をRUまたはMRPパッチ操作として識別します。この機能は個別パッチにも適用されます。ターゲットOracleホームに適用されたRUまたはMRPがソースOracleホームのRUまたはMRPより新しい場合は、この方法を使用して、必要に応じてターゲットOracleホームに個別パッチを適用できます。

AutoUpgradeはパッチ操作を実行する際、Datapatchを使用してOracle Real Application Clusters (Oracle RAC)データベースなどのデータベースにRUまたはMRPを適用します。パッチ適用のプロセスでは、完全なリリース・アップグレードと同様に、保証付きリストア・ポイントの作成など、既存のAutoUpgradeオプションおよび操作を利用します。パッチ適用プロセス中、データベースはソースOracleホームで停止され、ターゲットOracleホームで再起動されます。RUまたはMRPの更新は、Datapatchを使用してアップグレード・モードで実行されます。

AutoUpgradeパッチ適用の利点

  • AutoUpgradeを使用すると、構成ファイルに指定されたすべてのデータベースのパッチ適用が1回の操作でできるようになります。
  • 再開機能は、AutoUpgradeにすでに組み込まれています。
  • リストア機能は、旧リリースのOracleホームにロールバックできるように提供されています。
    • パッチ適用プロセス中に生成された保証付きリストア・ポイント(GRP)を使用してリストアします。
    • GRPが存在しない場合は、Datapatchのロールバック機能でもリストアを実行できます。AutoUpgradeは、GRPが存在しないことを検出すると、自動的にDatapatchを使用してリストアを実行します。Datapatchのロールバック・リストアを有効にするには、リストア構成オプションをnoに設定します。例: sales1.restoration=no。
  • Oracle RAC管理は、AutoUpgradeで自動的に提供されます。
  • AutoUpgradeのエラー管理レポート機能は、パッチ適用にまで拡張されています。
  • AutoUpgradeのJSONステータスおよび進捗レポートは、パッチ適用にまで拡張されています。
  • AutoUpgradeは、Datapatch JSONステータス・ファイルを使用して各プロセスの成否を判断し、プロセスの完了時にその結果をレポートします。
  • トラブルシューティングおよびエラー・トリアージを簡略化するために、AutoUpgradeには、AutoUpgradeによって実行されるすべてのアクションおよびアクションが失敗した理由を特定する広範なトレース・ロギングが用意されています。

AutoUpgradeパッチ適用でサポートされている機能

AutoUpgradeパッチ適用には、次の機能が用意されています。

  • Transparent Data Encryption (TDE)により暗号化されたデータベースのパッチ適用。
  • ホット・クローニング/再配置。非CDBから、またはリモート・ホスト上のPDBからPDBを作成できるようになります。
  • 事前修正。PDBにパッチが適用されるとすぐにPDBに対して事後修正を実行します。
  • Oracle Real Application Clusters (Oracle RAC)を使用した分散データベース・アップグレード。これにより、複数のノード間でパッチ適用ワークロードを分散できます。
  • ソースのOracleホーム構成ファイル(tnsnames.ora、sqlnet.oraおよびその他のファイル)をターゲットのOracleホームにコピーまたはマージすることによる構成管理。
  • パッチの準備が整っていることを確認するための、パッチ適用プロシージャを開始する前のデータベースの分析。
  • 停止時間を短縮するための、パッチ適用前の本番での修正の実行。その後、-mode upgradeを使用して修正の実行をバイパスし、データベースへのパッチ適用に直接進むことができます。
  • エンドツーエンドのパッチ適用を実現するための、すべてのパッチ適用タスクのデプロイ・モードでの実行。
  • パッチ適用プロセスの拡張レポート。これにより、datapatch_summary.logレポートを使用してエラーをより簡単に診断できるようになります。
  • DatapatchサマリーJSONファイルに含まれるDatapatchログ・ファイルは、次のような適用またはロールバックの操作ログの出力ファイルにコピーされます。
    • 適用ログの形式(dbnameはデータベースの名前): applydatapatchlogfiles#dbname.log
    • ロールバック・ログの形式(dbnameはデータベースの名前): rollbackdatapatchlogfiles#dbname.log
  • Datapatch出力は、次の操作ログに記録されます。
    • 適用ログの形式(dbnameはデータベースの名前): applyautoupgrade#dbname.log
    • ロールバック・ログの形式(dbnameはデータベースの名前): rollbackautoupgrade#dbname.log
  • Datapatch JSON出力は、次の操作ログに記録されます。
    • 適用ログの形式(dbnameはデータベースの名前): applydatapatchsummary#dbname.log
    • ロールバック・ログの形式(dbnameはデータベースの名前): rollbackdatapatchsummary#dbname.log
  • AutoUpgradeによって生成されたすべての関連パッチ適用ログ・ファイルのストレージは、dbupgradeディレクトリに格納されます。
  • 標準のDatapatchログ・ファイルは、Oracle-base/cfgtoollogs/sqlpatchに格納されます(Oracle-baseは、AutoUpgradeを実行しているユーザー・アカウントのOracleベース・ディレクトリです)。
  • AutoUpgrade 23.1以降、パッチ適用はMicrosoft Windowsのデータベースでサポートされています。

AutoUpgradeパッチ適用を使用するための要件および制限事項

  • AutoUpgradeパッチ適用を使用するには停止時間が必要です。
    • パッチ操作が完了すると、データベースは再起動されます。
    • 通常モードでのパッチ適用では、パッチ適用の進行中にターゲット・ホームでデータベースを使用できるようになります。
    • アップグレード・モードでのパッチ適用では、ターゲット・ホームでデータベースを再起動する前に、パッチ適用を完了する必要があります。
    • パッチ操作中、デフォルトでは、すべてのPDBでパッチ適用プロセス全体が完了するまで、CDBおよびすべてのPDBは使用できません。
    • パッチが正常に適用されたらすぐにPDBを使用できるようにするには、必ず構成ファイルでtune_settingsのオプションmake_pdbs_avaliableをtrueに設定します。例: sales3.tune_setting=proactive_fixups=true,make_pdbs_available=true
  • AutoUpgradeは、追加のパッチが適用されたターゲットRUまたはMRPをサポートできます。ただし、ソースOracle DatabaseのRUまたはMRPは、ターゲットのOracle DatabaseのRUまたはMRPよりも古い必要があります。
  • AutoUpgradeは、OPatchコマンドを実行しません。そのため、AutoUpgradeを起動する前に、ターゲットOracleホームにパッチを完全に適用する必要があります。
  • AutoUpgradeは、リスナーを新しいOracleホームに移動しません。必要に応じて、AutoUpgradeの起動前にリスナーを新しいOracleホームに手動で移動する必要があります。
  • AutoUpgradeパッチ適用を使用してRUおよびMRPをターゲット・ホームに対して実行する前に、ターゲットOracle Databaseホームのインストールおよび構成が完了している必要があります。データベースに適用された後にターゲットRUにパッチが適用された場合、AutoUpgradeパッチ適用を使用できなくなります。かわりに、Datapatchを使用して更新を適用する必要があります。
  • Oracle Database (単一インスタンスまたはOracle RAC)のローリング・パッチの実行はサポートされていません。単一インスタンスまたはOracle RAC Oracle DatabaseでAutoUpgradeパッチ適用を使用すると、AutoUpgradeのOracle RAC管理によって、すべてのノードでデータベースが停止されます。
  • ターゲットOracle Database RUは、少なくともOracle Database 19c, RU 19.3以降のリリースである必要があります。AutoUpgradeパッチ適用を使用して、Oracle Databaseの旧リリースに対してRUまたはMRPを実行することはできません。
  • Oracle Data Guardフィジカル・スタンバイまたはOracle Data Guardロジカル・スタンバイおよびローリング・アップグレードを使用したデータベースに対するAutoUpgradeパッチ適用の影響は、Datapatchを使用した場合と同じです。AutoUpgradeパッチ適用をプロシージャに含めることができます。
  • データベースを別のターゲット・システムに移動する場合、AutoUpgradeパッチ適用を-mode upgradeオプションとともに使用できます。ただし、データベースが別のシステムに移動されると、AutoUpgradeはリストアを実行できません。その場合、パッチ適用のアップグレード・オプションは、データベースのアップグレードに適用されるのと同じルールに従います。
  • このドキュメントでは、アップグレードを実行しているAutoUpgradeについて説明します。AutoUpgradeがパッチ適用を実行する場合、機能的にはパッチ適用はアップグレードと似ています。したがって、このガイドまたは図でのアップグレードについての言及は、AutoUpgradeパッチ適用によるアップグレードとパッチ適用の両方に適用されます。
  • AutoUpgradeパッチ適用によるパッチ適用の実行では、アップグレードでのみサポートされているpreupgradeモードを除くすべてのAutoUpgrade -modeオプションがサポートされています。
  • 再配置可能なPDBへのパッチ適用またはアップグレードの場合、構成ファイルにはパッチ・クローンPDBとアップグレード済クローンPDBを混在させることはできません。クローンPDBの構成は、すべてアップグレード・クローンまたはすべてパッチ適用済クローンのいずれかである必要があります。

  • AutoUpgradeパッチ適用では、catctl_options設定の-n number (numberはパラレル操作に使用するプロセスの数)が1つのみサポートされます。catctl_options=-n設定を使用すると、パッチ適用プロセス中に同時に実行するPDBの合計数を制御できます。デフォルトは、CPU_COUNTを2で割った値です。たとえば、CPU_COUNTが24に設定されている場合、デフォルトでは、パッチ適用プロセス中に12個のPDB (Datapatchインスタンス)を同時に実行できます。

    デフォルトを上書きするには、prefix.catctl_optionsを構成ファイルに追加し、実行する同時Datapatchインスタンスの数の値を指定します。たとえば、デフォルトをオーバーライドして、接頭辞salesを付けて指定されたパッチ操作に対して6個のPDB (Datapatchインスタンス)を実行するようにAutoUpgradeを構成するには、次の行を構成ファイルに追加します。 

    sales.catctl_options=-n 6

    注意:

    19.13以前のリリース更新(RU)の場合、パッチ適用操作にcatctl_optionsパラメータを設定することをお薦めします。

    19.13以前のRUでは、各Datapatchインスタンスに割り当てられるSQL*Plusプロセッサのデフォルト値は、AutoUpgradeが起動するDatapatchインスタンスごとにCPU_COUNTに2を掛けた数(CPU_COUNT*2)のプロセッサです。このデフォルトのSQL*Plusプロセッサ割当てにより、すぐにシステムが過負荷状態になる可能性があります。パッチ操作に割り当てられるシステム・リソースを制限するには、同時に実行されるDatapatchインスタンスの数を制限することが唯一の選択肢です。RU 19.13以降では、Datapatchのインスタンスごとに1つのSQL*Plusプロセスのみが起動されます。この変更により、AutoUpgradeは大量のシステム・リソースを消費することなく、より多くのPDBをパラレルで実行できます。

AutoUpgradeパッチ適用のセキュリティ特性

  • AutoUpgradeパッチ適用を実行しているユーザーには、データベースにログインしてパッチ適用操作を実行するためにSYSDBAシステム権限が必要です。
  • アップグレードに適用されるのと同じセキュリティ・ルールが、AutoUpgradeパッチ適用でも適用されます。

AutoUpgradeパッチ適用のパフォーマンス特性

  • RUまたはMRPのデプロイ速度は、CDB内のPDBの数およびリリース更新またはリリース更新リビジョンの変更内容によって左右されます。ソースRUまたはMRPパッチからの変更数が比較的少ない場合は、パッチのデプロイメントは速くなります。パッチに多数の変更がある場合は、パッチの適用にさらに時間が必要となります。
  • AutoUpgradeパッチ適用には多数の追加の自動化プロシージャが組み込まれているため、リリース更新のデプロイメントは、手動でDatapatchを実行する場合よりもわずかに遅くなります。たとえば、AutoUpgradeパッチ適用には、無効なオブジェクトの再コンパイルおよびターゲット・システムでのOracle RAC管理の構成が自動的に組み込まれています。

AutoUpgradeパッチ適用でリリース更新がロールバックされた場合の処理

  • AutoUpgradeは、パッチ適用プロセス中に生成された保証付きリストア・ポイント(GRP)を使用して、旧リリースのOracleホームにロールバックします。
  • GRPが作成されていない場合、AutoUpgradeは自動的にDatapatchをコールして変更をロールバックします。

親トピック: AutoUpgradeパッチ適用

AutoUpgradeパッチ適用の構成ファイルおよびログ・ファイル

AutoUpgradeパッチ適用の構成ファイルおよびログ・ファイルの例を見てみましょう。

AutoUpgradeパッチ適用の構成ファイルは、アップグレード用のAutoUpgrade構成ファイルと基本的に同じです。ただし、指定されたパラメータを使用してアップグレードを実行するかわりに、AutoUpgradeはソースOracle Databaseパッチ・リリースからターゲットOracle Databaseパッチ・リリースにパッチ操作を実行し、プロシージャの一部としてDatapatchを実行します。

例4-5 様々なパッチ適用シナリオのためのAutoUpgrade構成ファイル

次の構成ファイルの例では、次のOracle Databasesに、リリース更新(RU) 11から19c RU 13にパッチが適用されたOracle Database 19cからパッチが適用されます。

  • 19.11.0から19.13.0にパッチが適用され、接頭辞patch1が指定された非CDBデータベース
  • 19.11から19.13にパッチが適用され、接頭辞patch2が指定されたOracle Database 19c CDB
  • 切断/接続によってパッチが適用され、接頭辞patch3が指定された暗号化されたPDB
  • パッチが適用されてCDBに変換され、接頭辞patch4が指定された非CDB
  • パッチ適用操作中に再配置されるPDBが含まれる、接頭辞patch5が指定されたCDB
  • 接頭辞patch6が指定されたOracle Real Application Clusters (Oracle RAC)データベース
  • 接頭辞patch7が指定された、分散クラスタ構成内のOracle RACデータベース
#
# Global log directory for patch logs
#
global.autoupg_log_dir=/databases/patchlogs
#
# Non-CDB patch to Non-CDB patch, source and target home
#
patch1.sid=db19
patch1.source_home=/databases/ee/product/1911/dbhome_1
patch1.target_home=/databases/ee/product/1913/dbhome_2
#
#
# CDB patch, Source and Target home
#
patch2.sid=cdb19
patch2.source_home=/databases/ee/product/1911/dbhome_1
patch2.target_home=/databases/ee/product/1913/dbhome_2
#
# Unplug-Plug with KeyStore
#
global.keystore=/databases/tde
patch3.sid=cdb19
patch3.source_home=/databases/ee/product/1911/dbhome_1
patch3.target_home=/databases/ee/product/1913/dbhome_2
patch3.target_cdb=cdb1913
patch3.target_pdb_name=sales
patch3.target_pdb_copy_option=file_name_convert=('/databases/ee/oradata/CDB19/sales', '/databases/ee/oradata/CDB1913/sales')
#
# Non-CDB to CDB, Source and Target home
#
patch4.sid=db19
patch4.source_home=/databases/ee/product/1911/dbhome_1
patch4.target_home=/databases/ee/product/1913/dbhome_2
patch4.target_cdb=cdb1913
patch4.target_pdb_name=emp
patch4.target_pdb_copy_option=file_name_convert=('/databases/ee/oradata/DB19', '/databases/ee/oradata/CDB1913/emp')
#
# Patch relocate DB
#
patch5.sid=cdb19
patch5.source_home=/databases/ee/product/1911/dbhome_1
patch5.target_home=/databases/ee/product/1913/dbhome_2
patch5.target_cdb=cdb1913
patch5.pdbs=cars
patch5.target_pdb_copy_option.cars=file_name_convert=('/databases/ee/oradata/CDB19/cars', '/databases/ee/oradata/CDB1913/cars')
patch5.source_dblink.cars=db19_link
#
# Oracle RAC
#
patch6.sid=rac1
patch6.source_home=/databases/ee/product/1911/dbhome_1
patch6.target_home=/databases/ee/product/1913/dbhome_2
#
# Distributed Oracle RAC with proactive fixups
#
patch7.sid=rac2
patch7.source_home=/databases/ee/product/1911/dbhome_1
patch7.target_home=/databases/ee/product/1913/dbhome_2
patch7.tune_setting=distributed_upgrade=true

例4-6 AutoUpgradeパッチ適用のサマリー・ログ・ファイル

このパッチ適用サマリー・レポート・ファイルでは、AutoUpgradeによってCDBおよびPDBにパッチがどのように適用されたかを確認できます。 


********************************************************************************
		Datapatch Apply Summary Report for CDB$ROOT

	Return code        = 0 SUCCESS
	Failure reason     = null
	Total time         = 161.721805095673
	Install patches    = 1
	Database Open      = SUCCESS
	Invocation Log     = /databases/cfgtoollogs/sqlpatch/sqlpatch_17781_2022_05_18_10_57_58/sqlpatch_invocation.log
	Bootstrap Required = 1
	Bootstrap Status   = SUCCESS
	Bootstrap Log      = /databases/cfgtoollogs/sqlpatch/sqlpatch_17781_2022_05_18_10_57_58/bootstrap1_CDB19X_CDBROOT.log
	Total patches      = 1

	Patch Key          = 33192793-24462514
	Mode               = apply
	Status             = SUCCESS
	Patch Log File     = /databases/cfgtoollogs/sqlpatch/33192793/24462514/33192793_apply_CDB19X_CDBROOT_2022May18_10_58_06.log
	RU Log File        = /databases/cfgtoollogs/sqlpatch/33192793/24462514/33192793_ru_apply_CDB19X_CDBROOT_2022May18_10_58_05.log
	RU Errors          = N/A

********************************************************************************
		Datapatch Apply Summary Report for PDBX

	Return code        = 0 SUCCESS
	Failure reason     = null
	Total time         = 123.969398021698
	Install patches    = 1
	Database Open      = SUCCESS
	Invocation Log     = /databases/cfgtoollogs/sqlpatch/sqlpatch_18416_2022_05_18_11_01_40/sqlpatch_invocation.log
	Bootstrap Required = 1
	Bootstrap Status   = SUCCESS
	Bootstrap Log      = /databases/cfgtoollogs/sqlpatch/sqlpatch_18416_2022_05_18_11_01_40/bootstrap1_CDB19X_PDBX.log
	Total patches      = 1

	Patch Key          = 33192793-24462514
	Mode               = apply
	Status             = SUCCESS
	Patch Log File     = /databases/cfgtoollogs/sqlpatch/33192793/24462514/33192793_apply_CDB19X_PDBX_2022May18_11_01_55.log
	RU Log File        = /databases/cfgtoollogs/sqlpatch/33192793/24462514/33192793_ru_apply_CDB19X_PDBX_2022May18_11_01_55.log
	RU Errors          = N/A

********************************************************************************
		Datapatch Apply Summary Report for PDB$SEED

	Return code        = 0 SUCCESS
	Failure reason     = null
	Total time         = 124.234117984772
	Install patches    = 1
	Database Open      = SUCCESS
	Invocation Log     = /databases/cfgtoollogs/sqlpatch/sqlpatch_18406_2022_05_18_11_01_40/sqlpatch_invocation.log
	Bootstrap Required = 1
	Bootstrap Status   = SUCCESS
	Bootstrap Log      = /databases/cfgtoollogs/sqlpatch/sqlpatch_18406_2022_05_18_11_01_40/bootstrap1_CDB19X_PDBSEED.log
	Total patches      = 1

	Patch Key          = 33192793-24462514
	Mode               = apply
	Status             = SUCCESS
	Patch Log File     = /databases/cfgtoollogs/sqlpatch/33192793/24462514/33192793_apply_CDB19X_PDBSEED_2022May18_11_01_55.log
	RU Log File        = /databases/cfgtoollogs/sqlpatch/33192793/24462514/33192793_ru_apply_CDB19X_PDBSEED_2022May18_11_01_55.log
	RU Errors          = N/A

親トピック: AutoUpgradeパッチ適用

AutoUpgradeとOracle Data Guard

Oracle Database 21c以降、AutoUpgradeでは、Oracle Data Guard用に構成されたプライマリ・データベースおよびセカンダリ・データベースのアップグレード・プロセスを簡略化できます。

親トピック: AutoUpgradeおよびOracle Databaseの構成オプション

AutoUpgradeによるOracle Data Guardのアップグレードの実行方法

AutoUpgradeは、Oracle Data Guard構成を検出し、プライマリ・データベース用に構成されたスタンバイ・データベースへのログの送信を遅延させることができます。

AutoUpgradeでは、Oracle Data Guardデプロイメントの有無と、そのデプロイメントが手動で構成されているのか、Data Guard Brokerを使用してOracle Data Guard構成を管理およびモニターしているのかが自動的に検出されます。

構成ファイルでパラメータdefer_standby_log_shippingをno (デフォルト)に設定すると、AutoUpgradeでは、Oracle Data Guardが手動で構成されている場合とData Guard Brokerを使用してOracle Data Guardが構成されている場合の両方で、構成済のスタンバイ・データベースへのログ送信を遅延させることができます。

データベースとOracle Data GuardのAutoUpgradeによるアップグレード前の準備

アップグレードを開始する前に、プライマリ・データベースのアップグレード中に障害が発生した場合またはプライマリ・データベースをソースOracleホームに戻す必要がある場合に備えて、スタンバイ・データベースが保護されており、リカバリ可能であることを確認します。

親トピック: AutoUpgradeとOracle Data Guard

Oracle Data GuardのアップグレードのためにAutoUpgradeで実行されるステップ

AutoUpgradeで実行されるステップは、スタンバイ・データベースが手動で管理されているか、Data Guard Brokerを使用して管理されているかによって異なります。

Oracle Data Guardが手動またはData Guard Brokerを使用して管理されるOracle Data Guardの以前のリリース(ソース)のデータベースの場合、スタンバイ・データベースへのログ送信を管理するために、AutoUpgrade構成ファイルでdefer_standby_log_shipping=yes (デフォルトはno)を設定できます。ただし、AutoUpgradeで実行される特定のアクションは、スタンバイ・データベースの管理方法によって異なります。

ノート:

手動またはData Guard Brokerを使用して管理されるスタンバイ・データベースの場合、アップグレードの完了後、プライマリ・データベースでのアップグレードが正常に終了した後に各スタンバイ・アーカイブ・ログの宛先でENABLE DATABASE database-name;を実行し、REDOログ適用を使用してスタンバイ・データベースをアップグレードするために必要なステップをすべて実行する必要があります。

手動管理のOracle Data Guardスタンバイ・データベース

直接アップグレードがサポートされているOracle Data Guardスタンバイ・データベースの場合、AutoUpgradeは、手動管理スタンバイ・データベースとData Guard Broker管理スタンバイ・データベースの両方のアップグレード・プロセスを開始する前に、すべてのVALIDおよびENABLEDスタンバイ・アーカイブ・ログの宛先をDEFERモードにします。

Data Guard Broker管理のOracle Data Guardスタンバイ・データベース

Data Guard Brokerを使用して管理されるOracle Data Guardスタンバイ・データベースとの直接アップグレードがサポートされているOracle Databaseリリースの場合、AutoUpgradeは次のアクションを完了します。

  • プライマリ・データベースの状態が、Data Guard Brokerを使用して構成されたすべてのスタンバイ・データベースに対してTRANSPORT-OFFに設定されます。
  • Data Guard Brokerのファイルが、ソースOracleホームからターゲットOracleホームにコピーされます。

ノート:

Data Guard BrokerファイルがOracleホームの外部にある場合、ファイルは見つからず、コピーされません。

親トピック: AutoUpgradeとOracle Data Guard

プライマリ・データベースのアップグレード後のステップ

Oracle Data Guardのアップグレードでは、プライマリ・データベースをアップグレードした後に、次の手順を実行する必要があります。

  • プライマリ・データベースでREDO転送が有効になっていることを確認し、アップグレードがスタンバイ・データベースに適用されるようにします。
  • アーカイブが適用され、ギャップが最小限であることを確認します。適用ラグおよびトランスポート・ラグは5分以内にすることをお薦めします。

例4-7 REDO転送サービスのステータスの確認

プライマリ・データベースのREDO転送サービスのステータスを確認するには、Data Guard Brokerコマンドライン・インタフェース(DGMGRL)で監視可能なプロパティLogXptStatusを使用します。たとえば: 

DGMGRL> SHOW DATABASE 'sales1' 'LogXptStatus' ;

例4-8 適用ラグおよびトランスポート・ラグの確認

アーカイブが適用されていることを確認し、適用ラグおよびトランスポート・ラグが5分以内であることを確認するには、プライマリ・データベースにログインし、次のようなSQL問合せを発行します。

[oracle]$ sqlplus / as sysdba
SYS@sales1>

SET LINESIZE 200
COL VALUE FOR A30
SELECT NAME,VALUE,TIME_COMPUTED,DATUM_TIME FROM V$DATAGUARD_STATS WHERE NAME LIKE '%lag';

結果は次のようになります。 

NAME VALUE TIME_COMPUTED DATUM_TIME
-------------- -------------- --------------------- --------------------
transport lag +00 00:00:00 timestamp timestamp
apply lag +00 00:01:07 timestamp timestamp

関連項目

親トピック: AutoUpgradeとOracle Data Guard

高速デプロイ・オプションを使用してAutoUpgradeを実行する方法

停止時間を最小限に抑えるには、高速デプロイ・オプションを使用してAutoUpgradeを実行することでデータベースをアップグレードできます。

AutoUpgrade 21.2以降、アプリケーションで停止時間を最小限に抑える必要がある場合、高速デプロイを使用することで停止時間を短くしてアップグレードできるようになりました。高速デプロイ・オプションを使用すると、データベースがオンライン中でも事前チェックおよび事前修正を実行できます。ソース・データベースで修正を実行した後、デプロイ・モードでAutoUpgradeを実行し、事前チェックおよび事前修正のステージをスキップできるため、実際のアップグレードのみに停止時間が必要となります。

ノート:

標準の分析モードとデプロイ・モードを使用してAutoUpgradeを実行することをお薦めします。高速デプロイ方法を使用する場合は、アップグレード前の分析モードでAutoUpgradeを実行した後、かつアップグレード・モードでAutoUpgradeを実行する前の期間中に新しい問題が発生する可能性があるというリスクがわずかにあることに注意してください。これが問題を引き起こす可能性があります。そのリスクを評価し、それに応じて予防措置を講じてください。

  1. AutoUpgrade構成ファイルを作成し、ソース・システムおよびターゲット・システムに関する情報とアップグレード・プリファレンスを指定します。次の各ステップでは、そのファイル名はmyconfig.cfgです。

  2. 分析モードを使用してデータベースを分析します。

    – java -jar autoupgrade.jar -config myconfig.cfg -mode analyze

  3. 修正モードを使用してアップグレード前の修正を実行します。

    – java -jar autoupgrade.jar -config myconfig.cfg -mode fixups

  4. アップグレード・モードを使用してデータベースをアップグレードします。

    – java -jar autoupgrade.jar -config myconfig.cfg -mode upgrade

    このコマンドを実行すると、アップグレードされるデータベースがターゲットのOracleホームでUPGRADEモードでオープンされるため、データベースが停止することがあります。

親トピック: AutoUpgradeおよびOracle Databaseの構成オプション

暗号化されたPDBの切断/接続アップグレードの実行方法

AutoUpgradeユーティリティを使用して、暗号化されたPDBの切断/接続アップグレードを実行する方法について説明します。

注意:

AutoUpgradeがglobal.keystoreを使用して作成するディレクトリを指定する場合は、ソフトウェア・キーストアが格納されることに注意してください。TDEキーストア・ファイルとともに使用する場合と同じセキュリティのベスト・プラクティスを使用して保護する必要があります。

暗号化されたPDBのアップグレードを実行するには、AutoUpgradeでTDEキーストアのパスワードを独自のセキュア・キーストアにロードする必要があります。パスワードをロードするには、構成ファイルでAutoUpgradeグローバル構成ファイル・パラメータkeystoreを設定し、コマンドライン・パラメータload_passwordを使用してAutoUpgradeを実行します。このパラメータは、-configパラメータとともに使用する必要があります。引数はありません。かわりに、キーストアに必要な情報を提供できる特定のコマンドを使用して対話型プロンプトを起動します。AutoUpgradeは、アップグレード中に安全にロードされたパスワードを格納し、必要に応じてこれらのパスワードを使用します。

ノート:

データベースがOracle Secure External Password Store (SEPS)を使用しており、TDEキーストア・パスワードが要求されると、AutoUpgradeはIDENTIFIED BY EXTERNAL STORE句を使用するため、パスワードをAutoUpgradeパスワード・キーストアにロードする必要はありません。ただし、すべてのデータベースがセキュアな外部パスワード・ストアを使用して構成されている場合は、引き続き構成ファイルでglobal.keystoreを定義する必要があります。

AutoUpgradeキーストアは、Oracle Databaseが使用する他のキーストアと似ています。自動ログイン・キーストアとして作成することもできます。たとえば、外部キーストアがewallet.p12の場合、AutoUpgradeは、ewallet.p12キーストアを開くために使用される自動ログイン・キーストアcwallet.ssoを作成します。

暗号化されたPDBのアップグレードを開始する前に、次を満たす必要があります。

  • AutoUpgradeはバージョン22.2以降である必要があります。常に最新バージョンのAutoUpgradeをダウンロードして実行することをお薦めします。
  • 外部TDEキーストアを使用する必要があります
  • ソースおよびターゲットのCDBの外部キーストア・パスワードを使用可能にしておく必要があります。

例4-9 AutoUpgradeを使用した切断/接続アップグレードによる暗号化されたPDBのアップグレード

次の例では、Transparent Data Encryption (TDE)を使用しているOracle Database 12cリリース2 (12.2) PDBが、アップグレード中にTDEキーのセキュア・ストアを指定するためにAutoUpgrade構成ファイル・キーストア・パラメータとともにAutoUpgrade load_passwordコマンド・オプションを使用して、Oracle Database 19cにアップグレードされます。

  1. 最新バージョンのAutoUpgradeがあることを確認します。
    $ java -jar autoupgrade.jar -version

    AutoUpgradeバージョンが以前のリリースの場合は、My Oracle Support AutoUpgradeツール(ドキュメントID 2485457.1)から最新バージョンのAutoUpgradeをダウンロードします

  2. AutoUpgrade構成ファイルを作成します。この例では、パス/u01/app/oracle/admin/autoupgrade/keystoreの、Oracleベース・ディレクトリ下のadminフォルダに指定されているキーストアへのパスを使用して、構成ファイルPDB1.cfgが作成されます。ソースCDBはCDB1で、ターゲットCDBはCDB2です。
    global.autoupg_log_dir=/u01/app/oracle/cfgtoollogs/autoupgrade
global.keystore=/u01/app/oracle/admin/autoupgrade/keystore
upg1.log_dir=/u01/app/oracle/cfgtoollogs/autoupgrade/DB12
upg1.source_home=/u01/app/oracle/product/12.2.0/dbhome_1
upg1.target_home=/u01/app/oracle/product/19.1.0/dbhome_1
upg1.sid=CDB1
upg.pdbs=PDB1
upg1.target_cdb=CDB2

    ノート:

    キーストアの場所を指定せず、以前にAutoUpgradeキーストアが作成されていない場合は、AutoUpgradeによってAutoUpgradeキーストアが作成されます。

  3. 分析モードでAutoUpgradeを実行します。
    $ java -jar autoupgrade.jar -config PDB1.cfg -mode analyze

    サマリー・レポートは、アップグレードを開始する前にTDEキーストア・パスワードが必要であることを示しています(TDE_PASSWORDS_REQURED)。 

    [Stage Name]    PRECHECKS
[Status]        FAILURE
[Start Time]    2022-03-29 07:58:52
[Duration]       
[Log Directory] /u01/app/oracle/cfgtoollogs/autoupgrade/PDB1/CDB1/100/prechecks
[Detail]        /u01/app/oracle/cfgtoollogs/autoupgrade/PDB1/CDB1/100/prechecks/cdb1_preupgrade.log
		Check failed for PDB1, manual intervention needed for the below checks
		[TDE_PASSWORDS_REQUIRED]

  4. TDEキーストア・パスワードをAutoUpgradeキーストアに追加します。

    $ java -jar autoupgrade.jar -config PDB1.cfg -load_password

    -load_passwordコマンド・オプションを指定してAutoUpgradeを初めて実行すると、TDEパスワードを安全に格納できるAutoUpgradeキーストアのパスワードを作成するよう求められます。 

    
Starting AutoUpgrade Password Loader - Type help for available options
Creating new keystore - Password required
Enter password:       
Enter password again: 
Keystore was successfully created

    SEPSキーストアを使用しない場合、AutoUpgradeにより、構成ファイルのsource_homeで指定されたデータベースのTDEキーストア・パスワードをAutoUpgrade独自のキーストアに追加するよう求められますが、この場合、そのデータベースがTDEキーストア・パスワードを必要とします。これは、構成ファイルの例で指定したものです。

    次の例では、ソースおよびターゲットのTDEキーストア・パスワードがロードされます。 

    TDE> ADD CDB1
Enter your secret/Password:
Re-enter your secret/Password:

TDE> ADD CDB2
Enter your secret/Password:
Re-enter your secret/Password:

    パスワードがロードされたことを確認します。

    TDE> LIST
+---------------+-----------------+-----------------+--------------+----------------------+
|ORACLE_SID     |Action Required  |TDE Password     |SEPS Status   |Active Wallet Type    |
+---------------+-----------------+-----------------+--------------+----------------------+
| CDB1          |                 | Verified        | Inactive     | Auto-login           |
| CDB2          |                 | Verified        | Inactive     | Any                  |
+---------------+-----------------+-----------------+--------------+----------------------+

    Action Required列が空の場合、アップグレードにTDEパスワードを使用できます。

    ソースCDBまたはターゲットCDBでSEPSキーストアを使用する場合、AutoUpgradeはTDEパスワードのソースとしてSEPSキーストアを自動的に検出します。AutoUpgradeはIDENTIFIED BY EXTERNAL STORE句を使用するので、TDEキーストア・パスワードをAutoUpgradeキーストアにロードする必要がありません。ここでも、TDE LISTコマンドで空のAction Required列が表示されます。 

    TDE> LIST
+--------------+------------------+-------------------------+--------------+---------------------+
|ORACLE_SID    |Action Required    | TDE Password           |SEPS Status   |Active Wallet Type   |
+--------------+-------------------+------------------------+--------------+---------------------+
| CDB1         |                   |No password loaded      | Verified     | Any                 |
| CDB2         |                   |No password loaded      | Verified     | Any                 |
+--------------+-------------------+------------------------+--------------+---------------------+

    同じ構成ファイルで両方のオプションを使用できます。たとえば、ソース非CDBデータベースにSEPSキーストアを使用せずに、ターゲットCDBにSEPSキーストアを使用する場合、必要なのは、ソース非CDBのパスワードをロードすることのみです。

  5. TDEパスワードをAutoUpgradeキーストアに保存します。(オプション): この例では、キーストアを自動ログイン・キーストアに変換します。

    TDE> save
Convert the keystore to auto-login [YES|NO] ? YES
TDE> exit

  6. PDBを再度分析します。

    $ java -jar autoupgrade.jar -config PDB1.cfg -mode analyze

    レポートをレビューし、すべての問題が解決されたことを確認します。

  7. アップグレードおよび変換を開始します。
    $ java -jar autoupgrade.jar -config PDB1.cfg -mode deploy
  8. AutoUpgradeは、アップグレードを完了するために必要に応じてTDEパスワードを使用して、ターゲットOracle DatabaseでPDB1のアップグレードを開始します。この例では、AutoUpgrade自動ログイン・キーストアを作成し、独自のセキュア・キーストアを使用してTDEパスワードにアクセスするようにAutoUpgradeを構成したため、アップグレード中にTDEパスワードの指定を求められることはありません。

関連項目

親トピック: AutoUpgradeおよびOracle Databaseの構成オプション

暗号化されたPDBの非CDBからPDBへの変換を実行する方法

AutoUpgrade 22.1以降の更新では、AutoUpgradeにより、Transparent Data Encryption (TDE)を使用するOracle Databaseのアップグレードおよび変換が簡略化されます。

アップグレード・プロセスを簡略化しながらアップグレード中に機密情報を保護するには、AutoUpgradeグローバル構成ファイル・パラメータkeystoreおよびAutoUpgradeコマンドライン・パラメータload_passwordを使用して、TDEパスワードをAutoUpgradeキーストアに安全にロードし、必要に応じてそのパスワードを使用します。
AutoUpgradeキーストアを使用できるようにするには、global.keystoreを使用して、AutoUpgrade構成ファイルで外部パスワード・ストアの場所を指定します。

ノート:

AutoUpgradeキーストア・パスを指定する場合、そのパスは、AutoUpgradeで指定した他のファイル・パスとは異なる必要があるので、キーストアはどのログ・ファイルの場所にも存在しません。AutoUpgradeキーストア・パス・ディレクトリが存在しない場合、AutoUpgradeによって自動的に作成されます。

データベースがOracle Secure External Password Store (SEPS)を使用しており、TDEキーストア・パスワードが要求されると、AutoUpgradeはIDENTIFIED BY EXTERNAL STORE句を使用するため、パスワードをAutoUpgradeパスワード・キーストアにロードする必要はありません。ただし、すべてのデータベースがセキュアな外部パスワード・ストアを使用して構成されている場合は、引き続き構成ファイルでglobal.keystoreを定義する必要があります。

例4-10 TDEを使用したデータベースのアップグレードおよび非CDBからPDBへの変換

次の例では、Transparent Data Encryption (TDE)を使用しているOracle Database 12cリリース2 (12.2)非CDBデータベースが、PDB変換およびアップグレード中にTDEキーのセキュア・ストアを指定するためにAutoUpgrade構成ファイル・キーストア・パラメータとともにAutoUpgrade load_passwordコマンド・オプションを使用して、Oracle Database 19cにアップグレードされ、PDBに変換されます。

  1. 最新バージョンのAutoUpgradeがあることを確認します。
    $ java -jar autoupgrade.jar -version

    AutoUpgradeバージョンが以前のリリースの場合は、My Oracle Support AutoUpgradeツール(ドキュメントID 2485457.1)から最新バージョンのAutoUpgradeをダウンロードします

  2. AutoUpgrade構成ファイルを作成します。この例では、キーストアへのパスが、パス/u01/app/oracle/admin/autoupgrade/keystoreの、Oracleベース・ディレクトリ下のadminフォルダに指定されています。
    global.autoupg_log_dir=/u01/app/oracle/cfgtoollogs/autoupgrade
global.keystore=/u01/app/oracle/admin/autoupgrade/keystore
upg1.log_dir=/u01/app/oracle/cfgtoollogs/autoupgrade/DB12
upg1.source_home=/u01/app/oracle/product/12.2.0
upg1.target_home=/u01/app/oracle/product/19.1.0
upg1.sid=DB12
upg1.target_cdb=CDB2
  3. 分析モードでAutoUpgradeを実行します。
    $ java -jar autoupgrade.jar -config DB12.cfg -mode analyze

    サマリー・レポートは、アップグレードを開始する前に追加のアップグレード前タスクを完了する必要がないことを示しています。 

    [Stage Name]    PRECHECKS
[Status]        SUCCESS
[Start Time]    2022-03-30 10:28:38
[Duration]       
[Log Directory] /u01/app/oracle/cfgtoollogs/autoupgrade/DB12/DB12/100/prechecks
[Detail]        /u01/app/oracle/cfgtoollogs/autoupgrade/DB12/DB12/100/prechecks/db12_preupgrade.log
				Check passed and no manual intervention needed

    TDE_PASSWORDS_REQUIREDチェックが失敗した場合は、TDEパスワードをロードします。 

    $ java -jar autoupgrade.jar -config DB12.cfg -load_password

    -load_passwordコマンド・オプションを指定してAutoUpgradeを初めて実行すると、AutoUpgradeでアップグレードの実行にTDEパスワードが必要な場合は、TDEパスワードを安全に格納できるAutoUpgradeキーストアのパスワードを作成するよう求められます。 

    
Starting AutoUpgrade Password Loader - Type help for available options
Creating new keystore - Password required
Enter password:       
Enter password again: 
Keystore was successfully created

    SEPSキーストアを使用しない場合、AutoUpgradeにより、構成ファイルのsource_homeで指定されたデータベースのTDEキーストア・パスワードをAutoUpgrade独自のキーストアに追加するよう求められますが、この場合、そのデータベースがTDEキーストア・パスワードを必要とします。これは、構成ファイルの例で指定したものです。

    次の例では、ソースおよびターゲットのTDEキーストア・パスワードがロードされます。 

    TDE> ADD DB12
Enter your secret/Password:
Re-enter your secret/Password:

TDE> ADD CDB2
Enter your secret/Password:
Re-enter your secret/Password:
  4. TDE構成を確認するには、-load_passwordコマンド・パラメータを使用してAutoUpgradeを再度実行できます。今回は、パスワードがすでにロードされているため、TDEコンソール・プロンプトが表示されます。TDEコンソールのlistコマンドを実行して、TDE構成を確認します。
    $ java -jar autoupgrade.jar -config DB12.cfg -load_password
	
TDE> list
+----------+---------------+------------------+-----------+------------------+
|ORACLE_SID|Action Required|   TDE Password   |SEPS Status|Active Wallet Type|
+----------+---------------+------------------+-----------+------------------+
|      CDB2|               |No password loaded|   Verified|               Any|
|      DB12|               |No password loaded|    Unknown|        Auto-login|
+----------+---------------+------------------+-----------+------------------+

    listコマンドの表出力では、Action Required列は空です。この結果から、TDEキーストア・パスワードが指定されたことが確認されます。SEPS Status列で、AutoUpgradeはターゲットOracle Database CDB2でのパスワード・ストレージ・アクセスをチェックしたことをレポートし、パスワードが機能していることを確認しています。パスワードをチェックするTDEコンソール機能はOracle Database 19cで追加された機能であるため、AutoUpgradeはOracle Database 12cリリース2 (12.2)でTDEのパスワード・チェックを確認できないので、Unknownという結果が想定されます。

    ソースCDBまたはターゲットCDBでSEPSキーストアを使用する場合、AutoUpgradeはTDEパスワードのソースとしてSEPSキーストアを自動的に検出します。AutoUpgradeはIDENTIFIED BY EXTERNAL STORE句を使用するので、TDEキーストア・パスワードをAutoUpgradeキーストアにロードする必要がありません。ここでも、TDE LISTコマンドで空のAction Required列が表示されます。

    同じ構成ファイルで両方のオプションを使用できます。たとえば、ソース非CDBデータベースにSEPSキーストアを使用せずに、ターゲットCDBにSEPSキーストアを使用する場合、必要なのは、ソース非CDBのパスワードをロードすることのみです。

  5. アップグレードおよび変換を開始します。
    $ java -jar autoupgrade.jar -config DB12.cfg -mode deploy
  6. AutoUpgradeは、アップグレードを完了するために必要に応じてTDEパスワードを使用して、ソースの非CDB Oracle DatabaseのアップグレードおよびターゲットOracle DatabaseのPDBへの変換を開始します。

注意:

他のOracle Databaseキーストアと同様に、AutoUpgradeキーストア・ファイルを保護します。

  • 制限されたファイル・システム権限の適用
  • アクセスの監査
  • キーストアのバックアップ

関連項目

親トピック: AutoUpgradeおよびOracle Databaseの構成オプション