I agree that the log buffer is too big. But why do you want to decrease the
log file size from 32M to 5MB. This will increase the checkpoint frequency
and will create performance hit due to increased checkpoints. Also, I would
add log files to use all three disks rather than just 2 disks.
GROUP 11 (
'E:\ORACLE\ORADATA\JAVA16\LOG1101.LOG',
'F:\ORACLE\ORADATA\JAVA16\LOG1102.LOG'
) SIZE 32M,
GROUP 12 (
'G:\ORACLE\ORADATA\JAVA16\LOG1201.LOG',
'E:\ORACLE\ORADATA\JAVA16\LOG1202.LOG'
) SIZE 32M,
GROUP 13 (
'F:\ORACLE\ORADATA\JAVA16\LOG1301.LOG',
'G:\ORACLE\ORADATA\JAVA16\LOG1302.LOG'
) SIZE 32M
Further your application IO is 25% FTS and 75% index based access. I
would definitely pull the sql statements out of the v$sqlarea and tune
them..
Thanks
Riyaj "Re-yas" Shamsudeen
Certified Oracle DBA
i2 technologies www.i2.com
"My opinions and use at your own risk"
"Mohan, Ross"
<MohanR@STARS To: Multiple recipients of list ORACLE-L
<[EMAIL PROTECTED]>
-SMI.com> cc:
Sent by: Subject: RE: Log writer
root@fatcity.
com
03/22/01
01:30 PM
Please
respond to
ORACLE-L
Uh.....67,676 kb. ? as in 67 MB? for a redo log buffer? Is this a
result
of our new president being a texan?
On your system,
1) one by one add three (3) new groups of redo log files. Make them 5MB in
size, each.
2) ALTER system switch logfile until all the old redo logs show INACTIVE in
V$LOG,
3) ALTER system checkpoint;
4) DELETE the 32MB log file groups. With prejudice. ( If they don't die,
call in Dick Goulet.)
5) Edit the init.ora and make the log_buffer...oh...say 2M. Bounce the
instance.
Let us know what happens.
Please.
- Ross
-----Original Message-----
From: Kevin Kostyszyn [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 22, 2001 1:23 PM
To: Multiple recipients of list ORACLE-L
Subject: RE: Log writer
thanks Ross,
MTS, I didn't know it was on? Isn't that just an init.ora
setting? I am looking in to finding out about the cache, but no luck
yet. The redo log buffer is 67,676 kb. Yes, this isn't some normal
little system where the duhvelopers are just querying the db, they are
constantly doing DML, lots of FTS. I have found so many indexes in
the USERS tablespace which puts them on the same HD as the tables they
are accessing. I move them, but somehow more seem to always
appear...hmmm..wonder why that is.
But I am curious, when you say network/app tuning, what exactly do
you mean by that? I know that two disks aren't that great, but not my
idea, it was done before my dumbass got here, now I am just trying to
fix it. Everything else looks good on the system though,
library_cache hit ratio, buffer cache hit ratio all very high. It's
just this program occasionally, about every 10 minutes is telling me
the logwriter is a slouch.
What about my other question though,
MAXLOGFILES 32
MAXLOGMEMBERS 2
MAXDATAFILES 32
MAXINSTANCES 16
MAXLOGHISTORY 4764
LOGFILE
GROUP 11 (
'E:\ORACLE\ORADATA\JAVA16\LOG1101.LOG',
'F:\ORACLE\ORADATA\JAVA16\LOG1102.LOG'
) SIZE 32M,
GROUP 12 (
'E:\ORACLE\ORADATA\JAVA16\LOG1201.LOG',
'F:\ORACLE\ORADATA\JAVA16\LOG1202.LOG'
) SIZE 32M,
GROUP 13 (
'E:\ORACLE\ORADATA\JAVA16\LOG1301.LOG',
'F:\ORACLE\ORADATA\JAVA16\LOG1302.LOG'
) SIZE 32M
DATAFILE
'E:\ORACLE\ORADATA\JAVA16\SYSTEM01.DBF',
'E:\ORACLE\ORADATA\JAVA16\RBS01.DBF',
'E:\ORACLE\ORADATA\JAVA16\USERS01.DBF',
'E:\ORACLE\ORADATA\JAVA16\TEMP02.ORA',
'E:\ORACLE\ORADATA\JAVA16\TOOLS01.DBF',
'F:\ORACLE\ORADATA\JAVA16\INDX01.DBF',
'E:\ORACLE\ORADATA\JAVA16\DR01.DBF',
'E:\ORACLE\ORADATA\JAVA16\SYSTEM02.DBF',
'E:\ORACLE\ORADATA\JAVA16\USERS02.DBF',
'F:\ORACLE\ORADATA\JAVA16\INDX02.DBF',
'F:\ORACLE\ORADATA\JAVA16\RADS3PROD.DBF',
'G:\ORACLE\ORADATA\JAVA16\RADS3PRODINDX.DBF',
'G:\ORACLE\ORADATA\JAVA16\RBSBIG.DBF',
'G:\ORACLE\ORADATA\JAVA16\RADS3PRODINDX2.DBF'
Do you think the logrile is wrong? E and F&G are seperate HD's. I
don't know...help...
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Mohan, Ross
Sent: Thursday, March 22, 2001 12:21 PM
To: Multiple recipients of list ORACLE-L
Subject: RE: Log writer
Kev,
Pure shot from hip:
I'd say you have more network/app response tuning than log
tuning. I'd
say you have more disk tuning ( for table/index reads) than log
tuning. I
would DEFINITELY turn the silly ass MTS off.
I'd find out how to make sure disk cache is 4 MB and is writeBACK
not writeTHRU. ( if either ) I'd have questions about the
controller, too, but.."later".
(You didn't tell me the size of the redo log buffer...)
Of course, having a two disk wonder (or whatever it is) is the
number
one thing to work on.
In any case, with your hardware, your system should easily be
able
to handle a few users, in its sleep.
There's about two dozen little tweaks you can do to perk things
up a bit,
but basically, your "rock and a hard place" is going to be a two
disk wonder
on a single controller...
hth
Ross
-----Original Message-----
From: Kevin Kostyszyn [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 22, 2001 11:31 AM
To: Multiple recipients of list ORACLE-L
Subject: RE: Log writer
Jeez, Seagate Cheeta 18 and 36, 10k RPM ahhh
UNFORMATTED CAPACITY (GB) ________________22.54
FORMATTED CAPACITY (GB) __________________18.21
AVERAGE SECTORS PER TRACK ________________213 rounded
down
ACTUATOR TYPE ____________________________ROTARY
VOICE COIL
TRACKS ___________________________________167,008
CYLINDERS ________________________________6,962 user
HEADS ______PHYSICAL______________________24
DISCS (3 in) _____________________________12
MEDIA TYPE _______________________________THIN
FILM/MR
RECORDING METHOD _________________________PRML 8/9
PR4
INTERNAL TRANSFER RATE (mbits/sec)________152 to 231
EXTERNAL TRANSFER RATE (mbyte/sec) _______40 Sync
Low Voltage Differential(LVD) _______80 Sync
SPINDLE SPEED (RPM) ______________________10,025
AVERAGE LATENCY (mSEC) ___________________2.99
BUFFER (/optional) _______________________1MB/4MB
Read Look-Ahead, Adaptive,
I believe the only problem is that they are on one
controller. However, this is not a huge database, only
about 3-4 users connected at a time, but lots of DML. The
machine is a Dell Precision 410 with a gig of Ram and dual
PIII 450's. I don't think that it's a huge problem, but it
does keep coming up. There are three log file groups of 32
MB's each and yes the database is also spread accross these
two platters.
Oh and the results......YOINK!
rdbms ipc message
14980809
SQL*Net message from client
9595869
pmon timer
1880177
virtual circuit status
1877869
smon timer
1875449
dispatcher timer
1874318
SQL*Net break/reset to client
49746
control file parallel write
18026
db file sequential read
3947
log file sync
1456
db file scattered read
1017
EVENT
TIME_WAITED
----------------------------------------------------------------
-----------
log file parallel write
616
Null event
411
library cache pin
315
refresh controlfile command
292
reliable message
273
rdbms ipc reply
146
control file sequential read
108
log file switch completion
58
SQL*Net more data to client
45
enqueue
27
file identify
24
EVENT
TIME_WAITED
----------------------------------------------------------------
-----------
log file single write
23
latch free
19
SQL*Net message to client
17
file open
16
buffer busy waits
13
SQL*Net more data from client
6
direct path read
5
log file sequential read
0
db file parallel write
0
instance state change
0
direct path write
0
EVENT
TIME_WAITED
----------------------------------------------------------------
-----------
LGWR wait for redo copy
0
Which ya think master Ross?
Kev
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Mohan, Ross
Sent: Thursday, March 22, 2001 11:02 AM
To: Multiple recipients of list ORACLE-L
Subject: RE: Log writer
Disk mfr?
rpm?
seek/access times?
diskperf -y set already?
CPU,I/O, or diskbound system?
log buffer size? log file size?
what else is on the "separate" disks? anything?
separate disks share a controller?
select event, time_waited from v$system_event order by
2 desc; results?
just a few questions that come to mind....
-----Original Message-----
From: Kevin Kostyszyn [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 22, 2001 8:50 AM
To: Multiple recipients of list ORACLE-L
Subject: Log writer
Hi all,
I am testing out Spotlight on Oracle from Quest
Software. It is telling me
that my log writer process is slow. What it looks like
it is saying is that
most disks take about 20ms to right the data and mine
is taking on average
about 40ms. I don't know why, they are scsi drives and
there isn't that
much stress on the syste. Anyway, I moved the redo
logs to seperate disks,
but I fear I may have made an error. Instead of moving
each "group" to
seperate hard disks, I moved the members of each group
to seperate hard
disks. Anyway, I am wondering if anyone has advice on
this problem.
Sincerely,
Kevin Kostyszyn
DBA
Dulcian, Inc
www.dulcian.com
[EMAIL PROTECTED]
--
Please see the official ORACLE-L FAQ:
http://www.orafaq.com
--
Author: Kevin Kostyszyn
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).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author:
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).
