RE: DBWR, Direct I/O and the Devil


" Fourth, should I have even gone to directio in the first place?  "

Don, as you are using vxfs I suggest you give ODM a try to use quickio.
We have been using it for a few months and we are extremely pleased with
the performance improvements. We have seen a cpu utilization decrease of
about 15%-20% and a significant drop in the elapsed time of our batch
jobs.

Besides, it eliminates the maintenance burdens of Veritas Quickio.

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Don Seiler
Sent: Wednesday, November 28, 2007 8:59 PM
To: Oracle-L Freelists
Subject: DBWR, Direct I/O and the Devil

I'd like to lay bare some aspects of my instance and see what everyone
thinks.  I've recently been re-reading Kevin Closson's series on
over-configuring DBWRs [0], and had some questions.

First of all, this is on Oracle RDBMS 10.2.0.2 Enterprise Edition on
RHEL4.  Both DB and OS are 64-bit.  Processing is 4 dual-core 64-bit
CPUs.  Filesystem for all database files is Veritas (vxfs).

Second, based on a suggestion from a colleague, I set
filesystemio_options=directio.  We also mounted the vxfs drives with
the convosync=direct option.  However, disk_asynch_io is still true.
Is there a conflict here?

Third, we have db_writer_processes=4.  This was done a long time ago
and hasn't been looked at since.  I imagine it was done based on the
"1 DBWR for every CPU" line of thinking that Kevin spotlights in his
series.  Our database is a hybrid of OLTP data and bulk-loaded data
that is either direct-path sqlldr or INSERT/APPEND from external
tables.  Kevin mentioned that direct-path writes don't use the DBWR,
so that this instance *might* do perfectly well with just 1 DBWR.  I'm
wondering if using directio is also a factor in determining the proper
value of db_writer_processes.

Fourth, should I have even gone to directio in the first place?  I'd
like to know what people use to benchmark I/O throughput, similar to
what Kevin does in his tests.

[0]
http://kevinclosson.wordpress.com/2007/08/10/learn-how-to-obliterate-pro
cessor-caches-configure-lots-and-lots-of-dbwr-processes/
-- 
Don Seiler
http://seilerwerks.wordpress.com
ultimate: http://www.mufc.us
--
http://www.freelists.org/webpage/oracle-l





Bu mesaj ve onunla iletilen tum ekler gonderildigi kisi ya da kuruma ozel ve 
Bankalar Kanunu geregince, gizlilik yukumlulugu tasiyor olabilir. Bu mesaj, 
hicbir sekilde, herhangi bir amac icin cogaltilamaz, yayinlanamaz ve para 
karsiligi satilamaz; mesajin yetkili alicisi veya alicisina iletmekten sorumlu 
kisi degilseniz, mesaj icerigini ya da eklerini kopyalamayiniz, yayinlamayiniz, 
baska kisilere yonlendirmeyiniz ve mesaji gonderen kisiyi derhal uyararak bu 
mesaji siliniz. Bu mesajin iceriginde ya da eklerinde yer alan bilgilerin 
dogrulugu, butunlugu ve guncelligi Bankamiz tarafindan garanti edilmemektedir 
ve bilinen viruslere karsi kontrolleri yapilmis olarak yollanan mesajin 
sisteminizde yaratabilecegi zararlardan Bankamiz sorumlu tutulamaz.

This message and the files attached to it are under the privacy liability in 
accordance with the Banking Law and confidential to the use of the individual 
or entity to whom they are addressed. This message cannot be copied, disclosed 
or sold monetary consideration for any purpose. If you are not the intended 
recipient of this message, you should not copy, distribute, disclose or forward 
the information that exists in the content and in the attachments of this 
message; please notify the sender immediately and delete all copies of this 
message. Our Bank does not warrant the accuracy, integrity and currency of the 
information transmitted with this message. This message has been detected for 
all known computer viruses thence our Bank is not liable for the occurrence of 
any system corruption caused by this message
--
http://www.freelists.org/webpage/oracle-l

Other related posts: