Zero Downtime Migrationリリース・ノート

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

このリリースの新機能

Zero Downtime Migrationリリース21c (21.2)の新機能は、次のとおりです。

  • 物理移行での直接データ転送のサポート

    物理移行の間に直接データ転送を使用してデータベースを移行できます。それにより、ソース・データベースをオブジェクト・ストレージやNFSなどの中間ストアにバックアップする必要がなくなります。Recovery Manager (RMAN)により、Zero Downtime Migrationでデータベースをアクティブに複製することやサービスからリストアすることができるようになります。

    直接データ転送のサポート

  • 移行ソースとしての既存のRMANバックアップの再利用

    既存のレベル0バックアップを使用して、移行ジョブの全体バックアップ・フェーズをスキップできます。Zero Downtime Migrationでは、オンラインおよびオフラインの両方の物理移行ジョブについて、レベル0およびレベル1のバックアップをオンザフライで取得します。Zero Downtime Migrationでは、全体バックアップを実行するのではなく、ソース・データベースの既存のバックアップを再利用できるようになりました。

    既存のRMANバックアップを使用した移行ジョブの実行

  • CPATでの処置の一覧表示および処置スクリプトの作成

    クラウド移行前アドバイザ・ツール(CPAT)は、Zero Downtime Migrationと統合されており、論理移行ジョブで使用できます。CPATでは、選択した場合に実行可能な、チェックの失敗に対する移行是正スクリプトを生成できます。

    クラウド移行前アドバイザ・ツールの使用

  • Zero Downtime MigrationホームでのCPAT更新の実行

    クラウド移行前アドバイザ・ツール(CPAT)を最新の状態に保ち最新のツール・バージョンを取得します。

    クラウド移行前アドバイザ・ツールの更新

  • Amazon Web Services RDSからOracle Autonomous Databaseへの移行

    Zero Downtime Migrationのオフライン論理移行方式を使用してOracle DatabaseをAmazon Web Services (AWS) RDSからOracle Autonomous Database (ADB)に移行できるようになりました。AWSからデータを転送するには、Amazon Simple Storage Service (Amazon S3)バケットまたはデータベース・リンク(DBLINK)を使用します。

    Amazon Web Services RDSからOracle Autonomous Databaseへの移行

  • Exadata Cloud@Customer上のOracle Autonomous Databaseへの移行

    Zero Downtime Migrationでは、オフライン論理移行方式で、NFSをデータ転送媒体として使用して、オンプレミスのOracle DatabaseからExadata Cloud@Customer上(既存のExadata Cloud@Customerシステムも含む)のOracle Autonomous Databaseに移行する機能がサポートされています。

    Exadata Cloud@Customer上のOracle Autonomous Databaseへの移行

  • IBM AIXおよびOracle Solarisが含まれたプラットフォーム・サポート

    Zero Downtime Migrationでは、Linux x86-64に加え、論理オフライン移行モードでIBM AIXおよびOracle Solarisソース環境がサポートされるようになりました。

    サポートされているプラットフォーム

  • STATISTICSメソッドによるデータ・ポンプのダンプ・サイズの推定

    論理移行では、Zero Downtime Migrationにより、デフォルトで、事前チェックの一部として、およびフェーズZDM_DATAPUMP_ESTIMATE_SRCの実際の移行部分の一部として、BLOCKSメソッドを使用してデータ・ポンプのダンプ・サイズの推定が実行されます。新しいレスポンス・ファイル・パラメータDATAPUMPSETTINGS_DATAPUMPPARAMETERS_ESTIMATEBYSTATISTICSを使用すると、STATISTICSメソッドを選択して推定ダンプ・サイズを取得できます。

    DATAPUMPSETTINGS_DATAPUMPPARAMETERS_ESTIMATEBYSTATISTICS

  • 表領域の自動作成または再マップ

    論理移行の場合、Zero Downtime Migrationでは、移行するユーザー・スキーマに関連付けられたソース・データベース表領域を自動的に検出し、それらをデータ・ポンプのインポート・フェーズの前にターゲット・データベースに自動的に作成できます。

    重要な利点は、ターゲット上にBIGFILE表領域を作成でき、それにより、データベースのデータ・ファイル数を大幅に削減できるということです。AUTOEXTENDを有効にし、NEXT EXTENTサイズを指定することもできます。また、指定した表領域を自動作成から除外できます。

    さらに、自動再マップを有効にした場合は、ターゲット上に表領域を事前作成するのではなく、Zero Downtime Migrationにより、再マップする必要があるソース表領域が検出されます。

    自動表領域作成および自動表領域再マップ

  • 移行カスタマイズの拡張機能

    ユーザー処理スクリプトをローカルで編集することや、ユーザー処理メタデータ内のスクリプトを更新することができます。スクリプトのローカル・コピーがない場合に、ZDMCLIコマンドquery useractionを使用してユーザー処理メタデータ内のキャッシュされたユーザー処理スクリプトを検索できるようになりました。そのスクリプトへのフル・ベース・パスが出力に表示されます。

    ユーザー処理スクリプトの変更

    簡単に1つ以上のユーザー処理からデータを取得し、そのデータを使用して別のユーザー処理を実行できるようになりました。たとえば、ソース・データベースで処理を実行し、そのデータを使用してターゲット・データベースで処理を実行できます。

    ユーザー処理でのユーザー処理出力の使用

修正された不具合

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

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

