Cloning an Oracle database

You can use SnapCenter to clone an Oracle database using the backup of the database. The cloning operation creates a copy of the database data files, and creates new online redo log files and control files. The database can be optionally recovered to a specified time, based on the specified recovery options.

Before you begin

You should have created a backup of the database using SnapCenter.
The backups should be successfully created. You should have either online data and log backups, or offline (mount or shutdown) backups created for the cloning operation to succeed.
If you want to customize the control file or redo log file paths, you should have preprovisioned the required file system or Automatic Storage Management (ASM) disk group.
By default, redo log and control files of the cloned database are created on the ASM disk group or the file system provisioned by SnapCenter for the data files of the clone database.
The clone can be created on the same host as that of the source database or on an alternate host.
If you are creating the clone on an alternate host, the alternate host must meet the following requirements:
- SnapCenter Plug-in for Oracle Database should be installed on the alternate host.
- The clone host should be able to discover LUNs from primary or secondary storage.
  - If you are cloning from primary storage or secondary (Vault or Mirror) storage to an alternate host, then make sure that an iSCSI session is either established between the secondary storage and the alternate host, or zoned properly for FC.
    Linux Host Utilities Installation and Setup Guide.
  - If you are cloning from Vault or Mirror storage to the same host, then make sure that an iSCSI session is either established between the Vault or Mirror storage and the host, or zoned properly for FC.
  - If you are cloning in a virtualized environment, ensure that an iSCSI session is either established between the primary or secondary storage and the ESX server hosting the alternate host, or zoned properly for FC.
- If the source database is an ASM database:
  - The ASM instance should be up and running on the host where the clone will be performed.
  - The ASM disk group should be provisioned prior to the clone operation if you want to place archive log files of the cloned database in a dedicated ASM disk group.
  - The name of the data disk group can be configured, but ensure that the name is not used by any other ASM disk group on the host where the clone will be performed.
    Data files residing on the ASM disk group are provisioned as part of the SnapCenter clone workflow.
The protection type for the data LUN and the log LUN, such as mirror, vault, or mirror-vault, should be the same to discover secondary locators during cloning to an alternate host using log backups.
You should set the value of exclude_seed_cdb_view to FALSE in the source database parameter file to retrieve seed PDB related information for cloning a backup of 12c database.
The seed PDB is a system-supplied template that the CDB can use to create PDBs. The seed PDB is named PDB$SEED. For information about PDB$SEED, see the Oracle Doc ID 1940806.1.

Note: You should set the value before backing up 12c database.
SnapCenter supports backup of file systems that are managed by the autofs subsystem. If you are cloning the database, ensure that data mount points are not under the root of the autofs mount point because the root user of the plug-in host does not have permission to create directories under the root of the autofs mount point.
If control and redo log files are under data mount point, you should modify the control file path, and then redo log file path accordingly.

Note: You can manually register the new cloned mount points with the autofs subsystem. The new cloned mount points will not be registered automatically.
If you have a TDE (auto login) and want to clone the database on the same or alternate host, you should copy wallet (key files) under /etc/ORACLE/WALLET/$ORACLE_SID from the source database to the cloned database.

About this task

SnapCenter creates a stand-alone database when cloned from an Oracle RAC database backup. SnapCenter supports creating clone from the backup of a Data Guard standby and Active Data Guard standby databases.

