1.1 Zero Downtime Migration 21.3リリース・ノート

このリリース・ノートでは、最新の製品ソフトウェアおよびドキュメントのダウンロード方法を示し、Zero Downtime Migrationリリース21c (21.3)の新機能、修正されたバグ、既知の問題およびトラブルシューティング情報について説明します。

1.2 このリリースの新機能

Zero Downtime Migrationリリース21c (21.3)では、次の新機能を追加することで既存の機能が強化されています。

  • 物理オンライン移行でのソース・スタンバイ・データベースのサポート

    プライマリ・データベース・システムへの負荷を減らすために、Zero Downtime Migrationでは、既存のスタンバイ・データベースを使用して、ターゲット環境でデータベースをインスタンス化できます。移行ワークフローのその他の操作では、同期およびスイッチオーバーの目的で引き続きソース・プライマリ・データベースが使用されます。

    新しいレスポンス・ファイル(RSP)パラメータZDM_USE_EXISTING_STANDBY、ZDM_STANDBY_DB_NAMEおよびZDM_STANDBY_DB_CONNECT_STRINGで、この機能がサポートされています。

    既存のスタンバイの使用によるターゲット・データベースのインスタンス化を参照してください

  • 物理オンライン移行でのOracle Data Guard Brokerのサポート

    オンラインの物理移行でData Guard Broker構成を使用すると、データ移行後のデータベース・ロールの遷移を管理できます。OracleでのData Guard Brokerの使用は、様々なシナリオに合わせて調整可能です。

    新しい物理移行レスポンス・ファイル・パラメータZDM_USE_DG_BROKERを使用すると、Zero Downtime Migrationでのブローカの使用を有効にできます。

    Oracle Data Guard Brokerのロール・スイッチオーバーの使用を参照してください

  • Amazon Web Services Oracle RDSソースからの移行の機能拡張

    Amazon Web Services (AWS) RDSでのソースOracle Databasesの移行ターゲットのサポートが拡張されてAutonomous Databaseのみではなくなりました。論理オンライン移行を使用してDBCSやExadata Cloud Servicesなどの新しいターゲットに移行できるようになりました。また、Oracleのクラウド移行前アドバイザ・ツール(CPAT)を利用できるようになりました。

    Amazon Web Services RDS OracleからOracle Cloudへの移行およびリモートでCPATを起動するための移行の構成を参照してください

  • SolarisおよびAIXソース・プラットフォームからのオンライン移行

    Zero Downtime Migrationで、Oracle SolarisまたはIBM AIXオペレーティング・システムでホストされているソースOracle Databasesのクロスプラットフォーム・クラウド移行のサポートが強化されました。論理オンライン・ワークフローを利用できるようになり、ターゲットとして、Oracle Autonomous Database、および共同管理されたクラウドOracle Databasesを利用できるようになりました。

    サポートされているプラットフォームを参照してください。

  • Exadata On-Premisesへの論理オンライン移行

    論理オンライン移行を使用してオンプレミスのExadata Database Machineターゲットに移行できるようになりました。この方法では、進行中のアップグレード、ハードウェア・リフレッシュおよびクロス・プラットフォーム移行のためのプラットフォームが提供されます。このワークフローでOracle GoldenGateを使用するには、オンプレミスのGoldenGateハブが必要であり、お客様からのGoldenGateライセンスの提供が必要になります。

    サポートされている論理移行ターゲットを参照してください

  • 論理移行ジョブの一時停止および更新の機能拡張

    論理移行ワークフローで、移行ジョブを進行中に休止できるようになりました。また、移行ジョブの実行中にOracle GoldenGate ExtractまたはReplicatの構成を更新できるようになりました。

    新しいZDMCLIのsuspend jobコマンドで、この機能がサポートされています。

    移行ジョブの一時停止および移行ジョブの間のOracle GoldenGateプロセスの変更を参照してください

  • 並列での複数のスキーマの移行

    複数のスキーマを指定できるようになり、Zero Downtime Migrationでその移行が並列で実行されます。同じデータベースの様々なスキーマまたはすべてのスキーマを同時に選択できます。

    バッチを使用した並列でのスキーマの移行を参照してください

  • 論理データ・ポンプ・エラー時の自動再試行

    Zero Downtime Migration 21.3では、障害発生時にデータ・ポンプの特定のジョブを自動で再試行する機能が導入されています。以前は、データ・ポンプに障害が発生した場合は移行全体が失敗していました。この機能はZero Downtime Migrationによって処理されるため、ユーザーによる操作は必要ありません。

  • カスタマイズの機能拡張およびその他の修正

    Zero Downtime Migrationが、ソース・データベースの機能の使用状況を追跡するためのAPIに登録されました。ソース・データベースに直接問い合せることで、Zero Downtime Migrationを含め、移行中に使用されているすべての機能を追跡できます。

    リリース21.3より前のZero Downtime Migrationでは、Exadata Cloud@Customerの移行でのターゲット・データベースをOCI Database Serviceに登録し、OCIにAPIコールを促す必要がありました。OCIのRest APIをOCIDでコールすることなくExadata Cloud@Customerへの論理移行を実行できるようになりました。

1.3 修正された不具合

Zero Downtime Migrationリリース21.3では、次の表に示すバグの修正が発生しています。

表: Zero Downtime Migrationリリース21.3の修正された不具合

バグ番号 説明
33851812 ZDM: 非CDBからPDBの場合はPFILEにSGA_TARGETパラメータが必要です
33308423 ZDM 21.2 PRGZ-1306 : 物理移行の場合に-SOURCEDBオプションまたは-SOURCESIDオプションが足りません
33440085 ZDM: フェーズZDM_NONCDBTOPDB_CONVERSIONがORA-28407「ハードウェア・セキュリティ・モジュールがPKCS#11で失敗しました」エラーで失敗します
33507393 ZDM: PDB/DBオープン・モードの事前チェックが制限されています
33522861 ZDM: 非CDBからPDBへの変換フローで初期状態リストアが失敗します
33536405 ZDMによるZDMノードからのダンプ・ファイルの論理コピー転送でエラーPRGZ-1219、PRCZ-4001、PRCZ-2103が発生します
33338593 ZDM: RACからEXCSへの移行がMANIFEST TO CLOUDフェーズで「DB一意名不一致およびDBインスタンス不一致」で失敗します
33730988 2ノードのRACからEXACCへの移行がZDM_MANIFEST_TO_CLOUDフェーズで一意名ではなくDB名が渡されて失敗します
33522880 ZDM: 制御ファイルのリストアがORA-01678「パラメータDB_FILE_NAME_CONVERTはパターンと置換文字列のペアである必要があります」で失敗します
33391815 ZDMの物理オンライン移行のフェーズZDM_CLONE_TGTがPRCD-1035「データベースがクラスタ・データベースではありません」で失敗します
33871857 直接データ転送による非CDBからPDBへの変換 - 制御ファイルのリストアがTNSエラーで失敗します

1.4 Zero Downtime Migrationのインストール・ソフトウェアのダウンロード

最新のZero Downtime Migrationソフトウェア・バージョンを新規インストールする場合は、https://www.oracle.com/database/technologies/rac/zdm-downloads.htmlにアクセスします。

1.5 Zero Downtime Migrationのドキュメントのダウンロード

Zero Downtime Migrationのドキュメントは、https://docs.oracle.com/en/database/oracle/zero-downtime-migration/で参照してダウンロードできます。

1.6 一般情報

このリリースの時点では、Zero Downtime Migrationの動作について、留意する必要がある詳細および考慮事項がいくつかあります。

1.6.1 同じホストでのRHPおよびZero Downtime Migrationサービスの実行

RHPサーバーがデプロイされているのと同じホストにZero Downtime Migrationサービスがインストールされている場合は、いくつかの回避策があることに注意してください。

RHPサーバー/クライアントをZero Downtime Migrationサービスと同じノードでデフォルトのポートを使用して起動した場合は、次のいずれかを実行する必要があります

  • RHPS/RHPCを停止する

  • RHPS/RHPCのポートを変更する

これは、RHPとZero Downtime Migrationの間のポートの衝突を回避するためです。RHP構成を変更しない場合は、Zero Downtime Migrationサービスを開始する前にZero Downtime Migrationのポートを変更することもできます。

Zero Downtime Migrationで使用されるポートを識別するには: 

ZDMinstallation/home/bin/zdmservice status

Zero Downtime Migrationサービスを停止するには: 

ZDMinstallation/home/bin/zdmservice stop

ポートを変更するには: 

ZDMinstallation/home/bin/zdmservice modify -help
Modifies configuration values.
USAGE: zdmservice modify
Optional parameters:
                     transferPortRange=<Range_of_ports>
                     rmiPort=<rmi_port>
                     httpPort=<http_port>
                     mysqlPort=<mysql_port>

たとえば:

ZDMinstallation/home/bin/zdmservice modify mysqlPort=8899
Editing MySQL port...
Successfully edited port=.* in file my.cnf
Successfully edited ^\(CONN_DESC=\).* in file rhp.pref
Successfully edited ^\(MYSQL_PORT=\).* in file rhp.pref

