It is not possible to increase the number of
lgwr processes in a single instance until
9.2, and the manuals suggest that (a) you
don't do it, and (b) you only do it if you have a
very large number of CPU and massive stress
on redo generation.
Let me repeat - v$system_event can be very
First of all I'd like to have the full picture of your performance: Log
file sync might be 57% of the wait time, but how much of the response
time is wait time?
Second, Log File Sync means Commit; So if your system is waiting a lot
for commits there are two things you can do: Fewer commits
Yes, the lessons I took from that presentation were to use a shorter piece
of string and buy larger bottles of gin though I'm willing to admit that I
may have got the wrong end of the stick.
=)
Cheers,
Mike
-Original Message-
Sent: 02 January 2003 09:24
To: Multiple recipients of list
Usual caveat:
looking a v$system_event can be very misleading,
you need to examine v$session_event to determine
if anyone is actually noticing a problem.
Usual caveat 2:
A statspack report without a time interval
is almost meaningless. However, in this case,
log file
Obviously you weren't listening attentively enough.
The main thing you should have gleaned from the
presentation was that if you bash an ugly squirrel
with a hammer hard enough, then
... its still an ugly squirrel
:-)
Cheers
Connor
--- Hately, Mike (NESL-IT)
[EMAIL PROTECTED] wrote:
VIVEK_SHARMA,
Hi, can you try use raw device for those redo log files? or use
directio mode for your redo log volume.This do not need bounce your database and you
can change it on fly.
I ever hit the same problem before, and finally we modified the app to
do much
I was sensible enough to sit in the front row so I was soon distracted.
Cheers
Mike
-Original Message-
Sent: 02 January 2003 12:29
To: Multiple recipients of list ORACLE-L
Obviously you weren't listening attentively enough.
The main thing you should have gleaned from the
presentation
That was my understanding, too. Oh, and use bigger hammers, more nails and
Australian beer.
Hately, Mike (NESL-IT) wrote:
Yes, the lessons I took from that presentation were to use a shorter piece
of string and buy larger bottles of gin though I'm willing to admit that I
may have got the
REPLIES TO YOUR QUESTIONS ARE IN CAPITALS BELOW :-
THANKS
-Original Message-
Sent: Thursday, January 02, 2003 3:59 PM
To: Multiple recipients of list ORACLE-L
Usual caveat:
looking a v$system_event can be very misleading,
you need to examine v$session_event to determine
What ALL may be Done to Address the Following ?
Any /etc/system , init.ora parameter Changes too ?
Moving the Online Redo Logfiles onto RAID 1 NOT possible as that may warrant
Additional Hardware . Moreover T3+ does NOT Support RAID 1 (Only RAID 1+ )
Concurrent Oracle processes = 1500 Approx.
file sync wait
event? I do not understand it, can you explain it to me?
Maybe my log buffer is too big, now it is 2M in size. But when it was 1M, i see much
wait time for log buffer space:(, so wondering whether downsize the log buffer.
Thanks for your suggestions.
Good luck
Connor McDonald£¬
ÔÚ 2002-07-12 02:33:00 You wrote:
Some suggestions
a) Check your commit frequency - if you're committing
like mad then this is a great way to over stress redo
logging operations.
Yes, i check the statspack report and find there is about 20 commits/second in may,
and now
.
hi, you said the redo log size have something to do with this log file
sync wait event? I do not understand it, can you explain it to me?
Maybe my log buffer is too big, now it is 2M in size. But when it was
1M, i see much wait time for log buffer space:(, so wondering whether
downsize the log buffer
Also, as Anjo taught me a couple years ago, log file sync is
particularly susceptible to long latencies if you simply have long CPU
runqueues.
Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.com
Upcoming events:
- Hotsos Clinic, Jul 23-25 Chicago
- Miracle Database Forum, Sep 20-22
Hi ,
You encounter log file sync and log file parallel write events .
This can be because of a slow device on which redo log files are on . OR
your redo log sizing is bad.
Bunyamin Karadeniz
Oracle DBA
Havelsan A.S. Eskisehir yolu 7.km
Ankara / Turkey
Tel : +90 535 3357729
- Original
Some suggestions
a) Check your commit frequency - if you're committing
like mad then this is a great way to over stress redo
logging operations.
b) Check the size of the average redo write. If
they're small, you might get some benefit by
allocation write cache in the T3 to the redo logs (if
You say your log files are on RAID 5?
On a busy database?
Are your log files all on the same RAID 5 volume?
I'm going to take a SWAG and say that you seriously
need to consider dedicating at least 3 RAID 1 volumes
to nothing but log file usage.
There's a 400-500% write penalty on RAID 5.
17 matches
Mail list logo
