January 15, 2014 at 10:28 am
I have a suspended process with a Wait Type of ASYNC_NETWORK_IO and a Wait Resource of External ExternalResource=ASYNC_NETWORK_IO. Is there a way to figure out what exact resource this process is waiting on?
January 16, 2014 at 7:16 am
It's usually not a network problem, but it might be. It's usually an issue where the client code is doing row-by-row processing. There is no other wait occurring. It's literally the process waiting for other stuff to finish either in, or over, the network.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
January 16, 2014 at 12:18 pm
Well, it's MS Access actually. We have linked tables and macros pulling data but we're about to retire a server and move to a new one. So the process works fine on the user's PC from the current server. But when I made a copy of the Access db and updated the ODBC (and linked tables) to point to the new server, the process "froze" from his perspective and took much longer to complete.
I knew it wasn't the SQL Server, but I wasn't sure if it was network or his PC. And if it was his PC why it would work so quickly on one copy and not on the other copy.
Thoughts?
January 16, 2014 at 12:39 pm
Access.
But seriously, Access & ODBC and... yeah... Access.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
January 16, 2014 at 1:01 pm
It's SQL Server waiting for the client to accept the results and send an acknowledgement. It's usually the client app, but could be anything from the server to the client app.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
January 20, 2014 at 8:25 am
January 22, 2014 at 7:22 pm
I had a simlar experince using an MS-Access front end that worked well on one server and terrible on another.
I spent hours trying to figure out the difference. In my case it turned out to be a missing index in SQL Server.
Check that you have a Primary key on the SQL Server table, and suitable indexes that support whatever queries are commonly run In Access, make sure the Linked table defintion also has the primary key defined.
In my case it improved bulk updates from taking several minutes down to only a few seconds.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply