かわりに、インスタンスを別のコンパートメントに移動する場合は、別のコンパートメントへのインスタンスの移動を参照してください。

このタイプの移動を検討している場合は、移動をスムーズにするためのベスト・プラクティスをいくつか示します。

• Oracle Integrationインスタンスのカスタム・エンドポイントを使用します。インスタンスのカスタム・エンドポイントの構成に関する項を参照してください。すべてのクライアントが新規カスタム・エンドポイントを使用していることを確認します。
• 設計時メタデータをエクスポートおよびインポートして、既存の構成を新しいリージョンの新規インスタンスに移動します。Oracle Integration 3での統合の使用のサービス・インスタンス全体の設計時メタデータのクローニングを参照してください。
• できるだけ新しい地域での検証をしましょう。ただし、重複処理を回避するためにポーリングまたはスケジュールを開始しないでください。
• 新しいインスタンスに対して同じカスタム・エンドポイントを構成しますが、現時点ではDNS Canonical Name (CNAME)を更新しません。
• 新しいリージョン内のすべての検証が完了し、すべての非ポーリング統合がアクティブ化されている場合は、新しいOracle Integrationインスタンス・ホスト名を指すようにカスタム・エンドポイントCNAMEを切り替えます。
• ポーリング統合を非アクティブ化し、古いインスタンスのスケジュールを停止します。
• ポーリング統合をアクティブ化し、新しいインスタンスでスケジュールを開始します。
• ファイル・サーバーを使用する場合、各リージョンおよびホスト名にはロード・バランサが必要になる可能性があります。ファイル・サーバーのポート番号がインスタンス間で一致することは保証されていないため、ロード・バランサはポート・マッピングを実行します。これは、ホスト名とともに、外部クライアントに標準のSFTPポートを使用する絶好の機会です。ロード・バランサが各リージョンに設定され、動作することが確認されたら、トラフィックを新しいファイル・サーバーに移動する準備ができたら、ホスト名を新しいリージョン・ロード・バランサに切り替えることができます。
• これらのベスト・プラクティスを使用して、新しいストライプに移動できます。ただし、両方のインスタンスを同時にアクティブにすることはできず、元のインスタンスを削除する必要があります。