Cause:An incomplete recovery
session was started, but an insufficient number
of redo logs were applied to make the file consistent.
The named file was not closed cleanly when it was last opened by the
database.
The most likely cause of this message is forgetting to restore the
file from a backup before doing incomplete recovery.

Action:The file must be recovered
to a time when it was not being updated.
Either apply more redo logs until the file is consistent or restore
the file from an older backup and repeat recovery.if you face this type of error , after appling all redo log and archive
log successfuly.you can consider to setup
"_allow_resetlogs_corruption" this undocumented parameter .

Explanation :
==========
Before thinking about the use of the undocumented parameter
"_allow_resetlogs_corruption" all other avenues of database recovery
must have been exhausted. Because this parameter forces the opening of the
datafiles even if their SCNs do not match up. Then at the next checkpoint the
old SCN values are over-written. This could leave the database in an unknown
state as far as concurrency.

For that reason, you must export and rebuild your database after using belows
recovery method Most of the time, this recovery method is required when a data
file has been left in hot backup mode through several backup cycles without an
intervening shutdown and startup.Upon shutdown and startup
the database will complain that a file (usually file id#1 the SYSTEM
tablespace) needs more recovery and asks for logs past all available archive
logs and online logs.

An other scenario could be that the database is recovered from a hot backup and
the above scenario occurs, or,the database asks for an
archive log that is before any that are available (usually for the ROLLBACK
segment tablespace datafiles.)
In the Course of doing this... you may come up with Issues
ORA-01194: file 1 needs more recovery to be consistent ORA-01110: data file 1:
'..../system01.dbf'
or
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 12 needs more recovery to be consistent ORA-01110: data file 12:
..../data01.dbf'

If all available archive logs are applied and all available online redo logs
applied and the error is not corrected, only then should use of the parameter
"_allow_resetlogs_corruption" be considered.Make sure a good backup of the database in a closed state (all files) is
taken before attempting recovery using "_allow_resetlogs_corruption".

example:-

1) Do a "SHUTDOWN NORMAL" of the database

2) Set/Add the below parameter in pfile like

_allow_resetlogs_corruption = true

3) Do a "STARTUP MOUNT pfile='pfile_location_name' " and "ALTER
DATABASE OPEN RESETLOGS;"

4) If the database asks for recovery, use an UNTIL CANCEL type recovery and
apply all available archive and on-line redo logs, then issue CANCEL and
reissue the "ALTER DATABASE OPEN RESETLOGS;" command. like below..

Specify log: {<ret>=suggested | filename | AUTO | CANCEL}CANCELMedia recovery cancelled.This sitation will raise at the time of recover database .Reason 1.ALTER SYSTEM SWITCH LOGFILE command is using for production backup scripts with RMAN Backup.Reason 2.If we start a RESTORE database with a BACKUP controlfile and Flash Recovery Area is defined, RMAN execute and implicit crosscheck and catalog of all the objects in the Flash Recovery Area.I will be explain briefly regarding reason 1both ALTER SYSTEM SWITCH LOGFILE and ALTER SYSTEM ARCHIVE LOG CURRENT will force a log switch, but they do it in different ways! Both the SWITCH LOGFILE and ARCHIVE LOG CURRENT write a quiesce checkpoint, a firm place whereby that last redo log is a part of the hot backup, but ARCHIVE LOG CURRENT waits for the writing to complete. This can take several minutes for multi-gigabyte redo logs. Conversely, the ALTER SYSTEM SWITCH LOGFILE command is very fast and returns control to the caller in less than a second while ALTER SYSTEM ARCHIVE LOG CURRENT pauses. As we see below, the ALTER SYSTEM SWITCH LOGFILE is fast because it does not wait for the archiver process (ARCH) to complete writing the online redo log to the archivelog log filesystem:It issues database checkpoint It immediately starts writing to the next redo log In the background, the “switch logfile” command tells the ARCH background process to copy the “old” redo log file to the redo log filesystem.

ALTER SYSTEM SWITCH LOGFILE asynchronous . This command is fast to return to the invoking program because the writing of the redo log to the OS filesystem is done in the background. There is a very small risk in cases where the ARCH process cannot complete writing the redo log, such as cases where the OS archivelog file directory is out of space. It is also risky because the calling script may move on to a subsequent step, assuming that the redo has been written. Some scripts will place a SLEEP 60 command in their backup script to allow time for the redo to complete writing, but this is not a best practice.

ALTER SYSTEM ARCHIVE LOG CURRENT synchronous. This is faster to return because this command waits until the online redo log has completed the writing of the redo log file to the filesystem. This command is safer because it waits for the OS to acknowledge (ACK) that the redo log has been successfully written. Hence, ALTER SYSTEM ARCHIVE LOG CURRENT is the best practice for production backup scripts with RMAN.

RAC: If you are running RAC, the ALTER SYSTEM ARCHIVE LOG CURRENT will switch the logs on all RAC nodes (instances), whereas ALTER SYSTEM SWITCH LOGFILE will only switch he logfile on the instance where you issue the switch command. Hence, ALTER SYSTEM ARCHIVE LOG CURRENT is a best practice for RAC systems.The ALTER SYSTEM ARCHIVE LOG CURRENT allows you to specify the thread to archive while the ALTER SYSTEM SWITCH LOGFILE archives only the current thread. If you do not pass the thread parameter, Oracle will archive all full online redo logs.