バグ番号 説明
32749606 ZDMでの物理移行がPRGZ-3553キャラクタ・セットの不一致で断続的に失敗する
33013588 ZDM: CDB以外からCDBへの変換に失敗する - PRGO-1930およびPRCZ-2103
32808775 単一インスタンスのデータベースがソースの場合のCDB以外からPDBへの変換があるZDM物理移行の問題
33123365 ソースのSPFILEの内容でDB_DOMAINが上書きされる
32767162 ZDM: ターゲットがVMDBでバックアップ媒体がNFSの場合にCDB以外からCDBへの移行に失敗する
31507335 ZDM: オフライン論理移行 - 中断によって作成済データベース・リンクが消去される必要がある
32100209 ZDM : エクスポート・ディレクトリがASM内にある場合にエクスポート・フェーズが失敗する
32960299 ZDMにおいてSVCで優先されるインスタンス属性が正しくマップされない
32447725 ZDM : ZDMのジョブが中断されてもエクスポート・ジョブやインポート・ジョブが中断されない
32833720 Standard Editionのソース・データベースの場合に論理移行ワークフローが失敗する
33048353 ユーザーが同一ディスク・グループ内でパスワード・ファイルを移動またはコピーしようとしたというエラーASMCMD-9459がZDMで発生する
33032852 ZDM: 資格証明が存在しないことが原因でZDMのユーティリティでコアダンプ・エラーが報告される
32464487 ZDM: OSS統合ユーザー・アカウントがZDMでのソース検証に失敗する
32689878 19.7から21.1へのアップグレード後にZDMサービス・ノードを起動できない -> CRS_ERROR:TCC-0004: THE CONTAINER WAS NOT ABLE TO START.
32886747 論理移行: 長時間実行中のトランザクションはスイッチオーバー・フェーズの間にZDMで検出されない

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

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

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

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

一般情報

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

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

クラウド移行前アドバイザ・ツール(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ソースに対する修正スクリプトの生成

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

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

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

エディション間の移行

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

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

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

既知の問題

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

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

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

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

PRGZ-1306 グリッド・インフラストラクチャが構成されていない単一インスタンス・データベースからの物理移行中にスローされる

問題: -sourcesidパラメータを使用してグリッド・インフラストラクチャが構成されていない単一インスタンス・データベースを移行しようとすると、移行ジョブはエラーPRGZ-1306で失敗します。

解決策: これは、バグ33308423で追跡されている問題です。回避策として、-sourcesidオプションを-sourcedbオプションに置き換えて移行コマンドを再実行します。それ以外の場合は、バグが修正されてZero Downtime Migrationサーバー・ホームに適用されるまで、GIが構成されていない単一のインスタンス・データベースで物理移行を実行しないでください。

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)を参照してください

ソースで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

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

Amazon S3からAutonomous Database Dedicated Infrastructureへのダンプ・インポートでのORA-17503

問題: Amazon S3バケットからOracle Autonomous Database Dedicated Infrastructure (ADB-D)ターゲットにデータ・ポンプのダンプ・ファイルをインポートしようとしたときに、ADB-Dでエラーが発生します。

ADB-Dのアラート・ログには、次のようなエラーが示されます。

ORA-39000: bad dump file specification
ORA-31640: unable to open dump file
"https://s3-region.amazonaws.com/dump_file_path.dmp
for read
ORA-17503: target Failed to open file
https://s3-region.amazonaws.com/dump_file_path.dmp
ORA-17500: ODM err:ODM Client Error

解決策: Zero Downtime Migrationでデータベース・リンクのデータ転送媒体を使用して、データ・ポンプのダンプをADB-Dターゲットにインポートします。 

DATA_TRANSFER_MEDIUM=DBLINK
SOURCEDATABASE_ENVIRONMENT_NAME=AMAZON
SOURCEDATABASE_ENVIRONMENT_DBTYPE=RDS_ORACLE

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上にないようにすることで、この問題を回避できます。

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

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

ORA-39006: internal error

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

アップグレード後に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.

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

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のパッチが含まれていることを確認します。

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)を参照してください

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>

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

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

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

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

ln -sf <installed_location_of_the_cut> /bin/cut

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プロパティが最新であることを確認します。

トラブルシューティング

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

接続の問題

一般的な接続の問題

問題: 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アドレスおよび秘密キーの属性を参照します。

通信リンクの障害

問題: 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

フェーズ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アドレスとして割り当てられているために解決できないことがあるため、発生する可能性があります。

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

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形式を使用します。

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

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

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ドキュメントの透過的データ暗号化ウォレットの設定を参照してください。

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

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

「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を使用してソース・データベースを起動し、移行ジョブを再送信します。

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を使用してターゲット・データベースを起動し、移行ジョブを再開します。

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

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

ソース・データベースのリリースによっては、透過的データ暗号化(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)を参照してください。

フェーズ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)))

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

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

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

コンソールを使用して、「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>

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. 自動バックアップを再試行します。

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

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

その他の問題

インストール時に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:
...

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

フェーズ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

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

移行ジョブが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接続を設定する必要があります。

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-----

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

移行評価がエラー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コマンドを実行します。

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

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

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

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

ZDM_SWITCHOVER_SRCで移行ジョブが失敗

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

解決策:

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

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

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

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

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」オプションを選択しないでください。

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>

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」をクリックして手動バックアップを作成すると、問題なくバックアップが作成され、自動バックアップも成功します。

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

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

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でインストールする必要があります。

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

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を参照してください。