August 24, 2015 at 10:41 am
This is really a shot in the dark, but here's the general situation.
We are updating a 3rd party application which runs on 32 bit Windows only. Current version is w2003 (4G) with SQL2005 on same box.
We built the new version with W2008 sp2, SQL2008 (all 32 bit). SQL settings are the same between the 2005 and the 2008 SQL servers. Both boxes are on the same VM hardware, however even moderately complex queries are running about 10X SLOWER on the 2008 system as compared to the 2005. Database is not large, about 15G.
The VM admin has gone over all the wait states etc on the VM level and can see no trace of problems there or with I/O. CPU, memory usage, page swaps, etc are very comparable between the two systems... we're at a complete loss as to why there is such a huge difference in speed.
Is it possible that 2008 32 bit is a stepchild that is not taken as seriously by Microsoft?
[The queries were run from SQL studio, so the vendor's code changes are not part of this issue]
...
-- FORTRAN manual for Xerox Computers --
August 24, 2015 at 10:43 am
one of the first things you need to do when you upgrade from a lower version to a higher version, is to update statistics.
the engine uses stats differently, and you'll see poor performance until you get them rebuilt.
Lowell
August 27, 2015 at 9:42 am
updating...
After we demonstrated that the db from the previous version was much faster on the same server, now suddenly, the vendor stopped saying "it must be your server" and started to admit that they did make some changes deep in the structure (the test queries are very difficult to follow manually because of security constructs, multiple layers of views with differing permissions and schemas--calls follow wildly differing paths depending on the account).
the ball is now back in their court.
...
-- FORTRAN manual for Xerox Computers --
August 27, 2015 at 9:54 am
jay-h (8/27/2015)
updating...After we demonstrated that the db from the previous version was much faster on the same server, now suddenly, the vendor stopped saying "it must be your server" and started to admit that they did make some changes deep in the structure (the test queries are very difficult to follow manually because of security constructs, multiple layers of views with differing permissions and schemas--calls follow wildly differing paths depending on the account).
the ball is now back in their court.
You mean views on views on views cause performance problems? Who would have thought? 😉
Good job not accepting their standard line and getting them to admit that they've made changes.
Best of luck trying to get them to fix their structure.
August 27, 2015 at 9:43 pm
jay-h (8/27/2015)
updating...After we demonstrated that the db from the previous version was much faster on the same server, now suddenly, the vendor stopped saying "it must be your server" and started to admit that they did make some changes deep in the structure (the test queries are very difficult to follow manually because of security constructs, multiple layers of views with differing permissions and schemas--calls follow wildly differing paths depending on the account).
the ball is now back in their court.
I've had that happen many times and worked for a very short time for a company that used to pull those kinds of shenanigans. I cannot speak the actual words that I'm thinking without being banned from this forum. Real happy to see someone like yourself put a hammerlock on 3rd party know-it-alls like that. I especially like it because you used THEIR previous version to prove it. They just can't argue with that. Well done.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply