Link to home
Start Free TrialLog in
Avatar of IggyBlue
IggyBlue

asked on

Upgrade SQL 2008 to R2 creates timeouts

Hi,
I upgraded an exisiting 2008 Developer Edition (default instance) on a server to 2008 R2.
Since the upgrade the connection from client-pc (in domain) to the database has become real slow.
Simply connecting SSMS to the database engine takes about 45 seconds, which used to be like one second before the upgrade.
These delays makes the db engine useless because all our software using the db constantly has timeouts.
Where to look to fix this?
Thanks, Michael
Avatar of IggyBlue
IggyBlue

ASKER

Oh yes, important info I guess:

- Locally (on the server) apps using that db and ssms work just fine
- Shared Memory, Named Pipes and TCP/IP are active
- I use the default port
- Remote connections are allowed
- Server timeout is 600s
- Unlimited concurrent connections
- Mixed mode
- 64Bit
- Remote Login Timeout 20s
Please also post following query results:

SELECT TOP 10 *
FROM sys.dm_os_wait_stats
ORDER BY wait_time_ms DESC

Open in new window

On the server:

wait_type      waiting_tasks_count      wait_time_ms      max_wait_time_ms      signal_wait_time_ms
LOGMGR_QUEUE      129      1473840      1199995      2
LAZYWRITER_SLEEP      1501      1473156      1000      50
CHECKPOINT_QUEUE      5      1472815      1469728      0
SQLTRACE_INCREMENTAL_FLUSH_SLEEP      369      1472084      4000      0
XE_TIMER_EVENT      51      1470183      30000      1470035
REQUEST_FOR_DEADLOCK_SEARCH      295      1470084      5000      1470084
FT_IFTS_SCHEDULER_IDLE_WAIT      25      1440010      60000      0
SLEEP_TASK      6298      737855      1024      101
BROKER_TO_FLUSH      721      737322      1024      0
XE_DISPATCHER_WAIT      2      90150      90150      0

On the Client:
wait_type      waiting_tasks_count      wait_time_ms      max_wait_time_ms      signal_wait_time_ms
LAZYWRITER_SLEEP      1890      1860795      1000      50
XE_TIMER_EVENT      64      1860192      30000      1860044
XE_DISPATCHER_WAIT      4      1860192      1620038      0
REQUEST_FOR_DEADLOCK_SEARCH      373      1860106      5000      1860106
SQLTRACE_INCREMENTAL_FLUSH_SLEEP      466      1860106      4000      0
FT_IFTS_SCHEDULER_IDLE_WAIT      31      1800012      60000      0
CHECKPOINT_QUEUE      7      1783379      1469728      3
LOGMGR_QUEUE      132      1474123      1199995      2
SLEEP_TASK      7933      931502      1024      101
BROKER_TO_FLUSH      910      930869      1024      0
What do you mena by on the client?
Please also try to update statistics on upgraded sqervr - run sp_updatestats:
http://msdn.microsoft.com/en-us/library/ms173804.aspx
I mean my Developer machine by client (Win7 64Bit).
The DB-server runs on a Win2008 server.
I will update the statistics.
Thanks for you help!
I ran sp_updatestats on master, is that ok?
Results:
Updating [dbo].[spt_fallback_db]
    0 index(es)/statistic(s) have been updated, 0 did not require update.
 
Updating [dbo].[spt_fallback_dev]
    0 index(es)/statistic(s) have been updated, 0 did not require update.
 
Updating [dbo].[spt_fallback_usg]
    0 index(es)/statistic(s) have been updated, 0 did not require update.
 
Updating [sys].[queue_messages_1003150619]
    [queue_clustered_index], update is not necessary...
    [queue_secondary_index], update is not necessary...
    0 index(es)/statistic(s) have been updated, 2 did not require update.
 
Updating [sys].[queue_messages_1035150733]
    [queue_clustered_index], update is not necessary...
    [queue_secondary_index], update is not necessary...
    0 index(es)/statistic(s) have been updated, 2 did not require update.
 
Updating [sys].[queue_messages_1067150847]
    [queue_clustered_index], update is not necessary...
    [queue_secondary_index], update is not necessary...
    0 index(es)/statistic(s) have been updated, 2 did not require update.
 
Updating [sys].[syscommittab]
    [ci_commit_ts], update is not necessary...
    [si_xdes_id], update is not necessary...
    0 index(es)/statistic(s) have been updated, 2 did not require update.
 
Updating [dbo].[MSreplication_options]
    [_WA_Sys_00000001_45544755] has been updated...
    1 index(es)/statistic(s) have been updated, 0 did not require update.
 
Updating [dbo].[spt_monitor]
    0 index(es)/statistic(s) have been updated, 0 did not require update.
 
Updating [dbo].[spt_values]
    [spt_valuesclust], update is not necessary...
    [ix2_spt_values_nu_nc], update is not necessary...
    0 index(es)/statistic(s) have been updated, 2 did not require update.
 
Statistics for all tables have been updated.
Run this:

exec sp_MSforeachdb '
USE ?
IF DB_NAME() NOT LIKE ''%temp%''
BEGIN 
EXEC sp_updatestats
SELECT ''Stats update for ''+DB_NAME()+'' was executed''
END'

Open in new window

Done, see att for results Query-Results.txt
Is your server behaves better now?
You wrote that 'Locally (on the server) apps using that db and ssms work just fine' which I've overlooked, so please check whether your network does not suffer from hardware or other problems.
Check your system logs, device manager.
Hi Daniel,
No, the (remote) performance still is very bad.
System logs are fully checked and OK.
The problem literally started after I upgraded SQL Server 2008 DE to R2.
I am 99% sure the problem is caused by the upgrade :(
Please try to connect by SSMS using tcp/ip protocol. You can do it by typing server_ip:port instead of it's name, e.g.: 72.21.211.176:1433
Hi Daniel,
Sorry for the delay in feedback.
Using the IP instead of servername doesn't solve the issue.
It doesn't matter if I also use the port or not.
So my problem is still actual :(
What edition is it now in R2, still Developer?
It indeed may be R2 issue, I've read about problems on HP servers:
https://www.experts-exchange.com/questions/26597709/SQL-Server-2008-R2-very-slow-on-a-i7-machine.html
ASKER CERTIFIED SOLUTION
Avatar of IggyBlue
IggyBlue

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Problem wasn't solved but did a workaround