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).

Reply via email to