ORA-01203 - wrong creation SCN

[Enrico Venturi]

Hello colleagues,
I copy a database from a machine to a second one through this procedure:
I set each tablespace in backup mode
I copy the datafiles
I copy the control file

On the second machine I try to startup the database but the following errors are got:
SQL> @/usr/Systems/1359HA_9.0.0_Master/HA_EOMS_1_9.0.0_Master/tmp/oracle/CACHE/apply_redo.sql;
ORACLE instance started.

Total System Global Area 423624704 bytes

Fixed Size 2044552 bytes

Variable Size 209718648 bytes

Database Buffers 209715200 bytes

Redo Buffers 2146304 bytes

Database mounted.
alter database recover automatic from '/usr/Systems/1359HA_9.0.0_Master/HA_EOMS_1_9.0.0_Master/data/warm_rep
l/WarmArchive/CACHE' database until cancel using backup controlfile
*
ERROR at line 1:
ORA-00283: recovery session canceled due to errors
ORA-01110: data file 1: '/cache/db/db01/system_1.dbf'
ORA-01122: database file 1 failed verification check
ORA-01110: data file 1: '/cache/db/db01/system_1.dbf'
ORA-01203: wrong incarnation of this file - wrong creation SCN


You see the mount command and the error got.
What that error exactly mean?
Maybe I didn't copy timely aligned datafiles and controlfiles?

thanks for the support
Enrico

[Steven E. Protter]

Shalom,

Is the system time different between the source and destination systems?

It does seem like an incomplete fileset, but your restore method may require change.

SEP

[Keith Johnson]

You have a data file/control file mismatch. Please see the output below.

# oerr ora 01203
01203, 00000, "wrong incarnation of this file - wrong creation SCN"

// *Cause: The creation SCN in the file header is not the same as the creation SCN in the controlfile. This is probably a copy of a file that was dropped.

// *Action: Restore a current copy of the data file and do recovery as needed.

[Oviwan]

Hey

You have to copy all the datafile to a same directory structur as the original database.

if you copy the first datafile at: 12:00
and the last file at 12:30 then the data are inconsistent. so you have to copy the archivelogs from 12:00 until 12:30 and recovery them

or

you do a offline copy of the database

Regards

[Enrico Venturi]

Hi again,
still doesnt't work.
The control file is enclosed.
I copy all the files listed in the control file but the reported problems is still the same:
ORACLE instance started.

Total System Global Area 423624704 bytes
Fixed Size 2044552 bytes
Variable Size 209718648 bytes
Database Buffers 209715200 bytes
Redo Buffers 2146304 bytes
Database mounted.
alter database recover automatic from '/usr/Systems/1359HA_9.0.0_Master/HA_EOMS_1_9.0.0_Master/data/warm_repl/WarmArchive/CACHE' database until cancel using backup controlfile
*
ERROR at line 1:
ORA-00283: recovery session canceled due to errors
ORA-01110: data file 1: '/cache/db/db01/system_1.dbf'
ORA-01122: database file 1 failed verification check
ORA-01110: data file 1: '/cache/db/db01/system_1.dbf'
ORA-01203: wrong incarnation of this file - wrong creation SCN

I'm really in crisis :-((


please help me!

[Oviwan]

Hey

1. copy the datafile when the tablespace is offline
2. copy the controlfile e.g.
alter database backup controlfile to '/oracle/SID/control0/control0.dbf' reuse
3. copy all the archivelogs between the copytime of the first datafile and the copy of the controlfile.

now you can start it and recover the archivelogs this should work.

or as already mentioned. shutdown the database and copy all the datafiles and controlfiles and open the database..

check your ora-01203 with
$oerr ora 01203

hope this helps

regards

[Enrico Venturi]

Oviwan,
first of all I thank you for your support,
then:
the procedure we're using is the one used for a long time on several databases; now we're trying to replicate a new schema of database.
The procedure is the following:
the database works in archivelog mode
we look for all the datafiles in the sys.dba_data and sys.dba_temp views, then we get the tablespaces mapped on these datafiles and then we put those tablespaces in backup mode, then we copy the datafiles and then we copy the controlfile; at the end we put the tablespaces "end backup" mode.
It usually works, now we got that error....
I'm investigating but I can't understand.
Any other ideas?

[Enrico Venturi]

The procedure to copy the database is enclosed;
I've checked that the files are properly uncompresses on the standby host and the control files are recovered.

Please help ...

[Volker Borowski]

Hi,

some points :

Any symlinks in use on the pathnames to the controlfiles that have been droped on the target? This pretty much look like either
- the copy is not done at all
- the copy is done, but the target refers to another destination (i.E. if a symlink turned into a "real" directory)
- the target database is mounted while doing the copy (which would result in the overwriting of an active controlfile)

I do not understand why you (correctly) do a "alter database backup controlfile ..." (to the archive area if I checked correctly), but then use a binary copy of the active(!) controlfile to re-establish the database. That does not seem to be proper at all to me.
Correct would be to copy the only one backup file
"ctrl_pm.ctl"
to all of your multiple controlfile locations on the target and then mount.

May be the procedure did work in the past, because you have been lucky, that no activity took place during the copy of your several(?) controlfiles, so that they are in fact identical. But if you get a single commit between the copy of the multiple controlfiles it can not work at all.

The error says, that your sytem tablespace at the target does not correspond to the controlfile of the target. Did you check the permissions and filesize to ensure that the file is indeed overwritten. May it would be more safe to clear the target location to ensure that the copy is done correctly.

Another thing that comes to my mind:
Did you "open RESETLOGS" that source DB at any time after the last successful copy?
May be the %r in log_archive_format troubles you now. Could you attach "apply_redo.sql" for more information about your recoveryx procedure on the target?

Hope we are going to track this one down
Volker