Skip to main content
SnapManager Oracle

Creating clone specifications

Contributors
PDFs

SnapManager for Oracle uses a clone specification XML file, which includes the mappings, options, and parameters for use in the clone operation. SnapManager uses this information to determine where to place the files it clones and how to handle diagnostic information, control files, parameters, and so on.

You can create the clone specification file by using the SnapManager graphical user interface (GUI), command-line interface (CLI), or a text editor.

When you create the clone specification file by using a text editor, you must save it as a .xml file. You can use this XML file for other clone operations.

You can also create a clone specification template and then customize it. You can use the smo clone template command or in the GUI, use the Clone wizard.

SnapManager for Oracle adds a version string to any clone specification template that it generates. SnapManager for Oracle assumes the latest version for any clone specification file that lacks a version string.

If you want to perform remote cloning, do not change the default locations of the data files, redo log files, and control files in the clone specification file. If you change the default location, SnapManager fails to create the clone or creates the clone on a database that does not support Snapshot capability. Therefore, the automatic creation of profile fails.

Note Though mount point and ASM disk group information are editable from the GUI, you can only change the file name and not the file locations.

You can execute a task multiple times, either with the same or different parameter and value combinations.

  1. Open a text file and enter text as shown in the following example:

    <clone-specification xmlns="http://www.example.com>
     <storage-specification/>
     <database-specification/>
 </clone-specification>

  2. In the storage specification component, enter the mount points for the data files.

    The storage specification lists the locations for the new storage created for the clone such as data file mount points and raw devices. These items must be mapped from the source to the destination.

    The following example displays the data file mount point syntax that you use in the clone specification:

    <mountpoint>
     <source>/mnt/path/source_data file_mountpoint</source>
     <destination>/mnt/path/target_data file_mountpoint</destination>
</mountpoint>

  3. Optional: If you have a raw device on the source, you must specify the path for the raw device on the source, and then specify destination auto-generate=`"true`" for the destination.

    Unlike in the clone mapping file from previous versions of SnapManager for Oracle, you cannot specify a location for the raw device on the destination. SnapManager for Oracle will choose the next available device name for the cloned raw device.

    The following example displays the raw device syntax that you use in clone specification:

    <raw-device>
     <source>/dev/raw/raw1</source>
     <destination auto-generate="true"/>
</raw-device>

  4. In the database specification component, identify the control file information as a list of the control files that you want created for the clone.

    The database specification specifies the database options for the clone such as control files, redo logs, archive logs, and Oracle parameters.

    The following example displays the control file syntax that you use in clone specification:

    <controlfiles>
     <file>/mnt/path/clonename/control/control01.ctl</file>
     <file>/mnt/path/clonename/control/control02.ctl</file>
</controlfiles>

  5. Specify the redo log structure for the clone.

    The following example displays the redo log directory structure for cloning:

    <redologs>
     <redogroup>
          <file>/mnt/path/clonename/redo/redo01.log</file>
          <number>1</number>
          <size unit="M">100</size>
     </redogroup>
     <redogroup>
         <file>/mnt/path/clonename/redo/redo02.log</file>
         <number>2</number>
         <size unit="M">100</size>
     </redogroup>
</redologs>

  6. Specify the Oracle parameters that should be set to different values in the cloned database. If you are using Oracle 10, you must specify the following parameters:

    • Background dump

    • Core dump

    • User dump

    • (Optional) Archive logs

      Note If the parameter values are not set correctly, the clone operation is stopped and you receive an error message.

    If you do not specify the location where archive logs are stored, SnapManager creates the clone in noarchivelog mode. SnapManager copies this parameter information into the init.ora file of the clone.

    + The following example displays the parameter syntax that you use in clone specification:

    +

    <parameters>
     <parameter>
          <name>log_archive_dest_1</name>
          <value>LOCATION=/mnt/path/clonename/archive</value>
     </parameter>
