Thanks Rachel.
For Denham: Changing SPIN_COUNT from its default value is usually a Very
Bad Thing. Your sleeps are caused by lots of competition for one or more
latches. The best way to stop those sleeps from impacting response time
is to cut out the unnecessary competition. Because of how we're all
taught to tune SQL (by eliminating physical I/Os and then quitting),
almost every system in the world suffers from unnecessarily excessive
numbers of latch acquisition attempts.
If the competition is for the "shared pool" or a "library cache" latch,
then your application parses too much. For more details, see "Scaling
applications to massive user counts" at www.hotsos.com/catalog. If the
competition is for a "cache buffers chains" or "cache buffers lru chain"
latch, then your application reads too many blocks from the buffer
cache. For more details, see "Why you should focus on LIOs instead of
PIOs" at www.hotsos.com/catalog.
Yes, increasing SPIN_COUNT can reduce the number of sleeps, but it does
so by wasting more user-mode CPU doing an operation called a "busy
wait." See the LIO/PIO paper mentioned earlier for details about what
increasing SPIN_COUNT does to Oracle's latch acquisition algorithm.
Rachel's right: Instead of worrying whether there are too many sleeps on
your system, decide whether the business benefit of improving the
performance of one or more specific business functions will be worth the
effort. Direct performance improvement decisions by what's important to
the BUSINESS, not by what some V$ table says might be wrong with your
system.
Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.com
Upcoming events:
- Hotsos Clinic, Dec 9-11 Honolulu
- 2003 Hotsos Symposium on OracleR System Performance, Feb 9-12 Dallas
- Jonathan Lewis' Optimising Oracle, Nov 19-21 Dallas
-----Original Message-----
Carmichael
Sent: Thursday, November 07, 2002 9:09 AM
To: Multiple recipients of list ORACLE-L
Denham,
Sorry, I didn't mean to make you wince! It's just a case of seeing way
too many DBAs spending way too much time tuning things that really
aren't a problem.
Cary Millsap talks about this often. Find the business problem and tune
that. It's possible that something that shows up as "very slow" when
you look at the overall system is actually something that runs rarely
and tuning it will give you no noticeable improvement.
If the log switches are happening that frequently, you might look into
resizing them. I'd first look at what is going on during office hours
that's causing them to fill so fast.
Rachel
- Denham Eva <EvaD_at_TFMC.co.za> wrote:
> Ouch! :)
>
> Rachel,
>
> It's not a case of me looking for problems. I was surprised to find
> this
> occuring so maybe doing something about it would improve the system
> alittle.
> I am looking into the redo log performance because I am unsure that
> the redo
> log switches are normal as they can be very high during office hrs as
> high
> as 60 switches in an hr, but having said that the switches avrg out
> at 3-4
> switches an hour. So all the obvious are to be looked into ie
> checkpoints
> etc.
>
> From your line of thought in the email below, I am reading into it
> that you
> don't find this to be an issue, which is great. I will then just
> carry on
> checking all the other possible parameters and stats, until I am
> happy that
> the redo logs are as healthy as they can be.
>
> In my defence I did try the to change the parameter on my test system
> first.
>
> Hope that explains my line of thought and modus operandi.
> Regards
> Denham
>
> -----Original Message-----
> Sent: Thursday, November 07, 2002 3:18 PM
> To: Multiple recipients of list ORACLE-L
>
>
> there is a point at which you begin to tune for the sake of tuning
> and
> not because you are relieving a problem.
>
> if you are not getting reports of performance problems, why are you
> trying to fix it? the old adage "if it ain't broke, don't fix it"
> applies here.
>
>
> --- Denham Eva <EvaD_at_TFMC.co.za> wrote:
> > Hello Guru's
> >
> > I have run a script which indicates that of the three redo log
> > latches two
> > had occurences of sleeps. To overcome this usually you increase
> > SPIN_COUNT
> > by 50% or so.
> > When trying to ALTER SYSTEM SET SPIN_COUNT = 3000;
> > Present system is set as 2000. I get the following error.
> > *
> > ERROR at line 1:
> > ORA-25138: SPIN_COUNT initialization parameter has been made
> obsolete
> >
> > Now what? what can I do to overcome the sleeps issues?
> >
> > Regards
> > Denham Eva
> > Oracle DBA
> > "UNIX is basically a simple operating system, but you have to be a
> > genius to
> > understand the simplicity."
> > Dennis Ritchie.
> >
> >
> >
>
> _
> > DISCLAIMER
> > This message is for the named person's use only. It may contain
> > confidential,
> > proprietary or legally privileged information. No confidentiality
> > or privilege is waived or lost by any mistransmission. If you
> receive
> >
> > this message in error, please immediately delete it and all copies
> > of it from your system, destroy any hard copies of it and notify
> the
> > sender. You must not, directly or indirectly, use, disclose,
> > distribute, print, or copy any part of this message if you are not
> > the intended recipient. TFMC, its holding company, and any of its
> > subsidiaries each reserve the right to monitor and manage all
> e-mail
> > communications through its networks.
> >
> > Any views expressed in this message are those of the individual
> > sender,
> > except where the message states otherwise and the sender is
> > authorized
> > to state them to be the views of any such entity.
> >
>
> >
> >
>
> _________
> > This e-mail message has been scanned for Viruses and Content and
> > cleared
> > by MailMarshal
> >
> > For more information please visit www.marshalsoftware.com
> >
>
> _________
> >
>
>
> __________________________________________________
> Do you Yahoo!?
> U2 on LAUNCH - Exclusive greatest hits videos
> http://launch.yahoo.com/u2
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Rachel Carmichael
> INET: wisernet100_at_yahoo.com
>
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> 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).
>
>
> DISCLAIMER
> This message is for the named person's use only. It may contain
> confidential,
> proprietary or legally privileged information. No confidentiality
> or privilege is waived or lost by any mistransmission. If you receive
>
> this message in error, please immediately delete it and all copies
> of it from your system, destroy any hard copies of it and notify the
> sender. You must not, directly or indirectly, use, disclose,
> distribute, print, or copy any part of this message if you are not
> the intended recipient. TFMC, its holding company, and any of its
> subsidiaries each reserve the right to monitor and manage all e-mail
> communications through its networks.
>
> Any views expressed in this message are those of the individual
> sender,
> except where the message states otherwise and the sender is
> authorized
> to state them to be the views of any such entity.
>
>
>
> This e-mail message has been scanned for Viruses and Content and
> cleared
> by MailMarshal
>
> For more information please visit www.marshalsoftware.com
>
>
Do you Yahoo!?
U2 on LAUNCH - Exclusive greatest hits videos
http://launch.yahoo.com/u2
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Rachel Carmichael
INET: wisernet100_at_yahoo.com
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
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: Cary Millsap
INET: cary.millsap_at_hotsos.com
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
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).
Received on Thu Nov 07 2002 - 10:42:02 CST
