structure of redo.log is exactly the same as its archived log

What happens when issue below command in the wrong database

recover data using backup control file until cancel;

This could be happened on Windows platform, if you unfortunately have the following settings.

1. Has below setting on both client & server node in sqlnet.ora
SQLNET.AUTHENTICATION_SERVICES = (NTS) #allow local login as sysdba
2. has the tnsnames.ora to point to remote database.

As REMOTE_OS_AUTHENT has no affect on Windows Native Authentication. The same information is passed
regardless of this setting.
-- bad control caused the disaster


Hence, after press enter, the database is likely become recovery mode. (You may not know immediately ...).

--think control file status changed

Finally you will know ...


When you try to recover it :

--you can't use real backuped control file without restore all backed up datafiles
--startup mount
--RECOVER database using backup controlfile until cancel ; (this control file is current file which just corrupted by the command)


it complains can't find the last archived log file . e.g. TEST10P_001_0627748383_17328.ARC
actually, it is the CURRENT redo log.


So what I did is , copy the redo.log to archived directory and rename it to TEST10P_001_0627748383_17328.ARC


then tried the command again


ORA-279 signalled during: ALTER DATABASE RECOVER database using backup controlfile until cancel ...
Fri May 23 16:16:58 2008
ALTER DATABASE RECOVER CONTINUE DEFAULT
Fri May 23 16:16:58 2008
Media Recovery Log G:\TESTDB\ORAARCH2\TEST10P\TEST10P_001_0627748383_17328.ARC


RECOVER database using backup controlfile until cancel ;

cheers ! I saw the message: Media Recovered.

Finally, "alter database open resetlogs;"


We are saved!

Heart beat dropped from 200 to 65.



From this case, I guess the file structure of redo.log is exactly the same as its archived log.