This is a probably more of an observation than a question.
We had an interesting problem, which I'm hoping is a difference between SQL versions but any alternative ideas or thoughts migth prove useful. We have a development server running SQL 2008 v. 10.0.4064.0 with 4 processors, 2 gigs of ram. We have a prodution server running SQL 2008 v. 10.0.2531.0 with 8 processors, 16 gigs of ram. I got some code off the web and created a table valued function that splits a string of comma separated values. Here's the code, passing 100 values:
-- start of code --
-- end of code --
On the development server, executing it 5 times, the total execution time is: 18.2000 On the production server total execution time is: 315.2000. Already a pretty big difference. Of course, when moving it to production, we just did some cursory tests to ensure the code worked. At some point, 3500 values were passed into the function. On the dev server it ran in less than 1 second. On production, around 25 secs (yes that's 25 not .25).
Checking the execution plan on both, the only differences I can see are that on the production server there are eager table spools being done before the "Table Valued Functions (XML Reader)". The cost of these spools is 0%. And the cost of the Table Valued Function (XML Reader) are higher on production (56%, 36%) and on dev (30%, 19%).
I know I can write the function any number of ways and we have since changed it. The reason we initially went with the XML method is, in testing, (of course on the development server) it was faster than some of the "charindex", "pos", "length" methods we tested.
First of all, It seems that your Dev Server is with SP2 whereas your Production Server is with SP1 and If I were you I would have not compare the performance of servers with different Service Packs unless it is the last option. For e.g. I remember there was a CU for SP1 where CPU usage increases when you run a query that uses a string comparison function on a computer that has many processors after you upgrade to SQL Server 2005 Service Pack 3 or to SQL Server 2008.
Secondly, people tend to think that with huge amount of RAM, multiple processors we would gain huge improvement. Which is not the case always. I have seen servers with proper configuration, optimal disk configuration, optimal tempdb configuration etc. competing big servers with improper configuration. There are instances where one RAM chip tends to malfunction. So there are many more factors to look after before we compare the servers. Our GURUs to follow would add to that.
Moreover, have you tried MAXDOP option. Does it make any difference?
answered Dec 14 '11 at 01:29 AM