ben.brugman (1/14/2013)
Grant Fritchey (1/11/2013)
Right, so as far as SQL Server is concerned you're partitioning to a single drive. Performance is pretty much guaranteed to be poor. Yours does seem abnormally poor, but poor would be my assumption.The results I got where gathered during a benchtest.
We are going to make decisions based on these results.
But if we cannot explain the results, is will be difficult to use these results in arguments.
If 'Performance is pretty much guaranteed to be poor.', I would like to have a source (or evidence) for that.
As the results are (10 times) slower they will probably be rejected because they are redicules. (Or the testing is not done properly or something like that).
Ben
Sorry, online forum and all, I didn't mean that performance was guaranteed to be poor with partitioning. I meant, if you only have a single LUN where you are not separating out and isolating your I/O in order to use the full strength of partitioning, then performance will be poor. It just makes sense. One LUN with a straight I/O statement or one LUN that must determine partition location then do the I/O, the second option is slower because of the processing. The performance wins, when there are any, from partitioning, all come at the I/O part of the process. Your setup didn't allow for that to occur.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning