>Ed,
>
>>>2. The best hardware solution is to have two hard drives on two controllers. Large table copies, joins, etc. should always read from one physical drive and write to the other. Can cut real-world times by 50% or more.
>>>
>>
>>Absolutely not a correct statement. A RAID solution is going to outperform this by a wide margin.
>>
>
>On further thought, please tell me that you have done or seen this tested, as I don't buy it. Or, more diplomatically, I would say that I cannot accept it without either a theoretical or experienced argument.
>

I'm running on a system right now with a 4 drive array built around the Adaptec 7895 chipset and the Adaptec ARO1130SA. I deal routinely with extremely large data sets in my data generation apps. I have perhaps 25 sites doing a wide variety of things where we've benchmarked any number of configurations, and can prove out that we can far exceed channel capacities with RAID-based disk I/O. Yes, Kenneth, I have a clue - considerably more of one than you think, and I've considerably more exposure to storage issue than you'd even dream.

>Consider the basic physical action of a large read/write operation, such as a sort. It's easy to see that performing this operation on a single drive causes the heads to constantly navigate back and forth between the source and the destination (assuming an ideal defragmented source and plenty of space on the drive). It's easy to see as well that reading from one drive and writing to another dramatically speeds this up because neither set of drive heads must navigate.

>If you grant the above paragraph (testing of which is child's play), then the question becomes, does a striped set outperform that for 1G+ linear copy operations, such as SQL Selects, and if so, why? It seems to me that (and here is where I am inviting correction) a striped set can be visualized as a larger drive with many more heads which is faster because more than one set of heads is reading at once. But, every one of those drives must then navigate to the destination area. The striped set is faster on any individual transaction, but is it overall faster than the two drives I suggested for a large linear copy?
>

For a single large block transfer, if the operating system has sufficient buffer to allow disk I/O scheduling, where the data rate of a single drive can be exceeded for both reads and writes, your statement is incorrect. And you've not permitted for the use of multiple stripe sets. Realize that with a single drive, the amount of data that can be read or written simultaneously to the device is limited to the amount of data that passes beneath one head - with RAID, since there are multiple spindles, the maximum raw data rate is that rate multiplied by the number of drives. You've also missed the fact that any NT system with a RAID array has at least one device not a part of the RAID array, and that you can have more than one array on the system using the same RAID controller.

Given a dual channel U2 configuration, you could have as many as 30 spindles, spread across as many arrays as needed. The A133 has 3 U2 channels, and there is a wide variety of hardware supporting as many as 8 channels. Spindles are cheap. I can buy 47GB of UltraWide drive for well under $700/spindle. For what most of the clueless spend for 20GB of extremely fast U2 LVD drive, it's easy to put up 100+ GB spread across multiple devices and blow the single spindle from the water.

A dated, but fairly comprehensive introduction to DASD concepts might be Mass Storage Technologies by Sanjay Ranade; Adaptec now hosts a wide range of whitepapers on disk performance, and they also carry the content that formerly resided on DPT's web site (they bought DPT.) Mylex is another vendor with considerable material on their site that explains the concepts.

Again, the statement was "What's the fastest platform I can run this on" - no budget (obviously - he was considering the Sun, and already had a dual processor configuration that was far from optimally configured) and no basic understanding of the problem. Your solution also requires rewriting of the application to explicitly distribute operations across multiple distinct targets, and programmer time exceeds the cost of iron on a long term basis. YMMV. Perhaps there's a reason that players in the large-capacity high performance DASD marketplace use things like RAID and PTD (Parallel Transfer Disks); of course, they couldn't possibly know more than you...

Again, if your assertion was that you ghad an operation that was disk I/O bandwidth bound, the RAID (and especially the use of multiple arrays) can yield lots more performance. perhaps ypour assertion that the operations is disk I/O bandwidth bound is incorrect.