Has anyone had thsi issue, if so what was the fix?
We installed service pack2, the day after 2 of our production jobs started taking a long time to complete and causing a ton of blocking.
it went from running in 2 minutes to now taking 3 hours and 29 minutes to run. Can someone help?
Is it only certain queries running slower or is it all queries running slower? What high-level symptoms are you seeing? Does it look like CPU pressure, memory pressure, I/O pressure, blocking, etc.?
What kind of results do you get when you run these DMV queries?
-- Total waits are wait_time_ms (high signal waits indicates CPU pressure)
SELECT signal_wait_time_ms=SUM(signal_wait_time_ms)
,'%signal (cpu) waits'=CAST(100.0 *SUM(signal_wait_time_ms)/SUM(wait_time_ms)ASNUMERIC(20,2))
,resource_wait_time_ms=SUM(wait_time_ms - signal_wait_time_ms)
,'%resource waits'=CAST(100.0 *SUM(wait_time_ms - signal_wait_time_ms)/SUM(wait_time_ms)ASNUMERIC(20,2))
FROMsys.dm_os_wait_stats
-- Check SQL Server Schedulers to see if they are waiting on CPU
SELECT scheduler_id, current_tasks_count, runnable_tasks_count
FROMsys.dm_os_schedulers
WHERE scheduler_id < 255
-- Isolate top waits
WITH Waits AS
(
SELECT
wait_type,
wait_time_ms / 1000. AS wait_time_s,
100. * wait_time_ms /SUM(wait_time_ms)OVER()AS pct,
ROW_NUMBER()OVER(ORDERBY wait_time_ms DESC)AS rn
FROMsys.dm_os_wait_stats
WHERE wait_type NOTLIKE'%SLEEP%'
-- filter out additional irrelevant waits
)
SELECT
W1.wait_type,
CAST(W1.wait_time_s ASDECIMAL(12, 2))AS wait_time_s,
CAST(W1.pct ASDECIMAL(12, 2))AS pct,
CAST(SUM(W2.pct)ASDECIMAL(12, 2))AS running_pct
FROM Waits AS W1
INNERJOIN Waits AS W2
ON W2.rn <= W1.rn
GROUPBY W1.rn, W1.wait_type, W1.wait_time_s, W1.pct
HAVINGSUM(W2.pct)- W1.pct < 90 -- percentage threshold
ORDERBY W1.rn;
-- Detect blocking
SELECT blocked_query.session_id AS blocked_session_id,
blocking_query.session_id AS blocking_session_id,
sql_text.text AS blocked_text,
sql_btext.text AS blocking_text,
waits.wait_type AS blocking_resource
FROMsys.dm_exec_requestsAS blocked_query
INNERJOINsys.dm_exec_requestsAS blocking_query
ON blocked_query.blocking_session_id = blocking_query.session_id
CROSSAPPLY
(SELECT*
FROM sys.dm_exec_sql_text(blocking_query.sql_handle)
) sql_btext
CROSSAPPLY
(SELECT*
FROM sys.dm_exec_sql_text(blocked_query.sql_handle)
) sql_text
INNERJOINsys.dm_os_waiting_tasksAS waits
ON waits.session_id = blocking_query.session_id
|||After the SP2 Upgrade did you update the stats and index rebuilds on the tables?. You might want to perform some optimization and see if the problem still persists.|||If you have not done so already, try running sp_UpdateStats on your database(s). This will run UPDATE STATISTICS with the default 10% sample rate on every table in the database (which may take a while, depending on your hardware and db size).
You should always do that after upgrading to SQL Server 2005
Rebuilding (as opposed to reorganizing) indexes will also automatically update statistics.
|||Hi,We have experienced many slowness and trouble since the SP2 was installed.
Have a look at theses 2 KB:
http://support.microsoft.com/default.aspx/kb/937745
And
http://support.microsoft.com/default.aspx/kb/933564/en-us
Last point, run the following query when your server is slow:
select type, sum(single_pages_kb+multi_pages_kb) 'total memory' from sys.dm_os_memory_clerks ORDER by 2 DESC
This will help you to know what cache type is getting most of your SQL Ram.
If it's USERSTORE_TOKENPERM, consider using Trace flag 4618. It has had good impact on our system, but still not correct the case. I have conf call with MS Support on Monday about that point and will answer in this post if I have anymore informations.
Regards,
Jeremy
|||
Jeremy - Just wondering if you had any updates. We are currently hitting this issue. The clearing of ('TokenAndPermUserStore') does not work 100% of the time. We've experienced times when the system is so busy that we can not clear it fast enough.
We are considering using the trace flag.
Thanks -
Sam.
No comments:
Post a Comment