1.6.2 クラウド移行前アドバイザ・ツールのサポート

クラウド移行前アドバイザ・ツール(CPAT)は、次のユースケースの場合にZero Downtime Migrationでサポートされています。

  • CPATは、Oracle CloudおよびオンプレミスのOracle Databaseソースからの論理移行ジョブの間にソース・データベース環境で自動的に実行されます(デフォルトの動作)。

  • CPATは、Amazon Web Services RDSのOracle Databaseソースに対してリモート・サーバーから手動で実行します。つまり、CPATはZDMCLI migrate databaseでは実行されません(リモート接続でのCPATの実行を参照)

次のユースケースの場合、CPATはサポートされません。

  • 物理移行ジョブ

  • Amazon Web Services RDSのOracle Databaseソースに対する修正スクリプトの生成

1.6.3 ソース・データベースに追加されたUNDO表領域

Zero Downtime Migrationでは、本番データベースに含まれるインスタンスが少なくなると、ターゲット・インスタンス数と一致するようにUNDO表領域が本番データベースに追加されます。

Zero Downtime MigrationによってUNDO表領域がソース・データベースに追加されるのを防ぐには、スイッチオーバーまでターゲット・データベースのノード数をソース・データベースのノード数と一致させ、スイッチオーバー後に追加ノードをターゲット・データベースに追加できます。

1.6.4 エディション間の移行

Zero Downtime Migrationは、Enterprise EditionのデータベースからStandard Editionのデータベースへの移行には使用できません。逆の場合、Standard EditionのデータベースはEnterprise Editionのデータベースに移行できますが、論理移行ワーク・フローのみを使用します。

1.6.5 EXT3ファイル・システムのサポート

Zero Downtime MigrationをEXT3ファイル・システムにインストールできないという既知の問題があります。根本的な原因は、MySQLの不具合102384です。これは、Zero Downtime Migrationの制限事項ではなく、MySQLによる制約です。その不具合が解決されれば、Zero Downtime MigrationがEXT3ファイル・システムで機能することになります。

1.7 既知の問題

このリリースの時点で、まれな状況で発生する可能性があるZero Downtime Migrationの既知の問題は次のとおりです。各問題の回避策が提供されます。

1.7.1 zdminstall実行時に表示される警告

問題: ホーム・ディレクトリとベース・ディレクトリが事前に作成されていない場合は、zdminstall.shスクリプトの実行時に次のような警告が表示されます。 

