June 28, 2010 at 2:47 pm
Hi,
I'm investigating a different track as well, I was always wondering about the SAN track, since the SQL Agent error refers to TCP, i.e issues in the TCP stack, and the parameters mentioned in this thread also refes to tcp/ip.
Our test have been to disable the Arcserve open file agent, this is a kernel driver, that loads deep down in the tcp/ip stack (ofant.sys). Stopping the windows service is not enough since the driver stays loaded, so we went for an uninstall. Only two weeks after uninstall but have not seen any issues yet.
I mention Arcserve, but I guess all backup poducts have similar agents for backing up open files.
More news after some time running in this configuration...
//SUN
August 5, 2010 at 10:50 am
You can close this thread,
read the below links with the explanation of the problem and the ultimate fix.
SynAttackProtect
http://blogs.msdn.com/b/sql_protocols/archive/2006/04/12/574608.aspx
TCP Chimney Offload
http://support.microsoft.com/kb/942861
Query Timeout problem
http://support.microsoft.com/kb/945442
and Microsoft confirms:
SQL Server Intermittent Connectivity Issue
http://blogs.msdn.com/b/mssqlisv/archive/2008/05/27/sql-server-intermittent-connectivity-issue.aspx
August 8, 2010 at 2:47 am
Hi everyone,
we've had the same issue on a 2-node cluster. On 1 node everything runs fine but as soon as everything fails to the other node we encounter this issue randomly. This cluster used to run Windows 2003 R2 SP2 and SQL 2005 SP3 x64.
We rebuilt the cluster on the same hardware this weekend using Windows 2008 R2 and SQL 2008 SP1, and are encountering the same issue with the upgraded software... Grrr....
I'm not too sure if the HBA queue depth contributes to this specific error, although it does help with I/O throughput.
Has anyone been able to resolve this issue? We're left stranded with a half-working cluster now.
December 7, 2015 at 7:49 am
The Semaphore error has largely been associated with memory pressure but no definite solution has been provided by microsoft
April 27, 2016 at 9:10 am
We had this same issue for one of our cluster nodes and it was identified the issue with the network
dh-smz-821a %ETHPORT-5-IF_DOWN_LINK_FAILURE: Interface Ethernet2/13 is down (Link failure)
October 16, 2020 at 9:07 pm
We had the same problem starting last night when we shut down the VM that hosts one of our SQL Servers due to a Hyper-V host issue. This particular sql server, cs3, replicates data to eight other sql servers. cs3 could not connect to one of the down line sql servers, cs2. cs2 is our primary production sql server. All of our applications and processes could connect to it. It was only cs3 that could not. From a command line we could not even ping cs2.
Ultimately, we shut down cs3, deleted the nic adapter from with in SC-VMM. Then added it back in and set the configuration, both in VMM and in windows.
Environments:
cs3 - Windows Server 2016, Sql Server 2016 SP2 Enterprise Edition.
cs2 - Windows Server 2016, Sql Server 2016 SP2 Enterprise Edition.
Bill Soranno
MCP, MCTS, MCITP DBA
Database Administrator
Winona State University
Maxwell 143
"Quality, like Success, is a Journey, not a Destination" - William Soranno '92
Viewing 6 posts - 31 through 35 (of 35 total)
You must be logged in to reply to this topic. Login to reply