14 May, 2009

Rename Database while Cloning it.

As I recently pointed out in a thread on "Partial Database Cloning" it is perfectly possible to rename a database while cloning it.

Here, I clone a database "ORT24FS" to another name "DUPDB" on the same server, without shutting down ORT24FS. Also, I rename the copied database to DUPDB even *before* I issue the RECOVER database command. Furtheremore, DUPDB is able to use ORT24FS's ArchiveLog "as is".

First I copy my database files from the ORT24FS database directory to the DUPDB database directory :

ora10204>env |grep SID
ORACLE_SID=ORT24FS
ora10204>sqlplus '/ as sysdba'

SQL*Plus: Release 10.2.0.4.0 - Production on Thu May 14 23:04:08 2009

Copyright (c) 1982, 2007, Oracle. All Rights Reserved.


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> select file_name from dba_data_files;

FILE_NAME
--------------------------------------------------------------------------------
/oracle_fs/Databases/ORT24FS/users01.dbf
/oracle_fs/Databases/ORT24FS/sysaux01.dbf
/oracle_fs/Databases/ORT24FS/undotbs01.dbf
/oracle_fs/Databases/ORT24FS/system01.dbf
/oracle_fs/Databases/ORT24FS/example01.dbf

SQL> alter database begin backup;

Database altered.

