Here is the article on the process to create a clone/refresh request and the guidelines to consider for a better planning
- P2T – PROD as a source instance and TEST as target Instance clone. TEST can be any NON PROD instances like DEV, SIT and TEST
- T2T – TEST to TEST instance clone. This is a clone between any non-PROD instances
- Clone Request Process: An SR has to be raised with Oracle at least 3-4 weeks in advance to request for a clone. Raising an SR in advance is not a confirmation of a slot, Oracle would come up with final options of dates for customers to choose based on the slots available and slots are given based on a first come first serve basis
- Prerequisites: Both the source and target environments must be on same application release, patch set level and language pack
- The final check of release, patch set level and language happens five days prior to the start of the scheduled refresh. In case of any differences in patch set, release or language pack, oracle would raise a flag and clone SR has to be either canceled or a clone dates should be changed based on the sync of path sets
- Downtime The refresh duration could vary anywhere between 8 to 48 hours, including contingencies. Typically, the refresh completes in 8 hours
- The refresh process requires no downtime for the source environment but the target environment goes down during the refresh.
- Oracle takes a backup of the source environment at the start time of the environment refresh system outage notification. Data entered into the source environment before that time will be included in the clone
- Cancellation of P2T/T2Ts requires a minimum of 3-4 days’ of advance notice
- Blackout Period: Environments are subjected to blackout period around Monthly patches and Quarterly software upgrade patches. No new P2T/T2Ts are allowed in blackout period.
- Quarterly: Blackout period starts 5 days before software upgrade and ends after 3 days of the upgrade
- Monthly: Blackout period starts 2 days before applying patches and ends after 3 days of applying patches
- All Fridays are black-out days for all services & releases and P2T/T2T cannot be scheduled on any Fridays
- T2P – TEST to PROD clone is not recommended by Oracle, but an SR can be raised to check the feasibility or alternate options
- Oracle reserves the right to change the dates at any time.
- Changes to the Source, Target or Customer desired dates require you to create a new SR as our Request Fulfillment process is based exclusively on these 3 parameters. This will restart this 3 week notice period and can move the P2T/T2T’s schedule out.
- Data Note Copied on Clone:
- Worklist Notifications and Approval requests
- ESS and BIP Request History
- SOA Transaction tables
- Audit table
- Data masking of HCM and PII data can be requested on SR clone request. Refer to oracle support note for more details – Oracle Cloud Applications – Data Masking Standalone Service Entitlement, Doc ID 2092389.1
- SSO: In case of SSO enabled on Source Instance but not on the target instance, Users will not be able to login, since passwords are not setup. An SR has to be raised to update password of an ADMIN user, so that ADMIN can update passwords of rest of the users
Please drop a comment if you may have any question on this topic and do comment if you have anything to add. Thanks for reading the article!