Test/Development Database Refresh From Production Procedure

The following note describes the generic procedure to be followed to refresh a Energy Test or Development environment database from a Energy production database backup. In this example, we are refreshing the DEVE72 database from a backup taken of the PRD22 database. The assumption here is that the required RMAN production backup has already been either copied from the production database via scp or has been restored from tape or has been placed in an NFS shared location which is accessible from both machines. On the target machine the backups have been restored in the location u02/backup/DEVE72

Procedure: Shutdown the DEVE72 database if it is already running

[oracle@DEVE72 DEVE72]$ ps -ef |grep pmon oracle 12701 29275 0 15:36:00 pts/3 0:00 grep pmon oracle 7377 2235 0 May 19 ? 84:59 ora_pmon_DEVE72 [oracle@DEVE72 DEVE72]$ echo $ORACLE_SID DEVE72

[oracle@DEVE72 DEVE72]$ sqlplus sys as sysdba SQL*Plus: Release 10.2.0.4.0 - Production on Thu Jun 17 15:36:22 2010 Copyright (c) 1982, 2007, Oracle. All Rights Reserved. Enter password: Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options SQL> shutdown immediate Database closed. Database dismounted. ORACLE instance shut down. Delete the database data files, redo log files and control files

Note: **Ensure we are connected to the right server and are in the appropriate directory location**

[oracle@DEVE72 DEVE72]$ hostname DEVE72 [oracle@DEVE72 DEVE72]$ pwd /u03/oradata/DEVE72 [oracle@DEVE72 DEVE72]$ rm *.dbf [oracle@DEVE72 DEVE72]$ cd /u04/oradata/DEVE72 [oracle@DEVE72 DEVE72]$ ls control2.ctl redo01a.log redo02a.log redo03a.log [oracle@DEVE72 DEVE72]$ rm *.ctl [oracle@DEVE72 DEVE72]$ rm *.log [oracle@DEVE72 DEVE72]$ cd /u05/oradata/DEVE72 [oracle@DEVE72 DEVE72]$ ls control3.ctl redo01b.log redo02b.log redo03b.log

Copy the current init.ora parameter file of the DEVE72 database and create a parameter file with the name of the source production database (PRD22) [oracle@DEVE72 ~]$ cd $ORACLE_HOME/dbs [oracle@DEVE72 dbs]$ pwd /u01/app/oracle/product/10.2.0/db_1/dbs [oracle@DEVE72 dbs]$ cp initDEVE72.ora initprd22.ora Make the following changes to the initprd22.ora *.db_name='prd22'

Set the environment to reflect the source production database and start the instance in NOMOUNT mode [oracle@DEVE72 dbs]$ export ORACLE_SID=prd22

[oracle@DEVE72 dbs]$ sqlplus sys as sysdba SQL*Plus: Release 10.2.0.4.0 - Production on Mon Jun 21 12:58:32 2010 Copyright (c) 1982, 2007, Oracle. All Rights Reserved. Enter password: Connected to an idle instance.

SQL> startup nomount pfile=$ORACLE_HOME/dbs/initprd22.ora ORACLE instance started. Total System Global Area 3154116608 bytes Fixed Size 2043904 bytes Variable Size 637538304 bytes Database Buffers 2499805184 bytes Redo Buffers 14729216 bytes SQL> quit

Restore the control file from the backup location The control file backup exists in the format c-<DBID>-<DATE>-<BACKUP SEQUENCE NUMBER> Select the controlfile appropriate to the period of time that we wish to restore the database from [oracle@DEVE72 DEVE72]$ rman target / Recovery Manager: Release 10.2.0.4.0 - Production on Fri Jun 18 11:05:20 2010 Copyright (c) 1982, 2007, Oracle. All rights reserved. connected to target database: prd22 (not mounted) RMAN> restore controlfile from '/u02/backup/DEVE72/c-4031762323-20100616-00'; Starting restore at 18-JUN-10 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=538 devtype=DISK channel ORA_DISK_1: restoring control file channel ORA_DISK_1: restore complete, elapsed time: 00:00:06

output filename=/u03/oradata/DEVE72/control1.ctl output filename=/u04/oradata/DEVE72/control2.ctl output filename=/u05/oradata/DEVE72/control3.ctl Finished restore at 18-JUN-10

Mount the database RMAN> alter database mount 2> ; database mounted released channel: ORA_DISK_1

Catalog the RMAN backup sets which have been copied from the source production database RMAN> catalog start with '/u02/backup/DEVE72'; searching for all files that match the pattern /u02/backup/DEVE72 List of Files Unknown to the Database ===================================== File Name: /u02/backup/DEVE72/c-4031762323-20100616-00 File Name: /u02/backup/DEVE72/21lgatsk_1_1 File Name: /u02/backup/DEVE72/c-2263349373-20100419-00 ... ... Do you really want to catalog the above files (enter YES or NO)? YES cataloging files... cataloging done List of Cataloged Files ======================= File Name: /u02/backup/DEVE72/c-4031762323-20100616-00 File Name: /u02/backup/DEVE72/21lgatsk_1_1 File Name: /u02/backup/DEVE72/2flgdi89_1_1 ... ... List of Files Which Where Not Cataloged ======================================= File Name: /u02/backup/DEVE72/c-2263349373-20100419-00 RMAN-07518: Reason: Foreign database file DBID: 2263349373 Database Name: DEVE72

Note ignore any errors reported for files that are not cataloged

Determine the last archivelog sequence included in the backup. We will be recovering the database until this particular sequence number. Look for the string "List of archived logs" RMAN > list backup of archivelog all List of Archived Logs in backup set 69 Thrd Seq Low SCN Low Time Next SCN Next Time ---- ------- ---------- --------- ---------- --------1 79 7970987 16-JUN-10 7973402 16-JUN-10 In this case, the last archivelog backed up belongs to sequence number 79. If we wish to recover the database until the last archived log which has been backed up, we need to increment the last sequence number by 1. So in this case it will be 79+1 or 80 Create the following files in the location /u02/backup/{DB_NAME} vi rman_head RUN { # allocate a channel to the tape device ALLOCATE CHANNEL d1 DEVICE TYPE disk; # rename the datafiles and online redo logs

vi rman_tail # Do a SET UNTIL to prevent recovery of the online logs SET UNTIL SEQUENCE 80; # restore the database and switch the datafile names RESTORE DATABASE; SWITCH DATAFILE ALL; # recover the database RECOVER DATABASE; }

vi generate_datafiles.sql set head off pages 0 feed off echo off verify off set lines 200 spool rename_datafiles.lst select 'SET NEWNAME FOR DATAFILE ' || FILE# || ' TO ''' || '/u03/oradata/&1/' || substr(name,instr(name,'/',-1)+1) || ''';' from v$datafile; spool off exit; vi generate_logfiles.sql set head off pages 0 feed off echo off spool rename_logfiles.lst SELECT 'SQL "ALTER DATABASE RENAME FILE '''''|| MEMBER ||'''''' ||chr(10)||'to ''''' || member || '''''" ;' FROM V$LOGFILE; exit

Generate data file rename script While in directory /u02/backup/{DB_NAME}, connect as sys as sysdba via SQL*PLUS session and run the generate_datafiles.sql script. The generate_datafiles.sql script accepts a parameter which is the target database name. SQL> @generate_datafiles DEVE72 It will create a file rename_datafiles.lst . The contents of this file will be like this: SET NEWNAME FOR DATAFILE 1 TO '/u03/oradata/DEVE72/system01.dbf'; SET NEWNAME FOR DATAFILE 2 TO '/u03/oradata/DEVE72/undotbs01.dbf'; SET NEWNAME FOR DATAFILE 3 TO '/u03/oradata/DEVE72/sysaux01.dbf'; . . Generate redo log file rename script While in directory /u02/backup/{DB_NAME}, connect as sys as sysdba via SQL*PLUS session and run the generate_logfiles.sql script. SQL> @generate_logfiles.sql It will create a file called rename_logfiles.lst

Edit the rename_logfiles.lst file and change values of prd22 to DEVE72

SQL "ALTER DATABASE RENAME FILE ''/u04/oradata/prd22/redo01a.log'' to ''/u04/oradata/DEVE72/redo01a.log''" ; SQL "ALTER DATABASE RENAME FILE ''/u05/oradata/prd22/redo01b.log'' to ''/u05/oradata/DEVE72/redo01b.log''" ; SQL "ALTER DATABASE RENAME FILE ''/u04/oradata/prd22/redo02a.log'' to ''/u04/oradata/DEVE72/redo02a.log''" ; SQL "ALTER DATABASE RENAME FILE ''/u05/oradata/prd22/redo02b.log'' to ''/u05/oradata/DEVE72/redo02b.log''" ; SQL "ALTER DATABASE RENAME FILE ''/u04/oradata/prd22/redo03a.log'' to ''/u04/oradata/DEVE72/redo03a.log''" ; SQL "ALTER DATABASE RENAME FILE ''/u05/oradata/prd22/redo03b.log'' to ''/u05/oradata/DEVE72/redo03b.log''" ;

Specify the archive log sequence until which recovery will be performed Edit the rman_tail file and change the line with the words >> SET UNTIL SEQUENCE 80 to include the appropriate archive log sequence which was noted in an earlier step. Prepare the RMAN restore and recover database script [oracle@DEVE72 DEVE72]$ cat rman_head rename_datafiles.lst rename_logfiles.lst rman_tail > rman_recovery.rcv

Connect to the target database via RMAN and execute the rman_recovery.rcv script [oracle@DEVE72 dbs]$ rman target / Recovery Manager: Release 10.2.0.4.0 - Production on Mon Jun 21 13:04:04 2010 Copyright (c) 1982, 2007, Oracle. All rights reserved. connected to target database (not started) RMAN> @rman_recovery.rcv

Note: At this stage, we can continue to recover the database and keep it in sync with the source production database by manually applying the archive log files which are copied from the production server to the log archive destination of the test database on the target server. We can do this via SQL*PLUS connected as SYS by issuing the command RECOVER DATABASE UNTIL CANCEL USING BACKUP CONTROLFILE When there are no more archive log files to apply, we enter CANCEL Open the database with RESETLOGS After the RMAN script has successfully run and recovered the database until the last archive log sequence, we will now open the database using the ALTER DATABASE OPEN RESETLOGS command executed either via RMAN or from SQL*PLUS connected as SYS. SQL> alter database open resetlogs; Database altered. Temporary Tablespace Reconfiguration After the restore, we will note that the temporary tablespace files are still pointing to the source production database as these tempfiles have not been renamed when we renamed all the database data files in an earlier step. Obtain the name of the current tempfile SQL> select name from v$tempfile; NAME -------------------------------------------------------------------------------/u03/oradata/prd22/temp01.dbf Drop the tempfileSQL> ALTER DATABASE TEMPFILE '/u03/oradata/prd22/temp01.dbf' drop including datafiles; Database altered. Add a new tempfile for the refreshed database in the appropriate locationSQL> ALTER TABLESPACE temp ADD TEMPFILE '/u03/oradata/DEVE72/temp01.dbf' size 2G;

Tablespace altered. At this stage we will change the passwords if required for the SYS and SYSTEM or any other database accounts. Change the database name using nid We will now shutdown the database and then mount it. We will then run the nid utility to change the database name we need to provide the appropriate password for the user SYS and the new value we want for the database name. [oracle@DEVE72 dbs]$ nid target=sys dbname=DEVE72 DBNEWID: Release 10.2.0.4.0 - Production on Fri Jun 18 13:55:14 2010 Copyright (c) 1982, 2007, Oracle. All rights reserved. Password: Connected to database PRD22 (DBID=4031762323) Connected to server version 10.2.0 Control Files in database: /u03/oradata/DEVE72/control1.ctl /u04/oradata/DEVE72/control2.ctl /u05/oradata/DEVE72/control3.ctl Change database ID and database name PRD22 to DEVE72? (Y/[N]) => Y Proceeding with operation Changing database ID from 4031762323 to 2271553224 Changing database name from PRD22 to DEVE72 Control File /u03/oradata/DEVE72/control1.ctl - modified Control File /u04/oradata/DEVE72/control2.ctl - modified Control File /u05/oradata/DEVE72/control3.ctl - modified Datafile /u03/oradata/DEVE72/system01.dbf - dbid changed, wrote new name Datafile /u03/oradata/DEVE72/undotbs01.dbf - dbid changed, wrote new name Datafile /u03/oradata/DEVE72/sysaux01.dbf - dbid changed, wrote new name Datafile /u03/oradata/DEVE72/users01.dbf - dbid changed, wrote new name ... ... ...

Datafile /u03/oradata/DEVE72/COGNOSPAD_CLOB01.dbf - dbid changed, wrote new name Datafile /u03/oradata/DEVE72/temp01.dbf - dbid changed, wrote new name Control File /u03/oradata/DEVE72/control1.ctl - dbid changed, wrote new name Control File /u04/oradata/DEVE72/control2.ctl - dbid changed, wrote new name Control File /u05/oradata/DEVE72/control3.ctl - dbid changed, wrote new name Instance shut down Database name changed to DEVE72. Modify parameter file and generate a new password file before restarting. Database ID for database DEVE72 changed to 2271553224. All previous backups and archived redo logs for this database are unusable. Database has been shutdown, open database with RESETLOGS option. Succesfully changed database name and ID. DBNEWID - Completed succesfully.

At this stage the database has been shutdown and now we need to mount it and issue the RESETLOGS command after the database change. Note: We will now set the environment to the target database (until this stage, for example, ORACLE_SID had been set to the production database value) [oracle@DEVE72 backup] export ORACLE_SID=DEVE72 [oracle@DEVE72 backup]$ sqlplus sys as sysdba SQL*Plus: Release 10.2.0.4.0 - Production on Mon Jun 21 14:12:00 2010 Copyright (c) 1982, 2007, Oracle. All Rights Reserved. Enter password: Connected to an idle instance. SQL> startup mount ORACLE instance started. Total System Global Area 3154116608 bytes Fixed Size 2043904 bytes Variable Size 637538304 bytes Database Buffers 2499805184 bytes Redo Buffers 14729216 bytes

SQL> alter database open resetlogs;

Database altered. Post Database Refresh Tasks Create import and export directories required for Data Pump /u02/export/{DB_NAME} - export_dir /u02/import/{DB_NAME} - import_dir RMAN run the appropriate script to register details in the RMAN catalog database where required.

Cloning and Refreshing an Oracle Database

Dear Friends and Blog Readers, I have been asked many times about the Cloning and Refresh process of Oracle Database by emails of blog readers and the users of the Oracle Technology Network (OTN) Forums. Even though the information about Cloning and Refreshing a Database process available over web widely or has already been discussed. Here, in this post, I would like to explain and provide the information on the following Questions about Cloning and Refreshing of a Database with my simple terms. Terms used in this post: Source System - the system to be cloned - Production Target System - the newly created (or cloned) system Non Production Production Database PROD Test Database TEST Development Database - DEV

What is a Database Clone?

* A database clone is an activity/procedure which is performed by every DBA on regular basis or when there is a requirement or request to do so from the different departments i.e. Test/Development teams. * Cloning is nothing but creating a copy of production system in to a test or development environment. i.e. Having an exact image of production database in test area. * Cloning is a procedure for preparing and creating a test or development servers with the copy of Oracle production database for testing upgrades, migrating an existing system to new hardware.

* A cloning process includes a copy of Oracle Home (Directories and Binaries) backup and Database (Database related files) backup to prepare the instance on another server. * Though, it is possible to clone a database on the same server, Oracle doesnt suggest to clone a database on the same server, where the production database is running.

What is a Database Refresh?

* A Database Refresh is also referred to as a database clone. However, we dont clone Oracle Home rather we clone the Database as refresh. * Refreshing a database is something like applying the changes or updates of production database to the database where the database is already cloned. i.e. lets say you have cloned a database a month back, and now you are asked for doing refresh of a database, then you will perform the backup of database and prepare the clone the instance again on test server. This is nothing but refreshing. * Refreshing of a particular table, group of tables, schema, or tablespace will be done using traditional export/import, transportable Tablespaces, or data pump methods. * When an Oracle patch is applied on Production System, or in doubt, you have to prepare and clone the database again with the copy of Oracle Home (Directories and Binaries) Backup and Database (Database related files) Backup to prepare the instance. * The difference between Cloning and Refreshing is that cloning process includes Oracle Home and database Clone; where as Refreshing process only includes database clone. * If seen, the words, Clone and Refresh are used interchangeably for the sake of convenient.

When and why we Clone a Database?

* Generally production (PROD) database is cloned for various reasons and needs i.e. for something to be tested or something to be developed later those to be moved to production. * Its normal and quite common thing is that whenever there is any change or update to be performed and do not know the impact or effect after applying it on production (PROD), its required to be applied and tested on *NON* production database first (TEST or DEV), after the confirmation of change success, given by the users, then the changes will be moved to production. * A Cloned test instance (TEST) for testing team/environment is exclusively used for testing the changes or issues which will be come severe on Production. Oracle Support gives the solution as fix when there is an issue in the database, so this fix needs to perform or apply on test/development databases. * A Cloned development instance (DEV) for development team/environment is used for developing the new changes and then deploying the same on Production.

* A Cloned patch instance is used for patching to know the impact and the time required to apply the same on Production.

How to clone an Oracle Database and different ways of cloning.

There are many possible methods available for cloning a database, but each of them has pros and cons, and significance. Following are the methods. Using Cold (Offline) Backup: This is an easy and simple method to perform a clone of a database. This method requires your production database (PROD) needs to be shutdown gracefully, and take the backup of the database related files i.e. Data files, Control files, Redo Log files, using Operating System commands i.e. cp or copy. This is not possible where your PROD database is running 24/7 and should be available continuously for users. For syntax and the series of steps to perform the clone using cold backup, refer the following URLs from the reference. In this method, backup of the database will be done online i.e. without shutting down the database. For this, your Production Database is must be in Archive log mode. For syntax and the series of steps to perform the clone using hot backup, refer the following URLs from the reference. Reference: http://www.quest-pipelines.com/newsletter/cloning.htm http://www.oralnx.com/index.php/2007/03/22/cloning-an-oracle-database/ http://www.shutdownabort.com/quickguides/clone_hot.php Using RMAN Commands: Cloning can also be performed using RMAN Backups and RMAN commands and its also an easy method to perform so. The RMAN DUPLICATE command is used to perform the clone. Until Oracle 9i, to clone the database, it is required to be the Source and Target systems should have the same OS i.e. it is not possible to clone across the platform. But as workaround, using export/import can be cloning the database across the platforms. But starting from Oracle 10g the RMAN capabilities have improved immensely. Cross platform cloning/duplicating a database can be done using RMAN CONVERT commands. For syntax and the series of steps to perform the clone using RMAN Commands, refer the following URLs from the reference. References: Creating and Updating Duplicate Databases with RMAN

http://download.oracle.com/docs/cd/B19306_01/backup.102/b14191/rcmdupdb.htm#i1008564 Cross-Platform Transportable Database: RMAN CONVERT DATABASE http://download.oracle.com/docs/cd/B19306_01/backup.102/b14191/dbxptrn002.htm#CHDCFFDI Creating a Duplicate Database on a Local or Remote Host http://sabdarsyed.blogspot.com/2007/06/clone-of-database-on-same-host-ie.html http://download-east.oracle.com/docs/cd/B19306_01/backup.102/b14191/rcmdupdb005.htm

Pre & Post Cloning Steps/Changes:

* Do *NOT* set the clone database name as good as production database Name. * Its *NOT* mandatory to have the initialization parameter values of cloned instance similar to Production Instance. * It is *NOT* mandatory to have the cloned instance in Archive log mode. Because unnecessarily archive log files are generated, which consume the hard disk space? If at all, the cloned instance crashed and need to be recovered, it can easily be again cloned from the production. * After the clone, change the system users passwords i.e. SYS & SYSTEM, and for any critical users passwords. * Disable the jobs which are not required to be run in the cloned instance. * Change any application users tables from the cloned database which are still referring the Production Database i.e. Server IP, Port Details, Printer Details etc,

Other Useful Links:

OTN Forums on Cloning: http://forums.oracle.com/forums/search.jspa? threadID=&q=clone+a+database&objID=f61&dateRange=all&userID=&numResults=30&rankBy=10001 Ask Tom Forums: DB cloning -- what is it and why http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:575623107841 Creating test environment from production box http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:526422273445

Metalink Notes: Note:245262.1 - Subject: Create a Duplicate Database with NOCATALOG on Same Node Note:458450.1 - Subject: Steps to Manually Clone a Database Note:388431.1 - Subject: Creating a Duplicate Database on a New Host. Conclusion: These are only my views and outlines about cloning and need *NOT* to be the same with others or Oracle. One individual can still follow their cloning procedure documents which are there in place with them. I strongly suggest one to do the changes first in the test/development before doing it on Production. And also, use Oracle Documentations and Metalink Support for any kind of help. Hope that this post helps you in understanding the Cloning and Refreshing activity of a database. **Please leave your comments/suggestions about this post**.

Clone an Oracle database using RMAN duplicate (same server) tnsManager - Distribute tnsnames the easy way and for free!

This procedure will clone a database onto the same server using RMAN duplicate.

1. Backup the source database. To use RMAN duplicate an RMAN backup of the source database is required. If there is already one available, skip to step 2. If not, here is a quick example of how to produce an RMAN backup. This example assumes that there is no recovery catalog available: rman target sys@<source database> nocatalog backup database plus archivelog format '/u01/ora_backup/rman/%d_%u_%s'; This will backup the database and archive logs. The format string defines the location of the backup files. Alter it to a suitable location. 2. Produce a pfile for the new database This step assumes that the source database is using a spfile. If that is not the case, simply make a copy the existing pfile. Connect to the source database as sysdba and run the following: create pfile='init<new database sid>.ora' from spfile; This will create a new pfile in the $ORACLE_HOME/dbs directory. The new pfile will need to be edited immediately. If the cloned database is to have a different name to the

source, this will need to be changed, as will any paths. Review the contents of the file and make alterations as necessary. Because in this example the cloned database will reside on the same machine as the source, Oracle must be told how convert the filenames during the RMAN duplicate operation. This is achieved by adding the following lines to the newly created pfile: db_file_name_convert=(<source_db_path>,<target_db_path>) log_file_name_convert=(<source_db_path>,<target_db_path>) Here is an example where the source database scr9 is being cloned to dg9a. Note the trailing slashes and lack of quotes: db_file_name_convert=(/u01/oradata/scr9/,/u03/oradata/dg9a/) log_file_name_convert=(/u01/oradata/scr9/,/u03/oradata/dg9a/)

3. Create bdump, udump & cdump directories Create bdump, udump & cdump directories as specified in the pfile from the previous step. 4. Add a new entry to oratab, and source the environment Edit the /etc/oratab (or /opt/oracle/oratab) and add an entry for the new database. Source the new environment with '. oraenv' and verify that it has worked by issuing the following command: echo $ORACLE_SID If this doesn't output the new database sid go back and investigate why not. 5. Create a password file Use the following command to create a password file (add an appropriate password to the end of it): orapwd file=${ORACLE_HOME}/dbs/orapw${ORACLE_SID} password=<your password> 6. Duplicate the database From sqlplus, start the instance up in nomount mode: startup nomount Exit sqlplus, start RMAN and duplicate the database. As in step 1, it is assumed that no recovery catalog is available. If one is available, simply amend the RMAN command to include it. rman target sys@<source_database> nocatalog auxiliary / duplicate target database to <clone database name>; This will restore the database and apply some archive logs. It can appear to hang at the end sometimes. Just give it time - I think it is because RMAN does a 'shutdown normal'. If you see the following error, it is probably due to the file_name_convert settings being wrong. Return to step 2 and double check the settings.

RMAN-05001: auxiliary filename '%s' conflicts with a file used by the target database Once the duplicate has finished RMAN will display a message similar to this:

database opened Finished Duplicate Db at 26-FEB-05 RMAN> Exit RMAN. 7. Create an spfile From sqlplus: create spfile from pfile; shutdown immediate startup Now that the clone is built, we no longer need the file_name_convert settings: alter system reset db_file_name_convert scope=spfile sid='*' / alter system reset log_file_name_convert scope=spfile sid='*' / 8. Optionally take the clone database out of archive log mode RMAN will leave the cloned database in archive log mode. If archive log mode isn't required, run the following commands from sqlplus: shutdown immediate startup mount alter database noarchivelog; alter database open; 9. Configure TNS Add entries for new database in the listener.ora and tnsnames.ora as necessary.

Clone an Oracle database using an online/hot backup

tnsManager - Distribute tnsnames the easy way and for free!

This procedure will clone a database using a online copy of the source database files. Before beginning though, there are a few things that are worth noting about online/hot backups: When a tablespace is put into backup mode, Oracle will write entire blocks to redo rather than the usual change vectors. For this reason, do not perform a hot backup during periods of heavy database activity - it could lead to a lot of archive logs being created. This procedure will put all tablespaces into backup mode at the same time. If the source database is quite large and you think that it might take a long time to copy, consider copying the tablespaces one at a time, or in groups. While the backup is in progress, it will not be possible to take the tablespaces offline normally or shut down the instance. Ok, lets get started... 1. Make a note of the current archive log change number Because the restored files will require recovery, some archive logs will be needed. This applies even if you are not intending to put the cloned database into archive log mode. Work out which will be the first required log by running the following query on the source database. Make a note of the change number that is returned: select max(first_change#) chng from v$archived_log / 2. Prepare the begin/end backup scripts The following sql will produce two scripts; begin_backup.sql and end_backup.sql. When executed, these scripts will either put the tablespaces into backup mode or take them out of it: cr_hot_backup.sql 3. Put the source database into backup mode From sqlplus, run the begin backup script created in the last step: @begin_backup This will put all of the databases tablespaces into backup mode. 4. Copy the files to the new location Copy, scp or ftp the files from the source database/machine to the target. Do not copy the control files across. Make sure that the files have the correct permissions and ownership. 5. Take the source database out of backup mode Once the file copy has been completed, take the source database out of backup mode. Run the end backup script created in step 2. From sqlplus: @end_backup 6. Copy archive logs It is only necessary to copy archive logs created during the time the source database was

Clone an Oracle database using a cold backup tnsManager - Distribute tnsnames the easy way and for free!

This procedure will clone a database using a cold copy of the source database files. If a cold backup of the database is available, restore it to the new location and jump to step 2.

1. Identify and copy the database files With the source database started, identify all of the database's files. The following query will display all datafiles, tempfiles and redo logs: set lines 100 pages 999 col name format a50 select name, bytes from (select name, bytes from v$datafile union all select name, bytes from v$tempfile union all select lf.member "name", l.bytes from v$logfile lf , v$log l where lf.group# = l.group#) used , (select sum(bytes) as poo from dba_free_space) free /

Make sure that the clone databases file-system is large enough and has all necessary directories. If the source database has a complex file structure, you might want to consider modifying the above sql to produce a file copy script. Stop the source database with: shutdown immediate Copy, scp or ftp the files from the source database/machine to the target. Do not copy the control files across. Make sure that the files have the correct permissions and ownership. Start the source database up again startup 2. Produce a pfile for the new database This step assumes that you are using a spfile. If you are not, just copy the existing pfile.

From sqlplus: create pfile='init<new database sid>.ora' from spfile; This will create a new pfile in the $ORACLE_HOME/dbs directory. Once created, the new pfile will need to be edited. If the cloned database is to have a new name, this will need to be changed, as will any paths. Review the contents of the file and make alterations as necessary. Also think about adjusting memory parameters. If you are cloning a production database onto a slower development machine you might want to consider reducing some values. Note. Pay particular attention to the control locations. 3. Create the clone controlfile Create a control file for the new database. To do this, connect to the source database and request a dump of the current control file. From sqlplus: alter database backup controlfile to trace as '/home/oracle/cr_<new sid>.sql' / The file will require extensive editing before it can be used. Using your favourite editor make the following alterations: o Remove all lines from the top of the file up to but not including the second 'STARTUP MOUNT' line (it's roughly halfway down the file). o o o o Remove any lines that start with -Remove any lines that start with a # Remove any blank lines in the 'CREATE CONTROLFILE' section. Remove the line 'RECOVER DATABASE USING BACKUP CONTROLFILE'

o Move to the top of the file to the 'CREATE CONTROLFILE' line. The word 'REUSE' needs to be changed to 'SET'. The database name needs setting to the new database name (if it is being changed). Decide whether the database will be put into archivelog mode or not. o If the file paths are being changed, alter the file to reflect the changes.

Here is an example of how the file would look for a small database called dg9a which isn't in archivelog mode: STARTUP NOMOUNT CREATE CONTROLFILE SET DATABASE "DG9A" RESETLOGS FORCE LOGGING NOARCHIVELOG MAXLOGFILES 50 MAXLOGMEMBERS 5

MAXDATAFILES 100 MAXINSTANCES 1 MAXLOGHISTORY 453 LOGFILE GROUP 1 '/u03/oradata/dg9a/redo01.log' GROUP 2 '/u03/oradata/dg9a/redo02.log' GROUP 3 '/u03/oradata/dg9a/redo03.log' DATAFILE '/u03/oradata/dg9a/system01.dbf', '/u03/oradata/dg9a/undotbs01.dbf', '/u03/oradata/dg9a/cwmlite01.dbf', '/u03/oradata/dg9a/drsys01.dbf', '/u03/oradata/dg9a/example01.dbf', '/u03/oradata/dg9a/indx01.dbf', '/u03/oradata/dg9a/odm01.dbf', '/u03/oradata/dg9a/tools01.dbf', '/u03/oradata/dg9a/users01.dbf', '/u03/oradata/dg9a/xdb01.dbf', '/u03/oradata/dg9a/andy01.dbf', '/u03/oradata/dg9a/psstats01.dbf', '/u03/oradata/dg9a/planner01.dbf' CHARACTER SET WE8ISO8859P1 ; ALTER DATABASE OPEN RESETLOGS; ALTER TABLESPACE TEMP ADD TEMPFILE '/u03/oradata/dg9a/temp01.dbf' SIZE 104857600 REUSE AUTOEXTEND OFF; SIZE 100M, SIZE 100M, SIZE 100M

4. Add a new entry to oratab and source the environment Edit the /etc/oratab (or /opt/oracle/oratab) and add an entry for the new database. Source the new environment with '. oraenv' and verify that it has worked by issuing the following command: echo $ORACLE_SID If this doesn't output the new database sid go back and investigate. 5. Create the a password file Use the following command to create a password file (add an appropriate password to the end of it): orapwd file=${ORACLE_HOME}/dbs/orapw${ORACLE_SID} password=<your password> 5. Create the new control file(s) Ok, now for the exciting bit! It is time to create the new controlfiles and open the database: sqlplus "/ as sysdba"

@/home/oracle/cr_<new database sid>

It is quite common to run into problems at this stage. Here are a couple of common errors and solutions: ORA-01113: file 1 needs media recovery You probably forgot to stop the source database before copying the files. Go back to step 1 and recopy the files. ORA-01503: ORA-00200: ORA-00202: ORA-27038: CREATE CONTROLFILE failed controlfile could not be created controlfile: '/u03/oradata/dg9a/control01.ctl' skgfrcre: file exists

Double check the pfile created in step 2. Make sure the control_files setting is pointing at the correct location. If the control_file setting is ok, make sure that the control files were not copied with the rest of the database files. If they were, delete or rename them. 6. Perform a few checks If the last step went smoothly, the database should be open. It is advisable to perform a few checks at this point: o o Check that the database has opened with: select status from v$instance;

The status should be 'OPEN' o o Make sure that the datafiles are all ok: select distinct status from v$datafile;

It should return only ONLINE and SYSTEM. o Take a quick look at the alert log too.

7. Set the databases global name The new database will still have the source databases global name. Run the following to reset it: alter database rename global_name to <new database sid> / 8. Create a spfile From sqlplus: create spfile from pfile; 9. Change the database ID If RMAN is going to be used to back-up the database, the database ID must be changed. If RMAN isn't going to be used, there is no harm in changing the ID anyway - and it's a good practice to do so. From sqlplus: shutdown immediate startup mount

exit

From unix: nid target=/ NID will ask if you want to change the ID. Respond with 'Y'. Once it has finished, start the database up again in sqlplus: shutdown immediate startup mount alter database open resetlogs / 10. Configure TNS Add entries for new database in the listener.ora and tnsnames.ora as necessary. 11. Finished That's it!