Work around: Yes do not use spfile Hire a DBA :) -----Original Message----- Sent: Monday, July 15, 2002 5:02 PM To: Multiple recipients of list ORACLE-L
Okay.. Oracle Support just informed me that Bug # 2462605 has been filed regarding this issue with SPFILE.... not visible to public yet, but following text is in my TAR: ------------------- Called customer lms on vm.... please call when avail SME did see this.. but did not file a bug on this. 15-JUL-02 17:08:16 GMT talked with custoemr.. about this.. he would like me to file a bug filing bug 15-JUL-02 17:19:47 GMT bug was filed 2462605 15-JUL-02 17:29:37 GMT Associated bug 2462605 has been updated and has changed status to 10. ----------------- - Kirti > -----Original Message----- > From: Deshpande, Kirti [SMTP:[EMAIL PROTECTED]] > Sent: Monday, July 15, 2002 12:24 PM > To: Multiple recipients of list ORACLE-L > Subject: RE: Where is Oracle 9.2 init.ora? > > Thanks, Tony. > > If that were the case, the second test (scope=spfile) should not have > failed. > > Oracle Support left a v-mail to me stating that they are considering this > a > bug. And wanted to talk to me about more testing. I will get with them > later today (or tomorrow). > > Regards. > > - Kirti > > > -----Original Message----- > > From: Aponte, Tony [SMTP:[EMAIL PROTECTED]] > > Sent: Monday, July 15, 2002 9:37 AM > > To: [EMAIL PROTECTED] > > Cc: [EMAIL PROTECTED] > > Subject: RE: Where is Oracle 9.2 init.ora? > > > > On my version of UNIX (Solaris) moving/removing a file that is in use > only > > affects the directory entry and not the actual payload on disk. I > suspect > > that the spfile was held open by your sqlplus program and it executed > the > > I/O operation using the open file descriptor. I've participated in > > similar (and unplanned) tests with ufs-based file systems where all of > the > > underlying files where rm-ed and the database continued to run. It > > crashed when it tried to switch into the next and non-existent redo log > > files. A post-mortem on the incident taught us that removing an open > file > > only removed the entry from UNIX's directory file but the cleanup was > > postponed until the OS closed the last open handle for that i-node. > > > > HTH > > Tony Aponte > > > > -----Original Message----- > > From: Deshpande, Kirti [ <mailto:[EMAIL PROTECTED]>] > > Sent: Sunday, July 14, 2002 6:58 PM > > To: Multiple recipients of list ORACLE-L > > Subject: RE: Where is Oracle 9.2 init.ora? > > > > > > All Right, Larry. Since we have the test servers and databases; and my > > Company still pays for 'doing Oracle' the 'scary' way, here is another > > 'scary thing' I did with SPFILE :) > > (9iR1 on HP) > > > > SQL> conn / as sysdba > > Connected to an idle instance. > > SQL> startup <---- using spfile > > > > ORACLE instance started. > > Total System Global Area 72273416 bytes > > Fixed Size 437768 bytes > > Variable Size 37748736 bytes > > Database Buffers 33554432 bytes > > Redo Buffers 532480 bytes > > Database mounted. > > Database opened. > > SQL> show parameter db_cache_size > > NAME TYPE VALUE > > ------------------------------------ ----------- > > ------------------------------ > > db_cache_size big integer 33554432 > > > > SQL> !mv spfileKED9.ora spfileKED9.ora.bak <-- hide the spfile > > > > SQL> !ls -l *.ora > > -rw-r--r-- 1 oracle dba 12920 May 10 2001 initdw.ora > > > > SQL> alter system set db_cache_size=10M scope=both; <-- try to set a > new > > > > value > > > > System altered. <--- No problem? > > > > SQL> show parameter db_cache_size > > > > NAME TYPE VALUE > > ------------------------------------ ----------- > > ------------------------------ > > db_cache_size big integer 12582912 > > > > --> New value in effect. > > > > SQL> !ls -l *.ora > > -rw-r--r-- 1 oracle dba 12920 May 10 2001 initdw.ora > > > > --> Still no SFILE.... > > --> Now, why would not Oracle tell us that there was no spfile to > process > > SCOPE=BOTH ? > > > > SQL> c/both/spfile > > 1* alter system set db_cache_size=10M scope=spfile > > SQL> / > > alter system set db_cache_size=10M scope=spfile > > * > > ERROR at line 1: > > ORA-27037: unable to obtain file status > > HP-UX Error: 2: No such file or directory > > Additional information: 3 > > > > -->This is what should have happened with SCOPE=BOTH as well, or at > least > > a > > warning that SCOPE=BOTH was processed as SCOPE=MEMORY since there was no > > > SPFILE available. I would not have objected if Oracle re-recreated > SPFILE > > in > > the default location and told me so! > > > > If anyone has seen any mention of this particular behaviour of > SCOPE=BOTH, > > I > > would like to know the source of that information. I have searched > > Metalink, > > Google but have not come across any. I have created an iTar with OWS. > > Thanks. > > > > As I said before, SPFILE has some things that need to be made fool > proof. > > > > This time I did not drink prior to doing this 'scary' stuff !! ;-) > > > > Regards, > > > > - Kirti > > > > > -----Original Message----- > > > From: Larry Elkins [SMTP:[EMAIL PROTECTED]] > > > Sent: Friday, July 12, 2002 9:03 PM > > > To: Multiple recipients of list ORACLE-L > > > Subject: RE: Where is Oracle 9.2 init.ora? > > > > > > Man, it scares the heck out of me too that Jared and Kirti are > actually > > > "doing Oracle" -- I can't believe companies actually pay them ;-) > > > > > > And you two guys, and I'm talking to you Kirti and Jared, probably dig > > in > > > and do things you shouldn't on test boxes just to see how things work > > and > > > to > > > learn. FWIW, I've heard rumors about other people doing similar > things. > > > You've probably even intentionally crashed a DB or pulled the plug > just > > to > > > see if you could recover. Shame on you two. You should both be > banished > > > from > > > the list for doing such unconventional things ;-) > > > > > > And neither of you will ever be allowed close to a DB I deal with -- > > I'll > > > call ltiu from now on ;-) > > > > > > Larry > > -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Deshpande, Kirti INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
