database refresh

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 pmonoracle 12701 29275 0 15:36:00 pts/3 0:00 grep pmonoracle 7377 2235 0 May 19 ? 84:59 ora_pmon_DEVE72

[oracle@DEVE72 DEVE72]$ echo $ORACLE_SIDDEVE72

[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 ProductionWith the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> shutdown immediateDatabase 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]$ hostnameDEVE72

[oracle@DEVE72 DEVE72]$ pwd/u03/oradata/DEVE72

[oracle@DEVE72 DEVE72]$ rm *.dbf

[oracle@DEVE72 DEVE72]$ cd /u04/oradata/DEVE72

[oracle@DEVE72 DEVE72]$ lscontrol2.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]$ lscontrol3.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


Enter password:Connected to an idle instance.

SQL> startup nomount pfile=$ORACLE_HOME/dbs/initprd22.oraORACLE instance started.

Total System Global Area 3154116608 bytesFixed Size 2043904 bytesVariable Size 637538304 bytesDatabase Buffers 2499805184 bytesRedo Buffers 14729216 bytesSQL> 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-10using target database control file instead of recovery catalogallocated channel: ORA_DISK_1channel ORA_DISK_1: sid=538 devtype=DISK

channel ORA_DISK_1: restoring control filechannel ORA_DISK_1: restore complete, elapsed time: 00:00:06output filename=/u03/oradata/DEVE72/control1.ctloutput filename=/u04/oradata/DEVE72/control2.ctloutput filename=/u05/oradata/DEVE72/control3.ctlFinished restore at 18-JUN-10

• Mount the database

RMAN> alter database mount2> ;

database mountedreleased 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-00File Name: /u02/backup/DEVE72/21lgatsk_1_1File Name: /u02/backup/DEVE72/c-2263349373-20100419-00......

Do you really want to catalog the above files (enter YES or NO)? YEScataloging files...cataloging done

List of Cataloged Files=======================File Name: /u02/backup/DEVE72/c-4031762323-20100616-00File Name: /u02/backup/DEVE72/21lgatsk_1_1File Name: /u02/backup/DEVE72/2flgdi89_1_1......

List of Files Which Where Not Cataloged=======================================File Name: /u02/backup/DEVE72/c-2263349373-20100419-00RMAN-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 69Thrd 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 deviceALLOCATE 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 logsSET UNTIL SEQUENCE 80;

# restore the database and switch the datafile namesRESTORE DATABASE;SWITCH DATAFILE ALL;

# recover the databaseRECOVER DATABASE;}

vi generate_datafiles.sql

set head off pages 0 feed off echo off verify offset lines 200spool rename_datafiles.lstselect 'SET NEWNAME FOR DATAFILE ' || FILE# || ' TO ''' || '/u03/oradata/&1/' || substr(name,instr(name,'/',-1)+1) || ''';' from v$datafile;spool offexit;

vi generate_logfiles.sql

set head off pages 0 feed off echo offspool rename_logfiles.lstSELECT '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 ''/u05/oradata/prd22/redo02b.log'' to

''/u05/oradata/DEVE72/redo02b.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


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 tempfile-

SQL> ALTER DATABASE TEMPFILE '/u03/oradata/prd22/temp01.dbf' drop including datafiles;

Database altered.

Add a new tempfile for the refreshed database in the appropriate location-

SQL> 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


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 operationChanging database ID from 4031762323 to 2271553224Changing database name from PRD22 to DEVE72Control File /u03/oradata/DEVE72/control1.ctl - modifiedControl File /u04/oradata/DEVE72/control2.ctl - modifiedControl File /u05/oradata/DEVE72/control3.ctl - modifiedDatafile /u03/oradata/DEVE72/system01.dbf - dbid changed, wrote new nameDatafile /u03/oradata/DEVE72/undotbs01.dbf - dbid changed, wrote new nameDatafile /u03/oradata/DEVE72/sysaux01.dbf - dbid changed, wrote new nameDatafile /u03/oradata/DEVE72/users01.dbf - dbid changed, wrote new name

...

...

...

Datafile /u03/oradata/DEVE72/COGNOSPAD_CLOB01.dbf - dbid changed, wrote new nameDatafile /u03/oradata/DEVE72/temp01.dbf - dbid changed, wrote new nameControl File /u03/oradata/DEVE72/control1.ctl - dbid changed, wrote new nameControl File /u04/oradata/DEVE72/control2.ctl - dbid changed, wrote new nameControl File /u05/oradata/DEVE72/control3.ctl - dbid changed, wrote new nameInstance 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


Enter password:Connected to an idle instance.

SQL> startup mountORACLE instance started.

Total System Global Area 3154116608 bytesFixed Size 2043904 bytesVariable Size 637538304 bytesDatabase Buffers 2499805184 bytesRedo 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 DatabaseDear 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 - ProductionTarget System - the newly created (or cloned) system – Non ProductionProduction Database – PRODTest Database – TESTDevelopment 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 doesn’t 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 don’t 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. let’s 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.

* It’s 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), it’s 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.htmhttp://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 it’s 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

http://download-east.oracle.com/docs/cd/B19306_01/backup.102/b14191/rcmdupdb005.htm

