Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: ORACLE on Linux - IO bottleneck

Re: ORACLE on Linux - IO bottleneck

From: Noons <wizofoz2k_at_yahoo.com.au>
Date: 9 Feb 2006 16:07:29 -0800
Message-ID: <1139530049.694718.168210@g43g2000cwa.googlegroups.com>


Wyvern wrote:

> We have many versions of Redhat in different installations. We want to
> standardize all of them but not upgrading to RHAS4 but to RHAS3. About
> the update, you´re right, we should go to update 5.
>
> 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.

In any case, upd.1 seems to me totally out of character with the Oracle version you're running and the hardware. First thing to look into, in my book.

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.

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.

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. Received on Thu Feb 09 2006 - 18:07:29 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US