Option 1) Can you go from your last backup and apply archive log files up to just before the loss of online redo logs?

Option 2) Do you have a backup control file? You can create new online redo log files/groups/members. You will lose some data because of the loss of the orginal redo logs (otherwise, it would have been a case of instance recovery).

From MetaLink:
You accept the suggested archive log (by pressing Enter) and then receive
the following errors:

ORA-00308: cannot open archived log '%s'
ORA-07260: sfifi: stat error, unable to obtain information about file.
SVR4 Error: 2: No such file or directory

Checking for the file at the OS level confirms that the suggested archive log
does not exist. However, all archive logs prior to the suggested log exist.


Solution Description:
=====================

The change the database needs is most likely located in the current online
redo log. When the recovery process suggests the non-existent archive log,
you need to provide the path to the current online redo log. The current
log can be determined from the following query:

SELECT MEMBER
FROM V$LOGFILE F,
V$LOG L
WHERE L.STATUS = 'CURRENT'
AND L.GROUP# = F.GROUP#;

Once you know the current log, restart the recovery procedure and provide the
path to the log when prompted:

SVRMGR>recover database using backup controlfile;
ORA-00279: Change <#> generated at needed for thread <#>
ORA-00289: Suggestion:
ORA-00280: Change <#> for thread <#> is in sequence <#>
Specify log: {=suggested | filename | AUTO | CANCEL}
********************************************
* At this point, you should type in the *
* path to the current log and press enter. *
********************************************
Log applied.
Media recovery complete.

You should then be able to open the database:
SVRMGR> ALTER DATABASE OPEN RESETLOGS

The resetlogs option must be used to synchronize the controlfile.


Explanation:
============

When recovering using the backup control file, the database has no knowledge
of the current online redo logs. The change necessary is still in the current
online redo log but the database is forced to assume the change is in the next
consecutive archive log. This archive log has not yet been created.