/bin/df: '/ [...] /zdm21.3.1/home/..': No such file or directory
/ [...] /zdm3rdparty/zdminstall.sh: line 2092: [: -lt: unary operator expected

解決策: ホーム・ディレクトリとベース・ディレクトリは、存在しない場合はZero Downtime Migrationインストーラによって作成されるため、この警告メッセージは無視してかまいません。この警告は、インストールの結果に影響することも、移行での問題の原因になることもありません。

1.7.2 zdmservice操作の実行時に表示される警告

問題: zdmservice操作start、stop、statusまたはdeinstallの実行時に、次のような警告が表示されます。 

Use of uninitialized value in concatenation (.) or string at / [...]
 /zdm21.3.1/home/lib/jwcctl_lib.pm line 571.
CRS_ERROR: Invalid data ALWAYS_ON= in _USR_ORA_ENV

なお、この出力での行番号は異なる場合があります。

解決策: この警告メッセージは無視してかまいません。これは、zdmservice操作の使用に影響することも、移行での問題の原因になることもありません。

1.7.3 DBLINKを使用した論理移行がPRGZ-1177で失敗する

問題: バージョン12.1.0.xのPDBまたはマルチテナント・データベースでのデータベース・リンクを使用した論理移行が、「PRGZ-1177 : データベース・リンクdblink_nameは無効であり使用できません」というエラーで失敗します。

解決策: 12cのPDBまたはマルチテナントのみ: ORA-02085: データベース・リンクLINK_NAME_HEREがTARGET_DBに接続しています (ドキュメントID 2344831.1)を参照してください

1.7.4 PRGZ-1161 : 事前定義済のデータベース・サービスTPが存在しない

問題: 「PRGZ-1161 : Autonomous Databaseのocidには事前定義済データベース・サービスTPは存在しません」は、小数OCPU構成での既知の問題です

小数ADB (DB当たりのOCPUを整数ではなく小数で割り当てる)を構成することを選択した場合 – このフレーバでは標準のサービス別名HIGHは用意されていません。

解決策: RSPパラメータTARGETDATABASE_CONNECTIONDETAILS_SERVICENAMEをLOW_TLSまたはTP_TLSに設定します

使用可能なサービスは、OCPUが小数で割り当てられたAutonomous Data Warehouseの場合はlowまたはlow_tls、OCPUが小数で割り当てられたAutonomous Transaction Processingの場合はtpまたはtp_tlsです。

1.7.5 PRGG-1043 : No heartbeat table entries were found for Oracle GoldenGate Replicat process

問題: オンライン論理移行ジョブでは、次のいずれかの原因で、エラー「PRGG-1043 : No heartbeat table entries were found for Oracle GoldenGate Replicat process process_name」が報告されることがあります。

  1. ソースまたはターゲット・データベースで、初期化パラメータjob_queue_processesがゼロに設定されました。

    解決策: データベースで次の文を実行します。 

    show parameter job_queue_processes;
alter system set job_queue_processes=100 scope=both;
exec dbms_scheduler.set_scheduler_attribute('SCHEDULER_DISABLED','FALSE');

  2. スケジュールされたジョブGG_UPDATE_HEARTBEATSがソース・データベースでアクティブではありません。

  3. Oracle GoldenGateデプロイメントをホストするサーバーのタイム・ゾーンが、ソース・データベースと異なります。

    解決策: 最初に、次のいずれかの解決策を行います。

    • Oracle GoldenGateデプロイメントをホストするサーバーのタイム・ゾーンを変更します。または、

    • Oracle GoldenGateデプロイメントのWeb UIを使用して、ExtractパラメータTRANLOGOPTIONS SOURCE_OS_TIMEZONEを追加し、Extractを再起動します。

      たとえば、ソース・データベースのタイム・ゾーンがUTC-5の場合は、パラメータTRANLOGOPTIONS SOURCE_OS_TIMEZONE -5を設定します。詳細は、Oracle GoldenGateリファレンスのTRANLOGOPTIONSを参照してください。

    次に、ソース・データベースのDST_PRIMARY_TT_VERSIONプロパティが最新であることを確認します。

1.7.6 ソースでWALLET_ROOTが使用されている場合にリストアに失敗する

問題:ソース・データベースでwallet_root初期化パラメータが使用されている場合は、Zero Downtime Migrationで、ソース・データベースからターゲットへのTDEウォレットの移行は処理されません。ターゲット・データベース上に使用可能なウォレットがない場合、リストア・フェーズは次のようなエラーで失敗します。 

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 06/15/2021 07:35:11
ORA-19870: error while restoring backup piece
/rman_PRD1/ZDM/IQPCZDM/c-3999816841-20210614-00
ORA-19913: unable to decrypt backup

解決策: ウォレットをターゲットに手動でコピーし、ジョブを再開します。

1.7.7 Oracle Database 19.10ターゲットへの移行中にPRCZ-4026がスローされます

問題: ターゲットのOracle Database 19.10ホームに移行しようとすると、Oracle Clusterware (OCW)のバグ31070231が原因で、移行ジョブがフェーズZDM_FINALIZE_TGTでエラーPRCZ-4026で失敗します。

PRCZ-4026 : Resource ora.db_unique_name.db is already running on nodes node.

解決策: 報告された問題を回避するために、バグ#32646135のバックポート・ラベル・リクエスト(BLR)をターゲット19.10 dbhomeに適用します。BLRが適用されると、失敗した移行ジョブを再開して完了することができます。

注意: 物理的な移行の場合、ターゲット・データベースのホームがOracle Database 19.10上にないようにすることで、この問題を回避できます。

1.7.8 Oracle 11.2.0.4を含む環境ではPerlパッチの適用が必要

問題: Zero Downtime Migrationを使用する前に、ソース・データベース環境が次のいずれかの条件を満たす場合はPERLパッチを適用する必要があります。

  • Oracle Grid Infrastructure 11.2.0.4を使用したクラスタウェア環境
  • Oracle Database 11.2.0.4を使用した単一インスタンス環境

解決策: Perlパッチ・バージョン5.28.2以降をダウンロードして適用します。ソースとターゲットの両方のOracle Database 11gホームにBUG 30508206 - UPDATE PERL IN 11.2.0.4 DATABASE ORACLE HOME TO V5.28.2のパッチが含まれていることを確認します。

1.7.9 データベース・リンクを介したAutonomous Database専用インフラストラクチャへの論理移行中にORA-39006がスローされます

問題: データベース・リンクを介してデータベースをAutonomous DatabaseDedicated Infrastructure・ターゲットに移行しようとすると、移行ジョブがエラーORA-39006で失敗します。

ORA-39006: internal error

解決策: これは、バグ31830685で追跡されているデータ・ポンプの問題です。バグが修正され、修正がAutonomousターゲット・データベースに適用されるまで、Autonomous DatabaseDedicated Infrastructure・ターゲットへのデータベース・リンクを介した論理移行を実行しないでください。

1.7.10 アップグレード後にZero Downtime Migrationサービスの起動が失敗

問題: 次のシナリオが発生します。

  1. Zero Downtime Migration 19.7を使用して移行ジョブを実行します

  2. これらのジョブで使用されているレスポンス・ファイルが削除されます

  3. Zero Downtime Migration 21.1にアップグレードします

  4. 移行の実行を試行します

次のエラーが表示されます。

CRS_ERROR:TCC-0004: The container was not able to start.

CRS_ERROR:One or more listeners failed to start. Full details will be found in the appropriate container log fileContext [/rhp] startup failed due to previous errors sync_start failed with exit code 1.

zdm_installation_location/base/crsdata/hostname/rhp/logs/にあるログ・ファイルにも同様のエラーがあります。

Caused by: oracle.gridhome.container.GHException: Internal error:PRGO-3003 : Zero downtime migration (ZDM) template file /home/jdoe/zdm_mydb.rsp does not exist.

解決策: リカバリするには、ログにリストされているレスポンス・ファイルを手動で再作成し、ログで指定された場所に配置します。

1.8 トラブルシューティング

問題が発生した場合は、解決策が公開されている場合に備えて、ここを確認してください。各問題の回避策が提供されます。

1.8.1 インストールの問題

1.8.1.1 インストール時にINS-42505警告が表示される

問題: インストール中に、次の警告が表示されます。
/stage/user/ZDM_KIT_relnumber>./zdminstall.sh setup
oraclehome=/stage/user/grid oraclebase=/stage/user/base
ziploc=/stage/user/ZDM_KIT_relnumber/rhp_home.zip -zdm
---------------------------------------
Unzipping shiphome to gridhome
---------------------------------------
Unzipping shiphome...
Shiphome unzipped successfully..
---------------------------------------
##### Starting GridHome Software Only Installation #####
---------------------------------------
Launching Oracle Grid Infrastructure Setup Wizard...

[WARNING] [INS-42505] The installer has detected that the Oracle Grid
Infrastructure home software at (/stage/user/grid) is not complete.
   CAUSE: Following files are missing:
...

解決策: この警告メッセージは無視してかまいません。インストールに影響したり、移行の問題を引き起こすことはありません。

1.8.2 接続の問題

1.8.2.1 一般的な接続の問題

問題: Zero Downtime Migrationサービス・ホストとソース環境またはターゲット環境の間、またはソース環境とターゲット環境の間で接続の問題が発生した場合は、次の領域を確認してください。

解決策: SSH構成ファイル(/root/.ssh/config)に適切なエントリがあることを確認します。 

Host *
  ServerAliveInterval 10
  ServerAliveCountMax 2

Host ocidb1
  HostName 192.0.2.1
  IdentityFile ~/.ssh/ocidb1.ppk
  User opc
  ProxyCommand /usr/bin/nc -X connect -x www-proxy.example.com:80 %h %p

プロキシ・サーバーを接続に使用していない場合は、プロキシの設定が必要ないことがあります。たとえば、ソース・データベース・サーバーがOracle Cloud Infrastructure Classic上にある場合、ProxyCommandで始まる行を削除またはコメントにすることができます。

ソースがOracle RACデータベースの場合は、必ず~/.ssh/configファイルをすべてのソースOracle RACサーバーにコピーします。SSH構成ファイルは、最初のOracle RACサーバーのホスト名、パブリックIPアドレスおよび秘密キーの属性を参照します。

1.8.2.2 通信リンクの障害

問題: MySQLサーバーがクラッシュすると、ZDM操作で次のようなエラーが表示されます。 

$ ./zdmcli query job -jobid 6
Exception [EclipseLink-4002] (Eclipse Persistence Services -
2.7.7.qualifier): org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: com.mysql.cj.jdbc.exceptions.CommunicationsException:
Communications link failure
The last packet sent successfully to the server was 0 milliseconds ago. The
driver has not received any packets from the server.
Error Code: 0
Query: ReadAllQuery(referenceClass=JobSchedulerImpl sql="SELECT
JOB_IDENTIFIER, M_ACELIST, ARGUMENTS, ATTRIBUTES, CLIENT_NAME,
COMMAND_PROVIDED, COMPARTMENT, CONTAINER_TYPE, CREATEDATE, CREATOR,
CURRENT_STATUS, DB_OCID, DBNAME, DEPLOYMENT_OCID, DISABLE_JOB_EXECUTION,
ELAPSED_TIME, END_TIME, EXECUTE_PHASES, EXECUTION_TIME, IS_EVAL, IS_PAUSED,
JOB_TYPE, METHOD_NAME, METRICS_LOCATION, OPERATION, PARAMETERS,
PARENT_JOB_ID, PAUSE_AFTER_PHASE, RESULT, PHASE, JOB_SCHEDULER_PHASES,
REGION, REST_USER_NAME, RESULT_LOCATION, SCHEDULED_TIME, SITE, SOURCEDB,
SOURCENODE, SOURCESID, SPARE1, SPARE2, SPARE3, SPARE_A, SPARE_B, SPARE_C,
START_TIME, STOP_AFTER_PHASE, TARGETNODE, JOB_THREAD_ID, UPD_DATE, USER_NAME,
ENTITY_VERSION, CUSTOMER FROM JOBSCHEDULER WHERE (PARENT_JOB_ID = ?)")

解決策: このような通信エラーが表示された場合は、Zero Downtime Migrationサービスを再起動してMySQLサーバーが再起動されるようにすると、保留中のジョブが自動的に再開されます。

Zero Downtime Migrationサービスを停止します。

zdmuser> $ZDM_HOME/bin/zdmservice stop

Zero Downtime Migrationサービスを開始します。

zdmuser> $ZDM_HOME/bin/zdmservice start

1.8.2.3 フェーズZDM_GET_TGT_INFOで評価が失敗

問題: 移行プロセスの評価(-eval)フェーズ中、ZDM_GET_TGT_INFOフェーズで、Oracle RACインスタンスの移行に関する次のエラーで評価が失敗します。 

Executing phase ZDM_GET_TGT_INFO
Retrieving information from target node "trac11" ...
PRGZ-3130 : failed to establish connection to target listener from nodes [srac11, srac12]
PRCC-1021 : One or more of the submitted commands did not execute successfully.
PRCC-1025 : Command submitted on node srac11 timed out after 15 seconds.
PRCC-1025 : Command submitted on node srac12 timed out after 15 seconds.

解決策:

  1. ソース・データベースのSCAN名を取得し、ソース・データベース・サーバーのパブリックIPアドレスおよびソース・データベースのSCAN名を使用して、両方のターゲット・データベース・サーバー上にある/etc/hostsファイルに追加します。たとえば: 
    192.0.2.3 source-scan
  2. ターゲット・データベースのSCAN名を取得し、ターゲット・データベース・サーバーのパブリックIPアドレスおよびターゲット・データベースのSCAN名を使用して、両方のソース・データベース・サーバー上にある/etc/hostsファイルに追加します。たとえば:
    192.0.2.1  target-scan

ノート:

SCAN IPアドレスが/etc/hostsファイルに追加されないこの問題は、場合によってはSCAN IPアドレスがプライベートIPアドレスとして割り当てられているために解決できないことがあるため、発生する可能性があります。

1.8.2.4 Object Storageがアクセス不可

問題: ソースまたはターゲットのデータベース・サーバーからObject Storageにアクセスすると、次のエラーが発生して失敗することがあります。
About to connect() to swiftobjectstorage.xx-region-1.oraclecloud.com port 443 (#0)
Trying 192.0.2.1... No route to host
Trying 192.0.2.2... No route to host
Trying 192.0.2.3... No route to host
couldn't connect to host
Closing connection #0
curl: (7) couldn't connect to host

解決策: ソース・データベース・サーバーからObject Storageに接続するのにプロキシが必要である場合は、Zero Downtime Migrationサービス・ホストで、レスポンス・ファイル・テンプレート($ZDM_HOME/rhp/zdm/template/zdm_template.rsp)に、次に示すObject Storage Serviceのプロキシ・ホストおよびポートのパラメータを設定します。たとえば: 

SRC_OSS_PROXY_HOST=www-proxy-source.example.com
SRC_OSS_PROXY_PORT=80

ターゲット・データベース・サーバーからObject Storageに接続するのにプロキシが必要である場合は、レスポンス・ファイル・テンプレート($ZDM_HOME/rhp/zdm/template/zdm_template.rsp)に、次に示すObject Storage Serviceのプロキシ・ホストおよびポートのパラメータを設定します。たとえば: 

TGT_OSS_PROXY_HOST=www-proxy-target.example.com
TGT_OSS_PROXY_PORT=80

1.8.2.5 SSHエラー"EdDSA provider not supported"

問題: $ZDM_BASE/crsdata/zdm service hostname/rhp/zdmserver.log.0に次のエラー・メッセージが表示されます。 

[sshd-SshClient[3051eb49]-nio2-thread-1] [ 2020-04-04 00:26:24.142 GMT ]
 [JSChChannel$LogOutputStream.flush:1520]  2020-04-04: WARNING: org.apache.sshd.client.session.C:
 globalRequest(ClientConnectionService[ClientSessionImpl[opc@samidb-db/140.238.254.80:22]])[hostkeys-00@openssh.com,
 want-reply=false] failed (SshException) to process: EdDSA provider not supported

[sshd-SshClient[3051eb49]-nio2-thread-1] [ 2020-04-04 00:26:24.142 GMT ]
 [JSChChannel$LogOutputStream.flush:1520]  2020-04-04: FINE   : org.apache.sshd.client.session.C:
 globalRequest(ClientConnectionService[ClientSessionImpl[opc@samidb-db/140.238.254.80:22]])[hostkeys-00@openssh.com,
 want-reply=false] failure details
org.apache.sshd.common.SshException: EdDSA provider not supported
    at org.apache.sshd.common.util.buffer.Buffer.getRawPublicKey(Buffer.java:446)
    at org.apache.sshd.common.util.buffer.Buffer.getPublicKey(Buffer.java:420)
    at org.apache.sshd.common.global.AbstractOpenSshHostKeysHandler.process(AbstractOpenSshHostKeysHandler.java:71)
    at org.apache.sshd.common.global.AbstractOpenSshHostKeysHandler.process(AbstractOpenSshHostKeysHandler.java:38)
    at org.apache.sshd.common.session.helpers.AbstractConnectionService.globalRequest(AbstractConnectionService.java:723)
    at org.apache.sshd.common.session.helpers.AbstractConnectionService.process(AbstractConnectionService.java:363)
    at org.apache.sshd.common.session.helpers.AbstractSession.doHandleMessage(AbstractSession.java:400)
    at org.apache.sshd.common.session.helpers.AbstractSession.handleMessage(AbstractSession.java:333)
    at org.apache.sshd.common.session.helpers.AbstractSession.decode(AbstractSession.java:1097)
    at org.apache.sshd.common.session.helpers.AbstractSession.messageReceived(AbstractSession.java:294)
    at org.apache.sshd.common.session.helpers.AbstractSessionIoHandler.messageReceived(AbstractSessionIoHandler.java:63)
    at org.apache.sshd.common.io.nio2.Nio2Session.handleReadCycleCompletion(Nio2Session.java:357)
    at org.apache.sshd.common.io.nio2.Nio2Session$1.onCompleted(Nio2Session.java:335)
    at org.apache.sshd.common.io.nio2.Nio2Session$1.onCompleted(Nio2Session.java:332)
    at org.apache.sshd.common.io.nio2.Nio2CompletionHandler.lambda$completed$0(Nio2CompletionHandler.java:38)
    at java.security.AccessController.doPrivileged(Native Method)
    at org.apache.sshd.common.io.nio2.Nio2CompletionHandler.completed(Nio2CompletionHandler.java:37)
    at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126)
    at sun.nio.ch.Invoker$2.run(Invoker.java:218)
    at sun.nio.ch.AsynchronousChannelGroupImpl$1.run(AsynchronousChannelGroupImpl.java:112)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)
Caused by: java.security.NoSuchAlgorithmException: EdDSA provider not supported
    at org.apache.sshd.common.util.security.SecurityUtils.generateEDDSAPublicKey(SecurityUtils.java:596)
    at org.apache.sshd.common.util.buffer.keys.ED25519BufferPublicKeyParser.getRawPublicKey(ED25519BufferPublicKeyParser.java:45)
    at org.apache.sshd.common.util.buffer.keys.BufferPublicKeyParser$2.getRawPublicKey(BufferPublicKeyParser.java:98)
    at org.apache.sshd.common.util.buffer.Buffer.getRawPublicKey(Buffer.java:444)
    ... 22 more
[sshd-SshClient[3051eb49]-nio2-thread-1] [ 2020-04-04 00:26:24.142 GMT ]
 [JSChChannel$LogOutputStream.flush:1520]  2020-04-04: FINE   : org.apache.sshd.client.session.C:
 sendGlobalResponse(ClientConnectionService[ClientSessionImpl[opc@samidb-db/140.238.254.80:22]])[hostkeys-00@openssh.com]
 result=ReplyFailure, want-reply=false

[sshd-SshClient[3051eb49]-nio2-thread-2] [ 2020-04-04 00:26:24.182 GMT ]
 [JSChChannel$LogOutputStream.flush:1520]  2020-04-04: FINE   : org.apache.sshd.common.io.nio2.N:
 handleReadCycleCompletion(Nio2Session[local=/192.168.0.2:41198, remote=samidb-db/140.238.254.80:22])
 read 52 bytes

解決策: Zero Downtime MigrationはRSA形式を使用します。

1.8.3 透過的データ暗号化に関連する問題

1.8.3.1 透過的データ暗号化の一般情報

ソース・データベースのリリースによっては、透過的データ暗号化(TDE)ウォレット構成が必要な場合があります。

  • Oracle Database 12cリリース2以降

    Oracle Database 12cリリース2以降のリリースの場合、TDEウォレット構成は必須であり、移行の開始前にソース・データベースで有効になっている必要があります。

    TDEが有効になっていない場合、データベースの移行は失敗します。

    リストア時に、データベース表領域はウォレットを使用して暗号化されます。

  • Oracle Database 12cリリース1以前

    Oracle Database 12cリリース1およびOracle Database 11gリリース2 (11.2.0.4)では、TDE構成は必須ではありません。

Oracle Cloud環境でのTDEの動作の詳細は、My Oracle SupportドキュメントOracle CloudでのOracle Database表領域暗号化の動作(ドキュメントID 2359020.1)を参照してください。

1.8.3.2 フェーズZDM_SETUP_TDE_TGTでジョブが失敗

問題: フェーズZDM_SETUP_TDE_TGTが次のいずれかのエラーで失敗します。 

Executing phase ZDM_SETUP_TDE_TGT
Setting up Oracle Transparent Data Encryption (TDE) keystore on the target node oci1121 ...
oci1121: <ERR_FILE><Facility>PRGZ</Facility><ID>ZDM_KEYSTORE_NOT_SETUP_ERR</ID><ARGS><ARG>oci112_phx1z3</ARG></ARGS></ERR_FILE>
PRGO-3007 : failed to migrate database "db11204" with zero downtime
PRCZ-4002 : failed to execute command "/u01/app/18.0.0.0/grid/perl/bin/perl" using the privileged execution plugin "zdmauth" on nodes "oci1121"
PRCZ-2103 : Failed to execute command "/u01/app/18.0.0.0/grid/perl/bin/perl" on node "oci1121" as user "root". Detailed error:
<ERR_FILE><Facility>PRGZ</Facility><ID>ZDM_KEYSTORE_NOT_SETUP_ERR</ID><ARGS><ARG>oci112_phx1z3</ARG></ARGS></ERR_FILE>

Error at target server in /tmp/zdm749527725/zdm/log/mZDM_oss_standby_setup_tde_tgt_71939.log
2019-06-13 10:00:20: Keystore location /opt/oracle/dcs/commonstore/wallets/tde/$ORACLE_UNQNAME does not exists for database 'oci112_region'
2019-06-13 10:00:20: Reporting error:
<ERR_FILE><Facility>PRGZ</Facility><ID>ZDM_KEYSTORE_NOT_SETUP_ERR</ID><ARGS><ARG>oci112_region</ARG></ARGS></ERR_FILE>

解決策:

  • Oracle Database 12cリリース1以降

    ターゲット・データベースで、$ORACLE_HOME/network/admin/sqlnet.oraがTDEウォレットの正しい場所を指していることを確認します。次に例を示します。 

    ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/opt/oracle/dcs/commonstore/wallets/tde/$ORACLE_UNQNAME)
  • Oracle Database 11gリリース2 (11.2.0.4)のみ

    ターゲット・データベースで、$ORACLE_HOME/network/admin/sqlnet.oraがTDEウォレットの正しい場所を指していることを確認し、$ORACLE_UNQNAME変数をSHOW PARAMETER DB_UNIQUE_NAME SQLコマンドから取得した値で置き換えます。

    たとえば、次を実行します。

    SQL> show parameter db_unique_name
