From: pon@iki.fi   
      
   On 2009-09-05, Erland Sommarskog  wrote:   
   > customers had moved then disks from the SAN and attached them directly   
   > to the machine. The time to run a certain backup operation was reduced   
   > with 85%!   
      
   That's a good point. In our case the SAN-everything reduced the backup   
   time to about 50% of the original. Which is a nice bonus.   
      
   > But of course, SQL Server has to   
   > share that SAN with a lot of other servers, it only gets a part of   
   > that fat bandwidth. And if you don't configure the SAN properly,   
   > there is never any particular advantage with the SAN from performance   
   > point of view.   
      
   Painfully true. And it seems to be almost pointless in discussing SAN   
   without knowing any more details about it. But anyway. In this case   
   the measured real application performance was improved while moving   
   the stuff to SAN. But I was wondering if there could be a some kind of   
   usual phenomenon about the sequential read performance. Since while the   
   benchmarked sequential read performance for single process was bad (much   
   worse than for local raid), the performance increased while the number of   
   threads grew. That's exactly the opposite of how the local raid works.   
   In fact it seems almost as if the SAN somehow thought that "wow, this dude is   
   serious, better give him a boost in performance".   
      
   Pasi   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)