During cloning, SnapCenter mounts the log backup for recovery operations. After recovery, the log backup is unmounted. All such clones are mounted under /var/opt/snapcenter/scu/clones/. If you are using ASM over NFS, you should add /var/opt/snapcenter/scu/clones/*/* to the existing path defined in the asm_diskstring parameter.

While cloning a backup of an ASM database in a SAN environment, udev rules for the cloned host devices are created at /etc/udev/rules.d/999-scu-netapp.rules. These udev rules associated with the cloned host devices are deleted when you delete the clone.

Steps

In the left navigation pane, click Resources, and then select the appropriate plug-in from the list.
In the Resources page, select either Database or Resource Group from the View list.
Select the database either from the database details view or from the resource group details view.
The database topology page is displayed.
From the Manage Copies view, select the backups either from Local copies (primary), Mirror copies (secondary), or Vault copies (secondary).
Select the Data backup from the table, and then click .
In the Name page, enter the SID of the clone.
The clone SID is not available by default, and the maximum length of the SID is 8 characters.
Note: You should ensure that no database with the same SID exists on the host where the clone will be created.

In the Locations page, perform the following actions:

For this field...	Do this...
Clone host	By default, the source database host is populated. If you want to create the clone on an alternate host, select the host having the same version of Oracle and OS as that of the source database host.
Datafile locations	By default, the datafile location is populated. The SnapCenter default naming convention for SAN or NFS file systems is `FileSystemNameofsourcedatabase`_`CLONESID`. The SnapCenter default naming convention for ASM disk groups is SC_`HASHCODEofDISKGROUP`_`CLONESID`. The `HASHCODEofDISKGROUP` is an automatically generated number (2 to 10 digits) that is unique for each ASM disk group. Note: If you are customizing the ASM disk group name, ensure that the name length adheres to the maximum length supported by Oracle. If you want to specify a different path, you must enter the datafile mount points or ASM disk group names for clone database. When you customize the datafile path, you must also change the control file and redo log file ASM disk group names or file system either to the same name used for data files or to an existing ASM disk groups or file system.
Control files	By default, the control file path is populated. The control files are placed in the same ASM disk group or file system as that of the data files. If you want to override the control file path, you can provide a different control file path. Note: The file system or the ASM disk group should exist on the host. By default, the number of control files will be same as that of the source database. You can modify the number of control files but a minimum of one control file is required to clone the database. You can customize the control file path to a different file system (existing) than that of the source database.
Redo logs	By default, the redo log file group, path, and their sizes are populated. The redo logs are placed in the same ASM disk group or file system as that of the data files of the cloned database. If you want to override the redo log file path, you can customize the redo log file path to a different file system than that of the source database.. Note: The new file system or the ASM disk group should exist on the host. By default, the number of redo log groups, redo log files, and their sizes will be same as that of the source database. You can modify the following parameters: Number of redo log groups Note: A minimum of three redo log groups are required to clone the database. Redo log files in each group and their path Note: A minimum of one redo log file is required in the redo log group to clone the database. You can customize the redo log file path to a different file system (existing) than that of the source database. Sizes of the redo log file

In the Credentials page, perform the following actions:

For this field...	Do this...
Credential name for sys user	Select the Credential to be used for defining the sys user password of the clone database. If SQLNET.AUTHENTICATION_SERVICES is set to NONE in sqlnet.ora file on the target host, you should not select None as the Credential in the SnapCenter GUI.
ASM Instance Credential name	Select None if OS authentication is enabled for connecting to the ASM instance on the clone host. Otherwise, select the Oracle ASM credential configured with either "sys" user or an user having "sysasm" privilege applicable to the clone host.

The Oracle home, user name, and group details are automatically populated from the source database. You can change the values based on the Oracle environment of the host where the clone will be created.

In the PreOps page, perform the following steps:
1. Enter the path and the arguments of the prescript that you want to run before the clone operation.
  You must store the prescript either in /var/opt/snapcenter/spl/scripts or in any folder inside this path. By default, the /var/opt/snapcenter/spl/scripts path is populated. If you have placed the script in any folder inside this path, you need to provide the complete path up to the folder where the script is placed.
2. In the Database Parameter settings section, modify the values of prepopulated database parameters that are used to initialize the database.
  You can add additional parameters by clicking .
  Note: Fast recovery area (FRA) is not defined is the prepopulated database parameters. You can configure FRA by adding the related parameters.
  
  Note: The default value of log_archive_dest_1 is $ORACLE_HOME/clone_sid and the archive logs of the cloned database will be created in this location. If you have deleted the log_archive_dest_1 parameter, the archive log location is determined by Oracle. You can define a new location for archive log by editing log_archive_dest_1 but ensure that the file system or disk group should be existing and made available on the host.
  NetApp Knowledgebase Answer 1086191: SnapCenter Oracle restore or clone fails with the message 'ORA-00308: cannot open archived log /ORA_LOG/arch1_123_456789012.arc'
  
  Click Reset to get the default database parameter settings.

In the PostOps page, Recover database and Until Cancel are selected by default to perform recovery of the cloned database.

SnapCenter performs recovery by mounting the latest log backup that have the unbroken sequence of archive logs after the data backup that was selected for cloning. The log and data backup should be on primary storage to perform the clone on primary storage and log and data backup should be on secondary storage to perform the clone on secondary storage.

The Recover database and Until Cancel options are not selected if SnapCenter fails to find the appropriate log backups. You can provide the external archive log location if log backup is not available in Specify external archive log locations. You can specify multiple log locations.

Note: If you want to clone a source database that is configured to support flash recovery area (FRA) and Oracle Managed Files (OMF), the log destination for recovery must also adhere to OMF directory structure.

The PostOps page is not displayed if the source database is a Data Guard standby or an Active Data Guard standby database. For Data Guard standby or an Active Data Guard standby database, SnapCenter does not provide an option to select the type of recovery in the SnapCenter GUI but the database is recovered using Until Cancel recovery type without applying any logs.

Filed name	Description
Until Cancel	SnapCenter performs recovery by mounting the latest log backup having the unbroken sequence of archive logs after that data backup that was selected for cloning. The cloned database is recovered till the missing or corrupt log file.
Date and time	SnapCenter recovers the database up to a specified date and time. The accepted format is `mm/dd/yyyy hh:mm:ss`. Note: The time can be specified in 24 hour format.
Until SCN (System Change Number)	SnapCenter recovers the database up to a specified system change number (SCN).
Specify external archive log locations	Specify the external archive log location.
Create new DBID	By default Create new DBID check box is selected to generate a unique number (DBID) for the cloned database differentiating it from the source database. Clear the check box if you are fine to have the same DBID for the cloned database as that of the source database. In this scenario, if you want to register the cloned database with the external RMAN catalog where the source database is already registered, the operation fails.

In the Notification page, from the Email preference drop-down list, select the scenarios in which you want to send the emails.
You must also specify the sender and receiver email addresses, and the subject of the email. If you want to attach the report of the restore operation performed, select Attach Job Report.
Note: For email notification, you must have specified the SMTP server details using the either the GUI or the PowerShell command Set-SmSmtpServer.
Review the summary, and then click Finish.
Note: While performing recovery as part of clone create operation, even if recovery fails, the clone is created with a warning. You can perform manual recovery on this clone to bring the clone database to consistent state.
Monitor the operation progress by clicking Monitor > Jobs.

Result

After cloning the database you can refresh the resources page to list the cloned database as one of the resource available for backup. The cloned database can be protected like any other database using the standard backup workflow or can be included in a resource group (either newly created or existing). The cloned database can be further cloned (clone of clones).

Note: If you have not performed recovery while cloning, the backing up of the cloned database might fail due to improper recovery and you might have to perform manual recovery. The log backup can also fail if default location which was populated for archive logs is on a non-NetApp storage or if the storage system is not configured with SnapCenter.