When using the new 9i SPFILE facility, changes to parameters in the SPFILE are checked individually for correctness, but not combinations of parameters. Thus, its quite easy to create a scenario where your SPFILE will no longer permit you to restart your database.
For example, in a default 9i database, you can issue:
SQL> create spfile from pfile = '/u01/oracle/admin/db1/pfile/initdb1.ora';
(then shutdown / restart to activate the spfile)
SQL> alter system set db_block_buffers = 1000;
This will work, but (unbeknown to you) you now have both db_cache_size set (assuming a default 9i install) and db_block_buffers - which is not permitted. If you realise the error before the next database restart, then you can resolve the problem with:
SQL> alter system reset db_block_buffers scope=spfile sid='*';
to remove the change you just made. But if you shutdown without fixing the error, when you try to restart, the database will return an error (even if you try a startup nomount)
SQL> create pfile = '/u01/oracle/admin/db1/pfile/initdb1.ora' from spfile;
even if a database and/or instance is down. You then follow (1) above. (Thanks to Pete Sharman for this last one)
Thus, even though we now have the convenience of spfiles, you still need to take care.