SQL> !cp -rp /oracle_fs/Databases/ORT24FS/* /oracle_fs/Databases/DUPDB/


SQL>

SQL> alter database end backup;

Database altered.

SQL> alter system switch logfile;

System altered.

SQL>

SQL> exit

Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options


I then generate a controlfile trace that I will be using for the CREATE CONTROLFILE to rename the database consisting copied files in the "DUPDB" directory.

ora10204>sqlplus

SQL*Plus: Release 10.2.0.4.0 - Production on Thu May 14 23:09:52 2009

Copyright (c) 1982, 2007, Oracle. All Rights Reserved.

Enter user-name: / as sysdba

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> alter database backup controlfile to trace;

Database altered.

SQL> exit


Next, I edit initDUPDB.ora. Note how I set db_name to DUPDB but I use the same log_archive_dest_1 and log_archive_format as I have in ORT24FS. This allows me to use the ORT24FS archivelogs "as is" without renaming or relocating them :

ora10204>vi $ORACLE_HOME/dbs/initDUPDB.ora
DUPDB.__db_cache_size=616562688
DUPDB.__java_pool_size=4194304
DUPDB.__large_pool_size=4194304
DUPDB.__shared_pool_size=205520896
DUPDB.__streams_pool_size=0
*.audit_file_dest='/oracle_fs/ora10204/admin/DUPDB/adump'
*.background_dump_dest='/oracle_fs/ora10204/admin/DUPDB/bdump'
*.compatible='10.2.0.4.0'
*.control_files='/oracle_fs/Databases/DUPDB/control01.ctl','/oracle_fs/Databases/DUPDB/control02.ctl','/oracle_fs/Databases/DUPDB/control03.ctl'
*.core_dump_dest='/oracle_fs/ora10204/admin/DUPDB/cdump'
*.db_block_size=8192
*.db_domain=''
*.db_name='DUPDB'
*.db_recovery_file_dest='/oracle_fs/FRAs/DUPDB'
*.db_recovery_file_dest_size=17179869184
*.dbwr_io_slaves=0
*.dispatchers='(PROTOCOL=TCP) (SERVICE=DUPDBXDB)'
*.filesystemio_options='NONE'
*.job_queue_processes=10
*.log_archive_dest_1='LOCATION=/oracle_fs/ArchiveLogs/ORT24FS'
*.log_archive_format='%t_%s_%r.dbf'
*.open_cursors=300
*.pga_aggregate_target=179306496
*.processes=150
*.recovery_parallelism=4
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_max_size=838860800
*.sga_target=838860800
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='/oracle_fs/ora10204/admin/DUPDB/udump'
*.db_create_file_dest='/oracle_fs/Databases/DUPDB'



I now copy the controlfile trace to DUPDB and edit it to use it to SET the database name to DUPDB for all the database files in the DUPDB directory. I must use RESETLOGS when using SET. This also means that Oracle will ignore online redo logs present in the directory and that I will have to OPEN RESETLOGS later.

ora10204>cd $ORACLE_BASE/admin/DUPDB
ora10204>cp ../ORT24FS/udump/ort24fs_ora_4432.trc create_ctrl_file.sql
ora10204>vi create_ctrl_file.sql


STARTUP NOMOUNT
CREATE CONTROLFILE SET DATABASE "DUPDB" RESETLOGS ARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 8
MAXLOGHISTORY 292
LOGFILE
GROUP 1 '/oracle_fs/Databases/DUPDB/redo01.dbf' SIZE 50M,
GROUP 2 '/oracle_fs/Databases/DUPDB/redo02.dbf' SIZE 50M,
GROUP 3 '/oracle_fs/Databases/DUPDB/redo03.dbf' SIZE 50M
-- STANDBY LOGFILE
DATAFILE
'/oracle_fs/Databases/DUPDB/system01.dbf',
'/oracle_fs/Databases/DUPDB/undotbs01.dbf',
'/oracle_fs/Databases/DUPDB/sysaux01.dbf',
'/oracle_fs/Databases/DUPDB/users01.dbf',
'/oracle_fs/Databases/DUPDB/example01.dbf'
CHARACTER SET WE8ISO8859P1
;


I now set my ORACLE_SID to DUPDB and run the create script. Since my "cp /oracle_fs/Databases/ORT24FS/*" command had also copied the controlfiles, I have to remove them and run the CREATE CONTROLFILE command. Note that, at this stage, the database files in DUPDB are from a Hot Backup and are "not consistent" yet.

ora10204>ORACLE_SID=DUPDB;export ORACLE_SID
ora10204>sqlplus '/ as sysdba'

SQL*Plus: Release 10.2.0.4.0 - Production on Thu May 14 23:13:59 2009

Copyright (c) 1982, 2007, Oracle. All Rights Reserved.

Connected to an idle instance.

SQL> spool create_DUPDB_ctrl_file
SQL> @create_ctrl_file
ORACLE instance started.

Total System Global Area 838860800 bytes
Fixed Size 2087672 bytes
Variable Size 213910792 bytes
Database Buffers 616562688 bytes
Redo Buffers 6299648 bytes
CREATE CONTROLFILE SET DATABASE "DUPDB" RESETLOGS ARCHIVELOG
*
ERROR at line 1:
ORA-01503: CREATE CONTROLFILE failed
ORA-00200: control file could not be created
ORA-00202: control file: '/oracle_fs/Databases/DUPDB/control01.ctl'
ORA-27038: created file already exists
Additional information: 1


SQL> !rm /oracle_fs/Databases/DUPDB/*.ctl

SQL> shutdown
ORA-01507: database not mounted


ORACLE instance shut down.
SQL> set echo on
SQL> @create_ctrl_file
SQL> STARTUP NOMOUNT
ORACLE instance started.

Total System Global Area 838860800 bytes
Fixed Size 2087672 bytes
Variable Size 213910792 bytes
Database Buffers 616562688 bytes
Redo Buffers 6299648 bytes
SQL> CREATE CONTROLFILE SET DATABASE "DUPDB" RESETLOGS ARCHIVELOG
2 MAXLOGFILES 16
3 MAXLOGMEMBERS 3
4 MAXDATAFILES 100
5 MAXINSTANCES 8
6 MAXLOGHISTORY 292
7 LOGFILE
8 GROUP 1 '/oracle_fs/Databases/DUPDB/redo01.dbf' SIZE 50M,
9 GROUP 2 '/oracle_fs/Databases/DUPDB/redo02.dbf' SIZE 50M,
10 GROUP 3 '/oracle_fs/Databases/DUPDB/redo03.dbf' SIZE 50M
11 -- STANDBY LOGFILE
12 DATAFILE
13 '/oracle_fs/Databases/DUPDB/system01.dbf',
14 '/oracle_fs/Databases/DUPDB/undotbs01.dbf',
15 '/oracle_fs/Databases/DUPDB/sysaux01.dbf',
16 '/oracle_fs/Databases/DUPDB/users01.dbf',
17 '/oracle_fs/Databases/DUPDB/example01.dbf'
18 CHARACTER SET WE8ISO8859P1
19 ;

Control file created.

SQL>


I am now ready to issue a RECOVER DATABASE command for database DUPDB which datafiles are in the DUPDB directory. I use the ORT24FS ArchiveLogs to recover the database.


SQL> recover database using backup controlfile until cancel;
ORA-00279: change 711843 generated at 05/14/2009 23:04:19 needed for thread 1
ORA-00289: suggestion : /oracle_fs/ArchiveLogs/ORT24FS/1_8_685060711.dbf
ORA-00280: change 711843 for thread 1 is in sequence #8


Specify log: {=suggested | filename | AUTO | CANCEL}

ORA-00279: change 711924 generated at 05/14/2009 23:06:57 needed for thread 1
ORA-00289: suggestion : /oracle_fs/ArchiveLogs/ORT24FS/1_9_685060711.dbf
ORA-00280: change 711924 for thread 1 is in sequence #9
ORA-00278: log file '/oracle_fs/ArchiveLogs/ORT24FS/1_8_685060711.dbf' no
longer needed for this recovery


Specify log: {=suggested | filename | AUTO | CANCEL}
CANCEL
Media recovery cancelled.
SQL> alter database open resetlogs;

Database altered.

SQL>

I have RECOVERed DUPDB to a consistent state. Let me verify it :


SQL> select * from v$instance;

INSTANCE_NUMBER INSTANCE_NAME
--------------- ----------------
HOST_NAME
----------------------------------------------------------------
VERSION STARTUP_T STATUS PAR THREAD# ARCHIVE LOG_SWITCH_WAIT
----------------- --------- ------------ --- ---------- ------- ---------------
LOGINS SHU DATABASE_STATUS INSTANCE_ROLE ACTIVE_ST BLO
---------- --- ----------------- ------------------ --------- ---
1 DUPDB
linux64
10.2.0.4.0 14-MAY-09 OPEN NO 1 STARTED
ALLOWED NO ACTIVE PRIMARY_INSTANCE NORMAL NO


SQL> select * from v$database;

DBID NAME CREATED RESETLOGS_CHANGE# RESETLOGS
---------- --------- --------- ----------------- ---------
PRIOR_RESETLOGS_CHANGE# PRIOR_RES LOG_MODE CHECKPOINT_CHANGE#
----------------------- --------- ------------ ------------------
ARCHIVE_CHANGE# CONTROL CONTROLFI CONTROLFILE_SEQUENCE# CONTROLFILE_CHANGE#
--------------- ------- --------- --------------------- -------------------
CONTROLFI OPEN_RESETL VERSION_T OPEN_MODE PROTECTION_MODE
--------- ----------- --------- ---------- --------------------
PROTECTION_LEVEL REMOTE_A ACTIVATION# SWITCHOVER# DATABASE_ROLE
-------------------- -------- ----------- ----------- ----------------
ARCHIVELOG_CHANGE# ARCHIVEL SWITCHOVER_STATUS DATAGUAR GUARD_S SUPPLEME SUP
------------------ -------- -------------------- -------- ------- -------- ---
SUP FOR PLATFORM_ID
--- --- -----------
PLATFORM_NAME
--------------------------------------------------------------------------------
RECOVERY_TARGET_INCARNATION# LAST_OPEN_INCARNATION# CURRENT_SCN
---------------------------- ---------------------- -----------
FLASHBACK_ON SUP SUP DB_UNIQUE_NAME
------------------ --- --- ------------------------------
STANDBY_BECAME_PRIMARY_SCN FS_FAILOVER_STATUS FS_FAILOVER_CURRENT_TARGET
-------------------------- --------------------- ------------------------------
FS_FAILOVER_THRESHOLD FS_FAIL
--------------------- -------
FS_FAILOVER_OBSERVER_HOST
--------------------------------------------------------------------------------
4163910544 DUPDB 14-MAY-09 711925 14-MAY-09
659189 24-APR-09 ARCHIVELOG 711926
0 CURRENT 14-MAY-09 1796 712047
14-MAY-09 NOT ALLOWED 14-MAY-09 READ WRITE MAXIMUM PERFORMANCE
MAXIMUM PERFORMANCE ENABLED 412086823 412086823 PRIMARY
711925 DISABLED SESSIONS ACTIVE DISABLED NONE NO NO
NO NO 13
Linux x86 64-bit
2 2 712118
NO NO NO DUPDB
0 DISABLED
0



SQL>
SQL> select * from v$tempfile;

no rows selected

SQL> alter tablespace temp add tempfile '/oracle_fs/Databases/DUPDB/temp.dbf' size 100M;

Tablespace altered.

SQL>


At this stage, both Databases have the same DBID.

ora10204>ORACLE_SID=DUPDB;export ORACLE_SID
ora10204>sqlplus '/ as sysdba'

SQL*Plus: Release 10.2.0.4.0 - Production on Thu May 14 23:46:25 2009

Copyright (c) 1982, 2007, Oracle. All Rights Reserved.


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> select dbid, name from v$database;

DBID NAME
---------- ---------
4163910544 DUPDB

SQL> exit
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ora10204>ORACLE_SID=ORT24FS;export ORACLE_SID
ora10204>sqlplus

SQL*Plus: Release 10.2.0.4.0 - Production on Thu May 14 23:46:40 2009

Copyright (c) 1982, 2007, Oracle. All Rights Reserved.

Enter user-name: / as sysdba

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> select dbid, name from v$database;

DBID NAME
---------- ---------
4163910544 ORT24FS

SQL>


I can use the DBNEWID "nid" utility to change the DBID for "DUPDB" anytime now.

Note : My thanks to Maggie Wu who showed me, many years ago, that I could RENAME a cloned database even before I RECOVERed it.

.
.
.

36 comments:

Coskan Gundogar said...

Hi Hemant,

Nice one.

One question what was the need to do this?

Cant you use duplicate database to do all these (you loose your redologs anyway)

Hemant K Chitale said...

This was in response to a forums.oracle.com thread (URL at the beginning of my post).
A non-RMAN backup of a production database has been copied to development. Maybe RMAN hasn't been implemented yet. It could have been a backup as of 1 week ago. Simultaneous connections betweeen production and development may not be possible (different networks) or not permitted.
Lots of possible reasons.

Tello said...

Hi Hemant;
Is there a way to change the dbname with changing the filenames in os level as well?

I mean, suppose I want to change orcl to orcl2 and
suppose bdump is in:
/oracle/app/product/orcl/bdump

it should be:

/oracle/app/product/orcl2/bdump

Same for datafile locations.

Is that possible automatically?

Hemant K Chitale said...

Tello,
Changing the dbname alone can be done with the DBNEWID utility.
As for changing the datafile names as well, there are two ways :
1. Generate a CREATE CONTROLFILE script (using ALTER DATABASE BACKUP CONTROLFILE TO TRACE), shutdown the database, rename datafiles at the OS level (using "move" or "mv" or "ren" commands), edit the CREATE CONTROLFILE script to specify the new locations and then run it so that the controlfile reads and sets the new path names of the datafiles.
2. Use the ALTER DATABASE RENAME FILE 'oldlocation' TO 'newlocation' command for each datafile being so renamed/relocated , with the database in MOUNT mode, not OPEN (because you will be renaming SYSTEM as well !)

Setting new locations for trace files simply requires creating the new trace file target directories and then updating your instance parameter file (initSID.ora or spfileSID.ora) for "background_dump_dest", "user_dump_dest", "core_dump_dest" etc etc) for all the "destination" directories.

Hemant K Chitale

TK said...

Hi Hemant;

How can I know wheter controlfile knows where redo ends? or controlfile is older than redo, etc..
so that I dont need open resetlogs.


I can compare controlfile and datafile with v$datafile and v$datafile_header.

How about redo? How can I compare controlfile with redo?

Hemant K Chitale said...

TK,
The controlfile has *information* about Checkpoints and SCNs.
It, itself, doesn't need to be compared.
However, if say, the highest available SCN recorded by the controlfile (which you would see in v$DATAFILE and V$LOG) is lower than the SCN in datafile headers, Oracle would "know" that the controlfile is older than the datafiles -- that it is a "backup" controlfile.

John said...

Hi

1-)Even there is no active user in the database, there is always activity by oracle processes
and scn increments every commit.
What kind of action oracle perfoms in the background so this current_scn increments every second?

2-)
Even Im the only active session in the database.

When I check the user datafile, I see that it is being used by some other process.And it is always being used.
How can this happen?

fuser /oracle/u01/oradata/orcl/users01.dbf
/oracle/u01/oradata/orcl/users01.dbf: 1388o 1382o 1380o 1378o 1376o

Hemant K Chitale said...

SCN isn't only incremented on commit. It is obtained at the start of a transaction and remains incremented even if the transaction is rolled-back.
The background processes and any server process for a user session that last accessed the datafile would have a file pointer open -- even if not currently doing any reads/writes.

Hemant

Unknown said...

Shutdown immediate
Take Cold backup including controlfile.
startup
alter system switch logfile
/
/

Restore cold backup
sys@XE> recover automatic database;
ORA-00283: recovery session canceled due to errors
ORA-00264: no recovery required

When I restore cold backup why I cannot apply the latest archivelogs?

However if I issue:
recover automatic database using backup controlfile;
I can apply the latest archivelogs.

Hemant K Chitale said...

Because a RECOVER, by default (i.e. without specifying BACKUP CONTROLFILE and/or UNTIL ...) is an instruction to do a COMPLETE Recovery. If your shutdown wasn't NORMAL or IMMEDIATE, the datafiles would not be consistent with the redo logs and controlfiles.
In your case, all three sets of files are consistent. The database sees no need to do a Recovery.

A "USING BACKUP CONTROLFILE" tells Oracle that the controlfiles are not current -- therefore it has to assume that the database is not current and roll-forward needs to be made.

Hemant

John said...

Hemant;

1-)Assume;
I take a cold backup on Monday.
My database is crushed on Friday.

Once I restore Mondays backup I should issue"recover database using backup comtrolfile"
clause to rollfoward until Friday.
This is the only way.
Am I right?


2-)Is above scenerio same for hot backup? DO I again need to issue
"recover database using backup comtrolfile" to rollforward until Friday.

Hemant K Chitale said...

John,
In both cases, you would use "USING BACKUP CONTROLFILE" if you have also lost your current controlfile with the database.

Also note that when you use RMAN for your BACKUP, RESTORE and RECOVER, the "USING BACKUP CONTROFILE" is hidden -- RMAN automatically recognises which controlfile it is using when doing a RECOVER.

Hemant

john said...

Hemant;
Lets say Im using current controlfile. (and not rman)

I take a cold backup on Monday.
My database is crushed on Friday.

Once I restore Mondays backup I should issue"recover database using backup controlfile" clause to rollfoward until Friday.
or "recover database" would be enough?

Hemant K Chitale said...

John,
A RECOVER DATABASE would be enough.


Hemant

john said...

Hi Hemant;

I need current controlfile during recovery because it stores the information about archivelogs and therefore
it knows where to go.
Is that right?

Hemant K Chitale said...

It is not "need current controlfile" it is "use current controlfile". You use the current controlfile, if you have it, so as to be able to do a COMPLETE Recovery. This is possible because the controlfile identifies the Log Sequence Number of the Online Redo Logs (ie, the CURRENT Redo Log) and Oracle can then do a Recovery to that point. That is assuming that you also have the Online Redo Log(s) !

Note : You don't use the current controlfile because "it has information about archivelogs". That information can be inferred by Oracle based on a backup controlfile or a created controlfile plus the first archivelog you apply and the log_archive_dest and log_archive_format OR your db_recovery_file_dest (ie your FRA)

Hemant

john said...

Thanks sir.

When I issue "recover database using backup controlfile" , the information in controlfile is not deleted, am I right?

I notice that v$archived_log has same records.

Hemant K Chitale said...

John,

If you did a CREATE CONTROLFILE (from a controlfile trace), there is no archivelog information in the controlfile.

A Backup controlfile can be either of
a) a controlfile that was created -- as above, so not having information in v$archived_log
or
b) a binary backup -- which has information only as of the time the backup was created but no information on archivelogs generated since then.

Hemant

Anonymous said...

I know that scn increments every commit or rollback.
I am just confused with block scn.
When a commit is issued, does scn of all blocks incremenets?
or
only the scn of modified block increments

Hemant K Chitale said...

Anonymous.

When a transaction updates a block, the block SCN is also updated -- thus different blocks in a datafile may have different block SCNs, depending on when they were updated.

Hemant

Anonymous said...

Hi

Let say instance crashed and shutdown abort occurred.

Instance recovery has to be done once I startup the database.

When I startup the database, oracle has to determine the transactions in redologs which has not been written to disk and write them.

How does oracle understand which transaction is already written or not? How can it determine this info?

Hemant K Chitale said...

Anonymous,
The headers of the datafiles tell Oracle what is the last SCN applied to each datafile and whether the datafile was closed cleanly.
Before attempting an OPEN, Oracle reads the headers. If the SCNs are inconsistent and/or the files were not closed, RECOVERY is required. If the Recovery is satisfied by the Online Redo Logs, it is Instance Recovery. If one or more of the datafile headers is much older, media recovery requires ArchiveLogs.

Hemant K Chitale

Anonymous said...

Let say scn of the headers are inconsistent, how does oracle undestand which redo in redolog to apply to datafiles?

Hemant K Chitale said...

Anonymous,
The header contains more information than you think.

See http://hemantoracledba.blogspot.com/2008/02/database-recovery-rollforward-from.html

Hemant K Chitale

Anonymous said...

Hi Hemant,

Nice explination

I've cloned a database using create control file command,then i received two errors
1) copatibility issue
the version 10.2.0.1.0 is not compatible with 10.0.0.0

----so in this case if we want to clone database with differrent compatible parameters, then is it possible to do so?

2)your database name is 'old one' it is not 'new one'

----to solve it i tried to change all the related parameters in the
init.ora file but could not resolve it, guide me

Hemant K Chitale said...

I wouldn't set COMPATIBLE to 10.0.0.0. I would set it to at least 10.1 or 10.2 (e.g. 10.2.0.1 or 10.2.0.4)

Changing the init.ora file doesn't change the database name. The database name is also stored in the datafile headers. Use the nid utility or use the CREATE CONTROLFILE command to change the database name.

Hemant K Chitale

Quaresma said...

Hi Hemant,

In production, I perform a backup with "backup database plus arhivelog" and copy accross all the generated backups to remote host.
One hour later, I start the duplicate session,However it fires the below errors.
Note that, I can still open the database with resetlogs option.
Why does it still require archivelogs ? I have already copied accross backupsets which includes archivelogs.

RMAN> run{
DUPLICATE TARGET DATABASE TO TEST
LOGFILE
1GROUP 1 ('F:\ORACLE\ORADATA\TEST\REDOLOGS\TEST_REDO1A.LOG','G:\ORACLE\ORADATA\TEST\REDOLOGS\TEST_REDO1B.ORA') SIZE 50m REUSE,
GROUP 2 ('F:\ORACLE\ORADATA\TEST\REDOLOGS\TEST_REDO2A.LOG', 'G:\ORACLE\ORADATA\TEST\REDOLOGS\TEST_REDO2B.ORA') SIZE 50m REUSE,
GROUP 3 ('F:\ORACLE\ORADATA\TEST\REDOLOGS\TEST_REDO3A.LOG', 'G:\ORACLE\ORADATA\TEST\REDOLOGS\TEST_REDO3B.ORA') SIZE 50m REUSE
NOFILENAMECHECK;
}
.

Starting recover at 05-FEB-11
using channel ORA_AUX_DISK_1

starting media recovery

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 02/05/2011 22:46:38
RMAN-03015: error occurred in stored script Memory Script
RMAN-06053: unable to perform media recovery because of missing log
RMAN-06025: no backup of log thread 1 seq 3024 lowscn 5366311185 found to restore
RMAN-06025: no backup of log thread 1 seq 3023 lowscn 5366310982 found to restore
RMAN-06025: no backup of log thread 1 seq 3022 lowscn 5366310786 found to restore
RMAN-06025: no backup of log thread 1 seq 3021 lowscn 5366310462 found to restore
RMAN-06025: no backup of log thread 1 seq 3020 lowscn 5366310260 found to restore
RMAN-06025: no backup of log thread 1 seq 3019 lowscn 5366310044 found to restore
RMAN-06025: no backup of log thread 1 seq 3018 lowscn 5366309846 found to restore
RMAN-06025: no backup of log thread 1 seq 3017 lowscn 5366309646 found to restore
RMAN-06025: no backup of log thread 1 seq 3016 lowscn 5366309451 found to restore
RMAN-06025: no backup of log thread 1 seq 3015 lowscn 5366309117 found to restore
RMAN-06025: no backup of log thread 1 seq 3014 lowscn 5366308914 found to restore
RMAN-06025: no backup of log thread 1 seq 3013 lowscn 5366308702 found to restore
RMAN-06025: no backup of log thread 1 seq 3012 lowscn 5366308505 found to restore
RMAN-06025: no backup of log thread 1 seq 3011 lowscn 5366308151 found to restore

Hemant K Chitale said...

Quaresma,
Your comment DOES NOT relate to this blog post.

If your DUPLICATE does not specify an UNTIL, it keeps reading the current SEQ#s from the target database controlfile -- so it keeps expecting archivelogs.

Hemant K Chitale

Quaresma said...

Thanks a lot Hemant,

So in other words, if I dont use until command, my database will not be opened automatically with resetlogs. Is that right?

According to oracle manuals, duplicate command will also open the database with resetlogs option implicitly.

Hemant K Chitale said...

Quaresma,

If you have run an RMAN DUPLICATE DATABASE command you should see an "set until scn...." in the "contents of Memory Script" that RMAN creates.
That is how it does incomplete recovery and subsequently does an OPEN RESETLOGS.

Hemant K Chitale

Quaresma said...

so, bottom line is,
If I dont specify snc or time inside duplicate command, I always have to issue open resetlogs command manually.

Hemant K Chitale said...

Quaresma,

If you don't specify a SET UNTIL you have to ensure that the DUPLICATE has all the ArchiveLogs required to recover upto the SCN of the target controlfile.

I cannot allow further conversation on this topic as it is not relevant to this blog post.

Hemant K Chitale

Unknown said...

Hi I have to rename database while restoring db from backup and I have to apply few archivelogs. Is that possible

Anonymous said...

Pls do not call it cloning.....

Unknown said...

Can we change the archive location of the new Database. Also can both the databases run side by side?Is this relevant for 11GR2?

Hemant K Chitale said...

Yes, of course. The archive location is not part of the database -- it is specified as an instance parameter. So you could use either log_archive_dest_1='' or set it to USE_DB_RECOVERY_FILE_DEST after having added db_recovery_file_dest and db_recovery_file_dest_size to your instance parameter file.
So, two databases can have two different archive locations.

You can run two databases side-by-side, provided you have enough CPU and Memory resources, besides disk space.