db_unique_name         string      oci112_region

    次を

    ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/opt/oracle/dcs/commonstore/wallets/tde/$ORACLE_UNQNAME)))

    次で置き換えます。

    ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/opt/oracle/dcs/commonstore/wallets/tde/oci112_region)))

1.8.4 全体バックアップ・フェーズ(ZDM_BACKUP_FULL_SRC)の問題

1.8.4.1 ORA-19836でバックアップが失敗

問題: 次のいずれかのエラーで、ソース・データベースの全体バックアップが失敗します。 

</ERRLINE><ERRLINE>ORA-19836: cannot use passphrase encryption for this backup
</ERRLINE><ERRLINE>RMAN-03009: failure of backup command on C8 channel at 04/29/2019
      20:42:16
</ERRLINE><ERRLINE>ORA-19836: cannot use passphrase encryption for this backup
</ERRLINE><ERRLINE>RMAN-03009: continuing other job steps, job failed will not be
      re-run

解決策1: この問題は、誤ったケースで-sourcedb値を指定した場合に発生する可能性があります。たとえば、SQLコマンドSHOW PARAMETER DB_UNIQUE_NAMEから取得した値がzdmsdbの場合は、次の例に示すように小文字でzdmsdbと指定する必要があり、大文字でZDMSDBと指定しません。 

