Database and Binary Cloning

Most organizations need at least two identical databases for testing and production deployments. Cloning refers to creating an identical copy of a database. After you have successfully installed a database, it can be cloned to create an identical database for testing or training purposes.

A database can be cloned or re-created from another database by several methods, the most notable ones being hot or cold backups, copying the datafiles, and export/import processes. When you clone a database, do not keep it in mounted stage during the copy process because it will cause database corruption. Recovery Manager (RMAN) can be used as well for making a duplicate copy of the database. For more details on using RMAN for cloning a database, refer to Oracle Database Backup and Recovery Advanced User's Guide.

Can Database Block Size Be Different in a Clone?

One of the important points to be remembered in any database cloning effort is to have an identical db_block_size value in the cloned database as in the original database. If you use a different block size than that of the database being cloned, you will get ORA-600 errors. Remember to specifically set this value, or the database will assume the default block size of 2,048 bytes and the database copy will fail.

The following are the common steps for cloning any database, regardless of its data content and platform:

1.	Perform a full backup of the database.
2.	Back up the control file to trace. The trace file will be created in user_dump_dest: SQL> alter database backup controlfile to trace resetlogs; SQL> select name, value from v$parameter where name='user_dump_dest';
3.	Find the latest trace file (with the extension.trc) and rename it clone_db.sql.
4.	Get a list of all data files and redo log files to be copied over to the new database: SQL> select name from v$datafile; SQL> select member from v$logfile;
5.	Perform a clean shutdown of the database.
6.	Create directories on the target server to hold the cloned database file. Copy all data and redo log files from step 4 to the newly created directories.
7.	If you are planning to use the init.ora parameter file for the cloned database, make a copy of the host's file and rename it to init<clone>.ora file. Edit the init<clone>.ora file to have new values (paths) for the target database. This step will include paths for control_files, user_dump_dest, background_dump_dest, and so on.
8.	Make a copy of the trace file (clone_db.sql) on the target machine. This file has the commands for creating the control file for the original database.
9.	Delete the header information and the comments in the copied file on the target machine.
10.	Modify the startup command statement to include the new initclone.ora parameter file: SQL> startup nomount pfile= <new location/initclone.ora>
11.	Modify the control file command statement as follows: SQL> create controlfile set database "clone_db" resetlogs noarchivelog;
12.	Modify the data and redo filenames to point to the names of the appropriate files on the new server.
13.	Remove the lines containing the RECOVER DATABASE command and its associated comments.
14.	Set the Oracle environments (ORACLE_HOME and ORACLE_SID) to the new database.
15.	Edit tnsnames.ora and listener.ora to include the new database instance information.
16.	Stop and restart the listener.
17.	In UNIX systems, add an entry for the cloned database in the oratab file.
18.	Run the script on the target database server. Mount and open the database.
19.	Change the global name of the new cloned database as follows: SQL> alter database rename global_name to <clone_db_name>;

Can Databases Be Cloned Independent of Platforms?

Nowadays Linux servers are very affordable; hence, some organizations may want to keep their training environments in Linux or Windows platforms instead of the costly production environments on UNIX platforms. For cloning databases independent of platforms, export/import of the source database to its lower-end clone is the best option. Before you take the export of the source database, remember to perform a Shutdown Immediate operation followed by Startup Restrict command to keep all user activities out of the database. The actual modus operandi of the export/import process will be explained later in this section.