Cloning and Production-to-Test content movement tools provide different functionality and have different use cases in Oracle Fusion Applications, on premises. This chapter compares the tools to assist you in choosing the correct one for your purposes.
Each tool has its respective user guide: the Oracle Fusion Applications Cloning Administrator's Guide, and the Oracle Fusion Applications Production to Test Administrator's Guide.
This chapter contains the following topics:
Content Movement includes two official tools for duplicating and updating multiple Fusion Applications installations. These multiple environments are typically used for development, testing, production, and so on.
Cloning means creating an exact replica of an entire Oracle Fusion Applications environment. The source is a complete, functioning installation which is replicated to a pristine, empty (OS-only) target environment. For more information about cloning, see Fusion Applications Cloning and Content Movement Administrator's Guide
Production-to-Test content movement is essentially a data refresh. It copies the database contents only, between two already-installed, matched Fusion Applications installations. The most common scenario is to copy production data into a test environment so that testing activities won't impact a production system. However, despite the production-to-test naming convention, the process can be used to move data from any Fusion Applications source to any parallel Fusion Applications target.
Note:
Standard database duplication is another kind of content movement, which is a subsection of cloning (duplicating the database structure and contents), but does not include the rest of the Fusion Applications instance.
Remember that Production-to-Test content movement is essentially a data refresh. It copies the database contents only, between two already-installed, matched Fusion Applications installations. Also keep in mind that despite the production-to-test naming convention, the process can be used to move data from any Fusion Applications source to any parallel Fusion Applications target (with the exception of production-to-production).
Common use cases for production-to-test include:
Testing functional or development tasks and integrations with production data, including identity data (users/roles/policies)
Validating patches on a test environment with production data, before applying the patch to the production system
Performing load testing with production data to size, plan for, and minimize load issues on the actual production environment.
Production-to-test functionality allows for test environments to have easily refreshed production data which can be used for testing development, testing patches, tuning, and sizing, without affecting the production system.
The table below summarizes the key points of each tool . Each area is explored in more depth in the relevant content movement Administrator's Guide.
Table 1-1 Quick Comparison Chart
| Category | Production to Test | Cloning |
|---|---|---|
|
Purpose |
Replicate FA data quickly for other uses (eg. functional, development, performance tests, patch test, audit etc.). Periodically refresh production data to another environment |
Replicate full Fusion Applications system including all security details to make a new environment. Clone a Fusion Applications system (typically once) and avoid fresh install – but allow for external URL change so they can run in parallel. Used for deploying new environments. |
|
Usage |
Source & target can run in parallel before and after P2T. Copies just source data (including security / customizations) to target. Reconciles IDM one-way from source to target with exceptions allowed. Does not change target system user passwords and also blanks out functional user passwords in target by default to not carry over prod passwords. |
Source and target can run in parallel before and after cloning. Copies complete source environment (binaries and all data) to target. Copies complete IDM data from source to target with no exceptions allowed. Carries over all passwords from source to target as is, and then, resets system user passwords in target (for better safety and to preclude any end user errors). Normal functional user passwords remain as is. |
|
Requirements |
A working Fusion Applications target and source Fusion Applications DB backup must exist – often they already do and so additional resource need is rare. Source and target should be working and allow for IDM replication (ldap calls) between them. Source and target Fusion Applications must be same version/patch levels. A cold backup of source FA DB (not IDM DB) and export of some target schemas are needed. Source FA DB will be copied over target during the P2T followed by import of the few exported target schemas. The Fusion Applications deployment topologies and configuration of source and target must the same – eg. what Fusion Applications servers run on what hosts, the LDAP location of IDM and FA jpsroot entities, Fusion Applications file system directory etc. The hostnames used for Fusion Applications internal endpoints need to be identical in source and target (ie. internal Fusion Applications hostname entries need to be copied into target /etc/hosts files to not conflict with DNS). |
Typically target infrastructure does not exist and provisioning hardware/network/storage/OS needs cost/time resources. Target is an empty environment with just OS running and hardware setup and sized to mimic and host the source environment. Target starts without Fusion Applications and ends with same installation as source. A complete cold backup of entire Fusion Applications source environment (filesystems and DBs) is needed. It will be copied into the empty OS environment of the target. The Fusion Applications deployment topologies and configuration of source and target must the same – eg. what Fusion Applications servers run on what hosts, the LDAP location of IDM and FA jpsroot entities, Fusion Applications filesystem directory etc. The hostnames used for Fusion Applications internal endpoints need to be identical in source and target (ie. internal Fusion Applications hostname entries need to be copied into target /etc/hosts files to not conflict with DNS). |
|
Process |
Once initial process is streamlined, periodic refresh is quick (typically done within a day). Short downtime needed for target during P2T. P2T time taken is mainly for: – manual prerequisite work, especially to sync source/target patch levels. – copying FA DB into target and packing of source data. – IDM LDAP replication from source to target Needs admin access to FA, IDM, DBs, file systems and OS. |
Once the prerequisites are ready (ie. FA source/target info and target hardware/OS/storage) the actual cloning process itself is relatively quick (about 2 days). No source downtime needed during Cloning work. Cloning time taken is mainly for : – manual prerequisite work especially to create target hardware/OS/storage. – copying source FA files and DBs into target – post-clone steps Needs admin access to FA, IDM, DBs, file systems, OS & storage. |
|
Limitations |
Best used to refresh production data into test environment. While periodic repeat of P2T is perfect usage, avoid any possibility of cycling data back to source (production) environment. Transaction data is copied from source to target but some historic logs and pending notifications that may conflict with source environment are left out. Check this for corner-case system audits. Source data is copied to target, so data issues may spill to target and functional validation is always good. However, P2T does allow exceptions to IDM reconciliation. |
No limitations on how often to replicate (even cyclically) provided each target environment is self-contained by ensuring that FA internal hostnames do not conflict between environments. Complete data is replicated from source into target, but in-flight transactions are truncated to preclude any target transactions pointing to source and this needs to be minded for corner-case system audits. There are no exceptions in moving data from source to target – complete data comes through and only changes made are to delete pending transactions and change target system passwords. |