RE: Where is Oracle 9.2 init.ora?

After reading this, I ran to verify what happens when I edited the spfile.
Surprisingly I had the same situation (9.0.1 Solaris).
Edited the file and started the database without a single error and nothing
reported in the alert or bdump.

But Oracle used init.ora since non of the settings in spfile were in effect.

I can not believe that Oracle starts without any complaints or errors.

I am sincerely sorry about my earlier post. I must be drunk at that time as
I could not replicate my test. I was mistaken (happens as I get old... ;)

However, let me state the following:
SPFILE is in ASCII format (on AIX and HP that I checked) And can be edited
via 'the Six Editor' (that is the other name for VI editor per Dave Ensor ;)

There is some hashed information maintained in the 1st line based on the
contents of the file when it was originally created.

I edited the file for a few parameters and bounced the DB. It started fine
without any warnings, BUT it silently used the available init.ora file. My
changes did not take effect. There was no ORA error or warning. Nothing in
alert.log either.

When I renamed the init.ora file, and tried to bounce the database, it did
not start. But now, following ORA errors were reported...
SQL> startup
ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file
'/u01/home/oracle/product/9.0.1/dbs/initKED9.ora'

So, the lesson learned is not to edit the SPFILE. And if there is an
init.ora file, Oracle will simply use it, if it the SPFILE does not pass
the checks based in the hashed information in the 1st line of SPFILE.

And hence, there is still some work to be done by Oracle with how SPFILE is
implemented.
I would like to see an error telling me that "available SPFILE is useless"
before using the available init.ora file.
Then I used the "corrupted" SPFILE to build a new init.ora file and started
the database without any problems.

I like to 'play' around with throw away databases to see how these new
features work and how we can break them, there is nothing wrong in doing so.
This is how I 'do oracle' :)

--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Deshpande, Kirti
INET: kirti.deshpande_at_verizon.com
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Khedr, Waleed
INET: Waleed.Khedr_at_FMR.COM
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).