zdmuser> $ZDM_HOME/bin/zdmcli migrate database -sourcedb zdmsdb -sourcenode ocicdb1 -srcroot
-targetnode ocidb1 -targethome /u01/app/oracle/product/12.1.0.2/dbhome_1
-backupuser backup_user@example.com -rsp /u01/app/zdmhome/rhp/zdm/template/zdm_template_zdmsdb.rsp
-tgtauth zdmauth -tgtarg1 user:opc
-tgtarg2 identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk
-tgtarg3 sudo_location:/usr/bin/sudo

解決方法2: Oracle Database 12cリリース1以降では、次に示すように、$ORACLE_HOME/network/admin/sqlnet.oraがTDEウォレットの正しい場所を指していることを確認します。 

ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/opt/oracle/dcs/commonstore/wallets/tde/$ORACLE_UNQNAME)))

Oracle Database 11gリリース2 (11.2.0.4)のみでは、次に示すように$ORACLE_HOME/network/admin/sqlnet.oraがTDEウォレットの正しい場所を指していることを確認し、SQL文SHOW PARAMETER DB_UNIQUE_NAMEを使用して取得した値で変数$ORACLE_UNQNAMEを置換します。 

ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/opt/oracle/dcs/commonstore/wallets/tde/$ORACLE_UNQNAME)))

たとえば:

SQL> show parameter db_unique_name
db_unique_name    string      oci112_region

ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/opt/oracle/dcs/commonstore/wallets/tde/oci112_region)))

解決策3: 次の問合せを実行して、ウォレットのステータスがOPENであることを確認します。 

SQL> select * from v$encryption_wallet
WRL_TYPE
-------------
WRL_PARAMETER
-------------
STATUS
-------------
file
/opt/oracle/dcs/commonstore/wallets/tde/abc_test
OPEN

1.8.4.2 ORA-19914およびORA-28365でバックアップが失敗

問題: 次のエラーで、ソース・データベースの全体バックアップが失敗します。 

channel ORA_SBT_TAPE_3: backup set complete, elapsed time: 00:00:15
channel ORA_SBT_TAPE_3: starting compressed full datafile backup set
channel ORA_SBT_TAPE_3: specifying datafile(s) in backup set
input datafile file number=00005 name=+DATA/ODA122/7312FA75F2B202E5E053050011AC5977/DATAFILE/system.382.1003858429
channel ORA_SBT_TAPE_3: starting piece 1 at 25-MAR-19
RMAN-03009: failure of backup command on ORA_SBT_TAPE_3 channel at 03/25/2019 19:09:30
ORA-19914: unable to encrypt backup
ORA-28365: wallet is not open
continuing other job steps, job failed will not be re-run
channel ORA_SBT_TAPE_3: starting compressed full datafile backup set
channel ORA_SBT_TAPE_3: specifying datafile(s) in backup set

解決策: ウォレットがデータベースでオープンされていることを確認し、CDBの場合は、ウォレットがCDB、すべてのPDBおよびPDB$SEEDでオープンされていることを確認します。TDEの設定の詳細は、Zero Downtime Migrationドキュメントの透過的データ暗号化ウォレットの設定を参照してください。

1.8.4.3 Object Storage Bucket Nameという名前のバケットがネームスペースNamespaceに存在しないか、アクセスする権限がない

この問題の説明および回避策については、Oracle Supportナレッジ・ベースの記事『'<Object Storage Bucket Name>'という名前のバケットがネームスペース'<Namespace>'に存在しないか、アクセスする権限がありません(ドキュメントID 2605518.1)』を参照してください。

https://support.oracle.com/rs?type=doc&id=2605518.1

1.8.5 リストア・フェーズ(ZDT_CLONE_TGT)の問題

1.8.5.1 アサート[KCBTSE_ENCDEC_TBSBLK_1]でデータベースのリストアが失敗

問題: RDBMS Bugの31048741、32697431および32117834が原因で、物理移行のリストア・フェーズ中にアラート・ログにアサート[kcbtse_encdec_tbsblk_1]が表示される場合があります。

解決策: RDBMS Bugの31048741および32697431のパッチを、19.13更新より前のOracle Database 19c移行ターゲットに適用します。

1.8.5.2 「AUTOBACKUP does not contain an SPFILE」でデータベースのリストアが失敗

問題: フェーズZDT_CLONE_TGTの実行中に、データベースのリストアが次のエラーで失敗します。 

channel C1: looking for AUTOBACKUP on day: 20200427
channel C1: AUTOBACKUP found: c-1482198272-20200427-12
channel C1: restoring spfile from AUTOBACKUP c-1482198272-20200427-12
channel C1: the AUTOBACKUP does not contain an SPFILE

ソース・データベースはinit.oraファイルを使用して実行されていますが、ターゲットのリストア・フェーズ中に、データベースは自動バックアップからサーバー・パラメータ・ファイル(SPFILE)をリストアしようとするため、失敗します。

解決策: SPFILEを使用してソース・データベースを起動し、移行ジョブを再送信します。

1.8.5.3 ORA-01565でデータベースのリストアが失敗

問題: フェーズZDT_CLONE_TGTの実行中に、データベースのリストアが次のエラーで失敗します。 

</ERRLINE><ERRLINE>With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP
</ERRLINE><ERRLINE>and Real Application Testing options
</ERRLINE><ERRLINE>
</ERRLINE><ERRLINE>CREATE PFILE='/tmp/zdm833428275/zdm/PFILE/zdm_tgt_mclone_nrt139.pfile' FROM SPFILE
</ERRLINE><ERRLINE>*
</ERRLINE><ERRLINE>ERROR at line 1:
</ERRLINE><ERRLINE>ORA-01565: error in identifying file '?/dbs/spfile@.ora'
</ERRLINE><ERRLINE>ORA-27037: unable to obtain file status
</ERRLINE><ERRLINE>Linux-x86_64 Error: 2: No such file or directory
</ERRLINE><ERRLINE>Additional information: 3
</ERRLINE><ERRLINE>
</ERRLINE><ERRLINE>
</ERRLINE><ERRLINE>Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
</ERRLINE><ERRLINE>With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP

解決策: SPFILEを使用してターゲット・データベースを起動し、移行ジョブを再開します。

1.8.6 移行後の自動バックアップの問題

1.8.6.1 移行後の自動バックアップ障害のトラブルシューティング

問題: 移行後、ターゲット・データベースで自動バックアップが失敗することがあります。

コンソールを使用して、「Bare Metal」、「VM and Exadata」→「DB Systems」→「DB System Details」→「Database Details」→「Backups」で障害を確認できます。

解決策: 次のいずれかの場所からRMAN構成設定を取得します。

たとえば、2番目のオプションを使用すると、/opt/oracle/dcs/log/ocidb1/rman/bkup/ocidb1_abc127/rman_configure*.logからRMAN構成設定を取得し、問題なく自動バックアップが機能するように、ターゲット・データベースの変更されたRMAN構成設定をリセットできます。

この回避策が役に立たない場合は、DBCLIコマンドlist-jobsを実行してRMANジョブIDを取得してさらにデバッグを行い、データベース・サーバーからrootユーザーとしてDBCLIコマンドdescribe-job -i JOB IDを実行してエラーの詳細をさらに得るためにジョブの詳細を記述します。

たとえば、テスト時に、自動バックアップが機能するように次の強調表示されている設定が変更されました。

rman target /
Recovery Manager: Release 12.2.0.1.0 - Production on Mon Jul 8 11:00:18 2019
Copyright (c) 1982, 2017, Oracle and/or its affiliates.  All rights reserved.
connected to target database: ORCL (DBID=1540292788)
RMAN> show all;
using target database control file instead of recovery catalog
RMAN configuration parameters for database with db_unique_name OCIDB1_ABC127 are:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 30 DAYS;
CONFIGURE BACKUP OPTIMIZATION OFF;
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE SBT_TAPE TO '%F'; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 4 BACKUP TYPE TO COMPRESSED BACKUPSET;
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 2 G;
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' MAXPIECESIZE 2 G FORMAT '%d_%I_%U_%T_%t' PARMS
 'SBT_LIBRARY=/opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs/libopc.so ENV=(OPC_PFILE=/opt/oracle/dcs/commonstore/objectstore/opc_pfile/1245080042/opc_OCIDB1_ABC127.ora)';
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE ON;
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE COMPRESSION ALGORITHM 'MEDIUM' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE;
CONFIGURE RMAN OUTPUT TO KEEP FOR 7 DAYS; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO 'SBT_TAPE';
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+RECO/ OCIDB1_ABC127/controlfile/snapcf_ocidb1_abc127.f';
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK clear;
RMAN>

