Ummm,
Ross, was that a Freudian slip? db_block what?
hehehh
<FONT face=Tahoma
size=2>-----Original Message-----From: root_at_fatcity.com
[mailto:root_at_fatcity.com]On Behalf Of Mohan, RossSent:
Thursday, March 01, 2001 3:41 PMTo: Multiple recipients of list
ORACLE-LSubject: RE: DBWR slaves in NT???
I agree. I focussed my answer almost exclusively
on Raghu's last line. "My import is killing
me."
In my hazily-recalled modicum of experience, this
probably has a simple solution.
Or, hell, maybe I am wrong. It *could* require
doing something slick and esoteric, like calling in
Rivest from RSA to recalculate the prime number seed
for the db_block_hash_fuckits parameter and then
rewriting the kxscvngr subroutine in assembler
to more aggressively clump and scavenge the dirty
blocks in mode "1016" from the warm end of the
buffer cache.
But, I doubt it.
- Ross
p.s. Raghu, stay in touch, and tell us what you try,
willya?
-----Original Message----- From: Kevin
Kostyszyn [<A
href="mailto:kevin_at_dulcian.com">mailto:kevin_at_dulcian.com] <FONT
size=2>Sent: Thursday, March 01, 2001 3:09 PM To:
Multiple recipients of list ORACLE-L Subject: RE: DBWR
slaves in NT???
If I am completely off the wall here just slap me around a
little bit. But couldn't you play with the init
parameteres DBWR_IO_SLAVES or DB_WRITER_PROCESSES to
help improve write performance? I mean, I agree with <FONT
size=2>Ross, there is only one disk, but maybe it could help a little to
help simulate asynchronous I/O? <FONT
size=2>Kev Just thinkin out loud again!
-----Original Message----- Sent:
Thursday, March 01, 2001 2:31 PM To: Multiple
recipients of list ORACLE-L
Actually, that message is invalid for Oracle8 DBs. From
what I can gather, the DB_FILES init.ora parameter
only potentially affected DBWR performance in
Oracle7. In Oracle8, it ain't true.
Remember, the DBWRs write dirty buffers (data in memory that
has been modified from it's counterpart in a datafile)
from the buffer cache (memory) to the datafiles
(disk). In O7, the DBWR I/O clump size, or how many dirty
blocks could be written at once (also sometimes referred to
as the DBWR's "internal write batch size"), was
calculated as:
<FONT
size=2>DB_FILE_SIMULTANEOUS_WRITES*DB_FILES/2.
In O8, the DBWR I/O clump size is static, and is different
from platform to platform. Thus, for Oracle8,
the advise to change DB_FILES is bogus.
HTH!
Rich
Jesse
System/Database Administrator <FONT
size=2>Rich.Jesse_at_qtiworld.com
Quad/Tech International, Sussex, WI USA
Disclaimer: After taking the Oracle8 Perf Tuning class,
I think I know more than I do. Don't blame me
for your (in)actions based on my opinion!
-----Original Message----- Sent:
Thursday, March 01, 2001 12:27 To: Multiple recipients
of list ORACLE-L
not a dbwriter problem. on a
"single-disk wonder", your best bet is to DUMP all
indexes on loadable tables, then load your data, then
rebuild the indexes. of
course, that might take just as long. any possiblity
of getting more disk? like, several? a raid
controller? mit gluck!
-----Original Message----- Sent:
Thursday, March 01, 2001 11:26 AM To: Multiple
recipients of list ORACLE-L
Hi Friends I have toad tool for my NT
database DBWR Average Scan Depth 1024 **Number
of DB_Files too high?? I got doubt due to from
v$waitstat I got data block waits some time 8000 and
some times higher number. How can I increase the DBWR slaves
on NT?? although I set in development box, How can I
see as background process really working for
me?? I have my datafile and indexes same on E disk
drive, My hit ratios are okay,
My import is killing me. Any help
appreciated. Thanks <FONT
size=2>Raghu. <FONT
size=2>_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at <A
target=_blank href="http://www.hotmail.com">http://www.hotmail.com.
- Please see the official ORACLE-L
FAQ: <A target=_blank
href="http://www.orafaq.com">http://www.orafaq.com <FONT
size=2>-- Author: Raghu Kota <FONT
size=2> INET: raghukota_at_hotmail.com Fat City
Network Services -- (858) 538-5051 FAX: (858)
538-5051 San Diego,
California -- Public Internet access
/ Mailing Lists <FONT
size=2>--------------------------------------------------------------------
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).
<FONT
size=2>------------------------------------------------------------------------
This message has been scanned for viruses with Trend Micro's
Interscan VirusWall. --
Please see the official ORACLE-L FAQ: <A target=_blank
href="http://www.orafaq.com">http://www.orafaq.com <FONT
size=2>-- Author: Jesse, Rich <FONT
size=2> INET: Rich.Jesse_at_qtiworld.com
Fat City Network Services -- (858)
538-5051 FAX: (858) 538-5051 San Diego,
California -- Public Internet access
/ Mailing Lists <FONT
size=2>--------------------------------------------------------------------
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: <A target=_blank
href="http://www.orafaq.com">http://www.orafaq.com <FONT
size=2>-- Author: Kevin Kostyszyn <FONT
size=2> INET: kevin_at_dulcian.com
Fat City Network Services -- (858)
538-5051 FAX: (858) 538-5051 San Diego,
California -- Public Internet access
/ Mailing Lists <FONT
size=2>--------------------------------------------------------------------
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 Mar 01 2001 - 15:28:02 CST
