I just finished moving my production database from vxfs without qio to vxvm raw volume. There isn't performance difference, neither in application response time , nor the system resource usage. Yes, it is an active OLTP database, size is 80GB and doing 80Tx/Second.It does 600 disk read per second and 200 disk write per second. and 10G+ archive log per day. The only difference is the number of LWP(light weight process) reduced from 1800 to 900. CPU usage via sar -u report did not get any difference before and after the change, nor the iowait%, nor the application response time.(statspack report filestat section). I am surprised to see the result. I had expected to see some CPU usage reduction and IOWait drop. But it does not happen. Disk_asynch_io = true and all datafiles/redo/control are moved to raw volume. The theory of RAW-VS-FileSystem does not seem to make much sense in production environment. If you need the detailed data before and after the change, I can attach here. Regards Zhu Chao. ----- Original Message ----- From: "Mladen Gogala" <mladen@xxxxxxxxxxxxxxx> To: <oracle-l@xxxxxxxxxxxxx> Sent: Friday, May 28, 2004 1:45 AM Subject: Re: Filesystem vs. Raw IO > > On 05/27/2004 01:24:09 PM, Rick Stephenson wrote: > > I just ran some tests and I was shocked at the results. I assume I am > > missing something very obvious. > > You are right. > > > > > > > Exporting data 2 million row table: > > > > > > > > EMC disk on UFS filesystem: 50 sec > > > > EMC disk raw space: 3 min 8 sec > > > > NetApp disk UFS filesystem: 48 sec > > > > NetApp disk raw space: 3 min 7 sec > > > > > > > > What should I be looking at? Why such a big difference? > > > Well, during export you mostly read, using full table scan. With UFS, you're doing buffering > and prefetch and that speeds things up. With raw devices, you're not doing that. Raw devices > are a bit faster when it comes to an active OLTP system. For a read-only database, buffered > file systems are actually faster. Your case proves the importance of BCHR and validity of the > method "C". > > -- > Mladen Gogala > Oracle DBA > > > > Note: > This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Wang Trading LLC and any of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. > Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. > > ---------------------------------------------------------------- > Please see the official ORACLE-L FAQ: http://www.orafaq.com > ---------------------------------------------------------------- > To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx > put 'unsubscribe' in the subject line. > -- > Archives are at //www.freelists.org/archives/oracle-l/ > FAQ is at //www.freelists.org/help/fom-serve/cache/1.html > ----------------------------------------------------------------- > > ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------