Post reply

The semaphore timeout period has expired

  • June 28, 2010 at 2:47 pm

    #1186038

    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

    #1202940

    You can close this thread,

    read the below links with the explanation of the problem and the ultimate fix.

    SynAttackProtect

    http://sqlblog.com/blogs/merrill_aldrich/archive/2010/06/10/windows-server-2003-network-boogey-men-every-dba-should-know.aspx

    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

    #1203919

    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

    #1844384

    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

    #1874977

    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

    #3798160

    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