We've upgraded one of our systems to SQL 2008R2 and certain parts are running like a dog. One statement that would have taken an average of 20-40mins on the old box, took from 11:40 to 00:35. Its not every statement but odd ones.
Its a 2 cpu box, and the cpu usage sits a 50%, there's hardly any activity in activity monitor (no significant resource waits etc, no io, or requests)
Unfortunatley this didn't happen during conversion, system test or uat, so we've imp'ed, and now hitting these issues
Has anybody got some hints, places to look, good resources to read up on?
One thing we would like to work out, is it a fact, 2008 does things differently and query design, indexes etc need to be re-developed/analysed?
But updating all the stats did, the sample I was looking at now processes in 6s rather than 9h.
My concern now is I have Auto Update Stats On, and Update Stats Async, and the way the system works is it that each stage wipes the working tables before processing. So the stats would be invalidated every run.
Now we obviously could go through and do manual stat updates, but should we need to? Given we didn't for 2000.
Also I think that SQL is memory starved, would this be preventing it from also auto-updating stats?
Since it seems that you can isolate it down to a SQL statement, then you might want to put that SQL statement in SQL Server manager and under the query menu, enable the option to "Include Actual Execution Plan". After running the statement, you should get an idea of where the problem lies.
In our couple of runs we have identified 2 separate statements, the problem is this system is wiped each run and the data then passed through changes in size, so we probably have not found them all. We've also not been down all the varying processing paths.
So I was wondering if in doing a conversion to 2k8, you will always find statements that no longer work efficiently and you just have to find them all and fix. Or if there is something we might have set wrong?
If everyone says its the former then fine, I can plan for that, just want to make sure before saying we need to make more changes.
Let's look at this differently. Do you have an example of a SQL statement which took longer to execute under 2008 and have you found a solution ? (For example rebuild index)
Are you running SQL 2008 server in some "Compatibility Level" which is causing it work inefficiently?
For example, run
select compatibility_level from sys.databases where name=db_name()
and you should get 100 for SQL Server 2008.
I've recently upgraded an applicaiton from SQL 2005 to SQL 2008 and things seem to be just fine with the queries, etc.
I took a full backup from SQL 2005, created a brand new database on our SQL 2008 server and restored the backup. Very straight forward. No complaints. (The applicaiton which accesses the database was also upgraded, but I have no control over that because it is an application which we purchased.)
If you need more detailed help, send me a private message and I can point you to a SQL Server professional.
You can continue to post your questions here, I will do the best I can.
The Compatibility level is set to 100. We've not tried 80...
We do seem to have resolved the issue, the server now has 8Gb, rather than 4Gb. The 2000 server had 4Gb.
One query that took hours on 2008, but down to seconds once we added the 8Gb was:
OpeningBalance = z.OpeningBalance
, ClosingBalance = z.ClosingBalance
, AvgBalance = z.AvgBalance
from outMortgageAsset b
GroupID = a.GroupID
, MonthDate = k.MonthDate
, OpeningBalance = sum(k.OpeningBalance)
, ClosingBalance = sum(k.ClosingBalance)
, AvgBalance = sum(k.AvgBalance)
from EIRGroupAccountsToBeTotaled a
monthdate = b.ForecastMonth
, accountid = b.AccountID
, OpeningBalance = isnull(b.CurrentBalance, 0.0)
, ClosingBalance = isnull(c.CurrentBalance, 0.0)
, AvgBalance = (isnull(c.CurrentBalance, 0.0)
+ isnull(b.CurrentBalance, 0.0)) / 2.00000000from EIRAccountBalancePerPeriod b
leftjoin EIRAccountBalancePerPeriod c
on b.ForecastMonth = c.ForecastMonth - 1and c.AccountID = b.AccountID
ForecastMonth - 1
, OpeningBalance = 0
, ClosingBalance = isnull(CurrentBalance, 0.0)
, AvgBalance = (CurrentBalance) / 2.00000000from EIRAccountBalancePerPeriod a
where ForecastMonth =
from EIRAccountBalancePerPeriod z
where z.AccountID = a.AccountID
on a.accountid = k.accountid
groupby a.GroupID, k.MonthDate
on b.GroupID = z.GroupID
and fm = z.MonthDate
The row counts for the tables: outMortgageAsset: 1148 EIRGroupAccountsToBeTotaled: 1499860, Clustered Index on GroupID, AccountID EIRAccountBalancePerPeriod: 14347829, Non-Clustered on MonthDate, ForcastMonth, AccountID
So after you added the additional memory, the query executed faster?
What OS is the SQL 2008 Server running vs the SQL 2000 Server? (64 vs 32 bit?)
I'm thinking that the SQL 2008 server OS was struggling with memory; causing poor performance.
Does the system seem to be operating better with the 8GB of memory? It may have been just a memory issue. (Seems like Microsoft OS and Applicaitons need more and more memory with each new release. But memory is cheap these days ...)
Might have found something, a high number of CXPACKET waits. We've set the MAXDOP to 1 to see if we now get consistent performance, if we're lucky it will consistent performance that matches the old server...
Last Visit: 31-Dec-99 19:00 Last Update: 25-Mar-17 9:16