1.8.6.2 DCS-10045で移行後の自動バックアップが失敗

問題: 移行後、TDEが有効になっていない移行済のOracle Databaseリリース11.2.0.4および12.1.0.2について、次のエラーで自動バックアップが失敗します。 

DCS-10045: Validation error encountered: Backup password is mandatory to take OSS backup for non-tde enabled database...

DBCLIコマンドlist-jobsを実行してRMANジョブIDを取得してこのエラーを検証し、データベース・サーバーからrootユーザーとしてDBCLIコマンドdescribe-job -i JOB IDを実行してエラーの詳細を取得するためにジョブの詳細を記述します。

解決策:

  1. TDEウォレットの場所を見つけます。

    Oracle Cloud Infrastructureのプロビジョニング済のデータベース・インスタンスは、sqlnet.oraに次のエントリがあります。 

    ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/opt/oracle/dcs/commonstore/wallets/tde/$ORACLE_UNQNAME)))
  2. ウォレットの場所からcwallet.ssoファイルを削除します。

    たとえば、/opt/oracle/dcs/commonstore/wallets/tde/$ORACLE_UNQNAMEです。

  3. Oracle Database 11gリリース2の場合、次のステップを実行します。
    1. sysdbaとしてSQL*Plusを使用してデータベースに接続し、現在のウォレットの場所を確認します。
      SQL> select * from v$encryption_wallet;
WRL_TYPE    WRL_PARAMETER                                            STATUS
file        /opt/oracle/dcs/commonstore/wallets/tde/ocise112_region  OPEN
    2. データベースのウォレットを閉じます。
      SQL> alter system set wallet close;
    3. ウォレット・パスワードを使用してウォレットを開きます。
      SQL> alter system SET WALLET open IDENTIFIED BY "walletpassword"
    4. マスター暗号化キーを設定します。
      SQL> alter system set encryption key identified by "walletpassword"
    5. 自動ログインSSOファイルを再作成します。
      /home/oracle>orapki wallet create -wallet /opt/oracle/dcs/commonstore/wallets/tde/$ORACLE_UNQNAME -auto_login
Oracle PKI Tool : Version 11.2.0.4.0 - Production
Copyright (c) 2004, 2013, Oracle and/or its affiliates. All rights reserved.
Enter wallet password:            #
    6. 自動バックアップを再試行します。
  4. Oracle Database 12cの場合、次のステップを実行します。
    1. sysdbaとしてSQL*Plusを使用してデータベースに接続し、現在のウォレットの場所およびステータスを確認します。
      SQL> SELECT wrl_parameter, status, wallet_type FROM v$encryption_wallet;
WRL_PARAMETER                                            STATUS              WALLET_TYPE
/opt/oracle/dcs/commonstore/wallets/tde/ocise112_region  OPEN_NO_MASTER_KEY  OPEN

      STATUS列に値OPEN_NO_MASTER_KEYが含まれる場合、マスター暗号化キーを作成してアクティブにする必要があります。

    2. データベースのウォレットを閉じます。
      SQL> alter system set wallet close;
    3. パスワードを使用してウォレットを開きます。
      SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE open IDENTIFIED BY "walletpassword" CONTAINER=all;
    4. マスター暗号化キーを設定します。
      SQL> ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY "walletpassword" with backup;

      各PDBにログインして実行します。

      SQL> ALTER SESSION SET CONTAINER = PDB_NAME;
SQL> ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY "walletpassword" with backup;
    5. 自動ログイン・キーストアを作成します。
      SQL> ADMINISTER KEY MANAGEMENT CREATE AUTO_LOGIN KEYSTORE FROM KEYSTORE 'path to wallet directory' IDENTIFIED BY "walletpassword";
    6. 自動バックアップを再試行します。

1.8.6.3 DCS-10096で移行後の自動バックアップが失敗

問題: 移行後、次のエラーで自動バックアップが失敗します。 

DCS-10096:RMAN configuration 'Retention policy' must be configured as 'configure retentio n
      policy to recovery window of 30 days'

DBCLIコマンドlist-jobsを実行してRMANジョブIDを取得してこのエラーを検証し、データベース・サーバーからrootユーザーとしてDBCLIコマンドdescribe-job -i JOB IDを実行してエラーの詳細をさらに得るためにジョブの詳細を記述します。

解決策: RMANプロンプトにログインし、保存ポリシーを構成します。 

[oracle@racoci1 ~]$ rman target /
Recovery Manager: Release 12.2.0.1.0 - Production on Wed Jul 17 11:04:35 2019
Copyright (c) 1982, 2017, Oracle and/or its affiliates.  All rights reserved.
connected to target database: SIODA (DBID=2489657199)
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 30 DAYS;

old RMAN configuration parameters:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;

new RMAN configuration parameters:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 30 DAYS;

new RMAN configuration parameters are successfully stored

自動バックアップを再試行します。

1.8.7 その他の問題

1.8.7.1 既存のData Guardスタンバイからの移行が失敗する

問題: 既存のスタンバイを使用すると、Data Guardブローカ構成でTNS別名が使用されている場合、Zero Downtime Migrationジョブが失敗します。

Data Guardブローカ構成では、構成内の他のすべてのデータベースからすべてのデータベースに到達可能である必要があります。Zero Downtime Migrationがターゲットに新しいスタンバイを作成し、それを既存のData Guardブローカ構成に追加する際、Zero Downtime Migrationは接続文字列の形式で指定された接続識別子を持つターゲットを追加します。Zero Downtime Migrationでは、構成内に他のデータベースがあるターゲット上のtnsnames.oraは更新されません。tnsnames.oraエントリがないため、TNS別名で構成が作成された場合、他のデータベースに到達できない可能性があります。

解決策: プライマリ・データベースと既存のスタンバイ・データベースに対応するブローカ構成内のすべてのTNS別名が、ターゲットtnsnames.oraファイルで定義されていることを確認します。

または、ブローカ構成がTNS別名ではなく接続文字列で構成されていることを確認します。接続識別子文字列は、次のコマンドを使用して識別できます。

show database db_name dgconnectidentifier;

接続識別子がTNS別名である場合、次のコマンドを使用して識別子を更新し、EZconnect文字列の形式で接続文字列を指定できます。

クラスタ・データベースの場合:

edit database db_name set property
 dgconnectidentifier='scan_name:scan_port/service_name';

非クラスタ・データベースの場合:

edit database db_name set property
dgconnectidentifier='listener_host:listener_port/service_name';

TNS別名は、接続識別子がブローカ構成内のすべてのデータベース・インスタンスから到達可能な接続文字列として指定されている場合は必要ありません。これは、スタンバイが役割を切り替えてプライマリになる場合に備えて、ブローカがプライマリとスタンバイの関係を管理できるようにする必要があるためです。

1.8.7.2 ExaCSまたはExaCCへの移行後に失敗した状態のPDB

問題: ExaCSとExaCCが、最近、CDBのPDBを表示する機能を追加しました。ターゲット・データベースが移行前のソースと同じPDB名でプロビジョニングされている場合、移行後、PDB名は失敗としてステータスを報告します。

これは、ターゲットがプロビジョニングされている場合、PDBのPDBIDが異なるためです。移行中、Zero Downtime Migrationによってターゲットが削除され、再作成されます。したがって、PDB名が同じでも、別の内部PDBIDを持つ場合、コントロール・プレーンはPDBを失敗として報告します。

解決策: この問題を回避するには、ターゲットをプロビジョニングするときに次のようにします。

  1. ソースが非CDBの場合、dbaascliを介して非CDBターゲットをプロビジョニングします

  2. ソースがPDBを含むCDBの場合は、PDBなしでターゲットをプロビジョニングします

PDBが移行後に失敗した状態で報告された場合、解決策はPluggable Database(PDB) Resource Shows Failed Status In Cloud Console while it is Available in VM (Doc ID 2855062.1)に従うことです。

1.8.7.3 Oracle GoldenGateハブ証明書の既知の問題

問題: Oracle Zero Downtime Migrationは、論理オンライン移行ワークフローにOracle GoldenGateを利用します。このために、OCIコンピュートにOracle GoldenGateハブが設定されます。

Oracle GoldenGateハブのNginXリバース・プロキシは、次のエラーの原因となる自己署名証明書を使用します。

SunCertPathBuilderException: unable to find valid certification path to requested target when ZDM Server makes a REST API call.

解決策: My Oracle SupportドキュメントZero Downtime Migration - GoldenGateハブ証明書の既知の問題(ドキュメントID 2768483.1)を参照してください

