1.1 Zero Downtime Migration 21.5リリース・ノート
このリリース・ノートでは、最新の製品ソフトウェアおよびドキュメントのダウンロード方法を示し、Zero Downtime Migrationリリース21c (21.5)の新機能、修正されたバグ、既知の問題およびトラブルシューティング情報について説明します。
1.2 このリリースの新機能
Zero Downtime Migrationリリース21.5では、次の拡張機能により、21cの既存の機能が改善されています。
- ハイブリッド移行の導入
ZDMでは、RMANによるトランスポータブル表領域およびデータポンプ・メタデータのインポート/エクスポートを使用した、クロス・プラットフォームおよびクロス・バージョンの移行のサポートが導入されています。このワークフローは、オフライン移行の場合のみサポートされています。「Zero Downtime Migrationを使用したハイブリッド移行」、「ハイブリッド・データベース移行の準備」および「Zero Downtime Migrationハイブリッド移行レスポンス・ファイル・パラメータのリファレンス」を参照してください。
- ZDMによりTEMP表領域が自動的に再マップされる
ZDMにより、ソース・データベースにある一時表領域が、ターゲット・データベースにある指定した一時表領域に自動的に再マップされます。この機能は、表領域の作成を許可しないADBサーバーレスが対象となります。通常のデータベースに移行する場合は一時表領域を統合する必要があります。詳細は、TABLESPACEDETAILS_REMAPTEMPTARGETパラメータを参照してください。
- カスタム・ポート番号のための新しいオプション
ZDMインストーラに、カスタム・ポート番号を定義するための2つの新しいオプションがあります。
- ソース・データベースのプロファイル・ファイルのサポート
特定のユースケース用にプロファイル・レスポンス・ファイルを定義するための新しいオプション。新しい論理移行レスポンス・ファイル・パラメータにより、プロファイル・ファイルのフルパスを指定します。PROFILEパラメータを参照してください。
- FLASHBACK_ONパラメータのサポート
お客様が移行後フェーズの間にターゲット・データベースに対してフラッシュバックを有効または無効にできるようにする、新しいレスポンス・ファイル・パラメータ。詳細は、FLASHBACK_ONパラメータを参照してください。
- DATAPUMPSETTINGS_RETAINDUMPSパラメータのサポート
選択したデータ転送メディア内のダンプ・ファイルを消去するか残すかをZDMに示す新しいレスポンス・ファイル・パラメータ。オフライン論理移行の場合に、ZDMで、前のジョブからのダンプ・ファイルを再利用するためにダンプ接頭辞を指定できるようになりました。ターゲット・ステージにあるダンプ・ファイルを保持するには
DATAPUMPSETTINGS_RETAINDUMPS=TRUEを指定し、対応するダンプ接頭辞DATAPUMPSETTINGS_REUSE_DUMPPREFIX= ZDM_<jobID>_DP_EXPORT_<#>_dmpを指定します詳細は、DATAPUMPSETTINGS_RETAINDUMPSパラメータを参照してください。 - DATAPUMPSETTINGS_REUSE_DUMPPREFIXパラメータのサポート
この新しいレスポンス・ファイル・パラメータにより、お客様が既存のダンプ・ファイルのダンプ接頭辞を指定できます。ZDMにより、移行のために、指定されたダンプ・ファイルが再利用されます。詳細は、DATAPUMPSETTINGS_REUSE_DUMPPREFIXパラメータを参照してください。
- GOLDENGATESETTINGS_REPLICATIONMODEパラメータのサポート
Oracle GoldenGateを非統合モードで使用するか統合モードで使用するかを指定できる新しいレスポンス・ファイル・パラメータ。この変更により、ユーザーがプロシージャ・レプリケーションを使用して統合モードでデータベースを移行できるようになります。それにより、インポート後に、PLSQLのサポート対象オブジェクトをリロードする必要がなくなります。詳細は、GOLDENGATESETTINGS_REPLICATIONMODEパラメータを参照してください。
- GOLDENGATESETTINGS_RELOADUNREPLICATEDOBJECTS=TRUEの場合に監査証跡がインポートされる
GOLDENGATESETTINGS_RELOADUNREPLICATEDOBJECTS=TRUEに設定した場合は、論理オンライン移行の一部として、ZDM_RELOAD_PARALLEL_EXPORT_IMPORTリロード・フェーズの間に監査証跡もインポートされます。
- GOLDENGATESETTINGS_RELOADAQOBJECTSパラメータのサポート
この新しい論理移行レスポンス・ファイル・パラメータを使用すると、ユーザーが、インポート後にAQオブジェクトをリロードする必要があるかどうかを指定できます。詳細は、GOLDENGATESETTINGS_RELOADAQOBJECTSパラメータを参照してください。
- それぞれのPDB名を渡すためにユーザーアクション・スクリプトにZDM_SRCDBPDBおよびZDM_TGTDBPDB引数が追加された
ZDM_SRCおよびTGTDBPDB引数には、ソース・データベースとターゲット・データベースのPDB名があります。それらは、引数としてユーザーアクション・スクリプトに渡されます。
- ユーザーアクション・スクリプトの実行のためにデータベースに接続する際に、デフォルトでHIGHサービスに接続するのではなく、ユーザーが指定したサービスが使用されるようになった
ユーザーアクション・スクリプトにコメントを追加します。ユーザーアクション・スクリプトに、先頭に
--USERACTION_SERVICE=<service_name>(HIGH、LOW、TPなど)という接頭辞を付けてコメントを含めることができます。ZDMは、そのサービスに接続してから、そのユーザーアクションを実行します。 - バックアップ・リストアおよびサービスからのリストアの移行方法を使用する移行ではデータベース19c以上の場合はsystem、sysaux、undoおよびtemp表領域がZDMによって暗号化される
クラウドでの実行時は、表領域を暗号化することをお薦めします。21.5以降では、クラウドへの移行時に、ZDMによって、system表領域などのすべての表領域が暗号化されます。
- Oracle Cloudネイティブの障害時リカバリ計画の作成
ZDMで、ターゲット・レベルでのData Guard構成の設定がサポートされるようになり、障害時リカバリ・アーキテクチャが拡張されました。ZDMでは、クラウド・ネイティブのData Guard構成を使用した障害時リカバリ移行(物理)がサポートされています(移行後もコンソール・ツールは引き続き機能します)。移行が完了すると、2つのデータベース(プライマリとスタンバイ)が、Data Guardによって構成され保守されるようになります。この構成では、複数リージョンがサポートされています。許可されている移行方法としては、OSS、DIRECTおよびZDLRAがあります。詳細は、「Oracle Cloudネイティブの障害時リカバリ計画の作成」を参照してください。
- GOLDENGATESETTINGS_REPLICAT_SPLITTRANSRECSパラメータのサポート
大きなトランザクションを複数の有意義な部分に分割できるようになりました。各部分は、個々のOracle GoldenGateアプライヤによって並列で適用されます。そのため、Oracle GoldenGateによって大きなトランザクションをより迅速に処理できます。分割トランザクションと他のトランザクションの間の依存関係が考慮されます。この新しいレスポンス・ファイル・パラメータでは、分割する大きなトランザクションの個々の部分のサイズを指定します。デフォルト・サイズは100000バイトです。詳細は、GOLDENGATESETTINGS_REPLICAT_SPLITTRANSRECSパラメータを参照してください。
- GOLDENGATESETTINGS_FEATUREGROUPパラメータのサポート
プロシージャ・レプリケーションのための特定の機能グループをユーザーが選択できるようにする新しい論理移行レスポンス・ファイル・パラメータ。詳細は、GOLDENGATESETTINGS_FEATUREGROUPパラメータを参照してください。
- ZDM_ADVANCE_SEQUENCES論理移行フェーズ
オンライン論理移行の場合は、ZDMにより、スイッチオーバーでのブラウンアウトの間に、ソース・データベースでの順序値と一致するように、ターゲット・データベースでの順序値が進められます。
- データ転送メディアとしてファイル・システムを使用するAutonomous Databaseへの移行
ZDMでの移行のためのデータ転送メディアとしてOracle Cloud File Storage Service (FSS)を利用します。ZDMにより、Autonomousターゲット・データベースでFSSが自動マウントされます。データをVirtual Cloud Network (VCN)内のOracle Cloud Infrastructure File Storageから、またはFastConnectおよびサイト間VPNを介してオンプレミス・データ・センター内の他のネットワーク・ファイル・システムからロードできます。
詳細は、転送メディアとしてファイル・ストレージを使用したAutonomous Databaseサーバーへの移行を参照してください。
- REFRESHMVIEWSパラメータおよびZDM_REFRESH_MVIEWフェーズ
論理移行の場合、マテリアライズド・ビューは、インポート後にリフレッシュされます。このリフレッシュは、ZDM_REFRESH_MVIEW_TGTフェーズの一部として実行されます。REFRESHMVIEWSをTRUEに設定すると、ZDM_REFRESH_MVIEWフェーズが有効になり、移行後にマテリアライズド・ビューがリフレッシュされます。このパラメータをFALSEに設定した場合は、マテリアライズド・ビューはリフレッシュされません。REFRESHMVIEWSを参照してください。
- ユーザー・アクション・スクリプトの更新
ユーザー・アクションの実行のために使用するサービスを指定できるようになりました。Autonomous Databaseの場合は、ユーザーアクションとしてのSQLスクリプトのみがサポートされています。ZDMでは、ユーザーアクションの実行前にデータベースへの接続が確立されます。指定したサービスは、その接続を作成するために使用されます。サービスを指定しなかった場合は、ZDMにより、このレスポンス・ファイル・パラメータで指定されているデフォルト・サービスに接続されます。Autonomous Database以外の場合は、シェル・スクリプトを使用して、必要なサービスに接続し、SQL接続の問合せを実行できます。「ユーザー・アクション・スクリプト」を参照してください。
- 同時Autonomous Database移行
ZDMで、別々のAutonomous Database用に別々のウォレット・パスを指定できるようになりました。これにより、単一のOracle GoldenGateデプロイメントで複数のOracle Autonomous Databaseに同時にレプリケートできます。詳細は、「追加の論理移行の前提条件」を参照してください。
- 物理移行の場合の表領域レベルの暗号化
21.5以降では、ZDMにより、物理移行において、Oracle Database 19c以降のリリース場合にsystem、sysaux、undoおよびtemp表領域が暗号化されます。バックアップ/リストア含む移行、またはサービスからのリストアを使用した直接移行で、TDEが必須である場合は、ZDMにより、すべての表領域の暗号化が開始されます。「透過的データ暗号化キーストアの設定」を参照してください。
- Oracle GoldenGate Replicat用の新しいオプション
DBOPTIONS DEFERREFCONSTこのオプションにより、制約の処理が最適化されます。そのため、これはOracle GoldenGate Replicatの一部になりました。
DBOPTIONS DEFERREFCONSTオプションは、Oracle GoldenGate Replicatの非統合パラレルReplicatに対してデフォルトで設定されます。パラレル統合モードを選択しない場合は、ZDMにより、必ずこのReplicatパラメータが設定されます。「GOLDENGATESETTINGS_REPLICATIONMODE」および「論理移行パラメータの設定」を参照してください。 - 単一のOracle GoldenGate Microserviceを使用した同時移行がZDMでサポートされている
複数の移行ターゲットで、同じOracle GoldenGateデプロイメント・リンクを使用できるようになりました。これを行うには、Oracle GoldenGateデプロイメント・ディレクトリ内のウォレット・パスを
Wallet_<adb>に更新します。以前は、<deployment_dir>/etcの場所には1つのディレクトリ'adb'がありました。しかしながら、現在は、レプリケーションにOracle GoldenGate Microserviceを使用する各データベースに対して、ウォレット保管用の個別のディレクトリ(<deployment_dir>/etcディレクトリ内のWallet_<dbname>)を用意できます。 - 自動修正を実行するためのRUNFIXUPS
ZDMで、チェックに不合格になる原因の、限られた数の問題に対して、修正を生成し実行できるようになりました。論理移行の場合は、ZDMで、自動修正を実行するオプションを使用できます。この新しい論理移行レスポンス・ファイル・パラメータを使用して、ターゲット・データベース・ホストで自動修正を実行します。修正とは、ソース・データベースの移行前チェックのいくつかについて失敗を解決するのに役立つSQLスクリプトです。詳細は、RUNFIXUPSパラメータを参照してください。
- GGADMIN権限チェックが改善された
オンライン論理移行の場合のユーザビリティの向上: ZDMの事前チェックにより、ターゲット・データベースでOracle GoldenGate管理者の権限が不足していることがユーザーに通知されます。ユーザーは、レプリケーション・エラーを回避するために、示された不足している権限をターゲット・データベースでのOracle GoldenGate管理者に付与できます。
- デフォルトのggadminとは異なるGoldenGateスキーマ名のサポート
ZDMで、ソース・データベースとターゲット・データベースのデフォルトの
ggadminとは異なる名前を使用したGoldenGateスキーマがサポートされるようになりました。別の名前を指定した場合は、ZDMにより、ZDM_VALIDATE_GG_HUBフェーズの間にGLOBALSファイルが自動的に更新されます。ソースのOracle GoldenGate管理ユーザー名がターゲットと異なる場合は、ZDMで、移行にソースOracle GoldenGate管理スキーマが含まれます。「追加の論理移行の前提条件」を参照してください。 - CDBソース・データベースの物理移行とアップグレードのサポート
ZDMでは、EXACS/EXACCターゲット環境の場合とEXACS/EXACC以外のターゲット環境の場合のCDBの移行とアップグレードが、それぞれ
dbaascliおよび自動アップグレードを使用してサポートされています。アップグレードは、移行の完了後に開始されます。ターゲット・ノードで、バージョンをアップグレードするデータベース・ホームをプロビジョニングし、レスポンス・ファイル・プロパティZDM_UPGRADE_TARGET_HOMEで、プロビジョニングしたホーム・パスを指定します。「CDBデータベースの移行とアップグレード」を参照してください。 - ZDMでの非CDBデータベースの移行、アップグレードおよびマルチテナント変換のサポート
ZDMで、非CDBソース・データベースの移行、アップグレードおよびマルチテナント変換がサポートされるようになりました。ZDMにより、非CDB補助データベースへの移行が実行され、自動アップグレード・ユーティリティが使用された後、接続と切断の操作によってマルチテナントへの変換が実行されます。詳細は、「非CDBからPDBデータベースへの移行、アップグレードおよび変換」を参照してください。ソースと同じバージョンの他のホームが必要な場合は、ターゲットにすでにそれがあれば、新しいホームをプロビジョニングする必要なくそれを使用できます。
- ZDMでソース・データベースとしてAutonomous Databasesがサポートされるようになった
ZDMでは、ADB (ADB-S/ADB-D)ソースからの論理移行がサポートされています。既存のSOURCEDATABASE_CONNECTIONDETAILSプロパティを使用してADB接続詳細を指定するか、新しいパラメータSOURCEDATABASE_OCIDを使用することができます。SOURCEDATABASE_ENVIRONMENT_DBTYPEの値はADB-S/ADB-Dである必要があります。ノート: ターゲットとして有効なのはAutonomous Databaseのみです。
- 物理移行の場合の新しいパラメータZDMでの物理移行の場合に、次のパラメータを使用してウォレットを指定することもできるようになりました:
- Oracle Cloud InfrastructureインスタンスのRed Hat Enterprise Linux 9へのZero Downtime Migrationのインストール
Red Hat Enterprise Linux 9へのZero Downtime Migrationの移行で使用可能な手順を参照してください。
- Oracle Database 23aiの場合のZero Downtime MigrationでのOracle Exadata Database Service on Dedicated Infrastructure、Oracle Exadata Database Service on Cloud@Customer、Oracle Base Database Service (仮想マシンおよびベア・メタル)のサポート (ターゲット・データベースの場合のみサポート対象)
詳細は、「移行でサポートされているデータベース・バージョン」を参照してください。
- 論理移行の場合のsudoasuser認証プラグインの使用
sudoasuser認証プラグインを使用してsudoユーザーとしてホストに接続しスーパーユーザー権限なしでソースおよびターゲット・データベース・ノードでのアクションをすべて実行して、データベースをソースからターゲットに移行できます。この移行ではrootアクセスの必要がなくなります。詳細は、「SUDOユーザー権限による移行」を参照してください。 - RELOADOBJECTSパラメータでのワイルドカード式の使用が許可されている
詳細は、「RELOADOBJECTS-LIST_ELEMENT_NUMBER」および「移行するオブジェクトの選択」を参照してください。
- オンライン論理移行の場合にzdmcli問合せジョブでOracle GoldenGateレプリケーション・メトリックがレポートされるようになった
詳細は、「query job」を参照してください。
1.3 修正された不具合
Zero Downtime Migrationリリース21.5では、次の表で示しているバグ修正が導入されています。
表 - Zero Downtime Migrationリリース21.5での修正されたバグ
| バグ番号 | 説明 |
|---|---|
| 35239994 | ZDM: OMF形式以外の制御ファイルのリストア |
| 35483295 | ZDM: TNS_ADMINパラメータが原因でDSTアップグレードに失敗する |
| 35616936 | MZDM_CONVERT_NONCDB2PDB.PLの実行中にORA-28374エラーが発生する |
| 35688382 | ZDM - AWSからの移行- COPYFILESフェーズで失敗する |
| 35721877 | ORA-01619 ZDM_CLONE_TGTフェーズでエラーが発生する |
| 35680161 | ZDM_APPLY_LAG_MONITORING_INTERVALをDAILYにするとスイッチオーバー・ジョブが1日後にスケジュールされる |
| 35816145 | OC2レルムでのADBへのZDMデータ・ポンプ移行が失敗する |
| 35744878 | CPAT - ADBC@Cへの移行中にCPAT警告が発生する |
| 35931123 | ZDMによるINITパラメータの変更によってData Guard構成の問題が発生する |
| 35849014 | ZDM: 非CDBからCDBへの物理移行チェック - 評価 |
| 35300079 | ZDM: NONCDB_TO_PDB.SQLスクリプトの実行のステータスを確認する必要がある |
| 35552928 | ZDM: フラッシュバックの無効化 |
| 34069672 | ZDM: Standard Editionのデータベースの場合はDMSでダンプ暗号化なしが適用される |
| 35893947 | ZDM_CLONE_TGTフェーズの間にエラーORA-01127が発生してZDMが失敗する |
| 35801705 | ZDM - DB物理移行、LOG_ARCHIVE_DEST_1および10がターゲットEXAC DBで適切に設定される |
| 35816117 | ZDM: DGのクリーン・アップに関する問題 |
| 35721877 | ORA-01619 ZDM_CLONE_TGTフェーズでエラーが発生する |
| 35717895 | PL21.5ZDM: SOLARIS /AIX.PPC64 : 11204 RACデータベースのZDM_VALIDATE_SRCエラー:PRGD-1070 : コンテナ・ビューV$CONTAINERSからコンテナ数を取得する問合せが失敗する |
| 35340742 | ユーザー・アクションをサポートしていないフェーズZDM_PREPARE_SWITCHOVER_APPの場合にユーザー・アクションが指定される |
| 34707257 | ZDM: ORA-01144: ファイル・サイズ(12582400ブロック)が最大値4194303ブロックを超えている |
| 35181477 | PDB変換において警告メッセージでサービス名競合が示される |
| 35900871 | ZDM:PRCZ-2135 : SFTPでファイル属性の取得に失敗する - ZDM_COPYFILES - ZDLRA.ZIP - ZDLRA |
| 35920799 | データベース・サーバー名が大文字の場合にZDMでの検出に失敗する |
| 36383322 | 初期パラメータがソースDBから持ち越されない |
| 36346251 | エラーORA-27211が発生してZDMでの移行に失敗する |
| 36508136 | ZDM_ADVANCE_SEQUENCESがPRGD-1000(数値オーバーフロー)で失敗する |
| 36597616 | 分離モードでPDBのファイル・ベース・ウォレットがZDMによって正しくコピーされない |
| 36497386 | 物理移行の間にターゲットでのCLUSTER_INTERCONNECTSパラメータが保持されない |
| 36622632 | OKVエンドポイント共有のサポート |
| 36731870 | EXCLUDEOBJECTSがフェーズRELOAD OBJECTSに影響する。ORA-0942が発生して一時表が作成されない |
1.4 Zero Downtime Migrationのインストール・ソフトウェアのダウンロード
最新のZero Downtime Migrationソフトウェア・バージョンを新規インストールする場合は、https://www.oracle.com/database/technologies/rac/zdm-downloads.htmlにアクセスします。
1.5 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.pref1.6.2 エディション間の移行
Zero Downtime Migrationは、Enterprise EditionのデータベースからStandard Editionのデータベースへの移行には使用できません。逆の場合は、物理オンライン移行の方法を除き、Standard EditionのデータベースをEnterprise Editionのデータベースに移行できます。データポンプ・ベースの移行の場合、データポンプ・ダンプは暗号化されてエクスポートされません。
1.6.3 EXT3ファイル・システムのサポート
Zero Downtime MigrationをEXT3ファイル・システムにインストールできないという既知の問題があります。根本的な原因は、MySQLの不具合102384です。これは、Zero Downtime Migrationの制限事項ではなく、MySQLによる制約です。その不具合が解決されれば、Zero Downtime MigrationがEXT3ファイル・システムで機能することになります。
1.7.1 リストア時に暗号化を伴う移行の既知の問題
問題: Oracle Database 19c以降の場合、リストア時(サービスからのリストア、バックアップまたはリストアなど)の暗号化を伴う移行の場合は、移行を開始する前に、次の2つの修正をターゲット・データベースに適用します。
- 35495759 - (G) - 80 - V$DATABASE_KEY_INFO/制御ファイルDBキーをシステム・データファイルから再同期する必要がある(RTI 26895084)
- 36879267 - (G) - 80 - ORA-28374: TYPED MASTER KEY NOT FOUND IN WALLET AFTER FIX FOR BUG 36697088
1.7.2 ZDMでZDM_PRE_MIGRATION_ADVISORフェーズの間に障害が発生する
問題: Oracle Database 23aiの場合、Oracle Autonomous Database移行のZDM_PRE_MIGRATION_ADVISORフェーズの間に、ZDMで障害が発生します。
RUNCPATREMOTELY=TRUECOPYCPATREPORTTOZDMHOST=FALSE
1.7.3 表領域作成のための連続した移行によって領域不足になる
問題: 表領域の自動作成を選択し、表領域の作成に失敗した場合、その表領域の作成を再試行すると、それにより、データファイルの作成が重複実行されます。そのため、ターゲット・データベースに余分なデータファイルが追加されて、領域不足になります。
解決策: TABLESPACEDETAILS_EXCLUDEパラメータを指定してその表領域の作成を除外するか、TABLESPACEDETAILS_AUTOCREATEでFALSEを指定します。
1.7.4 ハイブリッド移行がZDM_VALIDATE_XTTS_SRCで失敗する
問題: ハイブリッド移行は、Oracle Database 11.2.0.4ソースからOracle Database 19cターゲット・データベースへの移行中にZDM_VALIDATE_XTTS_SRCで失敗します。
解決策: Oracle Database 11.2.0.4ソースから移行する予定の場合は、最新のPerlパッチ5.28.2以降も必要です。
1.7.5 ハイブリッド移行での暗号化された表領域の移行に関する問題
- それらの表領域は、TABLESPACEDETAILS_EXCLUDEパラメータを使用して除外されている場合でも移行されます。
- 前述の除外されている表領域は、ソース・データベースで暗号化されていた場合でも、ターゲット・データベースで、暗号化されていないものとして示されます。
1.7.6 ハイブリッド移行はソース・データベースがOracle Database 12.2である場合にZDM_DATAPUMP_IMPORT_TGTで失敗する
問題: ハイブリッド移行は、ソース・データベースがOracle Database 12.2である場合は、SPATIAL_CSW_ADMIN_USRオブジェクトが原因で、ZDM_DATAPUMP_IMPORT_TGTフェーズで失敗します。このMOSノートによると、ユーザーSPATIAL_WFS_ADMIN_USRはもう不要であり、Oracle Database 12.2の場合は無視する必要があります。
解決策: Oracle Data Pumpのドキュメントによると、これは想定されている動作です。それらのエラーを確認し、エラーがそれらのみである場合は、-ignore IMPORT_ERRORSを指定してそのジョブを再開してかまいません。
1.7.7 ZDM_XTTS_RESTORE_FULL_TGT: バックアップ・セットから外部表領域ユーザーを新しくリストアすると権限エラーで失敗する
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 06/24/2024 03:32:19
ORA-19505: failed to identify file "/nfsshare/allnodes/importdumpaix/rman_job_10/RRACW_backup_042u4ku2_4_1_1"
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 13: Permission denied
Additional information: 7これは、ターゲットOracleユーザーがRMANバックアップにアクセスできないことが原因です。ZDMレスポンス・ファイルの変数RMANSETTINGS_PUBLICREAD=TRUEを設定しても役に立ちません。
解決策: 同じユーザーを使用できず、共通のプライマリ・グループを使用できない場合は、回避策として、バックアップの場所で次のようなOSコマンドを実行することでそのバックアップをアクセス可能にして、ターゲットOracleユーザーがそのバックアップにアクセスできるようにします:
chmod -R a+rX /nfsshare/allnodes/importdumpaix/rman_job_10
1.7.8 物理オフライン移行がZDM_DATABASE_UPGRADE_TGTで失敗する
問題: Oracle Database 19cソースからOracle Database 23aiターゲットへの物理オフライン移行は、ZDM_DATABASE_UPGRADE_TGTフェーズで次のエラーで失敗します。
ORA-02149: Specified partition does not exist
解決策:回避策として、バグ36710007からパッチを取得し、ターゲットのdbhomeに適用します。この問題は、バグ36710007で追跡されています。
1.7.9 データ・ポンプ・エクスポートのログでソース・データベース・ホスト/S3バケットがスキップされる
問題: Amazon Web Services (AWS) RDSソースからOracle Autonomous Database Serverlessターゲット・データベースへの移行中にOracle Data Pumpエクスポートのログでソース・データベース・ホスト/S3バケットがスキップされます。
- 指定したディレクトリがソースに存在する: ディレクトリが存在する場合は、移行ジョブの完了(成功/失敗)後に、既存のディレクトリにエクスポート・ログと見積りログがあります。
- 指定したディレクトリはソースに存在せずワークフローで作成されている: このシナリオでは、次のケースが考えられます:
evalジョブ:evalジョブの完了後に、作成されたディレクトリに見積りログが存在します。- 移行ジョブに失敗:
evalジョブの完了後に、作成されたディレクトリに見積りログが存在します。 - 移行ジョブに成功: ZDMにより、RDSにディレクトリが作成され、このディレクトリにエクスポート・ダンプおよびログ・ファイルが格納され、ログ・ファイルがS3にアップロードされ、作成されたディレクトリが削除されます。
1.7.10 アップグレード・シナリオに関する既知の問題
問題: ORACLE_HOMEなどの環境変数と、symlinkパスを使用するその他の環境変数が原因で、UPGRADE関連のフェーズが失敗する場合があります。
解決策: ORACLE_HOMEとその他の環境変数を、symlinkパスではなく実際のパスを使用して設定します。
1.7.11 ソース・データベースがOracle Database 11.2.0.4の場合のハイブリッド移行に関する問題
問題: Oracle Database 11.2.0.4ソースへのハイブリッド移行は、ZDM 21.5では、次のエラーで失敗します:
</ARG><ARG>ERROR at line 1:
</ARG><ARG>ORA-00904: "ORACLE_MAINTAINED": invalid identifier
</ARG><ARG></ARG><ARG></ARG><ARG>Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
</ARG><ARG>With the Partitioning, Real Application Clusters, OLAP, Data Mining
</ARG><ARG>and Real Application Testing options
</ARG></ARGS></ERR_FILE>
1.7.12 Oracle Database 23aiターゲットへのハイブリッド移行がEM_EXPRESS_ALLが存在しないというエラーで失敗する
問題: Oracle Database 23aiターゲット・データベースへのハイブリッド移行が、ZDM_DATAPUMP_IMPORT_TGTフェーズで、EM_EXPRESS_ALLが存在しないというエラーで失敗します。
回避策: それらのインポート・エラーを確認し、-ignore IMPORT_ERRORSを指定してそのジョブを再開します。
1.7.13 タイムゾーン・アップグレードとデータベース・アップグレードを伴う非CDBからPDBへの物理移行がTIMEZONE_UPGRADE_PREPARE_TGTフェーズで失敗する
問題: タイムゾーン・アップグレードとデータベース・アップグレードを伴う非CDBからPDBへの物理移行が、TIMEZONE_UPGRADE_PREPARE_TGTフェーズで失敗します。
1.7.14 DATAPUMPSETTINGS_JOBMODE=FULLを指定した論理移行に関する問題
問題: ターゲット・データベースがOracle Base Database 21cである場合、ZDMによる論理移行は、DATAPUMPSETTINGS_JOBMODE=FULLが指定されていると失敗します。これは、ZDM_DATAPUMP_IMPORT_TGTフェーズでスタックします。
1.7.15 オフライン移行でのRMAN暗号化に関する問題
問題: RMANの'encrypt on restore'を有効にするバッファ・キャッシュ・レイヤーは、制御ファイルが2度目にリストアされるときに問題があります。
回避策: 移行後にシステム表領域を暗号化します。
1.7.16 論理移行でのZDMAUTH資格証明使用時にCOPYCPATREPORTTOZDMHOSTがTRUEに設定されている場合の問題
問題: 移行にZDMAUTH資格証明を使用している場合は、パラメータCOPYCPATREPORTTOZDMHOST=TRUEに設定すると、CPATレポートがZDMホストにコピーされません。
回避策: この問題は、dbuser資格証明を使用する場合は発生しません。
1.7.17 NONCDBTOPDB移行の間にZDM_NONCDBTOPDB_CONVERSIONが失敗する
- Oracle Database 12g (12.1)の一種では、NONCDBTOPDB移行の間に、変換フェーズ(ZDM_NONCDBTOPDB_CONVERSION)が想定外に失敗します。
- NONCDBTOPDB移行の間に、パッチ互換性違反エラーが見つかり、データパッチ・フェーズがスキップされた場合(TGT_SKIP_DATAPATCH=TRUE)、変換フェーズが失敗します。
回避策: NONCDBTOPDB移行の場合は、変換フェーズの前にデータパッチ・フェーズを実行すること(TGT_SKIP_DATAPATCH=FALSE)をお薦めします。
1.7.18 ORA-12514: TNS:接続記述子で要求されているサービスがリスナーで現在認識されていません
問題: ZDM_SWITCHOVER_SRCフェーズの間に次のエラーが発生します:
ORA-12514: TNS:接続記述子で要求されているサービスがリスナーで現在認識されていません。SERVICE_NAME=<unique_db_name>_DGMGRLを使用してデータベースに接続できません。
回避策: 「Oracle Data Guard Broker and Static Service Registration」(ドキュメントID 1387859.1) https://support.oracle.com/epmos/faces/DocContentDisplay?id=1387859.1を参照することで、<db_unique_name>_DGMGRLサービスを手動で登録します。
1.7.19 ZDMジョブが権限拒否の問題で失敗する
PRCZ-4001 : failed to execute command "/tmp//oradiscover_<>.sh"PRCZ-2103 : Failed to execute command "/tmp//oradiscover_<>.sh" bash: /tmp//oradiscover_120212.sh: Permission denied
回避策: GET_SRC_INFOフェーズで移行ジョブが失敗すると、前述のエラーが表示されることがあります。しかしながら、これらは実際のエラーではない場合があります。実際のエラーを確認するには、ログ・ファイルを調べます。
/tmpが、ソース・データベースおよびターゲット・データベースの前提条件としてexecute権限でマウントされていることを確認します。
1.7.20 ハイブリッド移行に関する既知の問題
- RMANバックアップ暗号化。
- リストア時の暗号化。
解決策: 前述の問題はどちらも、次のRMANバグの状況によって異なります。
バグ31229602 - RMANバックアップ - KD4_ENCRYPT_OFFSET1で処理されたK_BTTRDAブロックが暗号化されていない。
1.7.21 エラー'ORA-01031: 権限の不足'が発生してプロシージャ・レプリケーションが機能しない
問題: 次のエラーで移行に失敗します:
ORA-01031: INSUFFICIENT PRIVILEGES
解決策: 回避策としては、sysユーザーとして次のコマンドを実行します:
- alter session set container = '<pdb>'- grant set container to ggadmin
1.7.22 非CDBソースの場合は物理移行がUPGRADE_TGTで失敗する
問題: 物理移行がZDM_DATABASE_UPGRADE_TGTフェーズで、非CDBソースから上位バージョンのCDBへの接続とアップグレードの実行中に、SYS.ALERT_QUEの問題のために失敗することがあります。この問題は、catupgrd0.log内に次のエラーがある場合に発生します:
SQL>
SQL> -- Create alert queue table and alert queue
SQL> BEGIN
2 BEGIN
3 dbms_aqadm.create_queue_table(
4 queue_table => 'SYS.ALERT_QT',
5 queue_payload_type => 'SYS.ALERT_TYPE',
6 storage_clause => 'TABLESPACE "SYSAUX"',
7 multiple_consumers => TRUE,
8 comment => 'Server Generated Alert Queue Table',
9 secure => TRUE);
10 dbms_aqadm.create_queue(
11 queue_name => 'SYS.ALERT_QUE',
12 queue_table => 'SYS.ALERT_QT',
13 comment => 'Server Generated Alert Queue');
14 EXCEPTION
15 when others then
16 if sqlcode = -24001 then NULL;
17 else raise;
18 end if;
19 END;
20 dbms_aqadm.start_queue('SYS.ALERT_QUE', TRUE, TRUE);
21 dbms_aqadm.start_queue('SYS.AQ$_ALERT_QT_E', FALSE, TRUE);
22 commit;
23 EXCEPTION
24 when others then
25 raise;
26 END;
27 /
BEGIN
*
ERROR at line 1:
ORA-04063: SYS.ALERT_QUE has errors
ORA-06512: at line 25
ORA-06512: at "SYS.DBMS_AQADM", line 742
ORA-06512: at "SYS.DBMS_AQADM_SYS", line 8049
ORA-06512: at "SYS.DBMS_AQADM_SYSCALLS", line 912
ORA-06512: at "SYS.DBMS_AQADM_SYS", line 8025
ORA-06512: at "SYS.DBMS_AQADM", line 737
ORA-06512: at line 20解決策: 回避策として、次の手順を実行します:
- ターゲット・ノードで、移行データベース関連のすべてのファイルを12.1HOME/dbsから19c HOME/dbsにコピーします。
- 「Upgrade to 12.2 fails with Error : ORA-04063: SYS.ALERT_QUE has errors」(ドキュメントID 2632809.1)で示されている手順を実行します。
- 「How to recreate the
SYS.ALERT_QUE」(ドキュメントID 430146.1)で示されている手順を実行します。
1.7.23 INCLUDEOBJECTSの数に関する制限事項
問題: データポンプ・コンポーネントに、多数のINCLUDEOBJECTSを指定できないという、INCLUDEOBJECTSの制限事項があります。
解決策: 回避策としては、エクスポート・ユーザー・スキーマでソース・データベース内に表を作成してフィルタ対象のTABLEオブジェクトをすべてリストし、次のパラメータを指定します:
<ADMIN schema>.INCLUDE_TEMP_LISTを作成し、SCHEMA SCOTTでフィルタするINCLUDEOBJECTSで指定されているオブジェクトすべてをリストします。INCLUDEOBJECTS-1=owner:SCOTT
DATAPUMPSETTINGS_METADATAFILTERS-1=name:NAME_EXPR,value:’IN(select OBJECT_NAME from <ADMIN schema>.INCLUDE_TEMP_LIST’)’, objectType:TABLEノート:
オンライン論理移行の場合は、Extractの作成後にOracle GoldenGate EXTRACTパラメータでそのようなオブジェクトのフィルタリングを設定します。ZDM_CREATE_GG_EXTRACT_SRCの後に移行ジョブを一時停止し、そのパラメータ・ファイルを更新します。1.7.24 DR移行の場合は非CDBからPDBへの移行がサポートされていない
問題: 非CDBソース・データベースからPDBターゲット・データベースへの移行のユースケースは、DR移行の場合はサポートされていません。
解決策: DRはコンテナ・レベルで実行されます。ターゲットCDBにそれ固有のDRを設定できます。非CDBがターゲットCDBに接続されたときに(通常の非CDBからPDBへの移行)、それがターゲットCDBを介してレプリケートされます。
1.7.25 ZDMの操作が「kexアルゴリズムのキー交換をネゴシエートできません」で失敗する
問題: 非推奨のKexAlgorithmsのみを使用する古いLinuxディストリビューションにソースDBがある場合は、ZDMの操作が次のエラーで失敗します:
kexアルゴリズムのキー交換をネゴシエートできません。
<zdmBase>/crsdata/<hostname>/rhp/conf/rhp.prefを編集して、USE_LEGACY_SSH=TRUEという行を追加します。- ZDMを再起動します。
1.7.26 21.3.12からの再開ジョブは21.4.2へのアップグレード後に認識できないフィールド"ENVIRONMENT"というエラーで失敗する
問題: 21.4.1より古いZDMバージョンを使用して開始されたジョブを再開する場合は、ZDMをZDM 21.4.1バージョンにアップグレードした後に、再開ジョブが次のエラーで失敗します:
認識できないフィールド"environment" (class oracle.cluster.gridhome.apis.actions.database.ZdmPayload$SourceContainerDatabase$Builder)、無視可能としてマークされていません(既知のプロパティ6個: "agentId"、"connectionDetails"、"copy"、"streamId"、"adminUsername"、"ggAdminUsername"]).
解決策: 以前のバージョンのZDMからアップグレードする場合は、回避策として、ZDM 21.4.2以降のバージョンをインストールする必要があります。
1.7.27 Data Guardでのクリーン・アップに関する問題
- 次の文を使用して
log_archive_configをクリアすると、インスタンスがORA-16188でクラッシュします。Alter system set log_archive_config='' scope=both sid='*' fal_severはクリアされず、ターゲット・データベースを指しています。これにより、ソース・データベースでREDOログのフェッチが続行されます。
- MOSノートドキュメントID 1580482.1によると、
log_archive_configをリセットするための正しい方法は、それをNODG_CONFIGに設定することです。alter system set log_archive_config=NODG_CONFIG scope=both sid='*'; - 次のコマンドを実行することで
fal_serverをクリアします:alter system set fal_server='' scope=both sid='*';
1.7.28 ZDMによるINITパラメータの変更によってData Guard構成の問題が発生する
問題: Oracle Exadata Database ServiceからOracle Exadata Database Service on Dedicated Infrastructureへのオフライン物理移行の実行中に、コンソールからのData Guard構成が、インスタンス固有のパラメータではなくデータベース・レベルでの特定のinitパラメータ(*.init_parameterの使用)が想定されているため失敗します。
initパラメータが変更され、他のエントリが追加されます:
- ZDMによって
. *.compatible='19.0.0'が削除されます -
ZDMによって
inst1. compatible='19.0.0'inst2. compatible='19.0.0'が追加されます - これにより、移行後にクラウドでData Guardを構成しようとした場合に問題が発生し、次のエラーが発生します:
CDG-50611 : Parameter COMPATIBLE is not
set Set parameter as ALTER SYSTEM SET COMPATIBLE=<value>- さらに、ZDMによって
*.db_files=1024が削除されます - ZDMによって
inst1. db_files=1024 inst2. db_files=1024が追加されます - 移行後にData Guardを構成するときに、
*.db_files=1024などのエントリがないため、Data Guardでdb_filesの値として200が取得されます。 - さらに、ZDMにより、データベースが機能するためには必要のない次のエントリが追加されます:
exacs-hostname1.thread=1 exacs-hostname2.thread=2 exacs-hostname1.undo_tablespace=’UNDOTBS1’ exacs-hostname1.undo_tablespace=’UNDOTBS2’ exacs-hostname1. instance_number=1 exacs-hostname1. instance_number =2ノート:
ZDMにより、インスタンス固有のスレッド・エントリ、インスタンス固有のinstance_numberエントリおよびインスタンス固有のundo_tablespaceエントリに加えて、これらのエントリが追加されます。
- インスタンス固有の値をできるだけ削除し、次のパラメータを削除します:
exacs-hostname1. undo_tablespace=’UNDOTBS1’ exacs-hostname1. undo_tablespace=’UNDOTBS2’ exacs- hostname1. instance_number=1 exacs- hostname1. instance_number=2 exacs- hostname1.thread=1 exacs-hostname2.thread=2 - 次に示すように、
sid='*'のエントリを作成します:SQL> alter system set compatible='19.0.0' scope=spfile sid='*'; System altered. SQL> alter system set db_files=1024 scope=spfile sid='*'; System altered. - 次に示すように、前述の作成したエントリを問い合せます:
SQL> show parameter compatible NAME TYPE VALUE compatible string 19.0.0 noncdb_compatible boolean FALSE
1.7.29 Oracle Data Pumpの起動エラー
- エクスポート・ディレクトリ・パスに対する権限が無効。
- 引数が無効、または
- 入力パラメータの組合せが原因のプロシージャ・セマンティクスの問題。
ジョブが開始されなかったため、根本的なエラーはデータポンプのエラー・ログで取得されません。このような場合は、Oracle Data Pumpの開始失敗を、次に示すようにファイル内で確認する必要があります。Data Guardでのクリーン・アップの間に次の問題が発生します:
解決策: 先頭行で強調表示されたテキストを確認して、ZDMジョブに関連付けられているデータ・ポンプ・ジョブ一意識別子(ZDM_152_DP_EXPORT_9176)を特定します。
- ソース・データベース・ホストに接続します(それがRACである場合は、ログを任意のデータベース・ノードに配置できるため、各ノードで次の手順を繰り返します)。
- 次の問合せを使用して、診断の場所を特定します(必要な場合)。
select name, value from v$diag_info where name like '%Trace'; cdを使用してディレクトリを変更します- 次のコマンドを実行します:
grep ZDM_152_DP_EXPORT_9176 *dm* ZDM_152_DP_EXPORT_9176ジョブの開始詳細を含むファイルを開き、失敗の原因となったORA-エラーを特定します。
- 失敗したアクションがインポートである場合は、ターゲット・ノードで同じ手順を実行します。
- ADBターゲットの場合は、次の問合せの出力で同様のテキストを確認します:
select payload from v$diag_trace_file_contents where trace_filename like'%dm0%';
1.7.30 ZDM AUX STARTUPの場合の非CDBからPDBへの変換のユースケース
問題: 非CDBソースをCDBターゲットにPDBとして移行する場合は、ZDMにより補助データベースが作成されて、まずその非CDBソースがターゲット上に非CDBデータベースとして移行されます。非CDBがターゲットに移動された後、ZDMにより切断/接続が実行されて移行後の非CDBが接続されます。補助データベースを作成するために、ZDMでソース・データベースのSPFILEが使用されます。つまり、移行の進行中は、ターゲットで2つのデータベース(ターゲットCDB、およびソースのSPFILE/構成を使用して実行されている補助データベース)を同時に実行できる必要があります。非常に大きいメモリー・サイズまたはSGA/PGAでソースが構成されている場合は、補助データベースの起動に失敗する可能性があります。
- 移行期間中はターゲットのサイズを増やします。これにより、エラスティック・コンピューティングを使用する場合などに、sysctlパラメータの構成、ocpuまたはメモリーのサイズ設定が大きくなる可能性があります。
- 移行前にソースのメモリーおよびSGA/PGAのサイズを小さくします。
- AUX SPFILEを再作成することで、ZDMの補助データベースのサイズを変更します。
1.7.31 ZDMでC##またはc##ユーザーがスキップされる
問題: 論理移行の間に、PDBにおいて見つかったC##ユーザーが、Oracle Data Pumpによって移動されません。しかしながら、問題は、権限付与とそれに関連付けられているプロファイルをインポートできないということです。したがって、これらのC##ユーザーに対して明示的なEXCLUDEを設定すると、その依存オブジェクトも移動されなくなります。
回避策: ZDMでは、SCHEMAモードの移行の場合は、PDBにおいて見つかった共通ユーザー('C##''で始まる)は移行されません。FULLジョブの場合は、PDBにおいて見つかった共通ユーザーは明示的に検出され、そのようなユーザー全員に対してSCHEMA EXCLUDEが設定されます。
1.7.32 各ユーザーのデータ表領域ではなくOracle Autonomous Database内のデータ表領域に表が作成される
問題: オブジェクトがターゲットでDATAにマップされ、各ユーザーのデータ表領域ではなく、Oracle Autonomous Database on Exadata Cloud@Customerのデータ表領域に表が作成されます。
想定されている動作: ソース・データベースと同じ表領域にオブジェクトがある、Oracle Autonomous Database on Exadata Cloud@Customerへの移行。
回避策: ユーザー表領域がターゲット内に作成されている場合は、ZDMにより、TRANSFORM SEGMENT_ATTRIBUTESパラメータがNOに設定されなくなります。これ避けるには、次の回避策を使用します:
適用されるデフォルト変換をすべて無効にすることで、DATAPUMPSETTINGS_SKIPDEFAULTTRANSFORM=TRUEの確認後に、必要な変換を選択します。前述の設定ではデフォルト変換がすべて回避されるため、次の変換を確認し、関連する変換を想定どおりに設定します。前述のデフォルトの詳細は、「Zero Downtime Migrationのデフォルトのデータ・ポンプ・パラメータ設定」を参照してください。
DATAPUMPSETTINGS_SECUREFILELOB=TRUE
DATAPUMPSETTINGS_METADATATRANSFORMS-1=name:LOB_STORAGE, value:'SECUREFILE'
DATAPUMPSETTINGS_METADATATRANSFORMS-2=name:OMIT_ENCRYPTION_CLAUSE, value:1
DATAPUMPSETTINGS_METADATATRANSFORMS-3=name:DWCS_CVT_IOTS, value:1
DATAPUMPSETTINGS_METADATATRANSFORMS-4=name:CONSTRAINT_USE_DEFAULT_INDEX,
value:11.7.33 論理移行の間にADB-SおよびADB-Dのエクスポートとインポートに失敗する
問題: 論理移行の間にOracle Autonomous Database ServerlessのエクスポートおよびOracle Autonomous Database on Exadata Cloud@Customerへのインポートに失敗します。同様に、論理移行の間にOracle Autonomous Database on Exadata Cloud@CustomerのエクスポートおよびOracle Autonomous Database Serverlessへのインポートに失敗します。
これは、Oracle Autonomous Database ServerlessとOracle Autonomous Database on Exadata Cloud@Customerそれぞれにデフォルト・ロールが存在しない場合に発生します。
1.7.34 空のスキーマまたは適格なオブジェクトがないスキーマのZDM RELOADがスキップされる
解決策: ZDMでリロード用のオブジェクトをフィルタします。次の条件を適用した後に特定のスキーマに対してリロードするオブジェクトがない場合は、リロード機能を回避するか、特定のスキーマを含めないでください。
SUPPORT_MODE=NONE、SUPPORT_MODE=PLSQLまたはSUPPORT_MODE= INTERNALが設定されているDBA_GOLDENGATE_SUPPORT_MODEのオブジェクト。-
BAD_COLUMN=YとマークされたDBA_GOLDENGATE_NOT_UNIQUEのオブジェクト。ZDMは、リロードから
特定のスキーマからリロードするオブジェクトが表示されない場合は、リロード機能をスキップするか、特定のスキーマを含まないでください。QUEUE_TABLESをスキップします。
1.7.35 ドライ・ラン中に事前移行アドバイザのコンパイルが失敗する - PRCZ-2103でJSON/PP.PMが見つからない
問題: ZDM_PRE_MIGRATION_ADVISORフェーズ中にOPRCZ-2103 CAN'T LOCATE JSON/PP.PMエラーが発生します。
RUNCPATREMOTELY=TRUECOPYCPATREPORTTOZDMHOST=FALSE
1.7.36 ORA-23605: INVALID VALUE "" FOR GOLDENGATE PARAMETER PARALLELISM.
問題: 次のエラーにより、ソース・データベースがOracle Standard Edition 2の場合、Oracle GoldenGate Extractの起動が失敗します:
ORA-23605: INVALID VALUE "" FOR GOLDENGATE PARAMETER PARALLELISM.
解決策: ソース・データベースでパッチを適用しない場合は、ZDMレスポンス・ファイルでGOLDENGATESETTINGS_EXTRACT_PARALLELISM=1パラメータを指定します。ZDMは、Oracle GoldenGate Extractに対してTRANLOGOPTIONS INTEGRATEDPARAMS (parallelism 1)を設定します。
1.7.37 PRCZ-4002: ノード"dbserver"で特権実行プラグイン"zdmauth"を使用したコマンド"/bin/cp"の実行に失敗する
問題: 移行中にZDMCLI RESUME JOBコマンドが失敗し、ZDMジョブがZDM_CONFIGURE_DG_SRCフェーズで一時停止します。ソース・データベース・サーバーの/etc/hostsファイルを、ソース・データベース・サーバーの異なるIPアドレスまたは別名で更新すると、エラーが発生します。
解決策: ソース・データベース・サーバーおよびZDMサーバーの/etc/hostsファイルで、ソース・データベース・サーバーのIPアドレスが正しく更新されていることを確認します。
1.7.38 Oracle Autonomous Databaseの小数OCPUサービスにはTLSサービスが必要
問題: レスポンス・ファイル・パラメータで指定されるOracle Autonomous Databaseサービス別名の小数OCPUサービスには、TLSサービスが必要です。非TLS別名の指定はサポートされていません。
解決策: ターゲット・データベースが、小数OCPUサービスを使用しているOracle Autonomous Database on Dedicated Exadata InfrastructureまたはOracle Autonomous Database on Exadata Cloud@Customerである場合、TARGETDATABASE_CONNECTIONDETAILS_SERVICENAMEパラメータにTP_TLSまたはLOW_TLS別名を指定できます。
ターゲット・データベースにおけるサービス別名の要件の指定方法は、論理移行パラメータの設定を参照してください。
1.7.39 読取り不可能なダンプを含むNFSを使用したAIXからEXACCへの移行がCHOWNに失敗
問題: 読取り不可能なダンプを含むNFSを使用してAIXからEXACCに移行すると、ソースAIXホストのCHOWNに失敗します。
解決策: NFS Data Transfer Mediumを使用した共同管理データベース・サーバーへの移行に記載されているNFSを使用して移行する場合は、別のオプションを使用します。
ただし、IBM AIXでは次のシナリオはサポートされていません。IDが一致しない場合、Zero Downtime Migrationでは、ターゲット・データベース・ユーザーのプライマリ・グループが自動的に検出され、ダンプのグループがターゲット・データベース・ユーザーのプライマリ・グループに変更されます。
1.7.40 DBUSERプラグインを使用した論理移行ではRUNCPATREMOTELYの設定も必要
解決策: データベース・ユーザー認証プラグインをdbuserとして使用して論理移行を実行するには、RUNCPATREMOTELYパラメータの値をTRUEに設定する必要があります。
このパラメータの詳細は、RUNCPATREMOTELYを参照してください。
1.7.41 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.42 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.43 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.44 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」が報告されることがあります。
-
ソースまたはターゲット・データベースで、初期化パラメータ
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'); -
スケジュールされたジョブ
GG_UPDATE_HEARTBEATSがソース・データベースでアクティブではありません。 -
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.45 ソースで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.46 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.47 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.48 データベース・リンクを介したOracle Autonomous Database on Dedicated Exadata Infrastructureへの論理移行中にORA-39006がスローされる
問題: データベース・リンクを介してデータベースをOracle Autonomous Database on Dedicated Exadata Infrastructureターゲットに移行しようとすると、移行ジョブがエラーORA-39006で失敗します。
ORA-39006: internal error
解決策: これは、バグ31830685で追跡されているデータ・ポンプの問題です。バグが修正され、修正がAutonomousターゲット・データベースに適用されるまで、Oracle Autonomous Database on Dedicated Exadata Infrastructureターゲットへのデータベース・リンクを介した論理移行を実行しないでください。
1.7.49 アップグレード後にZero Downtime Migrationサービスの起動が失敗
問題: 次のシナリオが発生します。
-
Zero Downtime Migration 19.7を使用して移行ジョブを実行します
-
これらのジョブで使用されているレスポンス・ファイルが削除されます
-
Zero Downtime Migration 21.1にアップグレードします
-
移行の実行を試行します
次のエラーが表示されます。
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.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 一般的な接続の問題
問題: 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 stopZero 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.解決策:
- ソース・データベースのSCAN名を取得し、ソース・データベース・サーバーのパブリックIPアドレスおよびソース・データベースのSCAN名を使用して、両方のターゲット・データベース・サーバー上にある
/etc/hostsファイルに追加します。たとえば:192.0.2.3 source-scan - ターゲット・データベースのSCAN名を取得し、ターゲット・データベース・サーバーのパブリックIPアドレスおよびターゲット・データベースのSCAN名を使用して、両方のソース・データベース・サーバー上にある
/etc/hostsファイルに追加します。たとえば:192.0.2.1 target-scan
ノート:
SCAN IPアドレスが/etc/hostsファイルに追加されないこの問題は、場合によってはSCAN IPアドレスがプライベートIPアドレスとして割り当てられているために解決できないことがあるため、発生する可能性があります。
1.8.2.4 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 透過的データ暗号化の一般情報
ソース・データベースのリリースによっては、透過的データ暗号化(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_NAMESQLコマンドから取得した値で置き換えます。たとえば、次を実行します。
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.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
OPEN1.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)』を参照してください。
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 移行後の自動バックアップ障害のトラブルシューティング
問題: 移行後、ターゲット・データベースで自動バックアップが失敗することがあります。
コンソールを使用して、「Bare Metal」、「VM and Exadata」→「DB Systems」→「DB System Details」→「Database Details」→「Backups」で障害を確認できます。
解決策: 次のいずれかの場所からRMAN構成設定を取得します。
- ターゲット・データベースの前提条件のZero Downtime Migrationドキュメント(取得されている場合)
/opt/oracle/dcs/log/hostname/rman/bkup/db_unique_name/のログ・ファイル/tmp/zdmXXX/zdm/zdm_TDBNAME_rman.dat
たとえば、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を実行してエラーの詳細を取得するためにジョブの詳細を記述します。
解決策:
- TDEウォレットの場所を見つけます。
Oracle Cloud Infrastructureのプロビジョニング済のデータベース・インスタンスは、
sqlnet.oraに次のエントリがあります。ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/opt/oracle/dcs/commonstore/wallets/tde/$ORACLE_UNQNAME))) - ウォレットの場所から
cwallet.ssoファイルを削除します。たとえば、
/opt/oracle/dcs/commonstore/wallets/tde/$ORACLE_UNQNAMEです。 - Oracle Database 11gリリース2の場合、次のステップを実行します。
- sysdbaとしてSQL*Plusを使用してデータベースに接続し、現在のウォレットの場所を確認します。
SQL> select * from v$encryption_wallet; WRL_TYPE WRL_PARAMETER STATUS file /opt/oracle/dcs/commonstore/wallets/tde/ocise112_region OPEN - データベースのウォレットを閉じます。
SQL> alter system set wallet close; - ウォレット・パスワードを使用してウォレットを開きます。
SQL> alter system SET WALLET open IDENTIFIED BY "walletpassword" - マスター暗号化キーを設定します。
SQL> alter system set encryption key identified by "walletpassword" - 自動ログイン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: # - 自動バックアップを再試行します。
- sysdbaとしてSQL*Plusを使用してデータベースに接続し、現在のウォレットの場所を確認します。
- Oracle Database 12cの場合、次のステップを実行します。
- 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 OPENSTATUS列に値OPEN_NO_MASTER_KEYが含まれる場合、マスター暗号化キーを作成してアクティブにする必要があります。
- データベースのウォレットを閉じます。
SQL> alter system set wallet close; - パスワードを使用してウォレットを開きます。
SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE open IDENTIFIED BY "walletpassword" CONTAINER=all; - マスター暗号化キーを設定します。
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; - 自動ログイン・キーストアを作成します。
SQL> ADMINISTER KEY MANAGEMENT CREATE AUTO_LOGIN KEYSTORE FROM KEYSTORE 'path to wallet directory' IDENTIFIED BY "walletpassword"; - 自動バックアップを再試行します。
- sysdbaとしてSQL*Plusを使用してデータベースに接続し、現在のウォレットの場所およびステータスを確認します。
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 既存の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を失敗として報告します。
解決策: この問題を回避するには、ターゲットをプロビジョニングするときに次のようにします。
-
ソースが非CDBの場合、dbaascliを介して非CDBターゲットをプロビジョニングします
-
ソースが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:N1.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 移行ジョブを再開できない
問題: 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.11 移行ジョブが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.12 ZDM_SWITCHOVER_SRCで移行ジョブが失敗
問題: 移行ジョブがZDM_SWITCHOVER_SRCフェーズで失敗します。
解決策:
-
プライマリ・データベース・ノードからスタンバイ・データベース・ノードへの接続があることを確認し、REDOログが想定どおりに送信されるようにします。
-
リカバリ・プロセス(MRP0)がターゲットで実行されていない場合、ジョブが
ZDM_SWITCHOVER_SRCで失敗します。MRP0がOracle Cloudデータベースのスタンバイ・インスタンスで実行されていない場合は、リカバリ・プロセスの失敗の理由を修正し、Oracle Cloudデータベースのスタンバイ・インスタンスでプロセスを手動で起動した後、移行ジョブを再開する必要があります。
1.9 Oracle Exadata Database Serviceへの移行に関する追加情報
Zero Downtime Migrationを使用したOracle Exadata Database Service on Dedicated Infrastructureへのデータベースの移行に関する一般情報、考慮事項、参照先のリンクは、次を一読してください。
1.9.1 Oracle Exadata Database Service on Dedicated Infrastructureへの移行に関する考慮事項
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 Oracle Exadata Database Service on Dedicated Infrastructureデータベースの登録
移行後、Oracle Exadata Database Service on Dedicated Infrastructureデータベースを登録し、すべての要件を満たしていることを確認します。
Oracle Exadata Database Service on Dedicated Infrastructureデータベース・サーバーで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 Oracle Exadata Database Service on Dedicated Infrastructureの自動バックアップの問題
コンソールから自動バックアップを有効にする前に、バックアップ構成を確認します。次の最初のステップに示すように、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から自動バックアップが無効になっていることを確認し、次のステップに従って既存のバックアップ構成を削除します。
- バックアップ構成ファイルを生成します。
/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 - 前のステップで作成した/tmp/db_name.bkファイルを開きます。
たとえば、/tmp/zdmdb.bkを開きます。
bkup_oss=yesをbkup_oss=noから変更します。
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- 再構成ステータスを確認します。
/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 Oracle Exadata Database Service on Cloud@Customerへの移行に関する追加情報
Zero Downtime Migrationを使用したOracle Exadata Database Service on Cloud@Customerへのデータベースの移行に関する一般情報、考慮事項、参照先のリンクは、次を一読してください。
1.10.1 Oracle Exadata Database Service on Cloud@Customerへの移行に関する考慮事項
Zero Downtime Migrationのこのリリースでは、次の考慮事項に注意してください。
- すべてのOracle Exadata Database Service on Cloud@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 Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。
Oracleサポートへのアクセス
Oracle SupportサービスへのOracleカスタマ・アクセスおよび使用は、該当するサービスのOracleオーダーで指定された条件に従って行われます。
Oracle Zero Downtime Migrationリリース・ノート, リリース21c (21.5)
G15059-02