transfer time, not seek time

Exadata uses at least a 4 MB Automatic Storage Management (ASM) allocation unit (AU) [more on ASM basics]. This means that there is at least 4 MB of contiguous physical data laid out on the HDD which translates into 4 MB of contiguous data streamed off of disk for full table scans before the head needs to perform a seek. With such large I/O requests the HDDs are able to spend nearly all the time transferring data, and very little time finding it and that is what matters most. Clearly if Exadata is able to stream data off of disk at 125 MB/s per disk (near physics speed for this type of workload) then any alleged “contention” is really not an issue. In many multi-user data warehouse workloads for PoCs, I’ve observed that each Exadata Storage Server is able to perform very close or at the data sheet physical HDD I/O rate of 1500 MB/s per server.




http://structureddata.org/2010/08/10/oracle-exadata-and-netezza-twinfin-compared-%E2%80%93-an-engineer%E2%80%99s-analysis/?utm_source=rss&utm_medium=rss&utm_campaign=oracle-exadata-and-netezza-twinfin-compared-%25e2%2580%2593-an-engineer%25e2%2580%2599s-analysis