8 Zero Downtime Migrationを使用したデータベースの移行
データベース移行ジョブを評価し、ジョブを実行し、データベースの移行中または移行後にその他の操作を実行します。
既知の問題、My Oracle Supportノートおよびランブックの最新情報は、Zero Downtime Migrationリリース・ノートを参照してください。
8.1 移行ジョブの評価
Zero Downtime Migrationには、移行ジョブを本番データベースに対して実行する前に評価するためのオプションおよびツールが用意されています。
また、次のタスクが完了していることを確認してください。
-
必要なアクセス資格証明を取得します。
Oracle Cloud Infrastructure Object Storageをバックアップ媒体として使用する場合は、Object Storageのアクセス資格証明を取得します。Oracle Cloud Infrastructureコンソール・ユーザーの場合はユーザーIDが、Object Storageの場合は認証トークンが必要です。既存の認証トークンを使用していない場合は、Oracle Cloud Infrastructureコンソールを使用して新しい認証トークンを生成できます。
ソース・データベース・サーバーにrootユーザーでアクセスする場合は、rootユーザーのパスワードが必要です。ソース・データベース・サーバーとターゲット・データベース・サーバーに秘密キー・ファイルを使用してアクセスする場合は、秘密キー・ファイルが必要です。ソース・データベース環境のSYSパスワードも必要です。
Zero Data Loss Recovery Applianceをバックアップ媒体として使用する場合は、Zero Data Loss Recovery Appliance仮想プライベート・カタログ(VPC)のユーザー資格証明を取得します。
-
Zero Downtime Migrationのレスポンス・ファイルを準備します。
データベースの移行は、タスクを完遂するために不可欠なパラメータを取得するレスポンス・ファイルによって決定されます。
特定のソース、ターゲットおよびバックアップ環境のレスポンス・ファイルを設定するために必要なエントリ例に、
$ZDM_HOME/rhp/zdm/template/
ファイルのサンプルRSPテンプレートを使用します。
ZDMCLI migrate database
コマンドには、本番で実行する前に移行をテストできるオプションがあります。次の構文例では、オプションが強調表示されています。
Autonomous Database移行のZDMCLI migrate database
構文:
zdmuser> $ZDM_HOME/bin/zdmcli migrate database
-rsp file_path
-sourcedb source_db_unique_name_value
-sourcenode host
-srcauth zdmauth
-srcarg1 user:username
-srcarg2 identity_file:ssh_key_path
-srcarg3 sudo_location:sudo_path
-eval [-advisor [-ignoreadvisor] | -skipadvisor]]
共同管理データベース移行のZDMCLI migrate database
構文:
zdmuser> $ZDM_HOME/bin/zdmcli migrate database
-rsp file_path
-sourcedb source_db_unique_name_value
-sourcenode host
-srcauth zdmauth
-srcarg1 user:username
-srcarg2 identity_file:ssh_key_path
-srcarg3 sudo_location:sudo_path
-targetnode host
-tgtauth zdmauth
-tgtarg1 user:username
-tgtarg2 identity_file:ssh_key_path
-tgtarg3 sudo_location:sudo_path
-eval [-advisor [-ignoreadvisor] | -skipadvisor]]
migrate database
オプションを使用して移行を評価する方法の詳細は、次の各トピックを参照してください。
8.1.1 ZDMCLI MIGRATE DATABASE -evalオプションの使用
本番データベースのデータベース移行ジョブを発行する前に、テスト移行を実行して、ご使用の構成および設定でプロセスがどこまで対応できるかを判断します。
移行ジョブごとに、まずmigrate database
を評価モードで実行することをお薦めします。評価モードにより、本番データベースで実際の移行を実行する前に、設定および構成の潜在的な問題を修正できます。
評価モードでは、移行プロセスが変更に影響を与えずに実行されます。実際の移行ジョブを実行する前に、必要に応じて何回でも評価モードで移行ジョブを実行できます。
migrate database
出力は、移行ジョブIDを示します。このIDを使用して、ジョブのステータスを問い合せることができます。
移行ジョブの評価を実行するには、次の例に示されているように、ZDMCLIコマンドmigrate database
を-eval
オプションを指定して実行します。
Zero Downtime Migrationサービス・ホストにログインし、zdmuser
インストール・ユーザーに切り替えます。
su - zdmuser
ソース・データベース・サーバーへの接続がルート資格証明によって行われる場合、コマンドは次のようになります。
zdmuser> $ZDM_HOME/bin/zdmcli migrate database -sourcedb source_db_unique_name_value
-sourcenode source_database_server_name -srcroot
-targetnode target_database_server_name
-backupuser Object_store_login_user_name
-rsp response_file_location
-tgtauth zdmauth
-tgtarg1 user:target_database_server_login_user_name
-tgtarg2 identity_file:ZDM_installed_user_private_key_file_location
-tgtarg3 sudo_location:/usr/bin/sudo -eval
プロンプトに、ソース・データベースのSYSパスワードと、ソース・データベース・サーバーのrootユーザーのパスワードを指定します。バックアップ先がObject Store (バケット)の場合は、ユーザーswift認証トークンを指定します。バックアップ先がStorage Classic (コンテナ)の場合は、テナンシ・ログイン・パスワードを指定します。
たとえば、
zdmuser> $ZDM_HOME/bin/zdmcli migrate database -sourcedb zdmsdb -sourcenode ocicdb1
-srcroot -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
Enter source database zdmsdb SYS password:
Enter source user "root" password:
Enter user "backup_user@example.com" password:
ソース・データベース・サーバーへの接続がSSHキーによって行われる場合、コマンドは次のようになります。
zdmuser> $ZDM_HOME/bin/zdmcli migrate database -sourcedb source_db_unique_name_value
-sourcenode source_database_server_name -srcauth zdmauth
-srcarg1 user:source_database_server_login_user_name
-srcarg2 identity_file:ZDM_installed_user_private_key_file_location
-srcarg3 sudo_location:/usr/bin/sudo -targetnode target_database_server_name
-backupuser Object_store_login_user_name -rsp response_file_location
-tgtauth zdmauth -tgtarg1 user:target_database_server_login_user_name
-tgtarg2 identity_file:ZDM_installed_user_private_key_file_location
-tgtarg3 sudo_location:/usr/bin/sudo -eval
プロンプトに、ソース・データベースのSYSパスワードを指定します。バックアップ先がObject Store (バケット)の場合は、ユーザーswift認証トークンを指定します。バックアップ先がStorage Classic (コンテナ)の場合は、テナンシ・ログイン・パスワードを指定します。
zdmuser> $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
Enter source database zdmsdb SYS password:
Enter user "backup_user@example.com" password:
ソースのシングル・インスタンス・データベースがGrid Infrastructureホームなしでデプロイされている場合、前述のコマンドでは、-sourcedb
のかわりに-sourcesid
を使用します。
また、ソース・データベースがPASSWORD
ベースのウォレット用に構成されている場合、前述のコマンドに-tdekeystorepasswd
オプションを追加し、プロンプトにソース・データベースのTDEキーストア・パスワード値を指定します。
–backupuser
引数は、Object Storageアクセス・ユーザーまたはZero Data Loss Recovery Appliance VPCユーザーを取り、NFSがバックアップ媒体の場合はスキップされます。NFSの場合は、ソース・データベース・ユーザーには、指定されたNFSパスに対する'rwx'アクセス権が必要です。
移行コマンドでは、ソース・ホームとターゲット・ホームのパッチ・レベル間のパッチの互換性がチェックされ、ターゲット・ホームのパッチ・レベルがソース以上であることが要求されます。ターゲット・ホームのパッチ・レベルが想定どおりでない場合、移行ジョブは停止し、欠落しているパッチがレポートされます。ターゲット・ホームに必要なパッチを適用することも、–ignore PATCH_CHECK
または-ignore ALL
オプションを移行コマンドに追加することによって移行を強制的に続行することもできます。
zdmuser> $ZDM_HOME/bin/zdmcli migrate database
-rsp response_file_location
-targetnode target_database_server_name
-tgtauth zdmauth
-tgtarg1 user:target_database_server_login_user_name
-tgtarg2 identity_file:ZDM_installed_user_private_key_file_location
-tgtarg3 sudo_location:/usr/bin/sudo
-eval
-eval
を指定してmigrate database
を実行すると、Zero Downtime Migrationでは、移行ジョブ・フェーズのサブセットのみが実行されます。たとえば、-eval
を指定して論理移行ジョブを実行すると、次のフェーズのみが実行されます。
ZDM_VALIDATE_SRC
ZDM_VALIDATE_TGT
ZDM_SETUP_SRC
ZDM_PRE_MIGRATION_ADVISOR
ZDM_VALIDATE_DATAPUMP_SETTINGS_SRC
ZDM_VALIDATE_DATAPUMP_SETTINGS_TGT
ZDM_PREPARE_DATAPUMP_SRC
ZDM_DATAPUMP_ESTIMATE_SRC
ZDM_CLEANUP_SRC
migrate database
出力は、移行ジョブのジョブIDを示します。このIDを使用して、ジョブのステータスを問い合せることができます。
コマンドラインでパスワードを指定せずにコマンドを実行する場合は、ウォレットを使用した非対話型のパスワード指定を参照してください。
8.1.2 クラウド移行前アドバイザ・ツールによるZero Downtime Migrationスキーマ分析
論理移行ジョブの場合、Zero Downtime Migrationはクラウド移行前アドバイザ・ツール(CPAT)と統合されています。このツールは、移行ジョブの間にソース・データベースを分析し、問題のあるデータベース機能および構造についてアドバイスを提供します。
CPATには、移行の評価に役立つ次のような機能があります。
-
データベースで使用されている、ターゲット環境でサポートされていない機能について警告します
-
データ・ポンプ・エクスポートおよびインポート操作に使用する修正変更またはパラメータ(あるいはその両方)を提案します
-
オプションで、ソース・データベースに対して実行できるチェックに失敗した場合の修正スクリプトを生成します
ノート:
Autonomous Databaseの場合、ZDMには従来のDBAロールがないため、CPATで、指定したユーザーには管理ロールがないことがレポートされる場合があります。その場合は、次のように、必要な管理ロールをユーザーに付与します: connect ADMIN;
GRANT OCPROLE TO <username>;
GRANT DWROLE TO <username>;
ZDMCLI migrate database
を使用して論理移行を実行すると、CPATはデフォルトでフェーズZDM_PRE_MIGRATION_ADVISOR
として実行されます。チェックは、レスポンス・ファイルの入力パラメータの設定に基づいてカスタマイズされます。
Zero Downtime MigrationでサポートされるCPATユースケースについては、クラウド移行前アドバイザ・ツールのサポートを参照してください。
CPATの実行方法をカスタマイズするためやCPATフェーズをスキップするためにZDMCLIのmigrate database
で使用できるオプションを次に示します。
-
-advisor
は、移行時にクラウド移行前アドバイザ・ツール(CPAT)を排他的に実行するために必要な次の最小移行ジョブ・フェーズのみを実行します。ZDM_VALIDATE_SRC
ZDM_VALIDATE_TGT
ZDM_SETUP_SRC
ZDM_PRE_MIGRATION_ADVISOR
ZDM_CLEANUP_SRC
-
-ignoreadvisor
は、CPATによって報告された問題またはエラーを無視します。 -
-skipadvisor
は、移行ジョブのCPATフェーズをスキップします。 -
-genfixup {YES | NO}
は、チェックに失敗した場合に選択に応じて実行できる修正スクリプトを生成します。
移行ジョブの出力には、この例に示されるように、実行されたチェック、問題の説明および問題を解決するために実行できるアクションが表示されます。
Cloud Premigration Advisor Tool Version 21.1.0-10
Cloud Premigration Advisor Tool completed with overall result: Action Required
Cloud Premigration Advisor Tool generated report location:
/scratch/app/u02/base/zdm/zdm_db12151_1/out/premigration_advisor_report.json
RESULT: Action Required
Schemas Analyzed (2): HR01,HR02
A total of 29 checks were performed
There were 0 checks with Failed results
There were 1 checks with Action Required results: nls_character_set_conversion
(0 relevant objects)
There were 3 checks with Review Required results: timezone_table_compatibility_higher
(0 relevant objects), has_role_privileges (0 relevant objects),
has_sys_privileges (0 relevant objects)
There were 1 checks with Review Suggested results: has_default_tablespace_not_data
(2 relevant objects) nls_character_set_conversion
RESULT: Action Required
DESCRIPTION: Check for issues caused by conversion of character data
from the source to the target database character set, such as expansion of
character values beyond column length or loss of invalid character codes.
ACTION: Scan the schemas to be migrated using Database Migration
Assistant for Unicode (DMU) and analyze all possible convertibility issues.
FIXUP SCRIPT:
/scratch/app/u02/base/zdm/zdm_db1215_1/zdm/lib/cpatfixups/gg_force_logging.sql
コマンド・オプションの詳細は、migrate databaseを参照してください。クラウド移行前アドバイザ・ツールの詳細は、Cloud Premigration Advisor Tool (CPAT) Analyzes Databases for Suitability of Cloud Migration (Doc ID 2758371.1)を参照してください。
ノート:
移行レスポンス・ファイルでTABLESを除外しても、CPAT分析からは除外されません。スキーマ全体が除外されている場合は、CPATからSCHEMASを除外できます。Oracle Cloudではサポートされていない表が存在すると、CPATレポートで「Action Required」ステータスになる可能性があります。他のすべてのCPATの「Action Required」エラーに対処している場合は、-ignoreadvisor
を使用して新しい移行ジョブを発行して「Action Required」エラーを無視し、移行を続行できます。
8.1.3 リモートでCPATを起動するための移行の構成
Zero Downtime Migrationでは、指定されたソース・データベース・アクセスに基づいて、クラウド移行前アドバイザ・ツール(CPAT)の実行が処理されます。場合によっては(ソースがAmazon RDS Oracleである場合など)、Zero Downtime Migrationにより、安全な方法でリモートでCATPが実行されます。
Zero Downtime MigrationでリモートでCPAT検証を実行するには、レスポンス・ファイル・パラメータRUNCPATREMOTELY=true
を設定します。
接続文字列は、次のパラメータの設定を使用して作成されます。
-
SOURCEDATABASE_ADMINUSERNAME
-
SOURCEDATABASE_CONNECTIONDETAILS_HOST
-
SOURCEDATABASE_CONNECTIONDETAILS_SERVICENAME
-
SOURCEDATABASE_CONNECTIONDETAILS_PORT
-
SOURCEDATABASE_CONNECTIONDETAILS_TLSDETAILS_DISTINGUISHEDNAME
CPATの詳細は、Cloud Premigration Advisor Tool (CPAT) Analyzes Databases for Suitability of Cloud Migration (Doc ID 2758371.1)を参照してください
8.2 データベースの移行
ZDMCLI migrate database
コマンドを使用して、Zero Downtime Migrationでデータベースの移行を実行します。
このトピックの移行手順を開始する前に、すべての前提条件を満たし、物理データベース移行の準備で説明されている必要な準備を完了しておきます。
特に、次のタスクが完了していることを確認してください。
-
必要なアクセス資格証明を取得します。
Oracle Cloud Infrastructure Object Storageをバックアップ媒体として使用する場合は、Object Storageのアクセス資格証明を取得します。Oracle Cloud Infrastructureコンソール・ユーザーの場合はユーザーIDが、Object Storageの場合は認証トークンが必要です。既存の認証トークンを使用していない場合は、Oracle Cloud Infrastructureコンソールを使用して新しい認証トークンを生成できます。
ソース・データベース・サーバーにrootユーザーでアクセスする場合は、rootユーザーのパスワードが必要です。ソース・データベース・サーバーとターゲット・データベース・サーバーに秘密キー・ファイルを使用してアクセスする場合は、秘密キー・ファイルが必要です。ソース・データベース環境のSYSパスワードも必要です。
Zero Data Loss Recovery Applianceをバックアップ媒体として使用する場合は、Zero Data Loss Recovery Appliance仮想プライベート・カタログ(VPC)のユーザー資格証明を取得します。
-
Zero Downtime Migrationのレスポンス・ファイルを準備します。
データベースの移行は、タスクを完遂するために不可欠なパラメータを取得するレスポンス・ファイルによって決定されます。
特定のソース、ターゲットおよびバックアップ環境に対してレスポンス・ファイルを設定するのに必要なエントリ例に、サンプルの$ZDM_HOME/rhp/zdm/template/zdm_template.rspファイルを使用します。
-
データベース移行を開始する前に、移行プロセスを一時停止して再開する必要があるかどうかを決定します。移行ジョブが開始されると、ジョブ・システムによって、構成されたとおりにジョブが実行されます。
移行ジョブを特定の時点で一時停止して再開する必要がある場合、詳細は、「移行ジョブのフェーズのリスト」および「移行ジョブの一時停止および再開」の各トピック(次の相互参照)を参照してください。
ルート資格証明を使用した物理移行
データベース移行ジョブは、zdmuser
ユーザーがZDMCLIコマンドmigrate database
を使用してZero Downtime Migrationサービス・ホストから発行します。
物理移行では、ソース・データベース・サーバーへの接続がルート資格証明によって行われる場合、コマンドは次のようになります。
zdmuser> $ZDM_HOME/bin/zdmcli migrate database
-sourcedb source_db_unique_name_value
-sourcenode source_database_server_name
-srcroot
-targetnode target_database_server_name
-backupuser Object_store_login_user_name
-rsp response_file_location
-tgtauth zdmauth
-tgtarg1 user:target_database_server_login_user_name
-tgtarg2 identity_file:ZDM_installed_user_private_key_file_location
-tgtarg3 sudo_location:/usr/bin/sudo
プロンプトに、ソース・データベースのSYSパスワードと、ソース・データベース・サーバーのrootユーザーのパスワードを指定します。バックアップ先がObject Store (バケット)の場合は、ユーザーswift認証トークンを指定します。バックアップ先がStorage Classic (コンテナ)の場合は、テナンシ・ログイン・パスワードを指定します。
たとえば:
zdmuser> $ZDM_HOME/bin/zdmcli migrate database
-sourcedb zdmsdb
-sourcenode ocicdb1
-srcroot
-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
Enter source database zdmsdb SYS password:
Enter source user "root" password:
Enter user "backup_user@example.com" password:
SSHキーを使用した物理的移行
物理移行では、ソース・データベース・サーバーへの接続がSSHキーによって行われる場合、コマンドは次のようになります。
zdmuser> $ZDM_HOME/bin/zdmcli migrate database
-sourcedb source_db_unique_name_value
-sourcenode source_database_server_name
-srcauth zdmauth
-srcarg1 user:source_database_server_login_user_name
-srcarg2 identity_file:ZDM_installed_user_private_key_file_location
-srcarg3 sudo_location:/usr/bin/sudo
-targetnode target_database_server_name
-backupuser Object_store_login_user_name
-rsp response_file_location
-tgtauth zdmauth
-tgtarg1 user:target_database_server_login_user_name
-tgtarg2 identity_file:ZDM_installed_user_private_key_file_location
-tgtarg3 sudo_location:/usr/bin/sudo
プロンプトに、ソース・データベースのSYSパスワードを指定します。バックアップ先がObject Store (バケット)の場合は、ユーザーswift認証トークンを指定します。バックアップ先がStorage Classic (コンテナ)の場合は、テナンシ・ログイン・パスワードを指定します。
たとえば、
zdmuser> $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
Enter source database zdmsdb SYS password:
Enter user "backup_user@example.com" password:
ソースのシングル・インスタンスがGrid Infrastructureホームなしでデプロイされている場合、前述のコマンドでは、-sourcedb
のかわりに-sourcesid
を使用します。
ソース・データベースがPASSWORD
ベースのウォレット用に構成されている場合、前述のコマンドに-tdekeystorepasswd
オプションを追加し、プロンプトにソース・データベースのTDEキーストア・パスワード値を指定します。
–backupuser
引数は、Object Storageアクセス・ユーザーまたはZero Data Loss Recovery Appliance VPCユーザーを取り、NFSがバックアップ媒体の場合はスキップされます。NFSの場合は、ソース・データベース・ユーザーには、指定されたNFSパスに対する'rwx'アクセス権が必要です。
Autonomous Databaseへの論理移行
Autonomous Databaseへの論理移行では、コマンドは次のようになります。
zdmuser> $ZDM_HOME/bin/zdmcli migrate database
-rsp file_path
-sourcedb source_db_unique_name_value
-sourcenode host
-srcauth zdmauth
-srcarg1 user:username
-srcarg2 identity_file:ssh_key_path
-srcarg3 sudo_location:sudo_path
-eval [-advisor [-ignoreadvisor] | -skipadvisor]]
共同管理データベースへの論理移行
共同管理システムへの論理移行では、コマンドは次のようになります。
zdmuser> $ZDM_HOME/bin/zdmcli migrate database
-rsp file_path
-sourcedb source_db_unique_name_value
-sourcenode host
-srcauth zdmauth
-srcarg1 user:username
-srcarg2 identity_file:ssh_key_path
-srcarg3 sudo_location:sudo_path
-targetnode host
-tgtauth zdmauth
-tgtarg1 user:username
-tgtarg2 identity_file:ssh_key_path
-tgtarg3 sudo_location:sudo_path
[-ignoreadvisor | -skipadvisor]
SSHアクセスを使用しない共同管理データベースへの論理移行
ソース・データベース・サーバーへのSSH接続がなく、ターゲットがOracle Cloud Infrastructure共同管理データベースの場合は、次のコマンドを実行します:
zdmuser> $ZDM_HOME/bin/zdmcli migrate database
-rsp response_file_location
-targetnode target_database_server_name
-tgtauth zdmauth
-tgtarg1 user:target_database_server_login_user_name
-tgtarg2 identity_file:ZDM_installed_user_private_key_file_location
-tgtarg3 sudo_location:/usr/bin/sudo
パッチの互換性
移行コマンドでは、ソース・ホームとターゲット・ホームのパッチ・レベル間のパッチの互換性がチェックされ、ターゲット・ホームのパッチ・レベルがソース以上であることが要求されます。ターゲット・ホームのパッチ・レベルが想定どおりでない場合、移行ジョブは停止し、欠落しているパッチがレポートされます。ターゲット・ホームに必要なパッチを適用することも、–ignore PATCH_CHECK
または-ignore ALL
オプションを移行コマンドに追加することによって移行を強制的に続行することもできます。
ジョブID値
コマンド結果出力には、移行ジョブのジョブIDが示されます。このIDを使用して、ジョブのステータスを問い合せることができます。
非対話型の移行の実行
コマンドラインでパスワードを指定せずにコマンドを実行する場合は、ウォレットを使用した非対話型のパスワード指定を参照してください。
8.3 移行後のタスク
移行ジョブが完了したら、関連する移行後のタスクを完了します。
global_nameの更新
global_nameは、データベース(そのドメインを含む)のフル・ネームを指し、これは他のデータベースから一意に識別されます。移行中、ソース・システムのglobal_nameは保持されます。これは、domain_nameが含まれていないかぎり有効です。
domain_nameがglobal_nameの一部である場合は、ターゲット・システムでglobal_nameを手動で更新して、新しいドメイン名を含めます。
Oracle Database 11.2および12.1ソースからの移行後のTDEウォレットの構成
Oracle Database 11.2および12.1ソースの場合、TDEウォレット構成は必要ありません。ソースにTDEウォレットが構成されていない場合、ターゲット上のTDE構成はすべて削除されます。移行後、新しい表領域を作成する前に、ターゲットでTDEウォレットを構成する必要があります。
8.4 移行ジョブのステータスの問合せ
ジョブの実行中に、移行ジョブのステータスを問い合せることができます。
ジョブIDを指定してZDMCLI query job
コマンドを使用し、データベース移行ジョブのステータスを問い合せます。ジョブIDは、データベース移行ジョブの発行時にコマンド出力に表示されます。
zdmuser> $ZDM_HOME/bin/zdmcli query job -jobid job-id
移行ジョブのコンソール出力は、query job
コマンド出力(結果ファイルのパス)に示されているファイルで確認できます。指定されたファイルで移行の進行状況メッセージを確認できます
8.5 移行ジョブのフェーズのリスト
移行ジョブに組み込まれている操作フェーズをリストできます。
移行ジョブに組み込まれている操作フェーズをリストするには、-listphases
オプションをZDMCLI migrate
コマンドに追加します。このオプションは、操作に組み込まれているフェーズをリストします。
たとえば、
zdmuser> $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 -listphases
8.6 移行ジョブの一時停止
移行ジョブは、ZDM_SETUP_TGT
フェーズ後の任意の時点で一時停止できます。また、いつでも再開できます。
移行ジョブを一時停止するには、ZDMCLI
migrate
コマンドで、一時停止する直前の有効なフェーズとともに–pauseafter
オプションを指定します。
次の例で-pauseafter ZDM_SETUP_TGT
と指定すると、移行ジョブはZDM_SETUP_TGT
フェーズの完了後に一時停止します。
zdmuser> $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 -pauseafter ZDM_SETUP_TGT
一時停止する直前の移行ジョブ・フェーズの選択
migrate database ... -listphases
コマンド出力でリストされるZDM_CONFIGURE_DG_SRC
の後の有効なフェーズを選択します。
-pauseafter
オプションで指定できるフェーズは1つのみです。
次の場合は、移行ジョブを一時停止し、いくつかの手動ステップの後で再開する必要があります。
- スタンバイ・データベースをTDEに変換する。ソースが暗号化されていない場合、ZDLRAがデータ転送媒体として使用されている場合、またはOracle Databaseのバージョンが12.2より前の場合は、ターゲット・クラウド・データベースを暗号化する必要があります。
- Active Data Guardを有効にする(オプション)
- スイッチオーバー前にData Guard構成ヘルスをモニターする
- クラウド・データベースをテストする(オプション)。アプリケーション・スイッチオーバーを実行せずにスタンバイをプライマリに変換でき、これを使用してクラウドでテスト用にソース・データベースを複製できます。
物理移行ジョブの一時停止のベスト・プラクティス
物理移行では、フェーズZDM_CONFIGURE_DG_SRC
で-pauseafter
を使用すると、フェーズの実行終了時にターゲット・データベースでスタンバイが作成され、ソース・データベースとターゲット・データベースの間で同期が発生します。
次のことを実行できるように、ZDM_CONFIGURE_DG_SRC
の後に移行ジョブを一時停止することをお薦めします。
- クラウドへのアプリケーション・スイッチオーバーを実行する
- ZDLRAがバックアップ方法である場合、またはデータベース・リリースがOracle Database 12.2より前の場合、クラウド・データベースを手動で暗号化する
- オンプレミス・データベースを変更せずに、フェイルオーバーを実行してクラウド・データベースをテストする
一時停止された移行ジョブ中のログ・ファイルの保持
移行ジョブの一時停止と再開の間でソース・データベース・ログ・ファイルとターゲット・データベース・ログ・ファイルがクリーン・アップされないように、ログ・ファイルはそれぞれのソース・データベース・サーバーとターゲット・データベース・サーバーの$ORACLE_BASE/zdm/zdm_db_unique_name_zdm_job_id/zdm/log
に書き込まれます。
ZDM_BACKUP_INCREMENTAL_SRC
フェーズ中およびフェーズ後に生成されたすべてのアーカイブ・ログが、できればスイッチオーバーまで、または少なくともターゲット・データベースとソース・データベースが同期化されるまで利用可能であることを確認します。ZDM_BACKUP_INCREMENTAL_SRC
より前に生成された古いアーカイブ・ログは必要ありません。
8.7 移行ジョブの再開
一時停止されたジョブは、それぞれのジョブIDを指定してZDMCLI
resume job
コマンドを実行することで、いつでも再開できます。
zdmuser> $ZDM_HOME/bin/zdmcli resume job -jobid Job_ID
[-pauseafter valid-phase | -rsp zdm_logical_template]
[-rerun {BACKUP|RESTORE}]
[-ignore
{IMPORT_ERRORS | EXPORT_ERRORS}]
-skip SWITCHOVER
再開時における別の一時停止のスケジュール
次の例に示すように、別の一時停止をスケジュールするには、resume job
コマンドで、一時停止する直前の有効なフェーズとともに–pauseafter
オプションを指定します。
現在一時停止しているフェーズより後の有効なフェーズを選択してください。migrate database ... -listphases
コマンドの出力にフェーズのリストが表示されます。
zdmuser> $ZDM_HOME/bin/zdmcli resume job -jobid Job_ID
-pauseafter valid-phase
再開時のRMANのバックアップ操作またはリストア操作の再実行
物理移行ジョブでは、-rerun
オプションを指定すると、そのジョブを再開するときに、関連する移行ジョブ・フェーズをトリガーして再実行できます。
RESTORE
オプション値により、Zero Downtime Migrationで既存のターゲット・データベースの削除、SPFILEのリストア、制御ファイルおよびデータファイルのリストアなどのリストア関連フェーズが再実行される必要があることを指定します。
BACKUPオプション値により、Zero Downtime MigrationでZDM_BACKUP_INCREMENTAL_SRC
フェーズ以降のフェーズが再実行される必要があることを指定します。バックアップ・フェーズの再実行の一部として、まずRMANでのクロスチェックが実行されて、ソース制御ファイルがバックアップ・メディア内のバックアップと一致することが確認されます。
それらのフェーズを再実行するのは、主に、移行ジョブの失敗時にバックアップまたはリストアの手順を再試行するためです。バックアップの再実行のユースケースとして考えられるのは、リストアの試行前または完了前にバックアップが誤って削除された場合です。別の理由としては、次のケースが考えられます。Zero Downtime MigrationでTDEウォレットがターゲットにコピーされた後にそのウォレットが変更された場合、差分バックアップ・ソースによって新しいウォレットでそのバックアップが暗号化されますが、ターゲットに最新のウォレットがないため、増分リストアが失敗することになります。この場合は、再実行によって、ウォレットのコピーが再度行われ、その後に、ターゲット・データベースの削除と再作成を含めリストアが再度行われます。
追加のZDMジョブ固有のエクスポートまたはインポート・エラー無視オプション
resume job
コマンドで–ignore
オプションを指定します。zdmcli resume job -jobid <num> [-ignore {IMPORT_ERRORS | EXPORT_ERRORS}]
ノート:
デフォルトのエラーを含め、追加のエラーがある場合は末尾に追加します。再開アクション用にIGNOREEXPORTERRORSおよびIGNOREIMPORTERRORSパラメータが更新された場合は、更新後のレスポンス・ファイルを次のように指定してジョブを再開する必要があります:zdmcli resume job -jobid <job number> -rsp <updated response file>
。
FAILED
がステータスIGNORED_ON_FAILURE
でマークされるフェーズ・ステータス。
-ignore EXPORT_ERRORS
はData Pumpエクスポートで検出されたエラーをすべて無視し、ZDMジョブは次のワークフロー・アクションに進みます。
-ignore IMPORT_ERRORS
はData Pumpインポートで検出されたエラーをすべて無視し、ZDMジョブは次のワークフロー・アクションに進みます。
スイッチオーバーのスキップ
スイッチオーバー・フェーズで障害が発生した場合は、問題を修正して手動スイッチオーバーを実行できます。ZDMフローの問題を回避するために、手動スイッチオーバーが実行され、ZDMがスイッチオーバー・フェーズをスキップするように指定できます。次を使用して移行ジョブを再開します:
zdmcli resume job -jobid <jobid> -skip SWITCHOVER
再開時における移行パラメータの変更
論理移行ジョブでは、ジョブの一時停止やジョブ障害時に、一部のパラメータを変更できます。ジョブを再開する準備ができたら、変更したレスポンス・ファイルをコマンドresume job
に指定します。この変更は、ジョブが再開されたときにZero Downtime Migrationによって取得されます。
次に示すように、再開時にパラメータを変更するには、resume job
コマンドで–rsp
オプションを指定し、変更されたパラメータを含む論理移行レスポンス・ファイルへのパスを指定します。
zdmuser> $ZDM_HOME/bin/zdmcli resume job -jobid Job_ID
-rsp modified_zdm_logical_template
次の考慮事項および制限が適用されます。
- 特定のプロパティのみを変更できます
- 使用されているフェーズがすでに完了している場合、プロパティ変更は拒否されます
- ファイルへのプロパティの削除または追加は変更とみなされ、Zero Downtime Migrationでは、追加/削除を含めることができるかどうかを判断するための検証が実行されます。
- 終了(中止)されたジョブと評価ジョブは再開できません。
レスポンス・ファイル・パラメータの参照により、どのパラメータを変更でき、どのフェーズまで変更できるかを特定します。DATA_TRANSFER_MEDIUM
がDBLINK
に設定されている場合、設定できる期間が終了するフェーズは異なることに注意してください。
表8-1 再開時に変更可能な移行パラメータ
パラメータ | いつ変更できますか? |
---|---|
|
任意のフェーズで変更 |
|
任意のフェーズで変更 |
|
任意のフェーズで変更 |
|
任意のフェーズで変更 |
|
任意のフェーズで変更 |
|
任意のフェーズで変更 |
|
任意のフェーズで変更 |
|
任意のフェーズで変更 |
|
任意のフェーズで変更 |
|
任意のフェーズで変更 |
|
任意のフェーズで変更 |
|
任意のフェーズで変更 |
|
任意のフェーズで変更 |
|
任意のフェーズで変更 |
|
任意のフェーズで変更 |
|
任意のフェーズで変更 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
任意のフェーズで変更 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
IGNOREIMPORTERRORS |
|
8.8 移行ジョブの一時停止および再開
移行ジョブはどの時点でも一時停止でき、いつでも再開できます。
移行ジョブを一時停止するには、次のコマンドを実行します。
zdmuser> $ZDM_HOME/bin/zdmcli suspend job -jobid job_id
休止と一時停止の違いは何ですか。
移行ジョブでの休止は、移行ジョブの開始時にスケジュールするイベントであり、一時停止は、移行ジョブの実行中に採用できるスケジュールされていないイベントです。
一時停止された移行ジョブの再開
一時停止されたジョブは、それぞれのジョブIDを指定してZDMCLI
resume job
コマンドを実行することで、いつでも再開できます。
zdmuser> $ZDM_HOME/bin/zdmcli resume job -jobid Job_ID
[-pauseafter valid-phase]
オプションで、resume
コマンドで–pauseafter
オプションを指定して、一時停止する有効なフェーズを指定することにより、一時停止をスケジュールできます。migrate database ... -listphases
コマンド出力にリストされるフェーズで、現在一時停止しているフェーズより後の有効なフェーズを選択します。
一時停止によってジョブが中断されるのはどのようなときですか。
移行ジョブのフェーズには、中断可能なものとそうでないものがあります。
論理移行では、一時停止されたときに、進行中のジョブ・フェーズが中断可能である場合はそのフェースが中断され、進行中のフェーズが中断可能でない場合はそのフェーズが完了した後にジョブが一時停止されます。
Oracle Data Pumpの場合、次のフェーズは中断可能です。ZDM_DATAPUMP_EXPORT_SRC
ZDM_TRANSFER_DUMPS_SRC
ZDM_DATAPUMP_IMPORT_TGT
Oracle GoldenGateの場合、次のフェーズは中断可能です。
ZDM_CREATE_GG_EXTRACT_SRC
ZDM_CREATE_GG_REPLICAT_TGT
ZDM_MONITOR_GG_LAG
ZDM_SWITCHOVER_APP
一時停止操作が完了すると、ジョブ・ステータスがSUSPENDED
に更新されます
8.9 移行ジョブの再実行
移行ワークフローに予期しないエラーがある場合は、それらを修正して移行ジョブを再実行できます。
エラーはジョブ出力に記録され、ZDMCLI query job
コマンドを使用して問い合せることができます。エラーを解決したら、失敗したジョブを障害が発生した時点から続行できます。
次に示すように、再実行するジョブのジョブIDを指定してZDMCLI resume job
コマンドを実行し、移行ジョブを再実行します。
zdmuser> $ZDM_HOME/bin/zdmcli resume job -jobid Job_ID
8.10 実行中の移行ジョブの終了
指定したデータベースに対してデータベース移行ジョブを再発行する場合は、まず、実行中の移行ジョブを停止する必要があります。
Zero Downtime Migrationでは、データベースがすでに進行中の移行ジョブの一部である場合、指定されたデータベースに対してMIGRATE DATABASE
コマンドの再実行の試行をブロックします。
指定されたデータベースのデータベース移行ジョブを再発行する場合は、まずZDMCLI ABORT JOB
コマンドを使用して、EXECUTING
またはPAUSED
のいずれかの状態にある実行中の移行ジョブを終了する必要があります。
zdmuser> $ZDM_HOME/bin/zdmcli abort job -jobid job-id
8.11 移行ジョブの間のOracle GoldenGateプロセスの変更
移行ジョブの実行中(進行中)に、Oracle GoldenGate ReplicatおよびExtractプロセスのパラメータを変更できます。
実行中の移行ジョブを変更するには、次のコマンドを実行します。
zdmuser> $ZDM_HOME/bin/zdmcli modify job -jobid job_id -rsp response_file_path
この変更コマンドは、指定されたレスポンス・ファイルに、Oracle GoldenGate構成に関連する次のパラメータのうち1つ以上が含まれている場合のみ、移行ジョブに影響します。
GOLDENGATESETTINGS_EXTRACT_PERFORMANCEPROFILE
GOLDENGATESETTINGS_REPLICAT_PERFORMANCEPROFILE
ノート:
Oracle Zero Downtime Migration 21c (21.4)リリース以降、次のプロパティは非推奨であり、今後のリリースでサポートされなくなります:GOLDENGATESETTINGS_REPLICAT_MAPPARALLELISM
GOLDENGATESETTINGS_REPLICAT_APPLYPARALLELISM
GOLDENGATESETTINGS_REPLICAT_MAXAPPLYPARALLELISM
GOLDENGATESETTINGS_REPLICAT_MINAPPLYPARALLELISM
GOLDENGATESETTINGS_REPLICAT_PERFORMANCEPROFILE
パラメータで置き換えられます。GOLDENGATESETTINGS_REPLICAT_PERFORMANCEPROFILE
パラメータを構成する場合、これらの非推奨のパラメータを構成する必要はありません。ただし、これらの非推奨のパラメータを構成すると、GOLDENGATESETTINGS_REPLICAT_PERFORMANCEPROFILE
パラメータは無効になります。
Extractのパラメータは、移行ジョブのフェーズZDM_CREATE_GG_EXTRACT_SRC
(含めない)からZDM_MONITOR_GG_LAG
(含める)までの間のみ更新できます。
Replicatのパラメータは、移行ジョブのフェーズ ZDM_CREATE_GG_REPLICAT_TGT
(含めない)からZDM_MONITOR_GG_LAG
(含める)までの間のみ更新できます。
Zero Downtime MigrationでGoldenGateプロセスのパラメータが更新されると、移行ジョブが一時停止されていないかぎり、そのプロセスが再起動されます。その場合、GoldenGateプロセスは停止されたままになります。
8.12 論理移行でのアプリケーション・スイッチオーバーの処理
次の手順を実行すると、読取り/書込みアプリケーションのスイッチオーバーの間のデータ損失がなくなります。
論理移行ワークフローの間にソース・データベースとターゲット・データベースの両方が読取り/書込みでオープンされます。次の条件が適用されます。
-
読取り専用アプリケーションの場合、GoldenGate Replicatによって未処理ソース・トランザクションがすべて適用された直後に、スイッチオーバーを発生させることができるため、それらのサービスではアプリケーションの停止時間をなくすことができます。
-
読取り/書込みアプリケーションでは、確実にデータ損失をなくすには、アプリケーションをスイッチオーバーする前に、すべてのトランザクションがターゲットに適用されていることを確認する必要があります。
アプリケーションが読取り/書込みの場合、確実にデータ損失をなくすには、次のことを実行する必要があります。
-
フェーズ
ZDM_MONITOR_GG_LAG
の後にZero Downtime Migrationジョブを休止させます。このフェーズでは、ターゲット・データベース上でReplicatの遅延がなくなるまでOracle GoldenGate ExtractおよびReplicatの操作が監視されます。エンドツーエンド(E2E)のレプリケーション遅延は30秒未満である必要があります。
-
フェーズ
ZDM_MONITOR_GG_LAG
が完了し、移行ジョブが休止されたら、ソース・データベース上のワークロードを停止します(停止時間の開始)。データベース・サービスを使用するようにアプリケーションが構成されている場合は、srvctl
stop serviceコマンドで、-drain_timeout
を使用してサービスを停止できます。詳細は、アプリケーション・コンティニュイティの確保を参照してください。ノート:
そのアプリケーションでは、排出タイムアウトになるとそれらのデータベース・サービスが停止されそれらのサービスを使用するセッションが終了されることに対応しておく必要があります。 -
移行ジョブを再開し、フェーズ
ZDM_PREPARE_SWITCHOVER_APP
の後に別の休止をスケジュールします。このフェーズでは、次の処理が実行されます。
-
レプリケーションのE2Eの遅延がまだ30秒未満であることを確認します
-
ソース・データベース上の未処理トランザクションがExtractで取得されていることを確認します
-
Extractを停止します
-
残りすべての証跡ファイル・データがReplicatによって適用されたことを確認します
-
Replicatを停止します
-
- フェーズ
ZDM_PREPARE_SWITCHOVER_APP
が完了し、移行ジョブが休止されたら、次のように移行ジョブを再開します:- (オプション) 1つ以上のオブジェクトがレプリケーションから除外された場合は、この時点でターゲット・データベースにオブジェクトをリロードする必要があります。移行ジョブを再開し、フェーズ
ZDM_RELOAD_PARALLEL_EXPORT_IMPORT
の後に別の休止をスケジュールします。このフェーズでは、Data Pump ExportおよびImportが実行され、必要なオブジェクトがリロードされます。 - 移行ジョブを再開し、フェーズ
ZDM_SWITCHOVER_APP
の後に別の休止をスケジュールします。
- (オプション) 1つ以上のオブジェクトがレプリケーションから除外された場合は、この時点でターゲット・データベースにオブジェクトをリロードする必要があります。移行ジョブを再開し、フェーズ
- ZDMでは、スイッチオーバー中にターゲット・データベースで順序値が自動的に進むようになりました。詳細は、「Zero Downtime Migrationプロセスのフェーズ」の「
ZDM_ADVANCE_SEQUENCES
」フェーズを参照してください。 - フェーズ
ZDM_SWITCHOVER_APP
が完了し、移行ジョブが休止されたら、ソース・データベースとターゲット・データベース間のデータの整合性を確認できます。ターゲット・データベースでの順序の値が正しいことを確認する必要があります。必要に応じて、ターゲット・データベースでの順序を、次の値が十分な大きさになるまで増分します。ソース・データベースで次の問合せを実行して、SQLスクリプトを生成できます。
前述のSQLスクリプトをターゲット・データベースで実行して順序を進めます。移行ジョブを再開し、select 'alter sequence '||SEQUENCE_OWNER||'."'||SEQUENCE_NAME||'" restart start with '|| LAST_NUMBER||';' from dba_sequences where SEQUENCE_OWNER in ( select username from dba_users where nvl(oracle_maintained, 'N') = 'N');
ZDM_POST_SWITCHOVER_TGT
フェーズの後に別の休止をスケジュールします。 ZDM_POST_SWITCHOVER_TGT
フェーズが完了し、移行ジョブが休止されたら、ターゲット・データベース上のワークロードを開始できます(停止時間の終了)。ノート:
リロード機能の有効化については、GOLDENGATESETTINGS_RELOADUNREPLICATEDOBJECTS
およびRELOADOBJECTS-n
パラメータを参照してください。
8.13 Zero Downtime Migration集中フリート移行管理
Zero Downtime Migrationでは、Object StorageサービスPAR URLを使用してフリート・レベルの移行を集中的にモニターできます。
Zero Downtime集中フリート移行管理では、次の機能が提供されます。
- フリート・レベルの移行モニタリング
- トラブルシューティングおよびデータ・マイニングを容易にするフリート・レベルのログ集計
- ジョブ・メトリック収集ごとの集中移行。エグゼクティブレベルの移行ステータス・ダッシュボードおよび将来の移行予測に利用できます。
また、集中フリート移行管理により、移行が失敗した場合に操作チームがソースまたはターゲットのデータベース・サーバーにアクセスすることを禁止できます。操作チームは、指定されたZDM_LOG_OSS_PAR_URL
にあるログ、または操作のトラブルシューティングのために別のOracle Cloudストレージ・バケットにさらにステージングされたログを使用して、障害をトラブルシューティングできます。
集中フリート移行管理は、物理移行ジョブでのみサポートされ、パラメータZDM_LOG_OSS_PAR_URL
を次のような事前認証済URLに設定することで有効になります。
https://objectstorage.us-region.oraclecloud.com/ … /DEV_ZDM_LOGS_RGN/o/
Zero Downtime Migrationは、移行ジョブの進行中に、指定されたOSS PAR URLにジョブ固有のデータ(次の表を参照)を定期的にアップロードします。
表8-2 集中フリート移行ジョブ・データ
カテゴリ | URLネームスペース接尾辞(ZDM_LOG_OSS_PAR_URLの値に付加) | 内容 |
---|---|---|
ジョブ・メトリック |
たとえば、
|
ジョブ・メトリックは、ワークフローおよびエラーに関連するフェーズごとのソースおよびターゲット・データベースの重要な統計とバックアップおよびリストア統計の詳細を示します。このデータは、エグゼクティブ・ダッシュボードのフリート・レベルの移行統計に使用できます。 |
ジョブ・ステータス |
たとえば、
|
ステータス・エントリは次の形式でリストされます
たとえば、 フェーズ・ステータス値は、 |
フェーズ・ログ |
PAR_URL/2/TIMESTAMP/POD_NAME/ZDM_HOST/JOB_ID/ACTION HOST/PHASE_NAME.log たとえば、 2/2011-11-07T17:58:34.049000/PRD_TEST_MIGRATION/2-zdm-01/1/cldx01/ZDM_BACKUP_FULL_SRC.log |
Zero Downtime Migrationは、UTCタイムスタンプ付きネームスペースを使用して、各フェーズの最後にフェーズ固有のログをアップロードします。ジョブの再実行時に、タイムスタンプが変更され、再実行固有のログが最新のタイムスタンプで識別されます。 |
フェーズ・ステータス |
たとえば、
|
ファイルの内容は、フェーズが完了した場合は 移行ジョブの開始時に、Zero Downtime Migrationは
|
進行状況メッセージ |
たとえば、
|
Zero Downtime Migrationは、通常は受信したコンソール・メッセージのn個のチャンクごとに(たとえば、10行ごとに) 進行状況メッセージは次のように書式設定されます。
たとえば、 |