Refreshing Data (Cloning)

Cloning Process Overview

This section provides an overview of the cloning process.

What is Environment Cloning

Environment cloning is a process of cloning data from source to target environment. The most frequent use cases include:

• During implementation, to clone an environment with converted data to another environment for System Integration testing or User Acceptance Testing.
• Once live, to clone Production data to a Test environment.

  Note:

  For moving configuration data from any Dev sized environment to a Test and/or Prod environment, Oracle recommends using Process Automation and/or Content Migration Assistant (CMA).

Pre-requisites for Requesting Environment Clones

• The source environment version must be compatible with the target environment version. Compatibility is defined as the source version being either the same version or one version lower than the target version. For example, a source environment version 24B can be cloned to a target environment version 24C, but not to a target environment version 25.4 or 24A.
• Cross-product clones are also supported from Meter Solution Cloud Service (MSCS) to Customer Cloud Service (CCS).
• Non-Mandatory: Any information you have on your target environment that you want to keep (including message senders, user information, etc) can be preserved using the following procedure:
  • Before you submit the clone request, extract the information you want to preserve using CMA Export.
  • After the clone procedure was successfully completed, import the preserved data using CMA Import.
• During the implementation phase, a customer can request:
  • A Dev-sized environment to be cloned to another Dev-sized environment.

    However as an exception, if a clone from Dev to Test and or Prod is required, the Customer will need to submit evidence of up-to-date ILM partitioning in the Source environment. Please refer to “Chapter 7: Information Lifecycle Management” in Oracle Utilities Cloud Services Implementation Guide for more details.

  • A Test-sized environment can be cloned to another Dev, Test or Prod environment as long as the source environment size is within the usage limits of the target environment.
  • A Production environment can be cloned to another Dev or Test environment as long as the source environment size is within usage limits of the target environment.
  • Refer to the Usage Limits section in the Oracle Energy and Water Cloud Services document.
  • Once the customer is live, a non-prod environment will not be cloned to the Prod environment.

Frequency of Clone Requests

There is a limit to number of data refresh (cloning) requests that a customer can make. Refer to the Usage Limits section in the Oracle Energy and Water Cloud Services document.

Process of Cloning

Cloning in Oracle Utilities cloud environments is done by using following two methods:

• Hot clone (in which the source environment will be online during the cloning activity)
• Cold clone (in which the source environment will not be available for certain duration of the cloning activity)

Note: Hot clone will be performed only for live customers where source environment is Production.

The following data would be preserved in the target environment

• Process automation configuration (only when cloning in between same cloud services for example CCS to CCS), used for running CMA between environments
• •Process automation configuration will be recreated from base of the target environment, if cloning source and target cloud services are different for example from MSCS to CCS.
• Configuration related to how the target environment is identified by name is preserved in the clone. For example, if the target environment is called "DEV01"
• Environment specific Oracle Object Storage configurations are preserved during the clone and not overwritten by source data.
• Key Rings: Additional key rings may be added, existing key rings from clone source may be updated. Keys are copied for both
• •Key rings that are in the clone source but not in the clone target environment are NOT deleted. However, their keys are deleted, because they will not be usable in the target system. You will have to create new keys.
• Similar to key rings, F1-FileStorage extendable lookup values are preserved from the target to the clone. The ones only in the source are kept, but the BO data area is set to null to erase the contents.

The following data would be neither cloned nor preserved in the target environment:

• Configuration related to outbound integrations with external systems are NOT preserved if the source environment is a production environment (including message senders, external system references). Customer must reconfigure these as post cloning steps. Please refer to Post-Cloning Steps below for more information. Customers can use Content Migration Assistant (CMA) to preserve custom message senders and apply them after the clone has been created to save time.
• Identity Cloud Service (IDCS) or Oracle Cloud Infrastructure Identity and Access Management (IAM) users are not migrated from source to target IDCS or IAM. Therefore, users that exist as IDCS or IAM Users with rights to access the source environment will not automatically have IDCS or IAM rights to access the target environment. Customers may need to adjust this manually as needed (please refer to Identity and Access Management with Identity Domains in the Oracle Utilities Cloud Services Administration Guide for details).
• If a user exists in the target environment IDCS or IAM instance, but is not defined in the original source application environment, the user will be created upon access with minimal access.

Business Impact

For clone requests of live production environments, no outage is expected on the source environment because the Hot clone method will be used.

