Dick, This is a classic Hot backup problem which has a mirror-split and lots of active datafiles. The reason you are being asked for additional archive logs is this: (and I bet this was for recovering the system.dbf file?)
When a tablespace is either put into backup mode or taken out of backup mode, a redo entry that records this event is made in the online redolog. When you break the mirror while still in hot backup mode and copy off the datafiles, SYSTEM.DBF records that you put these tablespaces as being in hot backup mode. On account of the database rename via CCF/RESETLOGS, the online redo logs can now *not* be used and thus the redo vectors that record the fact that the tablespaces came out of hot backup mode are now not available. When the database is opened now with RESETLOGS, all datafiles need to come up to the maximum SCN amongst themselves - details of which is present only in the first archive logs generated *after* the backup completed on the source system. You will then have to apply at least this one archivelog with a CANCEL based recovery before opening the database. If you copied out your archivelog destination via a mirror copy, then you need to add code to the script to 'archivelog current' on the source *after* the hot backup/mirror script is complete and then FTP the last archivelog to the destination server, as well as script the cancel based recovery. There could also be another deeper problem - if the mirror does not contain all the datafiles or parts of the mirror are stale, you will be asked for archivelogs starting from the time the missing datafiles were created or they went stale because of an invalid resilvering or missed filesystems.... (Been there and been bitten by such an issue, since another DBA created datafiles on non-mirrored filesystems :) Hope this helps - I did not find any 'companion in crime' listed in the address since the Listserv chops it off. I am sending this directly to you in case you have set an autoreply and left for the week - I can then get your alternate contacts. John Kanagaraj Oracle Applications DBA DBSoft Inc (W): 408-970-7002 Wanna know the reason for the season? Click on 'http://www.needhim.org' ** The opinions and statements above are entirely my own and not those of my employer or clients ** > The sequence of events we're using is: > > 1) Place production DB into hotbackup mode. > 2) Break the mirror. > 3) End backup on production. > 4) Mount the mirror on the second machine. > 5) Startup nomount the new instance, but under a different SID. > 6) Rebuild the control file with a new name while > renaming datafiles, > including the online redo. > 7) Recover the database. This is where the trouble commences. > > Anybody have an idea??? BTW: We're trying to do this as a > complete scripted > operation that the SA can just run. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: John Kanagaraj INET: [EMAIL PROTECTED] Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
