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_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] 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