| 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: Moving db to linux
Precisely. Their doco HAS the information, it's just not obvious.
Note: How many of those does Oracle routinely need?
File creation? Only when adding a datafile. Or an archive log.
Linking? Never. Making directory? Never. Makig node? Never.
Removing file? Very, very seldom. Rename? Hardly ever.
Removing directory? Perish the thought.
Symbolic link? I doubt Oracle even has the concept.
Set ACL? Same. Writing File? Not on normal conditions, as they say.
Truncating regular file? Hardly ever.
They forgot (or probably lumped with "writing file"), when more space is needed for a file. Oracle will use that with autoexpand only.
See why JFS is mostly redundant for Oracle DATAFILE file systems? It maybe important for archive logs and maybe (but I have no proof) for redo logs. For datafiles? Mostly redundant.
> with direct I/O. Most file systems simply ignore request for
> open with O_DIRECT, XFS reports an error on Linux (at a subsequent
> read/write one gets EINVAL) , but works as advertized on Irix.
I think most of the ones traditionaly used in Lunix do have it. I mean ext2, ext3, reiserfs. They are mostly offshots from the original BSD file system, which did have DIO. Not sure about others, but these things change weekly. The way to make sure is to test, like you so rightly have done.
> if (stat3=posix_memalign(&buff,ALIGN,BUFFSIZE)) {
> fprintf(stderr,"ALIGN ERR:%s\n",strerror(stat3));
> exit(0);
> }
:D I LIKE that! Would you believe this is the FIRST time EVER I've seen this little piece of code included in ANY program that purports to test I/O? Yet it is of capital importance: it makes a HUGE difference in getting any performance numbers. Well done!
There used to be an option for compilation that enabled this for ANY compiler-allocated buffers. But it was not guaranteed to work. This was one of the major sources of errors in I/O "benchmarks" for Unix: get the buffer alignment wrong and we got a huge jump in CPU time to do the I/O. Usually accounted for as a "defect" of the file system! Some "benchmark"...
As a side note: some of the newer PC server systems only get good memory performance if you align at 64K. Regardless of the f/s you use and whatever block size is chosen. Talk about wasting memory, if your average buffer size is 8K...
Another interesting thing in your program is #define BUFFSIZE 65536.
The actual I/O size may have a huge impact on the relative performance of
any
given file system. reiserfs for example is very, very fast for small
I/O requests. Anything under 2K. ext2/3 are very good at the 4K size.
Not sure about IBM's JFS nowadays but it used to have a sweet spot at 8K.
So do most of the ones from HP.
This would seem to indicate that for example for redo logs - where the I/O size is small - there would be an advantage in using reiserfs. While for all other kinds of Oracle datafiles, ext2/3 would be near optimal.
Yeah, it's amazing how many times a feature may appear to work and it doesn't. The only way to make sure is to test like you did, USING it in a real operation IN CONTEXT and see if it generates an error or not. Or read the source code: a most unpalatable option but quite possible with Lunix. A very strong argument indeed for open source systems.
And a very strong argument for Steve Adams' contention that Oracle I/O in Unix/Lunix should always be to raw disk: there are SO MANY variables to take care of, it's almost impossible (and certainly financial madness) to ensure things are what they should be.
Cheers
Nuno Souto
in sunny Sydney, Australia
dbvision_at_optusnet.com.au
-- 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 Sat Feb 28 2004 - 19:06:48 CST
 |
 |