REDO Logs? They were IMPORTANT?

Okay so it's been like... a year....

I've been busy!!  Seriously, I've been doing DBA work like a freaking FIEND!!! I've been wrecking test and dev databases left and right, learning about partitioning in all it's glory, learning about TUNING! (that's right I know how explain plans work, y'all!) and basically y'know.  Earning a living.

So... here's my first post in a really long time.  Say one is refreshing a database and not doing it the nice safe RMAN clone way, the way Tom Kyte tells us to, but does it in a "I live on the edge and will take my Production database down a walk into the dark side, becuz that's how I ROLL".... and in the excitedness of it all accidentally wipes out NOT the who-cares-about-it DEV database redo logs, but sort of overwrites the redo logs of a QA Test database.  That is up.  And running.  And no longer has the redo logs it was just dreaming about before you so painfully shoved new redo log up into its, um, tender parts.  Somehow that window was just up! And the rest of the database files are intact, but the REDO logs are now history.

This is what you can do.  By the way, you have lost all the transactions in flight that have not been archived.  There MAY be a way to recover those out of memory but those people get paid like 1000.00 an hour and have Black American Expresses.  I am not one of them.  This is the corn bread version.  Oh, and by the way, this is why we MULTIPLEX redo logs.  FYI.

RECOVER UNTIL CANCEL  Scenarios

You have accidently dropped or overwritten or have otherwise corrupted redo logs.  This can happen a couple of ways; When restoring the whole database, you can accidentally restore the online redo logs, thus overwriting the current online logs with the older, useless backups. This action forces you to perform incomplete recovery instead of the intended complete recovery, thereby losing the ability to recover valuable data contained in the overwritten redo logs.​  The database can crash, or it can just give you terrible inconsistent messages.

• ​Beginning crash recovery of 1 threads
• Parallel recovery started with 15 processes​
• ​ORA-00305: log 2 of thread 1 inconsistent; belongs to another database
  ​
  

SQL>SHUTDOWN IMMEDIATE (or abort, depending on the mood you are in); SQL>STARTUP MOUNT; {​Create three additional redo log file groups } SQL>ALTER DATABASE ADD LOGFILE GROUP 4 ('/oradata/foobar/redo04.log') SIZE 150m;  SQL>ALTER DATABASE ADD LOGFILE GROUP 5 ('/oradata/foobar/redo05.log') SIZE 150m;  SQL>ALTER DATABASE ADD LOGFILE GROUP 6 ('/oradata/foobar/redo06.log') SIZE 150m; SQL>SHUTDOWN IMMEDIATE; {delete the corrupted or incorrect redo log files in the file system} SQL>STARTUP MOUNT; SQL>RECOVER DATABASE UNTIL CANCEL; SQL>CANCEL; SQL>ALTER DATABASE OPEN RESETLOGS;​​

If this still doesn't give you the droids you are looking for then do a DBPITR and then after the RESTORE part, do this again. It will work.