| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: Filesystem vs. Raw IO--I have just done such a converstion without success
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.
>
> 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_at_freelists.org
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
>
>
-- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------Received on Fri May 28 2004 - 01:23:56 CDT
 |
 |