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
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
Please also post following query results:
SELECT TOP 10 *
FROM sys.dm_os_wait_stats
ORDER BY wait_time_ms DESC
ASKER
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_SEARC H 295 1470084 5000 1470084
FT_IFTS_SCHEDULER_IDLE_WAI T 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_SEARC H 373 1860106 5000 1860106
SQLTRACE_INCREMENTAL_FLUSH _SLEEP 466 1860106 4000 0
FT_IFTS_SCHEDULER_IDLE_WAI T 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
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
XE_TIMER_EVENT 51 1470183 30000 1470035
REQUEST_FOR_DEADLOCK_SEARC
FT_IFTS_SCHEDULER_IDLE_WAI
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_SEARC
SQLTRACE_INCREMENTAL_FLUSH
FT_IFTS_SCHEDULER_IDLE_WAI
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
Please also try to update statistics on upgraded sqervr - run sp_updatestats:
http://msdn.microsoft.com/en-us/library/ms173804.aspx
ASKER
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!
The DB-server runs on a Win2008 server.
I will update the statistics.
Thanks for you help!
ASKER
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_1003 150619]
[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_1035 150733]
[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_1067 150847]
[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_optio ns]
[_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.
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_1003
[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_1035
[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_1067
[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_optio
[_WA_Sys_00000001_45544755
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'
ASKER
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.
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.
ASKER
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 :(
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
ASKER
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 :(
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
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
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Problem wasn't solved but did a workaround
ASKER
- 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