翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Exadata から AWS 移行ツール
AWS 移行アプローチには 15 を超える Exadata があります。次の表は、最もよく使用されるツールを示しています。このテーブルには、Oracle の従来のエクスポート/インポート、Oracle SQL*Loader、Oracle SQL Developer Database Copy、Oracle SQL*Developer Export/Import Wizard、Oracle Transportable Tablespaces、Create Table as Select (CTAS)、Oracle 外部テーブルを使用した Oracle データベースリンク、抽出、変換、ロード (ETL) ソリューションは含まれません。
移行アプローチ |
移行戦略をサポート |
物理または論理 |
変更データキャプチャ (CDC) をサポート |
へのネットワークが必要です AWS |
|---|---|---|---|---|
すべて |
論理 |
あり |
あり |
|
すべて |
論理 |
あり |
あり |
|
リホスト、リプラットフォーム |
論理 |
なし |
なし |
|
リホスト |
物理 |
なし |
|
|
リホスト |
物理 |
あり |
あり |
Oracle Data Guard と Oracle Recovery Manager (RMAN) は、Exadata データベースを Amazon EC2 に移行するための優れたオプションです。ただし、Amazon RDS for Oracle はこれらのいずれのツールもサポートしていません。
Oracle Data Guard は、論理スタンバイまたは物理スタンバイ方式を使用して実装できます。論理スタンバイデータベースは、スタンバイデータベースにデータ操作言語 (DML) ステートメントを適用して、データの同期を維持します。論理スタンバイデータベースは通常、プライマリデータベースからレポートをオフロードするために使用されます。このセクションのすべての Oracle Data Guard リファレンスは、物理スタンバイに直接適用されます。物理スタンバイデータベースは、ブロックレベルでプライマリデータベースと完全に一致します。
AWS DMS 移行
AWS Database Migration Service (AWS DMS) は論理レプリケーションソリューションです。Oracle オンプレミスデータベースを 上の Oracle データベースに移行するなどの同種移行や AWS、Oracle から Microsoft SQL Server、Oracle から Amazon Aurora PostgreSQL 互換エディションなど、さまざまなデータベースプラットフォーム間の異種移行をサポートしています。 AWS DMS は、さまざまなソースとターゲットをサポートしています。サポートされている AWS DMS ターゲットには、Amazon Simple Storage Service (Amazon S3)
AWS DMS を使用して、Exadata ワークロードを Amazon RDS for Oracle または Amazon EC2 の Oracle データベースに移行できます。 は、Exadata からの初期ロードと変更データキャプチャ (CDC) の更新 AWS DMS を処理します。Exadata は移行プロセス中に完全に動作します。CDC を使用する場合、ターゲットデータベースは Exadata と継続的に同期されるため、アプリケーションのカットオーバーが都合の良いタイミングで発生する可能性があります。
Oracle RMAN、Oracle Data Guard、Oracle Data Pump などのネイティブ Oracle ツールの方が柔軟性が高く、より高速にデータをロードできます AWS DMS。大規模な (マルチ TiB) Exadata データベースを移行する場合は、 AWS DMS 初期データロードではなく、これらのネイティブ Oracle ユーティリティを選択することをお勧めします。
Oracle Data Pump は、テーブル間およびパーティション間の並列処理を実行して、複数、並列、またはダイレクトパスストリームでテーブルをロードおよびアンロードできる複数のワーカープロセスをサポートしています。ダンプファイルの読み取りと書き込みを含む Data Pump のすべてのインポートおよびエクスポート処理は、サーバーによって処理され、クライアントは含まれません。Data Pump ダンプファイルストレージ形式は、ダイレクトパス API の内部ストリーム形式です。この形式は、テーブルスペース内の Oracle Database データファイルに保存されている形式と非常によく似ています。したがって、Data Pump はINSERTステートメントバインド変数へのクライアント側の変換を実行する必要はありません。また、Data Pump は、従来の SQL よりも高速なデータアクセスメソッド、ダイレクトパス、外部テーブルをサポートしています。ダイレクトパス API は、最速のシングルストリームパフォーマンスを提供します。外部テーブル機能は、Oracle Database の並列クエリと並列 DML 機能を効率的に活用します。Exadata から Amazon RDS for Oracle への移行に低ダウンタイムが必要な場合、一般的な Exadata 移行アプローチは、初期ロードに Data Pump を使用し、CDC に AWS DMS または Oracle GoldenGate を使用することです。
Exadata をソースとして使用する場合は制限があります AWS DMS。詳細については、 AWS DMS ドキュメントを参照してください。また、ソース (オンプレミスのExadata) とターゲット (Oracle データベースオン AWS) へのネットワーク接続も必要です AWS DMS。
初期ロード AWS DMS に を使用する場合は、次のベストプラクティスを考慮してください。
-
通常、大規模な AWS DMS レプリケーションインスタンスを選択することでパフォーマンスを向上させることができます。大きなテーブルのロードには時間がかかり、それらのテーブルのトランザクションは、テーブルがロードされるまでキャッシュする必要があります。テーブルにロードされたら、これらのキャッシュされたトランザクションが適用されて、ディスクでは保持されなくなります。たとえば、負荷に 5 時間かかり、1 時間あたり 6 GiB のトランザクションを生成する場合は、キャッシュされたトランザクションに 30 GiB のディスク容量が割り当てられていることを確認します。初期ロードが完了したら、CDC を開始する前に、より小さなインスタンスを使用するように AWS DMS レプリケーションインスタンスを変更できます。
-
大規模な (マルチ TiB) Exadata 移行では、Oracle LogMiner (デフォルト) の代わりに Binary Reader を使用する AWS DMS ことをお勧めします。Binary Reader は、複数のデータベースクエリを必要とせずにログを直接マイニングするため、I/O または CPU への影響のリスクが低くなります。ただし、大量の変更があり、Oracle ASM を使用している場合は、Oracle LogMiner の方が適しています。Binary Reader を使用して REDO ログにアクセスするには、ソースエンドポイントに次の追加の接続属性を追加します。
useLogMinerReader=N;useBfile=Y完全な比較については、 AWS DMS ドキュメントの「Using Oracle LogMiner or AWS DMS Binary Reader for CDC」を参照してください。
-
Amazon EC2 で Oracle に移行する
NOARCHIVELOG場合は、Amazon RDS for Oracle バックアップを無効にするか、アーカイブモードを に変更します。CDC フェーズの前または最初のデータロード後にバックアップを有効にします。 -
すべてのスタンバイデータベースを無効にします AWS。これには、Amazon RDS for Oracle マルチ AZ とリードレプリカが含まれます。Amazon EC2 で Oracle に移行する場合は、Oracle Data Guard または Oracle Active Data Guard スタンバイも含まれます。
-
ターゲットデータベースに初期ロードする前に、プライマリキーインデックス、セカンダリインデックス、参照整合性制約、データ操作言語 (DML) トリガーを削除します。CDC フェーズを開始する前に、これらのオブジェクトを有効にします。
-
大きなテーブルの場合は、行フィルタリング、キー、またはパーティションキーを使用して、単一のテーブルを複数の AWS DMS タスクに分割することを検討してください。たとえば、データベースに 1~8,000,000 の範囲の整数プライマリキー ID がある場合、行フィルタリングを使用して 8 つの AWS DMS タスクを作成し、タスクごとに 100 万件のレコードを移行します。この手法は、日付列でも使用できます。
-
AWS DMS 移行を複数の AWS DMS タスクに分割します。トランザクションの一貫性はタスク内で維持されるため、個別のタスクのテーブルは一般的なトランザクションに参加しないでください。
-
デフォルトでは、 は一度に 8 つのテーブルを AWS DMS ロードします。パフォーマンスを向上させるために、大規模なレプリケーションサーバーを使用する場合は、この値を増やすことができます。
-
デフォルトでは、 はトランザクションモードで変更 AWS DMS を処理し、トランザクションの整合性を維持します。バッチ最適化適用オプションに変更すると、パフォーマンスを向上させることができます。初期ロード中にこれらの制約をオフにし、CDC プロセスのために再度オンにすることをお勧めします。
-
レ AWS DMS プリケーションインスタンスと の Oracle データベース AWS が異なる仮想プライベートクラウド (VPCs)
にある場合は、VPC ピアリングを使用することをお勧めします。 -
AWS DMS 移行タスクを作成または変更するときに Amazon CloudWatch
ログを有効にします。このパラメータは、タスクの作成時にタスク設定セクションで使用できます。 AWS DMS このパラメータを有効にすると、移行プロセス中のタスクステータス、完了率、削除時間、テーブル統計などの情報がキャプチャされます。詳細については、 ドキュメントの AWS DMS Amazon CloudWatch を使用したレプリケーションタスクのモニタリング」を参照してください。
その他のベストプラクティスについては、 AWS DMS ドキュメントの「 のソースとしての Oracle データベースの使用 AWS DMS」および「 のベストプラクティス AWS Database Migration Service」を参照してください。
Oracle GoldenGate の移行
Oracle GoldenGate は論理レプリケーションソリューションです。このツールを使用して、あるデータベースから別のデータベースにデータをレプリケート、フィルタリング、変換できます。コミットされたトランザクションを複数の異種システム間で移動し、Oracle データベースから他の同種データベースやサポートされている異種データベースにデータをレプリケートできます。Oracle GoldenGate は、多くの肯定的な特徴と制限を共有します AWS DMS。
どちらのツールも論理レプリケーションを提供します。ただし、 AWS DMS はインストールと設定を必要としないマネージドサービスですが、Oracle GoldenGate をインストールして設定する必要があります。オンプレミスまたは で設定できます AWS。 AWS 可用性の高い設定を使用して Exadata から にデータを移行することで、
AWS DMS と Oracle GoldenGate のもう 1 つの大きな違いは料金です。 AWS DMS は、レプリケーションインスタンスの使用とログストレージに対して課金します。へのすべてのデータ転送 AWS DMS は無料です。同じアベイラビリティーゾーン内の Amazon RDS AWS DMS および Amazon EC2 インスタンス上の と データベース間で転送されるデータも無料です。Oracle GoldenGate では、ソースデータベースとターゲットデータベースのすべてのコアに Oracle GoldenGate ライセンスが必要です。Oracle GoldenGate を使用して、初期ロードと Exadata からの CDC の両方について、Exadata ワークロードを Amazon RDS for Oracle または Amazon EC2 上の Oracle に移行できます。このプロセスにより、移行プロセス中に Exadata を完全に運用できます。
Amazon EC2 で大規模 (マルチ TiB) Exadata データベースを Oracle に移行するには、Oracle GoldenGate の代わりに Oracle RMAN、Oracle Data Guard、または Oracle Data Pump を使用することを検討してください。その理由は次のとおりです。
-
Oracle GoldenGate には、Exadata と 間のネットワーク接続が必要です AWS。
-
Oracle GoldenGate は、初期データロード用の他の Oracle 移行ツールと同様には機能しません。例えば、大規模な Exadata データベースを Amazon RDS for Oracle に移行するには、代わりに Oracle Data Pump を使用することを検討してください。Oracle GoldenGate よりも柔軟性が高く、データを高速にロードできるためです。
Exadata から Amazon RDS for Oracle への移行に低ダウンタイムが必要な場合は、一般的な移行アプローチとして、Oracle Data Pump を初期ロードに使用し、Oracle GoldenGate または CDC AWS DMS を使用します。Oracle GoldenGate の利点は、初期負荷と CDC を処理できることです。CDC を使用すると、ターゲットデータベースを Exadata と継続的に同期できるため、都合の良いタイミングで切り替えることができます。
Oracle GoldenGate でソースとして Exadata を使用する場合、制限があります。詳細については、GoldenGate ドキュメントの「サポートされている内容を理解する
初期ロードに Oracle GoldenGate を使用する場合は、次のベストプラクティスを考慮してください。
-
統合キャプチャモードで抽出を使用して、LogMiner サーバーとの統合を活用します。統合キャプチャにより、クラシックモードでの抽出よりも多くのデータ型をシームレスに抽出できます。これらの追加のデータ型には、基本圧縮、オンライントランザクション処理 (OLTP)、Exadata Hybrid Columnar Compression (HCC) などの圧縮データが含まれます。Extract が Oracle ASM に保存されているログファイルを読み取るために、追加の設定は必要ありません。
-
統合レプリカを使用します。このオプションは、データベース適用プロセスを使用します。参照整合性を維持し、DDL オペレーションを自動的に適用します。統合レプリカは自動並列処理も提供しており、現在のワークロードとデータベースのパフォーマンスに基づいて自動的に増減します。
-
Replicat パラメータファイル
BATCHSQLで を設定します。デフォルトでは、統合レプリカは、各トランザクション内の同じオブジェクトに対して同じタイプの DML ステートメントの順序を変更してグループ化しようとします。バッチを使用すると、DML ステートメントの CPU と実行時間を短縮できます。 -
GoldenGate ハートビートテーブルを設定してend-to-endのレプリケーションラグビューを提供します。これにより、
GG_LAGデータベースビューを表示してend-to-endのレプリケーションレイテンシーを確認できます。 -
Amazon EC2 で Oracle
NOARCHIVELOGを使用している場合は、Amazon RDS for Oracle バックアップを無効にするか、アーカイブモードを に変更します。CDC フェーズの前または最初のデータロード後にバックアップを有効にします。 -
AWS のすべてのスタンバイデータベースを無効にします。これには、Amazon RDS for Oracle マルチ AZ とリードレプリカが含まれます。Amazon EC2 で Oracle に移行する場合は、Oracle Data Guard または Oracle Active Data Guard スタンバイも含まれます。
-
ターゲットデータベースに初期ロードする前に、プライマリキーインデックス、セカンダリインデックス、参照整合性制約、データ操作言語 (DML) トリガーを削除します。CDC フェーズを開始する前に、これらのオブジェクトを有効にします。
-
Oracle GoldenGate レプリケーションインスタンスと の Oracle データベース AWS が異なる仮想プライベートクラウド (VPCs)
にある場合は、VPC ピアリングを使用することをお勧めします。
Oracle Data Pump の移行
Oracle Data Pump を使用して、ある Oracle データベースから別のデータベースにデータを移動できます。Data Pump には、Oracle Database の古いリリース (バージョン 10.1 に戻る) のサポートや、さまざまな形式、データベースアーキテクチャ、バージョンを持つプラットフォームのサポートなど、さまざまな利点があります。データベース全体をエクスポートするか、特定のスキーマ、テーブルスペース、またはテーブルのみをエクスポートするかを選択できます。
並列処理、圧縮、暗号化の度合いを制御し、含めるまたは除外するオブジェクトとオブジェクトタイプを指定できます。Data Pump は、中間ストレージを必要とせずにデータベースリンクを使用してデータを転送できるネットワークモードもサポートしています。
Data Pump API は、Oracle データベース間でデータとメタデータを移動するための高速で信頼性の高い方法を提供します。Data Pump Export ユーティリティと Data Pump Import ユーティリティは、Data Pump API に基づいています。Amazon RDS for Oracle インスタンスには Secure Shell (SSH) プロトコル経由でアクセスできないため、Data Pump を使用して Exadata から Amazon RDS for Oracle に移行する場合は、Data Pump API がデータをインポートする唯一の方法です。Data Pump コマンドラインインターフェイス (CLI) は、Amazon RDS for Oracle に移行するためのオプションではありません。
初期ロードに Data Pump を使用する場合は、次のベストプラクティスを考慮してください。
-
データをインポートする前に、必要なテーブルスペースを作成します。
-
存在しないユーザーアカウントにデータをインポートする場合は、ユーザーアカウントを作成し、必要なアクセス許可とロールを付与します。
-
Amazon EC2 で Oracle に移行する場合は、Amazon RDS for Oracle バックアップをオフにするか、アーカイブモードを に変更します
NOARCHIVELOG。CDC フェーズを開始する前、または最初のデータロード後にバックアップをアクティブ化します。 -
すべてのスタンバイデータベースをオフにします AWS。これには、Amazon RDS for Oracle マルチ AZ とリードレプリカが含まれます。Amazon EC2 で Oracle に移行する場合は、Oracle Data Guard または Oracle Active Data Guard スタンバイも含まれます。
-
ターゲットデータベースに初期ロードする前に、プライマリキーインデックス、セカンダリインデックス、参照整合性の制約、DML トリガーを削除します。CDC フェーズを開始する前に、これらのオブジェクトをアクティブ化します。
-
特定のスキーマとオブジェクトをインポートするには、スキーマまたはテーブルモードでインポートを実行します。
-
インポートするスキーマは、アプリケーションに必要なスキーマに制限します。
-
圧縮と複数のスレッドを使用して、データを並行してロードおよびアンロードします。
-
Amazon S3 のファイルは 5 TiB 以下である必要があります。この制限を回避するには、
PARALLELオプションを使用して複数の Data Pump ダンプファイルを作成します。 -
Data Pump のエクスポート後に CDC を実行する場合は、Data Pump で Oracle システム変更番号 (SCN) を使用します。
-
Amazon RDS for Oracle にデータをロードする場合は、次のタスクを実行します。
-
AWS Identity and Access Management (IAM) ポリシーを作成して、Amazon RDS に S3 バケットへのアクセスを許可します。
-
IAM ロールを作成して、ポリシーをアタッチします。
-
IAM ロールを Amazon RDS for Oracle インスタンスに関連付けます。
-
Amazon S3 統合用の Amazon RDS for Oracle オプショングループを設定し、Amazon RDS for Oracle インスタンスに追加します。
詳細については、Amazon S3 統合」を参照してください。
-
Oracle RMAN の移行
Oracle Recovery Manager (RMAN) は、Oracle データベースをバックアップおよび復旧するためのツールです。また、オンプレミスおよびオンプレミスデータベースとクラウドデータベース間のデータベース移行を容易にするために使用されます。
Oracle RMAN は物理的な移行アプローチを提供します。このため、リホスト (Amazon EC2 への移行) はサポートされていますが、Amazon RDS for Oracle での Oracle データベースのリプラットフォームには使用できません。移行ダウンタイムの許容値は、Oracle RMAN 増分バックアップをバックアップおよび復元するのに十分な大きさである必要があります。
Amazon S3 への移行
Exadata データベースを Amazon S3 にバックアップするには、次のオプションを使用できます。
-
Oracle Secure Backup (OSB)
クラウドモジュールを使用して、Exadata データベースを Amazon S3 に直接バックアップします。 -
Oracle RMAN バックアップセットを Exadata RMAN バックアップの場所から Amazon S3 にコピーします。
-
Oracle ZFS Storage Appliances を使用します。Oracle ZFS Storage Appliances に保存されている Oracle RMAN バックアップセットは、Oracle ZFS Storage Appliance Amazon S3 を使用して Amazon S3 に直接転送できます。 S3
-
Oracle RMAN バックアップを Exadata Storage Server、Oracle Zero Loss Recovery Appliance、テープライブラリに直接保存します。その後、これらのストレージプラットフォームのいずれかの RMAN バックアップセットを Amazon S3 に転送できます。
Amazon EC2 への移行
RMAN を使用して、バックアップセットを作成せずに、Exadata データベースを Amazon EC2 上の Oracle Database に直接バックアップすることもできます。これを行うには、Oracle RMAN DUPLICATE コマンドを使用してバックアップと復元を実行します。ただし、Oracle RMAN DUPLICATEは大規模 (マルチ TiB) Exadata 移行には推奨されません。
RMAN 設定は通常、バックアップサイズ、Exadata CPU、圧縮、並列処理、RMAN チャネルの数などの要因に基づいて設定されます。RMAN で Oracle Service Bus (OSB) と圧縮 (低、中、高) を使用するには、Oracle Advanced Compression Option (ACO) ライセンスが必要です。OSB には、OSB で使用する RMAN チャネルの数に基づく Oracle ライセンスも必要です。
RMAN を使用して Amazon EC2 上の Oracle に Exadata を移行する場合は、次のベストプラクティスを検討してください。
注記
このセクションで提供されるコマンドは、Amazon EC2 インスタンスの Oracle で実行する必要があります。
-
Amazon EC2 で異なる Oracle ASM ディスクグループ名を使用する場合は、RMAN 復元プロセスで
set newnameコマンドを実行します。set newname for datafile 1 to '+<disk_group>'; set newname for datafile 2 to '+<disk_group>'; -
オンライン REDO ログが の別の場所に存在する場合は AWS、REDO ログファイルの名前を変更します。
alter database rename file '/<old_path>/redo01.log' to '+<disk_group>'; alter database rename file '/<old_path>/redo02.log' to '+<disk_group>'; -
データベースを正常に開いた後 AWS:
-
他のインスタンスの redo スレッドの redo ロググループを削除します。
alter database disable thread 2; alter database drop logfile group 4; alter database clear unarchived logfile group 4; -
他のインスタンスの元に戻すテーブルスペースを削除します。
drop tablespace UNDOTBS2 including contents and datafiles; -
TEMPテーブルスペースが 1 つだけ存在することを確認します。不要なTEMPテーブルスペースを削除し、既存のTEMPテーブルスペースが、予想されるデータベースワークロードを処理するのに十分な大きさであることを確認します。
-
HCC に関する考慮事項
Exadata で Hybrid Columnar Compression (HCC) を使用する場合は、HCC を持つすべてのテーブルを Oracle ACO に変換するか、無効にする必要があります AWS。そうしないと、Amazon EC2 で Oracle データベースにアクセスすると SQL ステートメントは失敗します。Oracle ACO には Oracle ライセンスが必要です。
通常、ユーザーはオンプレミスの Exadata 本番稼働用データベースから HCC を削除することはできません。データベースを移行するときに HCC を削除できます AWS。データベースを に移行した後に HCC がテーブルまたはパーティションでアクティブ化されているかどうかを確認するには AWS、次の SQL ステートメントを実行します。
select TABLE_NAME, COMPRESSION, COMPRESS_FOR from DBA_TABLES where OWNER like 'SCHEMA_NAME'; select TABLE_NAME, PARTITION_NAME, COMPRESSION, COMPRESS_FOR from DBA_TAB_PARTITIONS where TABLE_OWNER = 'SCHEMA_NAME';
compression 列の値が に設定ENABLEDされ、compress_for列に次のいずれかの値がある場合、HCC が有効になります。
-
QUERY LOW -
QUERY HIGH -
ARCHIVE LOW -
ARCHIVE HIGH -
QUERY LOW ROW LEVEL LOCKING -
QUERY HIGH ROW LEVEL LOCKING -
ARCHIVE LOW ROW LEVEL LOCKING -
ARCHIVE HIGH ROW LEVEL LOCKING -
NO ROW LEVEL LOCKING
テーブルまたはパーティションで HCC をオフにするには、次の SQL ステートメントを実行します。
alter table table_name nocompress; alter table table_name modify partition partition_name nocompress;
で Oracle ACO をアクティブ化するには AWS、Oracle ドキュメント
Oracle Data Guard の移行
Oracle Data Guard を使用すると、高可用性とディザスタリカバリのために 1 つ以上のスタンバイデータベースを作成および管理できます。Data Guard は、スタンバイデータベースをプライマリ (通常は本番稼働用) データベースのコピーとして維持します。本番稼働用データベースで計画的または計画外の可用性の問題が発生した場合、Data Guard はロールを切り替えてダウンタイムとアプリケーションの継続性を最小限に抑えることができます。
Data Guard を実装するには、論理スタンバイメソッドと物理スタンバイメソッドの両方を使用できます。このガイドでは、プライマリデータベースと完全に一致する物理スタンバイデータベースを使用していることを前提としています。
Data Guard は、Exadata から Amazon EC2 上の Oracle Database への移行をサポートし、物理的なスタンバイを作成します。Amazon RDS for Oracle への移行には使用できません。これには、Oracle Data Pump AWS DMSや Oracle GoldenGate などの論理的な移行アプローチが必要です。
Data Guard は、 AWS DMS や Oracle GoldenGate などの CDC メカニズムと比較して、Exadata データベース全体を移行するためのシンプルで迅速なアプローチです。ダウンタイムの要件が最小限である場合 (スイッチオーバーの時間しかない場合など)、通常は推奨されるアプローチです。
Data Guard は、同期トランスポートまたは非同期トランスポートで設定できます。一般的に、ラウンドトリップネットワークレイテンシーが 5 ミリ秒未満の場合、Oracle のお客様は同期トランスポートでより大きな成功を得ます。非同期トランスポートの場合、Oracle は 30 ミリ秒未満のラウンドトリップネットワークレイテンシーを推奨します。
通常、Data Guard スタンバイは、本番稼働用 Exadata オンプレミスデータベースに既に存在します。Amazon EC2 上の Oracle は、通常、本番稼働用 Exadata オンプレミスデータベース用の追加のスタンバイデータベースとして機能します。Oracle RMAN AWS を使用して、 で Data Guard スタンバイデータベースを作成することをお勧めします。
Data Guard のパフォーマンスに影響する変数は多数あります。Data Guard レプリケーションがワークロードに与える影響に関する結論を導き出す前に、テストを実行することをお勧めします。
Data Guard レプリケーションでは、使用されるメカニズムが異なるため、レイテンシー (ping モニターで測定) は重要ではありません。Oracle oratcptest ユーティリティは、ネットワークリソースの評価に役立ちます。oratcptest は、My Oracle Support (MOS) Note 2064368.1