RAW vs Cooked file system
Austin, I don't see the thread you posted. Hence, I created one and this is the first thread I opened.
======== original Message from Austin ==================
Mark, that link you sent was interesting.
I believe I'm correct in saying that db_file_sequential_read siginifies a wait for an IO request to complete. Am I correct, then, in saying that the increase in db_file_sequential_read is introduced because of the increased IO throughput you get from async IO. In otherwords, it's a symptom of IO performance improvements and not degredation?
Thanks
Austin
Hello Mark
Thanks again for your input.
I do realise that db_file_sequential_read signifies a wait for a single block IO and when this event represents a large proportion of a query's resource profile the most appropriate action is to reduce the number of database calls (e.g. logical IOs). Only when the number of LIOs required has been truly reduced to a minimum should we consider making changes to the IO subsystem if a performance problem still exists.
Where my confusion comes in is that the optimal configuration in the
paper also exhibits the longest db_file_sequential_read durations. This despite the SQL that is being executed during the test being identical the SQL executed when testing the non-optimal configurations. This has led me to think that the increased throughput afforded by async IO has led to busier disks and longer db_file_sequential_read durations. Do you think this assumption is reasonable?
======================
Your assumption of db_file_sequential_read signifies a wait for a single BLOCK IO request to complete is correct.
However, what you said next "increase in db_file_sequential_read is introduced because of the increased IO throughput you get from async IO" may not be true. Increase in db_file_sequential_read will be caused b/c of the block not available in SGA, hence the user process reads blocks from the disk and puts it in SGA. When many user proces reads blocks from the disks, and the system has few disks and few controllers, then wait occurs. The increase in disk IO throughput depends upon the controller throughput, the disk throughput, IO bus speed etc..
The last assumption about "increased throughput afforded by async IO has led to busier disks and longer db_file_sequential_read durations" is also not correct. If the system is well configured (I leave it you for the definition of well configured), you will see less db_file_sequential_read duration.
I did a lot of benchmark in Oracle using RAW, LVM and JFS files, with 2 disk controllers as well as 4 disk controllers. In all cases RAW devices outperforms JFS file systems.
Tamil