In this article we will explain how to clone your Fusion Cloud Test environment from Production.
Prepare in Advance (Well in Advance)
Gone are the days when you request your DBA’s to take backups of your test environment and clone from your Production. The process is highly simplified in cloud. As we all know that with Fusion cloud, the client is not maintaining any hardware in house (or at least that is the expectation). The hardware is hosted by Oracle in one of their many data centers and the software installation, update and cloning are taken care of Oracle. For a lot of customers that’s a huge relief whereas some customers dislike the idea of waiting for weeks before their cloning request is executed. Yes, you read it right. The expected wait time is 3-6 weeks on an average. But one thing to note here. Oracle does accept exceptions if the customer has a strong case. But we still recommend that you plan your clone/refresh well in advance to avoid the last minute rush.
Private Cloud Deployment architecture:
- This is the SAS (Software as a service model) where the hardware and software are provided by Oracle or Oracle business partners that offer BPO solutions.
- Oracle is responsible for overall management, patching, security and other upgrade services.
- Hosted over the internet for easy access from any locations.
The request of a clone or P2T is done by an SR. The customer or someone from the implementation partner team creates the SR. Once the SR is raised, Oracle will provide the available dates and the customer chooses the one that suits them.
This is how a P2T request SR looks like:
Step 1: Enter the basic SR details
Step 2: Answer the set of questions
Enter the source target POD details
If upgrade dates are available, please provide those details
Provide the contact information of the key person
Optionally give a feedback. Else proceed to create the SR. In case of an expedited P2T, you can add any supporting documents as an attachment.
Determine the severity of the request. For normal request, we recommend setting it as a severity 2. For expedited requests, you can mark it as severity 1.
That’s it….Simply follow up on the SR to accept the final dates and you are done. If properly planned, this is really a breeze.
Points to Consider
Below are some of the key points when requesting to clone your Fusion Cloud Test environment from Production:
1. P2T/T2T service requests need 3 – 4 business days for initial approval and scheduling.
2. P2T/T2T requires that the source and target be on the same release, patches, and language packs.
3. P2T is not available for customers who patched their non-production with a weekly stage bundle (WSB) patching cadence. If the WSB patching cadence was canceled by the last day of the month, P2Ts can be scheduled the following month after production patching weekend (after Sunday following the 3rd Friday of the month).
4. P2T/T2T slot is given to customers on a first-come, first-served basis.
5. The P2T/T2T request absolutely needs a minimum of 3 weeks notice in the service request for processing (customer desired date to be at least 3 weeks after the SR create date). Since scheduling a P2T/T2T depends on the resource availability, this advance notice does not guarantee a spot, it is just the time required to execute the pre-requisite steps before scheduling the P2T/T2T. Less than 3 weeks’ notice does not even start the pre-req process. Also, P2T/T2T cannot be scheduled more than 12 weeks from SR Create date. 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.
6. If there is a release upgrade scheduled on the Stage/Test Environment, the P2T/T2T (which takes 48 hours) needs to be completed at least 72 hours prior to scheduled release upgrade start date/time. This means the P2T/T2T should start 5 days prior to the upgrade start date.
7. After P2T/T2T scheduling, it is the customer’s responsibility to make sure any patches and language packs that are deployed into one of the environment gets deployed into the other as well (for syncing).
8. Please be aware that the source environment will not go down during this activity. The target environment, however, will be down for around 48 hours, depending on the amount of data in the database.
9. P2T cannot happen in reverse (i.e., T2P).
10. If patches and languages are out of sync, customers will be given one or all of the options below:
a. Cancel P2T/T2T
b. Move the P2T/T2T date
c. Sync patches either in Production and/or Test (Environment Outage time is needed on both)
d. Wait until patch deployment, install language packs, etc.
11. Current Oracle release dictates a monthly black-out period for P2Ts. The black-out period is generally from the 1st Friday (Stage Patching) to the Saturday after the 3rd Friday of the month (Production Patching). The exceptions are:
a. P2Ts for previous release (where periodic monthly patching has been stopped)
b. T2Ts, which are usually patch-synced on the First Friday
c. Environment pairs are patched concurrently (until Production go-live).
12. All Fridays are black-out days for all services & releases and P2T/T2T cannot be scheduled on any Fridays.
13. The final patch check happens 1-5 days prior to the scheduled P2T/T2T start date.
14. Oracle reserves the right to change the dates at any time.
15. Cancelation of P2T/T2Ts require a minimum of 7 days notice.