I was doing RMAN RESTORE database for refreshing developers’ stand and stuck on next situation:
run{ SET UNTIL SCN 18508482749; SET NEWNAME FOR DATABASE TO ‘/oradata1/oradata/XXX/%b’; RESTORE DATABASE; RECOVER DATABASE; } creating datafile file number=1 name=/oradata1/oradata/XXX/system01.dbf RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of restore command at 08/08/2012 13:27:26 ORA-01180: can not create datafile 1 ORA-01110: data file 1: ‘/oradata1/oradata/XXX/system01.dbf’Based on message ORA-01180 it looks like RMAN wasn’t able to create a datafile, so it may be some directory permission issue, but I have checked and everything looks fine – I even was able to create mentioned file using Linux touch command. Checking everything took about 15 minutes, but still wasn’t able to restore database because of mentioned ORA-01180 issue, so I have decided to trace RMAN, but fist it would be better to check MOS for already known problems – and it was there 
In my particular case the issue was because of database backups on new server were in different location, so they actually have had status EXPIRED -> no FULL/LEVEL 0 backups AVAILABLE and RMAN decided to create files from scratch, but it isn’t supported/allowed for files belonging to SYSTEM tablespace…
But… in this situation I would actually expect error message like this one:
RMAN-06023: no backup or copy of datafile 1 found to restoreSo, I have CROSSCHECKed and DELETEd all EXPIRED backups, then CATALOGed backups from proper location and then I was able to complete my task.
I’ll list some possible scenarious for mentioned situation:
- no AVAILABLE datafile backup -> my situation – the simplest case
- SET UNTIL SCN/TIME specifies SCN/TIME that is less than SCN/TIME of datafile backup -> make UNTIL SCN/TIME larger than
- there are no FULL/LEVEL 0 datafile backups in CURRENT INCARNATION -> RESET DATABASE TO INCARNATION which has AVAILABLE FULL/LEVEL 0 datafile backups
- UNTIL TIME convertion to SCN is not exact and will lead to situation mentioned in second case -> better use UNTIL SCN
- Inactive Thread and Incarnation Issues are discussed in details in MOS document mentioned in Reference section
Conclusion:
- quite interesting situation and it really better to have been informed about it before You face it, so additionally read MOS document mentioned in Reference section
References:
- 1366610.1 Common Causes for RMAN-06023 and RMAN-06026
In my expeirence, such behaviour is typical for development copies of production databases where developers test their applications on point in time recovered databases and periodically need fresh database copy. New restore of database will fail if there are archivelogs in fast recovery area from previous testing (another incarnation after resetlogs due to point-in-time recover). Often, manually deleting old archivelog files from fast recovery area is enough (and restoring controlfile again if you already get such error).
Comment by Arsenij Kroptya — 11.02.2013 @ 17:03 |
Arsenij,
it looks like second reason mentioned in my post
Comment by odenysenko — 11.02.2013 @ 19:08 |
Yes, causes are like in second, but looks different as first recover command “restore database” do not use “set until” clauses. And it is not looks like third reason new incarnation problem as there are no any control or datafiles from previous test database and production database does not have any changes in incarnation. Statuses of backups from test database are ‘AVAILABLE’.
Comment by Arsenij Kroptya — 11.02.2013 @ 20:09