Zero Downtime Migrationリリース・ノート

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

このリリースの新機能

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

  • Oracle Data PumpとZero Downtime Migrationの統合が、Autonomous Databaseへの移行をサポートします

  • Oracle GoldenGateとZero Downtime Migrationの統合が、論理移行をサポートします

  • Zero Downtime Migrationが、オンライン・モードとオフライン・モードの両方で論理移行を実行できます

  • Zero Downtime Migrationが、データベース・リンクを介した移行をサポートします

  • Zero Downtime Migrationが、Oracle Cloud上のマルチテナント・アーキテクチャへの移行のために非マルチテナント・アーキテクチャ(非CDB)のソース・データベースを自動的に変換できます

  • 移行前アドバイザ・ツールがZero Downtime Migrationと統合され、移行ジョブの検証を提供します

  • Zero Downtime Migrationのホーム・フットプリントが減少します

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の動作について、留意する必要がある詳細および考慮事項がいくつかあります。

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

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

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

クロス・エディションの移行はサポートされていません

Zero Downtime Migrationは、Enterprise EditionのデータベースからStandard Editionのデータベースへの移行には使用できません。その逆も同様です。

既知の問題

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

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 Database専用インフラストラクチャ・ターゲットに移行しようとすると、移行ジョブがエラーORA-39006で失敗します。

ORA-39006: internal error

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

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

トラブルシューティング

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

接続の問題

一般的な接続の問題

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