1.8.7.4 ソース検出でデフォルトの場所に'cut'が見つからない

問題: ソース・データベース・サーバーの検出で、標準の場所にcutが見つかりません。

ソース・データベース・デプロイメントの標準のcutの場所は、/bin/cutです。cutがその場所に存在しない場合、Zero Downtime Migrationではソース・データベース情報を正しく検出できず、移行は初期フェーズで失敗します。

解決策: 問題を解決するには、cutが標準の/bin/cutパスにインストールされていることを確認するか、インストールした場所へのシンボリック・リンクを作成します。次に例を示します。

ln -sf <installed_location_of_the_cut> /bin/cut

1.8.7.5 フェーズZDM_GET_SRC_INFOで評価が失敗

問題: 移行プロセスの評価(-eval)フェーズ中、ZDM_GET_SRC_INFOフェーズで、ソースのシングル・インスタンスがGrid Infrastructureなしでデプロイされていることに関する次のエラーで評価が失敗します。 

Executing phase ZDM_GET_SRC_INFO
retrieving information about database "zdmsidb" ...
PRCF-2056 : The copy operation failed on node: "zdmsidb".
Details: {1}
PRCZ-4002 : failed to execute command "/bin/cp" using the privileged
execution plugin "zdmauth" on nodes "zdmsidb"
scp: /etc/oratab: No such file or directory

解決策: /etc/oratabファイル内にORACLE_HOME値エントリを、値db_name:$ORACLE_HOME:Nを使用して作成します。次に例を示します。 

zdmsidb:/u01/app/oracle/product/12.2.0.1/dbhome_1:N

1.8.7.6 Java例外の無効なキー書式による移行評価の失敗

問題: 次の条件が表示されます。

  • Zero Downtime Migrationのmigration -evalコマンドが次のエラーで失敗します。 

    Result file path contents:
"/u01/app/zdmbase/chkbase/scheduled/job-19-2019-12-02-03:46:19.log"
zdm-server.ocitoolingsn.ocitooling.oraclevcn.com: Processing response
file ...
null

  • ファイル$ZDM_BASE/<zdm service host>/rhp/rhpserver.log.0には、次のエントリが含まれています。 

    Verify below error message observed in file $ZDM_BASE/<zdm service
host>/rhp/rhpserver.log.0
rhpserver.log.7:[pool-58-thread-1] [ 2019-12-02 02:08:15.178 GMT ]
[JSChChannel.getKeyPair:1603]  Exception :
java.security.spec.InvalidKeySpecException:
java.security.InvalidKeyException: invalid key format

  • Zero Downtime Migrationインストール・ユーザー(たとえば: zdmuser)の秘密キー(id_rsa)ファイルには次のエントリがあります。

    -----BEGIN OPENSSH PRIVATE KEY----------
MIIEogIBAAKCAQEAuPcjftR6vC98fAbU4FhYVKPqc0CSgibtMSouo1DtQ06ROPN0
XpIEL4r8nGp+c5GSDONyhf0hiltBzg0fyqyurSw3XfGJq2Q6EQ61aL95Rt9CZh6b
JSUwc69T4rHjvRnK824k4UpfUIqafOXb2mRgGVUkldo4yy+pLoGq1GwbsIYbS4tk
uaYPKZ3A3H9ZA7MtZ5M0sNqnk/4Qy0d8VONWozxOLFC2A8zbbe7GdQw9khVqDb/x
END OPENSSH PRIVATE KEY-----

解決策: 認証キーのペア(秘密キーと公開キー)はssh-keygenユーティリティを使用して生成されないため、パスフレーズを使用しない秘密SSHキーの生成のステップを使用して認証キーのペアを生成する必要があります。

認証キーのペアを生成した後、秘密キー・ファイルの内容は次のようになります。

-----BEGIN RSA PRIVATE KEY-----
MIIEogIBAAKCAQEAuPcjftR6vC98fAbU4FhYVKPqc0CSgibtMSouo1DtQ06ROPN0
XpIEL4r8nGp+c5GSDONyhf0hiltBzg0fyqyurSw3XfGJq2Q6EQ61aL95Rt9CZh6b
JSUwc69T4rHjvRnK824k4UpfUIqafOXb2mRgGVUkldo4yy+pLoGq1GwbsIYbS4tk
uaYPKZ3A3H9ZA7MtZ5M0sNqnk/4Qy0d8VONWozxOLFC2A8zbbe7GdQw9khVqDb/x
-----END RSA PRIVATE KEY-----

新しく生成された認証キーのペアとの接続を設定し、移行ジョブを再開します。

1.8.7.7 移行評価がエラーPRCG-1022で失敗する

問題: 次の条件が表示されます。 

$ZDM_HOME/bin/zdmcli migrate database -sourcedb zdmsdb -sourcenode ocicdb1 
-srcauth zdmauth -srcarg1 user:opc 
-srcarg2 identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk 
-srcarg3 sudo_location:/usr/bin/sudo -targetnode ocidb1 -backupuser backup_user@example.com 
-rsp /u01/app/zdmhome/rhp/zdm/template/zdm_template_zdmsdb.rsp -tgtauth zdmauth 
-tgtarg1 user:opc -tgtarg2 identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk 
-tgtarg3 sudo_location:/usr/bin/sudo -eval

PRCG-1238 : failed to execute the Rapid Home Provisioning action for command  'migrate database'
PRCG-1022 : failed to connect to the Rapid Home Provisioning daemon for cluster anandutest
Failed to retrieve RMIServer stub: javax.naming.ServiceUnavailableException
[Root exception is java.rmi.ConnectException: Connection refused to host:
anandutest; nested exception is: java.net.ConnectException: Connection refused (Connection refused)]

解決策: $ZDM_HOME/bin/zdmservice STARTコマンドを使用してZero Downtime Migrationサービスを開始してから、任意のZDMCLIコマンドを実行します。

1.8.7.8 Oracle 12.1ソースからの全体エクスポートでのORA-01031

問題: Oracle Database 12c (12.1)ソース・データベースからエクスポート・データ・ポンプを使用して全体データベース・エクスポートを実行すると、次のエラーが発生します。

05-AUG-21 10:36:12.483: ORA-31693: Table data object "SYS"."TABLE" failed to load/unload and is being skipped due to error: ORA-01031: insufficient privileges

解決策: My Oracle SupportドキュメントEXPDP - ORA-31693 ORA-01031 (権限不足) 12cリリース1からのエクスポート時の一部の表 (ドキュメントID1676411.1)を参照してください

1.8.7.9 Data Transfer Medium COPYの問題

問題: Zero Downtime Migrationレスポンス・ファイルでDATA_TRANSFER_MEDIUM=COPYによって論理移行を使用してデータを移行すると失敗します。

解決策: DATA_TRANSFER_MEDIUM=COPYを指定する場合は、次のDUMPTRANSFERDETAILS_SOURCE_*パラメータも指定する必要があります。 

DUMPTRANSFERDETAILS_TRANSFERTARGET_DUMPDIRPATH=<Target path to transferthe dumps to >
DUMPTRANSFERDETAILS_TRANSFERTARGET_HOST=<Target Db server or Target sidetransfer node >
DUMPTRANSFERDETAILS_TRANSFERTARGET_USER=<user having write access to specified path>
DUMPTRANSFERDETAILS_TRANSFERTARGET_USERKEY=<user authentication keypath on zdm node>

1.8.7.10 MIGRATE DATABASEコマンドを再実行できない

問題: Zero Downtime Migrationブロックでは、データベースがすでに進行中の移行ジョブの一部である場合、指定されたデータベースに対してMIGRATE DATABASEコマンドの再実行が試行されます。

回避策: データベース移行を再発行する場合は、次のようにZDMCLI ABORT JOBコマンドを使用して、EXECUTINGまたはPAUSED状態の進行中の移行ジョブを停止できます。
-bash-4.2$ ./zdmcli abort job -jobid 70
server.example.com: Audit ID: 189

1.8.7.11 移行ジョブを再開できない

問題: Zero Downtime Migrationでは、ソースおよびターゲットのログ・ファイルが、それぞれのソースおよびターゲットのデータベース・サーバーの/tmp/zdm-unique idディレクトリに書き込まれます。

移行ジョブを一時停止してから、数日後(15～20日の場合もあります)にジョブを再開する場合、/tmp/zdm-unique idディレクトリがクリーン・アップまたはサーバー再起動の一環として削除またはパージされ、/tmpもクリーン・アップされることがあります。

解決策: 移行ジョブを一時停止した後、/tmp/zdm-unique idディレクトリをバックアップします。移行ジョブを再開する前に、/tmpディレクトリで/zdm-unique idを確認し、見つからない場合はディレクトリとその内容をバックアップとともにリストアします。

1.8.7.12 移行ジョブがZDM_GET_SRC_INFOで失敗します

問題: 移行ジョブが次のエラーで失敗します。 

