The sysaux tablespace is not required for the instance, not quite like the system tablespace datafile.
Could be possible to fix by recreating the control file(s) if there truly are no longer any extents in use in the suspect datafile. Get a controlfile trace backup, with a system connection run:
alter database backup controlfile to trace resetlogs;
And locate the new trace file way down in the trace directory under the DIAGNOSTIC_DEST location. Recreating the controlfile requires startup nomount and moving the current control file(s) out of the way, the instance will not overwrite existing controlfile(s). Do recovery, alter database open resetlogs, and (re) add the temp files.
In the create controlfile DDL leave out the suspect datafile.
*Might* be able to take the datafile offline and then drop it, although folks in the ASM forum should be able to offer better help.
Message was edited by: clcarter and remove bad datafile name
According to Logical Storage Structures a database must have the
SYSAUXtablespaces. During normal database operation, the database does not allow the
SYSAUXtablespace to be dropped or renamed. If the
SYSAUXtablespace becomes unavailable, then core database functionality remains operational. The database features that use the
SYSAUXtablespace could fail, or function with limited capability.