It's been a couple of months since I last did this on 10gR1, but I've seen this type (not sure if it's the exact one) before. Basically it's a bug in 10gR1, which is fixed in 10gR2. No harm is done, all you have to do is log out of the RMAN session, log in a SYSDBA in sqlplus and perform the recovery manually (recover database...). Then open resetlogs. Finn On 12/21/07, krish.hariharan@xxxxxxxxxxxx <krish.hariharan@xxxxxxxxxxxx> wrote: > > While I have not used the duplicate command per se, I have "cloned" multi > TB databases with RMAN. The error you are encountering is > > 01124, 00000, "cannot recover data file %s - file is in use or recovery" > // *Cause: An attempt to do media recovery found that the file was not > // available for recovery. Either it is online and the database > is > // open in some instance, or another process is curently doing > // media recovery on the file. > // *Action: Do not do media recovery. > > > I wonder if it is attemting to get a BR lock (out on a limb) for the > duplication and not able to get it since the file may perhaps be offline > or otherwise unavailable. In addition the alert log showed 1 through 12 > but the newname only applied to 1 through 10. You are connected to the > target database for the priming the duplication. > > As a soapbox/footnote, this is one of the reasons I am queasy about using > the duplicate command. > > -Krish > > -- > //www.freelists.org/webpage/oracle-l > > >