[opc@zdm-server rhp]$ cat /home/opc/zdm_base/chkbase/scheduled/job-34-2021-01-23-14:10:32.log
zdm-server: 2021-01-23T14:10:32.155Z : Processing response file ...
zdm-server: 2021-01-23T14:10:32.262Z : Starting zero downtime migrate operation ...
PRCZ-4002 : failed to execute command "/bin/cp" using the privileged execution plugin "zdmauth" on nodes "PROD.compute-usconnectoneb95657.oraclecloud.internal"

解決策: oracleユーザーのパスフレーズなしでSSH接続を設定する必要があります。

1.8.7.13 ZDM_SWITCHOVER_SRCで移行ジョブが失敗

問題: 移行ジョブがZDM_SWITCHOVER_SRCフェーズで失敗します。

解決策:

  1. プライマリ・データベース・ノードからスタンバイ・データベース・ノードへの接続があることを確認し、REDOログが想定どおりに送信されるようにします。

  2. リカバリ・プロセス(MRP0)がターゲットで実行されていない場合、ジョブがZDM_SWITCHOVER_SRCで失敗します。MRP0がOracle Cloudデータベースのスタンバイ・インスタンスで実行されていない場合は、リカバリ・プロセスの失敗の理由を修正し、Oracle Cloudデータベースのスタンバイ・インスタンスでプロセスを手動で起動した後、移行ジョブを再開する必要があります。

1.9 Exadata Cloud Serviceへの移行に関する追加情報

Zero Downtime Migrationを使用したExadata Cloud Serviceへのデータベースの移行に関する一般情報、考慮事項、参照先のリンクは、次を一読してください。

1.9.1 Exadata Cloud Serviceへの移行のための考慮事項

Zero Downtime Migrationのこのリリースでは、次の考慮事項に注意してください。

  • ソース・データベースがリリース18cの場合、バグ29445548 - "ORA-600でクラウド環境でのデータベースのオープンに失敗"などの問題を回避するために、ターゲット・ホームはリリース18.6以降にする必要があります。
  • 構成されたインスタンスのいずれかが停止したときにバックアップが実行された場合は、バグ29863717 - "インスタンス1が停止したためソース・データベースの複製に失敗"が発生します。
  • TDEキーストア・パスワードは、資格証明ウォレットに設定する必要があります。Zero Downtime Migrationワークフローの一部としてパスワードを設定するには、ウォレットがAUTOLOGINまたはPASSWORDのどちらを使用するかに関係なく、-tdekeystorewallet tde_wallet_pathまたは-tdekeystorepasswd引数を指定します。どちらの場合も、パスワードは資格証明ウォレットに格納されます。-tdekeystorepasswd引数を指定しない場合、Zero Downtime Migrationでは資格証明ウォレット内のtde_ks_passwdキーの設定がスキップされ、エラーはスローされません。
  • ターゲット環境は、db_unique_name変更サポートがインストールされた最新のDBaaSツーリングRPMでインストールする必要があります。
  • 自動バックアップを有効にせずに、コンソールからターゲット・データベースをプロビジョニングします。「Configure database backups」セクションで、「Enable automatic backups」オプションを選択しないでください。

1.9.2 Exadata Cloud Serviceデータベースの登録

移行後、Exadata Cloud Serviceデータベースを登録し、すべての要件を満たしていることを確認します。

Exadata Cloud Serviceデータベース・サーバーでrootユーザーとして次のコマンドを実行します。

/root>dbaascli registerdb prereqs --dbname db_name --db_unique_name db_unique_name

/root>dbaascli registerdb begin  --dbname db_name --db_unique_name db_unique_name

たとえば

/root>dbaascli registerdb prereqs --dbname ZDM122 --db_unique_name ZDM122_phx16n
DBAAS CLI version 18.2.3.2.0
Executing command registerdb prereqs --db_unique_name ZDM122_phx16n
INFO: Logfile Location: /var/opt/oracle/log/ZDM122/registerdb/registerdb_2019-08-14_05:35:31.157978280334.log
INFO: Prereqs completed successfully
/root>

/root>dbaascli registerdb begin --dbname ZDM122 --db_unique_name ZDM122_phx16n
DBAAS CLI version 18.2.3.2.0
Executing command registerdb begin --db_unique_name ZDM122_phx16n
Logfile Location: /var/opt/oracle/log/ZDM122/registerdb/registerdb_2019-08-14_05:45:27.264851309165.log
Running prereqs
DBAAS CLI version 18.2.3.2.0
Executing command registerdb prereqs --db_unique_name ZDM122_phx16n
INFO: Logfile Location: /var/opt/oracle/log/ZDM122/registerdb/registerdb_2019-08-14_05:45:29.000432309894.log
INFO: Prereqs completed successfully
Prereqs completed
Running OCDE .. will take time ..
OCDE Completed successfully.
INFO: Database ZDM122 registered as Cloud database
/root>

1.9.3 Exadata Cloud Serviceの自動バックアップの問題

コンソールから自動バックアップを有効にする前に、バックアップ構成を確認します。次の最初のステップに示すように、get configコマンドを使用できます。自動バックアップを有効にする前は、bkup_oss=noが表示されます。

コンソールに次のエラー・メッセージが表示される場合があります: A backup configuration exists for this database.You must remove the existing configuration to use Oracle Cloud Infrastructure's managed backup feature.

このエラーを修正するには、既存の構成を削除します。

まず、UIから自動バックアップが無効になっていることを確認し、次のステップに従って既存のバックアップ構成を削除します。

  1. バックアップ構成ファイルを生成します。
    /var/opt/oracle/bkup_api/bkup_api get config --file=/tmp/db_name.bk --dbname=db_name

    たとえば:

    /var/opt/oracle/bkup_api/bkup_api get config --file=/tmp/zdmdb.bk --dbname=zdmdb
  2. 前のステップで作成した/tmp/db_name.bkファイルを開きます。

    たとえば、/tmp/zdmdb.bkを開きます。

    bkup_oss=yesをbkup_oss=noから変更します。

  3. bkup_oss=noを設定してOSSバックアップを無効にします。
    /var/opt/oracle/bkup_api/bkup_api set config --file=/tmp/db_name.bk --dbname=db_name

    たとえば:

    /var/opt/oracle/bkup_api/bkup_api set config --file=/tmp/zdmdb.bk --dbname=zdmdb
  4. 再構成ステータスを確認します。
    /var/opt/oracle/bkup_api/bkup_api configure_status --dbname=db_name

    たとえば:

    /var/opt/oracle/bkup_api/bkup_api configure_status --dbname=zdmdb

ここで、コンソールからの自動バックアップを有効にします。

コンソールからバックアップを確認します。「Create Backup」をクリックして手動バックアップを作成すると、問題なくバックアップが作成され、自動バックアップも成功します。

1.10 Exadata Cloud at Customerへの移行に関する追加情報

Zero Downtime Migrationを使用したExadata Cloud at Customerへのデータベースの移行に関する一般情報、考慮事項、参照先のリンクは、次を一読してください。

1.10.1 Exadata Cloud at Customerへの移行に関する考慮事項

Zero Downtime Migrationのこのリリースでは、次の考慮事項に注意してください。

  • すべてのExadata Cloud at Customerノードで、バグ29715950 - "db_nameと異なるdb_unique_nameを処理するようにregdbを変更する"のためのregDBパッチを適用する必要があります。これは、ZDM_MANIFEST_TO_CLOUDフェーズに必要です。regDBツールは、DBaaSツーリングの一部であることに注意してください。
  • ソース・データベースがリリース18cの場合、バグ29445548 - "ORA-600でクラウド環境でのデータベースのオープンに失敗"などの問題を回避するために、ターゲット・ホームはリリース18.6以降にする必要があります。
  • -listphasesでPDB変換関連のフェーズがリストされますが、無視してもかまいません。これらは操作なしフェーズです。
  • バックアップ媒体がZero Data Loss Recovery Applianceの場合、すべての構成済インスタンスは、FULLまたはINCREMENTALバックアップが実行されるときにソースで稼働している必要があります。
  • 構成されたインスタンスのいずれかが停止したときにバックアップが実行された場合は、バグ29863717 - "インスタンス1が停止したためソース・データベースの複製に失敗"が発生します。
  • TDEキーストア・パスワードは、資格証明ウォレットに設定する必要があります。Zero Downtime Migrationワークフローの一部としてパスワードを設定するには、ウォレットがAUTOLOGINまたはPASSWORDのどちらを使用するかに関係なく、-tdekeystorewallet tde_wallet_pathまたは-tdekeystorepasswd引数を指定します。どちらの場合も、パスワードは資格証明ウォレットに格納されます。-tdekeystorepasswd引数を指定しない場合、Zero Downtime Migrationでは資格証明ウォレット内のtde_ks_passwdキーの設定がスキップされ、エラーはスローされません。
  • ターゲット環境は、db_unique_name変更サポートがインストールされた最新のDBaaSツーリングRPMでインストールする必要があります。

1.11 ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWeb サイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

サポートをご購入のOracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。