For all other types of clone requests, there will be an outage on the source environment for the initial stage of the cloning process. This is when data is extracted from the source environment.

Source environment outage window:

Database Size	Duration of Refresh (in hours)
Up to 3 TB	3 hours
Between 3 TB and 6 TB	5 hours
Between 6 TB and 9 TB	7 hours
Larger than 9 TB	More than 8 hours

The target environment require an outage for the duration of 3 hours.

Customer Notifications

The customer will receive notifications/ status updates as per the following guidelines:

• When the activity gets scheduled
• Interim update to announce that source environment is back - on the day of the activity for the cold clone approach
• Irrespective of clone approach (hot/cold), an interim update to notify bringing down of the target environment.
• Completion notification once the activity gets completed.
• Extension notification in case the activity is taking more time to complete, there on interim updates every three hours until completion of the activity

Post Cloning Steps

There are post-cloning steps that the customer must perform from the application user interface on the target environment before it can be released to end users. Once you receive cloning request completion notification from Oracle Support, you may require to perform the following steps:

1. Review Batch Controls for file path references to object storage buckets and or file names and change if necessary.
2. 2. Import custom Message Senders previously exported via CMA (see Doc ID 2863460.1 on My Oracle Support)
3. 3. Review Reporting Options: Check that 'Reporting Server from Browser' URL value is correct environment.
4. 4. Review Scheduler Programs and activate as necessary:
   1. Select Admin, the Batch Operations, then Scheduler Programs, and then Search.
   2. Review the Scheduler Programs that are in the "Inactive" state.
   3. For each of the Scheduler Programs that you would like to Activate, click on the description to navigate to the scheduler program:
      1. Click Edit in the Record Actions section to edit the scheduler program.
      2. Change the status from "Inactive" to "Active" and click Save.
5. Review Batch Job Stream Definitions and activate as necessary:
   1. Select Admin, the Batch Operations, then Batch Job Stream Definition, and then Search.
   2. b. Review the batch job stream definitions that are in the "Pending" state.
   3. For each of the batch job stream definition that you would like to Activate, click on the description to navigate to the batch job stream definition:
      1. i. Click Activate in the Record Actions section to activate the batch job stream definition.

Submitting a Request for Cloning

The customer can request to refresh data from one environment to another environment(s). The customer or system integrator must ensure its obligations are met at the time of scheduled activity. If any obligations are found to be incomplete, it will result in rescheduling of the cloning activity to a different date.

Customer Obligations

• The customer must specify the desired date/ time of the cut of the source environment if needed.
• The customer must submit one service request per cloning request.
• The scheduling of the clone activity for multiple clone requests made during same day or same week will be scheduled as per available slots, and the 7 business day service level objective may not be met for all requests

Oracle Cloud Operations Team Acknowledgment and Scheduling Obligations

• Acknowledge and schedule the execution of the service request.
• Inform the customer about the clone activity date/ time and ETA of activity via Service Request (SR) response.
• If the customer requested schedule is not available, propose alternative available schedule.
• Once the schedule is confirmed, send scheduled maintenance notification to the customer prior to its execution.

Oracle Cloud Operations Team Execution Obligations

• Provide the status updates as detailed in the Customer Notifications section

Customer Change Requests to Existing Clone Request

• Once the clone activity has been performed, it will not be possible to revert the environment to a prior state before the activity.
• If for any reason, the customer wishes to postpone the clone to a different date OR wish to change the environment (source or target), it will require the following:
  • Customers are advised to provide at least 48 hours advance notice when cancelling existing clone requests.
  • Customers will need to create a new service request ticket. The ticket will be counted as a fresh request by Oracle and will follow the SLA for the new request.
  • Customers will intimate this change on the existing Service request ticket providing reference of the new service request created and will then close the ticket
  • Oracle will acknowledge the new service request, perform pre-checks listed in the Pre-requisites for Requesting Environment Clones section above and availability of the requested schedule.
  • Oracle will update the Service request Ticket and confirm schedule.

Service Level Objective

• Advanced Notice: 7 business days (exception if the customer makes multiple clone requests at once, only the highest priority clone request will target this service level objective)
• Acknowledge/Schedule: 2 business days
• Execution Time: Based on the size of the source environment. Please see the table in Business Impact section above.
• Outage Expected: See the Business Impact section above