| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> AIX and Largefiles Performance
All:
I am not a native of Planet IBM, but this morning one of the systems administrators here forwarded over a tuning guide from the mother ship regarding Oracle on AIX. There were a number of interesting things in there that I am still working through, but one particular item piqued my interest.
"... Do not allocate a JFS with the large file enabled (bf) attribute. The big file attribute increases the minimum DIO transfer size (diocapbuf.dio_min returned by the finfo system call) from 4K to 128K, forcing Oracle to read and write a minimum of 128K byte to exploit DIO. Please note that 2GB is the largest file size applications (including Oracle) can use in a JFS without the 'bf' attribute -- large file enablement. Do not allocate a compressed JFS, which defeats DIO. Respecting the JFS 2GB maximum file size avoids potential file level inode locking performance issues in JFS or JFS2 (without CIO), but a downside of small (2GB) files in a very large database (VLDB) environment is the time required to open/close files during the startup/shutdown."
I have worked on most of the other major O/S variants, and this is the first time I have ever heard the largefiles settings have a negative impact on performance. In the interest of scientific investigation on this topic, I am officially checking my ego at the door and opening my mind to this possibility. I am trying to do some research on this, but, thus far, my findings have been sparse.
Has anyone heard this before? Or is this a performance myth along the lines of the BCHR's (if so it is a first for me to hear it)? Or is there a genuine benefit to be gained by doing this?
Any comments or thoughts on this matter would be appreciated.
--
Byron Pearce mailto:pearceb_at_tenure.com Tenure Systems, Inc. Dallas/Fort Worth, TX
"It's hard to be a ninja when you wear a beeper."
 |
 |