it seems like a bug, regression from 10g... did a quick lookup in metalink and didn't find anything...
How about opening an SR with a test case of 10g vs 11g? if it is a known issue, you might get a patch. If it isn't, they will hopefully fix it (eventually).
In a bit related note, you can consider using RMAN to check for physical and logical corruptions in your database. I believe it is better and more comprehensive check. For example,run rman VALIDATE CHECK LOGICAL DATABASE Check the docs here. If rman find block corruption, it populates v$database_block_corruption and you can then just use rman to recover the specific corrupted blocks. You can parallelize the RMAN VALIDATE by opening multiple channels...
I assume you have a pfile somewhere? Either in the directory where it's looking for the spfile in your question, or perhaps in the admin\pfile directory. Anyway, try:
sqlplus / as sysdba
create spfile from pfile='<location of pfile>'
startup
That should do it.
EDIT:
You can always go back and forth with your spfile and pfile in this manner. It's good to have a text file backup of your spfile, since you can't directly edit the spfile (you can only change it when the database is mounted):
create pfile='<pfile location>' from spfile;
The spfile gives you the ability to change dynamic parameters while the database is open without restarting the database and to make them permanent across database restarts:
alter system set open_cursors=new limit scope=both
This makes the change in the running database as well as the spfile to make it effective across DB restarts.
With the old pfile paradigm, you had to edit the pfile manually to make the change effective across restarts. Additionally, you can modify parameters that require a database restart in the spfile while the database is up, to become effective on the next restart:
alter system set sga_max_size=new_sga_max scope=spfile
You can't modify the running instance with this parameter, but you can make it effective on the next restart.
Best Answer
Yes, you can have different versions of Oracle installed and running on the same server. I'd probably go with different listeners on different ports. And you wouldn't want two instances with the same name running. There's plenty of other areas you'd want to be sure they don't bump into each other (mostly disk locations).
That said, running two instances (other than dev/test) on one server isn't generally recommended. If they are small, you'd probably get better performance as separate schemas in one instance, and if they are big then go for separate servers. Also consider virtualization as an option.