1 Zero Downtime Migrationの概要
Zero Downtime Migrationの仕組みと、その要件およびサポートされている構成について学習します。
1.1 Zero Downtime Migrationについて
Zero Downtime Migrationは、堅牢かつ柔軟で再開可能な移行プロセスを提供します。Zero Downtime MigrationはOracle Maximum Availability Architecture (MAA)を統合し、Oracle Database 11gリリース2 (11.2.0.4)以降のデータベース・リリースをサポートします。
個々のデータベースのデータベース移行を実行および管理したり、フリート・レベルでデータベース移行を実行できます。Oracle Data Guard、Oracle Recovery Manager (RMAN )、Oracle GoldenGate、Oracle Data Pumpなどのテクノロジを利用して、データベースをオンラインまたはオフラインで移行できます。
Zero Downtime Migrationを使用すると、Oracleデータベースを、オンプレミスおよびクラウドの様々なソースから、Oracle Database Cloud管理データベース、共同管理データベースおよびユーザー管理データベース(Autonomous Databaseや、クラウドまたはオンプレミスのExadata Database Machineなど)に移行できます。
Zero Downtime Migrationソフトウェアは、プロビジョニングするホストにインストールして実行するコマンドライン・インタフェースを備えたサービスです。Zero Downtime Migrationソフトウェアがインストールされるサーバーは、Zero Downtime Migrationサービス・ホストと呼ばれます。Zero Downtime Migrationサービス・ホストから1つ以上のデータベース移行ジョブを同時に実行できます。
Zero Downtime Migrationの機能
- 監査機能 - 移行ジョブで実行されたアクションを含め、すべてのカスタム・ユーザー・アクションが監査されます。
- ワークフローのカスタマイズ - ワークフローのフェーズの前後に実行できる独自のスクリプトを使用して、(操作フェーズでマークされた)移行ワークフローをカスタマイズできます。
- ジョブ・サブシステム - フリート・スケールでデータベース移行を実行および管理できます。
- ジョブ・スケジューラ - 将来のある時点で実行されるように移行ジョブをスケジュールできます。
- 休止および再開の機能 - ジョブの休止をスケジュールし、後で必要に応じて移行ジョブを再開できます。これは、メンテナンス時間枠に従うためなどに役立ちます。
- 一時停止および再開の機能 - 実行中のジョブを一時停止して後で再開できます。これは、移行アクティビティによってデータベースへの負荷が高くならないようにするためなどに役立ちます。
- ジョブの終了 - 実行中の移行ジョブの完了を待たずに、ジョブを終了できます。
- ジョブの再実行機能 - 移行ジョブを障害発生時点から再実行(再開)できます。
- ジョブの事前チェック - 移行タスクの事前チェックを実行して、データベース移行中のエラーを防止することができます。
- コンプライアンス - Zero Downtime MigrationはOracle Maximum Availability Architectureのベスト・プラクティスに準拠し、Oracle Database 11gリリース2 (11.2.0.4.0)以降がサポートされます。
Zero Downtime Migrationの概念
-
オンライン移行方法では、停止時間はゼロまたは最小限(通常は15分未満)になり、物理または論理移行方法を利用できます。
-
オフライン移行方法では、移行プロセスの一環としてソース・データベースで停止時間が発生します。物理または論理移行方法を利用できます。
-
物理移行方法:
-
Oracle Data GuardおよびRMANを使用して移行を実行します
-
非マルチテナント(非CDB)ソース・データベースをマルチテナント(CDB)ターゲット・データベースに変換できます
-
-
論理移行方法:
-
Oracle Data Pump、およびオンライン移行の場合はOracle GoldenGate Microservicesを使用します
-
ソースOracle DatabaseがOracle SolarisまたはIBM AIXオペレーティング・システム上で実行されており、ターゲットがOracle Linux上のOracle Autonomous Databaseまたは共同管理Oracle Databaseである場合に、クロスプラットフォーム移行を実行できます。
-
クラウド移行前アドバイザ・ツール(CPAT)との統合を含みます。このツールは、a)データベースで使用されている、ターゲット・クラウド環境でサポートされていない機能について警告し、b)データ・ポンプ・エクスポートおよびインポート操作に使用する修正変更またはパラメータ(あるいはその両方)について提案します
-
表1-1 ZDMの移行方法とその移行テクノロジおよびデータ転送メカニズム
移行方法 | 高可用性 | 移行テクノロジ | サポートされているデータ転送メカニズム |
---|---|---|---|
物理 ブロック・コピー |
オフライン バックアップおよびリストア1 |
Oracle RMAN |
|
オンライン バックアップおよびリストア1 フィジカル・スタンバイ・スイッチオーバー |
Oracle RMAN Oracle Data Guard |
||
論理 SQLアンロードおよびリロード |
オフライン エクスポートおよびインポート |
Oracle Data Pump |
|
オンライン エクスポートおよびインポート ExtractおよびReplicat |
Oracle Data Pump Oracle GoldenGate |
1バックアップはオプションです。既存のバックアップを使用できます。
2AWSからの移行のみ
移行方法については、次のトピックで説明します。
1.2 Zero Downtime Migrationを使用した物理移行
Zero Downtime Migrationによる物理移行では、Recovery Manager (RMAN)とOracle Data Guardを使用して、ソースからターゲット・データベースへのデータ転送を実行し、アプリケーション接続のためにターゲット・データベースからプライマリ・データベースへのロールスイッチを処理できます。
1.2.1 物理オンライン移行
Zero Downtime Migrationでは、Oracle Data Guardを利用してオンライン物理移行を実行します。
Zero Downtime Migrationのオンライン物理移行では、次のことが実行されます。
- 指定したデータ転送メディアにソース・データベースをバックアップする
- このバックアップからターゲット環境にスタンバイ・データベースをインスタンス化する
- 最大パフォーマンス保護モードおよび非同期(ASYNC) REDOトランスポート・モードでData Guardを構成する
- ソース・データベースとターゲット・データベースを同期させる
- 最小限の停止時間で新しいプライマリ・データベースとしてターゲット・データベースに切り替える
切り替えると、ターゲット・データベースがプライマリ・データベースになり、ソース・データベースがスタンバイになります。
スイッチオーバー後に新しいプライマリと新しいスタンバイからのSQL*Net接続がある場合、この構成では、新しいプライマリから新しいスタンバイ・ソース・データベースへのデータの同期(REDOの送信)が継続されます。この構成により、プライマリを元のソース・データベースに戻す必要がある場合に、最小限の停止時間でロールバックを実行できます。
ただし、スイッチオーバー後に新しいプライマリと新しいスタンバイからのSQL*Net接続がない場合は、新しいプライマリから新しいスタンバイのソース・データベースへのデータ同期(REDOの送信)はありません。この構成では、元のソース・データベースに戻すことはできません。
フォールバック操作は手動で行う必要があることに注意してください。Zero Downtime Migrationでは、プライマリ・データベースとして元のソース・データベースにフォールバックする逆ロール・スイッチは処理されません。
ノート:
- クラウドに移行する場合、TDEはOracle Database 12.2以降のリリースで必須です。
- ソースにはTDEが構成されている必要があります。ソース上の表領域は、暗号化する必要がありません。ターゲットの表領域は、バックアップ/リストアまたはサービスからのリストアを使用するときに暗号化されます。
- ターゲットがオンプレミスOracle Exadata Database Machine (
NON_CLOUD
)の場合、ZDM_TDE_MANDATORY=FALSE
を指定することで、TDEを使用せず、ソースでTDEをスキップすることを選択できます。この場合、ターゲットはTDEを使用しません。 - ソースでTDEが有効になっている場合、ターゲットもTDEを使用します。
1.2.2 物理オフライン移行
Zero Downtime Migrationでは、バックアップおよびリストア操作を実行して、オフライン物理移行を実行できます。
Zero Downtime Migrationのオフライン物理移行では、次のことが実行されます。
- 指定したデータ転送メディアにソース・データベースをバックアップする
- このバックアップからターゲット環境に新しいデータベースをインスタンス化する
オフライン移行方法は、データベースのクローニングと似ています。ターゲット・データベースにはソースとの関係がないため、データ同期またはフォールバック機能はありません。ソース・データベース・サーバーとターゲット・データベース・サーバーの間にSQL*Net接続は必要ありません。
物理移行の場合、Oracle Database Standard Editionをサポートするのはオフライン方法のみであることに注意してください 2
1.2.3 サポートされている物理移行パス
Zero Downtime Migrationでは、次の物理移行パスがサポートされます。
- オンプレミスのOracle DatabaseからOracle Cloud Infrastructure (仮想マシンまたはベア・メタル)
- オンプレミスOracle DatabaseからOracle Exadata Database Service on Dedicated Infrastructure
- オンプレミスOracle DatabaseからOracle Exadata Database Service on Cloud@Customer
- オンプレミスのOracle DatabaseからオンプレミスのExadata Database Machine
- オンプレミスOracle DatabaseからOracle Database@Azure上のOracle Exadata Database Service on Dedicated Infrastructure (ExaDB-D)
ノート:
現在は、直接データ転送による物理オンライン移行が、サポートされているワークフローです。詳細は、Zero Downtime Migration (ZDM)によるOracle DatabaseからOracle Database@Azure上のExaDB-Dへの移行およびOracle Zero Downtime Migration – Oracle Database@Azure上のExaDB-Dへの物理オンライン移行を参照してください。
- Oracle Cloud Infrastructure Classic DatabaseからOracle Cloud Infrastructure (仮想マシンまたはベア・メタル)
- Oracle Cloud Infrastructure Databaseから同じまたは別のOracle Cloud Infrastructureリージョン内のデータベース。
たとえば、データベースを
phoenix
商用OCIリージョンからfrankfurt
またはashburn
リージョンに移行できます。
1.2.4 物理移行でサポートされるデータ転送メディア
Zero Downtime Migrationの物理移行プロセスには、ソース・データベースのバックアップの作成と、ターゲット・データベースへのリストアが含まれます。Zero Downtime Migrationは、ターゲット環境に応じて次のバックアップ・メディアをサポートします。
- Oracle Cloud Infrastructure Object Storage
- Zero Data Loss Recovery Appliance
- ネットワーク・ファイル・システム(NFS)
ノート:
Oracle ACFS NAS - MAXは、最適な転送メディアとしてNFSが選択される物理移行シナリオと論理移行シナリオの場合に、十分にサポートされています。
1.2.5 直接データ転送のサポート
Zero Downtime Migrationは、物理移行中の直接データ転送をサポートして、ソース・データベースがObject StorageやNFSなどの中間ストアにバックアップされないようにしています。
大規模なデータベースを中間ストレージにバックアップすると、データの移動先の追加ホップのために追加のオーバーヘッドが発生します。この中間ステップは、大規模なデータベースを含む移行ではコストがかかる可能性があります。Recovery Manager (RMAN)を使用すると、Zero Downtime Migrationでアクティブなデータベースの複製とサービスからのリストアをサポートできます。
アクティブなデータベースの複製では、ソース・データベースのバックアップは必要ありません。ネットワークを介してデータベース・ファイルを補助インスタンスにコピーすることによって、ライブ・ソース・データベースを宛先ホストに複製します。RMANは、必要なファイルをイメージ・コピーまたはバックアップ・セットとしてコピーできます。
サービスからのリストアでは、RMANはRESTORE
コマンドのFROM SERVICE
句を使用し、ネットワークを介してデータベース・ファイルをリストアします。リストア操作中にRMANは、リストアする必要があるファイルのバックアップ・セットを作成し、これらのバックアップ・セットをネットワークを介してターゲット・データベースに転送します。
サービスからリストアすると、Oracle Data Guardスタンバイ・データベースからデータを転送できるため、プライマリ・データベース・システムの負荷が軽減されます。
1.2.6 物理移行でサポートされているデータベース・アーキテクチャ
Zero Downtime Migrationでは、次のデータベース・アーキテクチャの実装がサポートされています。
- Oracle Databaseシングルインスタンス: シングルインスタンスまたはOracle RACデータベース・ターゲットに移行できます。
- Oracle RAC One Node: Oracle RACデータベース・ターゲットに移行できます。
- Oracle RAC: Oracle RACデータベース・ターゲットに移行できます。
1.2.7 Oracle Database Editionのサポート
Zero Downtime Migrationでは、Standard EditionおよびEnterprise EditionのOracle Databaseの移行がサポートされます。
Standard EditionデータベースではZero Downtime Migrationを使用できますが、Data Guardを使用しないバックアップおよびリストア方法に基づいたオフライン移行方法を使用する必要があります。
Enterprise Editionは、オフラインまたはオンラインの方法を使用して移行できます。
1.2.8 ターゲット・プレースホルダ・データベース環境
Zero Downtime Migrationでは、移行プロセスを開始する前にプレースホルダ・データベース・ターゲット環境を構成する必要があります。Zero Downtime Migrationは、プロビジョニングされたターゲットをテンプレートとして使用し、移行中にターゲットを再作成します。
Zero Downtime Migrationでは移行中にこれが自動的に保持されないため、ネイティブ環境の必須および適切なオプションを使用してターゲット・データベースを構成する必要があります。
移行プロセス中、Zero Downtime Migrationサービス・ホストは、プレースホルダ・データベースを削除し、ソース・データベースと同じdb_name
を使用してターゲット環境にデータベースを再作成して、ソース・データベースをこのプレースホルダ・データベース・ターゲット環境にリストアします。
移行中、SGAパラメータを含め、ターゲット・データベースのデータベース・パラメータは保持され、移行されたデータベースはこの同じ構成で実行されます。
移行が完了すると、ターゲット・データベースはOracle Database Cloud Serviceコンソールを使用してアクセス可能になり、SRVCTLコマンドでデータベースを管理できます。データベース・パラメータに対する変更は、移行後に実行できます。
1.3 Zero Downtime Migrationを使用した論理移行
Zero Downtime Migrationを使用したオンラインおよびオフラインの論理移行については、次のトピックで説明します。
1.3.1 論理オンライン移行
Zero Downtime Migrationでは、Oracle GoldenGateおよびOracle Data Pumpを利用してオンライン論理移行を実行します。
論理オンライン移行中、Oracle Data PumpとOracle GoldenGateレプリケーションの組合せを使用してデータをターゲット・データベースに移動している間、ソース・データベースはクライアント接続に対してオンラインのままです。
OCIターゲットへの移行には、Oracle Cloud MarketplaceからOracle GoldenGateライセンスを使用できます。これは、Oracle Cloud InfrastructureでGoldenGateハブをデプロイするOracle認定の方法です。
Oracle Cloud Marketplaceで提供されているOracle GoldenGate for Oracle – Database Migrationsに、オンプレミスExadata Cloud@Customerシステムで使用する、Zero Downtime Migration用のダウンロード可能なdockerイメージが含まれるようになりました。最新のマーケットプレイスVMはhttps://cloudmarketplace.oracle.com/marketplace/en_US/listing/96175416で確認できます。この機能のドキュメントは、Oracle Zero Downtime Migrationの使用によるExadata Cloud@Customerへの移行にあります。
ソース・データベースは、プラガブル・データベース(PDB)でも非マルチテナント・データベースでもかまいません。
論理オンライン移行には、次の2つのステップが含まれます。
- ターゲット・データベースのインスタンス化。
Oracle Data Pumpは、ソース・データベースからデータを抽出し、ターゲット・データベースにロードします。
- ソース・データベースとターゲット・データベース間のリアルタイムのデータ・レプリケーション。
Zero Downtime Migrationは、両方のデータベースが同期されると移行を完了します。
オプションで、レプリケーションの設定後に一時停止するように移行ジョブを構成できます。また、Oracle GoldenGateは、アプリケーションをターゲット・データベースに切り替えるように選択するまで、ソース・データベースとターゲット・データベース間でデータをリアルタイムでレプリケートし続けることができます。
1.3.2 論理オフライン移行
Zero Downtime Migrationでは、Oracle Data Pumpを使用してオフライン論理移行を実行し、ソース・データベースからデータを抽出してターゲット・データベースにロードできます。
オフライン論理移行とは、データがターゲット・データベースに移動されている間、クライアントでソース・データベースを使用できないことを意味します。オフライン移行方法を使用する場合は、移行を開始する前にソース・データベースへの更新を停止する必要があります。移行が完了したら、ターゲット・データベースとソース・データベース間の直接SQL*Net接続は必要ありません。
1.3.3 サポートされる論理移行ターゲット
Zero Downtime Migrationは、次のターゲット・データベースへの論理データベース移行をサポートします。
- Oracle Autonomous Database on Shared Exadata Infrastructure (データ・ウェアハウスまたはトランザクション処理)
- Oracle Autonomous Database on Dedicated Exadata Infrastructure (データ・ウェアハウスまたはトランザクション処理)
- Exadata Cloud@Customer上のOracle Autonomous Database
- Oracleの共同管理データベース・システム:
- Oracle Base Database Service (仮想マシン、ベア・メタル)
- Oracle Exadata Database Service on Dedicated Infrastructure
- Oracle Exadata Database Service on Cloud@Customer
- オンプレミスのExadata Database Machine
-
OCPUが小数で割り当てられた(OCPUを整数でではなく、データベース・サービスごとにOCPUの一部分を割り当てる)、Autonomous Database on Dedicated InfrastructureおよびCloud@Customer上のAutonomous Database
使用可能な事前定義済の小数サービス別名を指定できます。ただし、Autonomous Transaction Processingのワークロードの場合、TP*サービスはLOW*サービスよりも優先されます。これは、LOW*が優先度の低いバッチ・ジョブ用であるためです。
TP_TLS
、TP
、LOW_TLS
またはLOW
(Autonomous Transaction Processingのワークロードの場合)LOW_TLS
またはLOW
(Autonomous Data Warehouseのワークロードの場合)
1.3.4 論理移行でサポートされる初期ロード方法
Zero Downtime Migrationの論理移行ワークフローの中には、ターゲット・データベースに転送するためにOracle Data Pumpダンプ・ファイルをストレージ・メディアに配置するものがあります。一部の移行ワークフローでは、中間ストレージを使用せずに初期ロードが転送されます。
Oracle Cloud Object Store
Object Storageは、すべてのターゲットのAutonomous Databaseまたは共同管理データベースへの論理移行用のデータ・ポンプ・ダンプ・ファイル・ストレージ・メディアとしてサポートされています。
共通管理ターゲットでOCI CLIを使用してObject Storageを使用するには、コマンドライン・インタフェース(CLI)を参照してください。
データベース・リンク
ノート:
数GBを超えるサイズのデータベースにデータベース・リンクを使用してデータベースを移行することはお薦めしません。ネットワーク・ファイル・システム(NFS)
共同管理ターゲット・データベースへのオフライン論理移行では、NFSがデータ転送メディアとしてサポートされています。Oracle ACFS 21c NAS - MAXは、最適な転送メディアとしてNFSが選択される両方の物理移行シナリオに対して、十分にサポートされています。詳細は、「NFSデータ転送メディアを使用した共同管理データベース・サーバーへの移行」および「DUMPTRANSFERDETAILS_PUBLICREAD」を参照してください。
ダイレクト・コピー
共有管理ターゲット・データベースへの移行では、データ・ポンプ・ダンプは、セキュア・コピー(SCP)またはRSYNCを使用して、ソース・データベースからターゲットに直接安全に転送できます。
Amazon Simple Storage Service (Amazon S3)バケット
Amazon S3バケットは、Amazon Web Services RDS Oracle DatabaseからOracle Databaseインスタンスを移行するための、データ・ポンプ・ダンプ・ファイルのストレージ・メディアとしてサポートされています。
1.3.5 初期ロード時の移行内容
移行ジョブの初期ロード・フェーズでは、すべてのスキーマの内容をソース・データベースからターゲット・データベース内の同じ名前のスキーマに移動します。移行の作成時に、特定のオブジェクトを除外し、オブジェクトの名前を変更できます。
移行可能なオブジェクト、スキーマ、ロールおよびユーザーにはいくつかの制限があります。これは、Oracle管理のデータおよびメタデータを含むシステム生成スキーマなどがデータ・ポンプによってエクスポートできないためです。
Oracle 12c以降のリリースでデフォルトで除外されるオブジェクト
デフォルトでは、Oracle管理ユーザー(ORACLE_MAINTAINED = Y
)と、ggadmin
およびc##ggadmin
ユーザーが所有するオブジェクトが移行から除外されます。また、データ・ポンプでは、Oracle管理ユーザーに加え、KU_NOEXP_VIEW
にリストされているスキーマも無視されます。
Oracle Databaseでは、どのオブジェクト、スキーマ、ロールおよびユーザーがOracleによって保持されているかを示す列ORACLE_MAINTAINED
が、いくつかのディクショナリ・ビューに含まれています。これらのビューを問い合せて、Oracle管理のため移行から除外されているオブジェクト・タイプを検出できます。ORACLE_MAINTAINED
を含むビューを検索するには、Oracle Databaseリファレンス(https://docs.oracle.com/en/database/oracle/oracle-database/21/refrn/database-reference.pdf)を参照してください。
Oracle 11gR2でデフォルトで除外されるオブジェクト
Zero Downtime Migrationでは、KU_NOEXP_VIEW
ビューにリストされているスキーマと、Oracleが管理する次のスキーマが、Oracle 11gR2の移行から除外されます。
"ORACLE_OCM"、"OJVMSYS"、"XS$NULL"、"GSMCATUSER"、"MDDATA"、"DIP"、"APEX_PUBLIC_USER"、"SPATIAL_CSW_ADMIN_USR"、"OWBSYS"、"SPATIAL_WFS_ADMIN_USR"、"GSMUSER"、"AUDSYS"、"FLOWS_FILES"、"MDSYS"、"ORDSYS"、"WMSYS"、"EXFSYS"、"APEX_040200"、"APPQOSSYS"、"GSMADMIN_INTERNAL"、"ORDDATA"、"CTXSYS"、"ANONYMOUS"、"XDB"、"ORDPLUGINS"、"SI_INFORMTN_SCHEMA"、"OLAPSYS"、"DBSNMP"、"SYSKM"、"SYSBACKUP"、"OUTLN"、"SYSDG"、"SYS"、"SYSTEM"、"APEX_030200"、"GGADMIN"、"LBACSYS"、"MGMT_VIEW"、"OWBSYS_AUDIT"、"DVSYS"、"TSMSYS"、"MGDSYS"
1.3.6 データ・レプリケーション
レプリケーションでは、レプリケーション遅延の監視フェーズ後に移行ジョブを再開するまで、初期ロード後にコミットされたトランザクションのすべてのデータおよびメタデータ操作が移行されます。
移行ジョブの間は、高速なデータベース・レプリケーションに最適な環境を提供するために、データベースでデータ定義言語(DDL)操作を実行しないようにすることをお薦めします。DDLがレプリケートされると、Oracle GoldenGate Replicatによってデータがシリアライズされて、同じオブジェクト上のDMLとDDLの間にロックの問題がないことが確認されます。
DBOPTIONS DEFERREFCONST
オプションは、レプリケーションのOracle GoldenGate Replicat非統合パラレルReplicatモードの場合はデフォルトで設定されます。DEFERREFCONST
では、制約を移行でき、ターゲット表に対する制約を無効にすることや、それらをDEFERREDに設定することはできません。使用すると、DEFERREFCONST
は、DEFERABLE
およびNOT DEFERABLE
の両方の制約を延期します。DEFERREFCONST
は、Replicatが処理するすべてのトランザクションに適用します。
デフォルトでは、Zero Downtime Migrationで、すべてのDDLがGoldenGateレプリケーションから除外されます。ただし、Zero Downtime Migrationでは、この動作を構成パラメータでオーバーライドできます。
次のオブジェクトはサポートされていません。
- 外部表に対する変更
- Oracle GoldenGateでサポートされていないタイプ(サポート対象の理解に関する項を参照)
1.4 Zero Downtime Migrationを使用したハイブリッド移行
ハイブリッド移行は、物理移行と論理移行の他の新しい移行方法です。現在は、データ転送メディアがNFSであるXTTS_OFFLINE
がサポートされています。このハイブリッド実装では、表領域の増分バックアップおよびリストアのためのRMANと、メタデータの移行のためのデータポンプが組み合されています。したがって、この移行では、物理移行と論理移行の両方の要素が組み合されています。
1.5 Zero Downtime Migrationの要件および考慮事項
1.5.1 サポートされているプラットフォーム
Zero Downtime Migrationでは、サービス・ホストと移行のソースおよびターゲット・データベース・サーバーで次のプラットフォームがサポートされます。
Zero Downtime Migrationサービス・ホスト - サポートされているプラットフォーム
Zero Downtime Migrationサービス・ホストは、Oracle Linux 7 (Linux-x86-64)、x86-64でのOracle Linux 8 (64ビット)、x86-64でのRed Hat Enterprise Linux 8 (64ビット)、x86-64でのRed Hat Enterprise Linux 9 (64ビット)で構成できます。
Zero Downtime Migrationサービスは、オンプレミスのスタンドアロン・サーバーまたはOracle CloudのスタンドアロンLinuxサーバー(コンピュート・インスタンス)にデプロイできます。Oracle Linuxは、Zero Downtime Migrationサービス・ホストでサポートされているプラットフォームです。
Zero Downtime Migrationサービス・ホストは、他の目的のために他のアプリケーションと共有できます。
サポートされているソース環境
- Oracle Cloud Infrastructureの共通管理データベースまたはオンプレミス環境
-
Amazon Web Services RDS Oracle Database
-
Linux-x86-64 (すべての移行モード)
-
IBM AIX (論理移行を使用)
-
Oracle Solaris on SPARC (64ビット) (論理移行を使用)
サポートされているターゲット環境
-
Oracle Cloud Infrastructureの共通管理データベース: Oracle Exadata Database Service on Dedicated Infrastructure、Oracle Exadata Database Service on Cloud@Customer、Oracle Base Database Service (仮想マシンおよびベア・メタル)
ターゲット共同管理データベースは、プラガブル・データベースでも非マルチテナント・データベースでもかまいません。
-
Linux-x86-64は、ターゲット・データベース・サーバーでサポートされるオペレーティング・システムです。
-
Autonomous Databaseは、論理移行でターゲット環境としてのみサポートされているプラットフォームです。専用インフラストラクチャ(Data WarehouseまたはTransaction Processing)または共有(Data WarehouseまたはTransaction Processing)を選択できます。
Autonomous Databaseは、Autonomous Exadata Infrastructure (AEI)ラックにデプロイされたAutonomous Container Database (ACD)内のプラガブル・データベースです。
OCPUが小数で割り当てられた(OCPUを整数ではなく、データベース・サービスごとにOCPUの一部分を割り当てる)、Oracle Autonomous Database on Dedicated Exadata InfrastructureおよびOracle Autonomous Database on Exadata Cloud@Customerに移行することもできます。
使用可能な事前定義済の小数サービス別名を指定できます。ただし、Autonomous Transaction Processingのワークロードの場合、TP*サービスはLOW*サービスよりも優先されます。これは、LOW*が優先度の低いバッチ・ジョブ用であるためです。
TP_TLS
、TP
、LOW_TLS
またはLOW
(Autonomous Transaction Processingのワークロードの場合)LOW_TLS
またはLOW
(Autonomous Data Warehouseのワークロードの場合)
-
オンプレミスのExadata Database Machine
- Oracle Exadata Database MachineまたはOracle Database Applianceへの論理移行方法を使用した移行がサポートされています。
1.5.2 移行でサポートされているデータベース・バージョン
Zero Downtime Migrationでは、Oracle Cloud Infrastructure、Oracle Exadata Database Service on Cloud@CustomerおよびOracle Exadata Database Service on Dedicated Infrastructureで使用可能なOracle Databaseバージョンのほとんどがサポートされています。
次のOracle Databaseバージョンは、Zero Downtime Migrationを使用して移行できます。
- Oracle Database 11 gリリース2 (11.2.0.4)
- Oracle Database 12cリリース1 (12.1.0.2)
- Oracle Database 12cリリース2 (12.2.0.1)
- Oracle Database 18c
- Oracle Database 19c
- Oracle Database 21c
- Oracle Database 23ai (ターゲット・データベースの場合のみサポートされている)
- すべての後続のOracle Databaseリリース
物理移行ワークフローにはいくつかの制限が適用されます。ソース・データベースおよびターゲット・データベースの準備を参照してください。
1.5.3 Zero Downtime Migrationのデータベース・サーバーのアクセス
Zero Downtime Migrationサービス・ホストでは、データベースの移行中にソースおよびターゲットのデータベース・サーバーにアクセスする必要があります。
移行を実行するために、Zero Downtime Migrationサービス・ホストでは、ソース・データベース・サーバーのいずれかに対するrootユーザーまたはSSHキー・ベースのアクセス権と、ターゲット・データベース・サーバーのいずれかに対するSSHキー・ベースのアクセス権が必要です。Oracle RACデータベースを移行する場合は、Oracle RACノードのいずれかへのアクセス権を付与することが適切です。Zero Downtime Migrationサービス・ホストでは、移行に必要なソフトウェアをソースおよびターゲットのサーバーにコピーして、操作の最後にクリーン・アップします。
SSH接続を確立するにはSSH秘密キーが必要です。この生成されたキーではパスフレーズを使用しないでください。Oracle Cloud Serviceコンソールを使用して、新しいSSHキーを作成して既存のデプロイメントに追加できます。
1.5.4 Zero Downtime Migrationの操作フェーズ
Zero Downtime Migrationサービスでは、操作フェーズの単位で移行プロセスを定義します。
Zero Downtime Migrationでは、ターゲット・プラットフォームやバックアップ媒体などの構成された入力パラメータに基づいて、定義された操作フェーズを使用して移行ワークフローを自動計算します。各操作フェーズでカスタム・プラグインを挿入すると、ワークフローをカスタマイズできます。Zero Downtime Migrationサービスを使用すると、選択した操作フェーズで移行ワークフローを一時停止および再開できます。
特定の操作について移行ワークフローに関連するフェーズをリストできます。ソース・データベース・サーバーで実行されるフェーズは接尾辞_SRC付きでリストされ、ターゲット・データベース・サーバーに関連付けられたフェーズは接尾辞_TGT付きでリストされます。
1.5.5 Zero Downtime Migrationのセキュリティ・プロビジョニング
Zero Downtime Migrationのファイルおよびディレクトリの権限と所有権と、セキュリティ機能の構成の処理はOracle Databaseのものと同等です。
Zero Downtime Migrationでは、ZDM_HOME
という名前の場所にインストールされます。これは、Oracle DatabaseのOracleホーム・ディレクトリORACLE_HOME
と同様に構造化されています。ZDM_HOME
内のファイルおよびディレクトリの権限と所有権は、データベースORACLE_HOME
と同じ規則に従います。
また、Zero Downtime Migrationでは、Zero Downtime Migrationの構成ファイル、ログおよびその他のアーティファクトを格納するための、ZDM_BASE
という名前のベース・ディレクトリ構造も作成されます。これは、Oracleホームに関連付けられている、Oracleベース・ディレクトリORACLE_BASE
と似ています。ZDM_BASE
のディレクトリおよびファイルの構造、所有者、権限は、ORACLE_BASE
のものと似ています。
ZDM_BASE
およびORACLE_BASE
は、グループまたはその他のユーザーによるアクセスを許可しません。
Zero Downtime Migrationの構成はすぐに使用できてセキュアであるように設計されているため、Zero Downtime Migrationの構成のセキュリティを確保するために、追加ステップを実行する必要はありません。
Zero Downtime Migrationは、ローカル・ホストからのJMX接続のみを受け入れ、HTTP接続用のループバック・アドレスでリスニングするように構成されます。Zero Downtime Migrationの操作は、製品をインストールしたオペレーティング・システム・ユーザーのみが実行できます。
物理移行では、Zero Downtime Migrationサービス・ホストからソース・データベース・サーバーおよびターゲット・データベース・サーバーへのSSH接続が必要です。移行ジョブの入力としてSSHキー・ファイルの場所を指定する必要があり、移行ジョブの間、このファイルが存在することが想定されています。これらのキー・ファイルが配置されているディレクトリおよびファイルのセキュリティを管理する必要があります。
ポートが別のアプリケーションと競合している場合は、通信ポートを変更できます。これらのポートへのアクセスは、Zero Downtime Migrationホスト内からのみ構成されます。RMIおよびHTTPポートのプロパティは、$ZDM_BASE/crsdata/zdm_service_host/rhp/conf/standalone_config.properties
ファイルで変更できます。
プロパティは次のとおりです。
- RMIポート -
oracle.jwc.rmi.port=8895
- HTTPポート -
oracle.jwc.http.port=8896
プロパティの変更後にZero Downtime Migrationサービスを再起動します。
Zero Downtime Migrationの操作にパスワードが必要な場合、デフォルトでパスワード入力用のプロンプトが表示されます。Zero Downtime Migrationは、移行レスポンス・ファイルの設定にウォレット情報を入力することで、非対話的に動作することもできます。
パスワードは暗号化されてZero Downtime Migrationデータベースに格納されます。指定されたパスワードは、移行ジョブの間、変更されないと想定されています。
操作の観点から、Zero Downtime Migrationは、ソースおよびターゲットのデータベースの移行用の構成(Oracleウォレット、透過的データ暗号化など)を処理するために、Oracle Databaseセキュリティ・ガイドのガイドラインに従います。