Re: Oracle function myth on Solaris machinie

guo_at_andrews.edu (Limin Guo) wrote in message news:<f866cfef.0311240602.11bf1263_at_posting.google.com>...
> joel-garry_at_home.com (Joel Garry) wrote in message news:<91884734.0311211705.1c47309b_at_posting.google.com>...
> > Sybrand Bakker <gooiditweg_at_sybrandb.nospam.demon.nl> wrote in message news:<00psrvgs8c8vilkp2tilu5u5joqoo25fkr_at_4ax.com>...
> > > On 21 Nov 2003 07:44:49 -0800, guo_at_andrews.edu (Limin Guo) wrote:
> > >
> > > > WHY sql_trace or 10046 has impact on the insert, I
> > > >don't understand.
> > >
> > > Are you familiar with the buffer cache? If so, won't you think a
> > > likely explanation is in your so-called 'fast-mode' everything is in
> > > the buffer cache and in your so-called 'slow-mode' Oracle has to fetch
> > > everything again?
> > > So why are you making up myths?
> >
> > So why was it slow on the third try?
> >
> > Maybe he needs to go to 8.1.7.4 to fix one of the performance bugs?
> >
> > jg
>
>
> I wouldn't think it was caused by buffer cache. just as common sense,
> I don't believe the buffer cache has this much impact on the insert
> statement (2 hours and 15 minutes vs. 10 minutes). Like Joel said it
> could be a performance bug. I am going to ask Unix group to reboot the
> machine soon. if problem is still around, I will try to rebuild this
> database. somehow, I kind of suspect the database was corrupted. If
> all fails, I will try to apply 8.1.7.4 patchset. Any other
> suggestions?

Do you have a huge regid.dat or other *.dat file under an otrace directory somewhere under $ORACLE_HOME? In past times, this would be a cause of thrashing when tracing was on.

>
> We used kill -9 a lot for last two weeks to kill running away report
> queries (I know it is bad practice to kill the process this way). I
> would not think this should have any permanent impact on my database.
> Has anyone have bad experience with kill -9 on Unix platform?

I've had much better luck with this than using alter..kill or OEM, because kill -9 implies cleanup with PMON as opposed to SMON, which may have other things to think about. But I think the potential for problems exists if you do it a lot either way, check v$session to see if they are going away, as well as netstat -a for ports incorrectly tied up with FIN_WAIT_2. Of course, killing the wrong process can be a very bad experience :-)

jg

--
@home.com is bogus.
http://www.renesys.com/news/index.html