Re: ORACLE on Linux - IO bottleneck

>> On the other hand, we´ve got Oracle 9i 64bit compilation on release
>> 9.2.0.5 in every 64bit linux machine with better performance and
>> without problems running also in RHAS3 so I´m not sure SO version is
>> the main problem in this case but the way it´s configured and "tuned".

>That's why I found it a bit strange when you mentioned
>the environment before. AFAIK, RH Linux release 3 requires a
>special version of OS to handle 64-bit CPU. Otherwise, all you're
>doing is using the 32-bit instructions of the IA64.

I´ve not found information (in redhat page nor intel page) about what you say but it worries me because it would another added problem, could you tell me where should I look about or if you know how to test if we are using 32 or 64 bit instructions?.

>As for block sizes: use dumpe2fs on the raw device of the
>file system (as root) to determine the actual block size being
>used by the file system.

The result is the same as the one using command "blockdev" ....

>If you are using raw devices, then Oracle takes care of the IO
>and uses whatever the db block size is - except for redo logs.
>If you're using file systems, then the file system block size becomes
>relevant: the dumpe2fs will tell you exactly what it is. You want it
>to be as close as possible to the db block size (8K), within the
>constraints of the file system you have chosen. If ext3, then that
>will be 4K - max block size for that. NEVER use a file system
>block size larger than the db block size. Not your case.

Well, we´ll consider this if we decide to migrate to FS. Thanks.

>Note that if you are using direct IO on the database, then many
>of the "smarts" of the Linux file system IO do not apply. You
>may experience a drop in performance if you have a particularly
>nasty IO configuration. By using direct IO, you are accepting the
>responsibility of managing IO from the database side.
>This requires some careful tuning of database io parameters and
>definitely a good spread across the IO hardware. For example,
>when using direct IO don't even dream of "all db IO through one
>controller" configurations! You will definitely have a problem.
>Where you don't have absolute control over the hardware config,
>then it's probably better to stay with OS buffered io rather than
>direct.

Yes, I think this is EXACTLY what is happening us, with EXT3 is easier to get an acceptable IO performance due to the "smarts" you mention. This scenario is the first one we prove with Linux and rawdevices (direct IO) so ... a big error supposing that raws would give the same performance using them in Linux than in AIX ....

Thanks a lot for your answer ... Received on Fri Feb 10 2006 - 07:14:33 CST