</parameters>

    + You can use a default value by using a default element within the parameter element. In the following example, the os_authentication_prefix parameter will take the default value because the default element is specified:

    +

    <parameters>
     <parameter>
          <name>os_authent_prefix</name>
          <default></default>
     </parameter>
</parameters>

    + You can specify an empty string as the value for a parameter by using an empty element. In the following example, the os_authentication_prefix will be set to an empty string:

    +

    <parameters>
     <parameter>
          <name>os_authent_prefix</name>
          <value></value>
     </parameter>
</parameters>

    + NOTE: You can use the value from the source database's init.ora file for the parameter by not specifying any element.

    + If a parameter has multiple values, then you can provide the parameter values separated by commas. For example, if you want to move the data files from one location to another, then you can use the db_file_name_convert parameter and specify the data file paths separated by commas as seen in the following example:

    +

    <parameters>
     <parameter>
          <name>db_file_name_convert</name>
          <value>>/mnt/path/clonename/data file1,/mnt/path/clonename/data file2</value>
     </parameter>
</parameters>

    + If you want to move the log files from one location to another, then following you can use the log_file_name_convert parameter and specify the log file paths separated by commas, as seen in the example:

    +

    <parameters>
     <parameter>
          <name>log_file_name_convert</name>
          <value>>/mnt/path/clonename/archivle1,/mnt/path/clonename/archivle2</value>
     </parameter>
</parameters>

  7. Optional: Specify arbitrary SQL statements to execute against the clone when it is online.

    You can use the SQL statements to perform tasks such as re-creating the temp files in the cloned database.

    Note You must ensure that a semicolon is not included at the end of the SQL statement.

    The following is a sample SQL statement that you execute as part of the clone operation:

    <sql-statements>
   <sql-statement>
     ALTER TABLESPACE TEMP ADD
     TEMPFILE '/mnt/path/clonename/temp_user01.dbf'
     SIZE 41943040 REUSE AUTOEXTEND ON NEXT 655360
     MAXSIZE 32767M
   </sql-statement>
</sql-statements>

Clone specification example

The following example displays the clone specification structure, including both the storage and database specification components:

<clone-specification xmlns="http://www.example.com>

   <storage-specification>
     <storage-mapping>
        <mountpoint>
          <source>/mnt/path/source_mountpoint</source>
          <destination>/mnt/path/target_mountpoint</destination>
        </mountpoint>
        <raw-device>
          <source>/dev/raw/raw1</source>
          <destination auto-generate="true"/>
        </raw-device>
        <raw-device>
          <source>/dev/raw/raw2</source>
          <destination auto-generate="true"/>
        </raw-device>
     </storage-mapping>
   </storage-specification>

   <database-specification>
     <controlfiles>
       <file>/mnt/path/clonename/control/control01.ctl</file>
       <file>/mnt/path/clonename/control/control02.ctl</file>
     </controlfiles>
     <redologs>
         <redogroup>
           <file>/mnt/path/clonename/redo/redo01.log</file>
           <number>1</number>
           <size unit="M">100</size>
        </redogroup>
        <redogroup>
           <file>/mnt/path/clonename/redo/redo02.log</file>
           <number>2</number>
           <size unit="M">100</size>
        </redogroup>
    </redologs>
    <parameters>
      <parameter>
        <name>log_archive_dest_1</name>
        <value>LOCATION=/mnt/path/clonename/archive</value>
      </parameter>
      <parameter>
        <name>background_dump_dest</name>
        <value>/mnt/path/clonename/admin/bdump</value>
      </parameter>
      <parameter>
        <name>core_dump_dest</name>
        <value>/mnt/path/clonename/admin/cdump</value>
      </parameter>
      <parameter>
        <name>user_dump_dest</name>
        <value>/mnt/path/clonename/admin/udump</value>
      </parameter>
    </parameters>
   </database-specification>
</clone-specification>

Related information

Cloning databases and using custom plug-in scripts

Cloning databases from backups

Cloning databases in the current state

Considerations for cloning a database to an alternate host