January 9, 2009 at 4:38 am
I applied CU #10 in STG and it made a considerable difference. I'll keep the thread updated in case anybody else comes across a similar problem. When I get a chance I'll post the specific bugs/fixes that I believe account for the issue.
January 9, 2009 at 5:22 am
One other thing to check: SSMS has a specific set of SET statements that it executes on connection and whatever API Peoplesoft uses to connect has another. Check for differences and see if they can be addressed because the SET conditions in effect can determine query plans developed as well as query plan caching/lookup. You can get the SET options for query plans from the DMV sys.dm_exec_plan_attributes. Check online and in BOL for various ways to use that DMV.
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
January 9, 2009 at 7:18 am
I'll check that out SQLGuru.
Thx all!
January 9, 2009 at 7:52 am
Here are the CUs and hotfixes that I felt applied, some strongly and some weakly.
Cumulative update package 4
FIX: The query performance is slower when you run the query in SQL Server 2005 than when you run the query in SQL Server 2000[/url]
Cumulative update package 7
FIX: A query may run much slower in SQL Server 2005 than in SQL Server 2000 when you use a cursor to run the query[/url]
Cumulative update package 6
FIX: A query takes longer to finish in SQL Server 2005 than in SQL Server 2000 when you open a fast forward-only cursor for the query [/url]
FIX: A query that you run by using a FORWARD_ONLY cursor takes a longer time to run in Microsoft SQL Server 2005 than in SQL Server 2000[/url]
Viewing 4 posts - 16 through 18 (of 18 total)
You must be logged in to reply to this topic. Login to reply