http://sabdarsyed.blogspot.com/2007/06/clone-of-database-on-same-host-ie.html





http://www.shutdownabort.com/quickguides/clone_hot.php

http://www.oralnx.com/index.php/2007/03/22/cloning-an-oracle-database/

http://www.quest-pipelines.com/newsletter/cloning.htm

Pre & Post Cloning Steps/Changes:

* Do *NOT* set the clone database name as good as production database Name.

* It’s *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 whyhttp://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:575623107841

Creating test environment from production boxhttp://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 NodeNote:458450.1 - Subject: Steps to Manually Clone a DatabaseNote: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

http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:526422273445

http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:575623107841

http://forums.oracle.com/forums/search.jspa?threadID=&q=clone+a+database&objID=f61&dateRange=all&userID=&numResults=30&rankBy=10001



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 databaseThis 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>)

http://www.shutdownabort.com/tnsmanager/index.php

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 directoriesCreate bdump, udump & cdump directories as specified in the pfile from the previous step.

4. Add a new entry to oratab, and source the environmentEdit 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 fileUse 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 databaseFrom 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 spfileFrom 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 modeRMAN 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 modeFrom 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 locationCopy, 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 modeOnce 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

http://www.shutdownabort.com/scripts/showscript.php?script=cr_hot_backup.sql


6. Copy archive logsIt is only necessary to copy archive logs created during the time the source database was in backup mode. Begin by archiving the current redo:

alter system archive log current;

Then, identify which archive log files are required. When run, the following query will ask for a change number. This is the number noted in step 1.

select namefrom v$archived_logwhere first_change# >= &change_noorder by name/

Create an archive directory in the clone database.s file system and copy all of the identified logs into it.

7. Produce a pfile for the new databaseThis 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;


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.

Ensure that the archive log destination is pointing to the directory created in step 6.

8. Create the clone controlfileCreate 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 Remove any lines that start with --

o Remove any lines that start with a #

o Remove any blank lines in the 'CREATE CONTROLFILE' section.

o Remove the line 'RECOVER DATABASE USING BACKUP CONTROLFILE'

o Remove the line 'ALTER DATABASE OPEN RESETLOGS;'

o Make a copy of the 'ALTER TABLESPACE TEMP...' lines, and then remove them from the file. Make sure that you hang onto the command, it will be used later.

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' SIZE 100M,


GROUP 3 '/u03/oradata/dg9a/redo03.log' SIZE 100M

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

;

9. Add a new entry to oratab and source the environmentEdit 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.

10. Create the a password fileUse the following command to create a password file (add an appropriate password to the end of it):


11. 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>

If all goes to plan you will see the instance start and then the message 'Control file created'.

12. Recover and open the databaseThe archive logs that were identified and copied in step 6 must now be applied to the database. Issue the following command from sqlplus:

recover database using backup controlfile until cancel

When prompted to 'Specify log' enter 'auto'. Oracle will then apply all the available logs, and then error with ORA-00308. This is normal, it simply means that all available logs have been applied. Open the database with reset logs:

alter database open resetlogs;

13. Create temp filesUsing the 'ALTER TABLESPACE TEMP...' command from step 8, create the temp files. Make sure the paths to the file(s) are correct, then run it from sqlplus.

14. Perform a few checksIf the last couple of steps went smoothly, the database should be open. It is advisable to perform a few checks at this point:

o Check that the database has opened with:

o select status from v$instance;

The status should be 'OPEN'

o Make sure that the datafiles are all ok:o select distinct status from v$datafile;

It should return only ONLINE and SYSTEM.

o Take a quick look at the alert log too.

15. Set the databases global nameThe 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> /

Note. no quotes!

16. Create a spfileFrom sqlplus:

create spfile from pfile; 17. 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 immediatestartup mountalter database open resetlogs/

18. Configure TNS

Add entries for new database in the listener.ora and tnsnames.ora as necessary.

19. FinishedThat's it!

Clone an Oracle database using a cold backuptnsManager - 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 filesWith 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;


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 controlfileCreate 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 Remove any lines that start with --

o Remove any lines that start with a #

o Remove any blank lines in the 'CREATE CONTROLFILE' section.

o 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 3 '/u03/oradata/dg9a/redo03.log' SIZE 100M

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;

4. Add a new entry to oratab and source the environmentEdit 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 fileUse the following command to create a password file (add an appropriate password to the end of it):


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: CREATE CONTROLFILE failedORA-00200: controlfile could not be createdORA-00202: controlfile: '/u03/oradata/dg9a/control01.ctl'ORA-27038: 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 checksIf the last step went smoothly, the database should be open. It is advisable to perform a few checks at this point:

o Check that the database has opened with:

o select status from v$instance;

The status should be 'OPEN'

o Make sure that the datafiles are all ok:o 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 nameThe 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 immediatestartup mountalter database open resetlogs/

10. Configure TNSAdd entries for new database in the listener.ora and tnsnames.ora as necessary.

11. FinishedThat's it!

database refresh

Documents

directory

oracledeve72

oracledeve72

archive log

archive log

database related

oracledeve72

database data