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.

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?

Perhaps a compromise: Since striped sets are manifestly faster for any linear read, but a long read/write always brings in the problem of back-and-forth navigation, the absolute fastest method (for those who can afford it) would be reading from one striped set and writing to another. For our budget and needs, though, reading to one single drive and writing to another works.