Title: RE: SPIN_COUNT - 8i obsolete? What now?
Thanks Cary and all for the imput. Now I atleast have something to work with.
Many Thanks
Denham
-Original Message-
From: Cary Millsap [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 07, 2002 6:42 PM
To: Multiple recipients of list
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 a
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 sl
Title: RE: SPIN_COUNT - 8i obsolete? What now?
additional factors:
log_checkpoint_timeout log_checkpoint_interval fast_start_io_target90% size of smallest redo
log
alter system
checkpoint
-Original Message-From: Jack van Zanen
[mailto:[EMAIL PROTECTED]]Sent
Title: RE: SPIN_COUNT - 8i obsolete? What now?
log_buffer has nothing to do with log switches. Just
with checkpointing and some other things I can't think of right
now.
Size
of online redo logfiles does.
Jack
-Original Message-From: Denham Eva
[mailto:[EMAIL PROT
Eva,
just to correct myself from my earlier post it's entirely possible to set
_spin_count using ALTER SYSTEM.
It may be a sensible measure to try if you're having serious contention
issues.
Steve Adams has some 'spin_count' scripts that you might find useful at
http://www.ixora.com.au/scripts/latc
Title: RE: SPIN_COUNT - 8i obsolete? What now?
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 tha
Title: RE: SPIN_COUNT - 8i obsolete? What now?
Already running on 100% caffeine_level saturation :)
Maybe your right, the contention could be elsewhere, the other issue I have been investigating is LGWR process? With increasing the LOG_BUFFER from 512 to a Meg in size, as I have at times very
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 <[EMAIL PROTECTED]> w
Eva,
the spin_count parameter became _spin_count in 8i. I believe that because
it's a hidden parameter it's now not possible to change it using "ALTER
SYSTEM".
Regards,
Mike Hately
-Original Message-
Sent: Thursday, November 07, 2002 11:33 AM
To: Multiple recipients of list ORACLE-L
H
> Denham Eva 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.
11 matches
Mail list logo
