4

I am recently seeing the Unknown Netowrk Error 59 which saves the full back ups to a file share on some of the servers . The back ups happens at different times.

Ola Halengren scripts are being used currently and the sql server edition used are 2012, 2014 enterprise edition.

I see there are suggestions for to create a DWORD with name ‘Sesstimeout’ and value 360 in HKLM\SYSTEM\CurrentControlSet\Services\lanmanworkstation\parameters.

My question is should we create this on the target server (file share) or the server from where the sql server resides

  • Noted. The back up to the SAN works but sometime fails and the reasons are a mystery to me. The google search only leads me to create a DWORD with name ‘Sesstimeout’ and value 360 in HKLM\SYSTEM\CurrentControlSet\Services\lanmanworkstation\parameters which i am reluctant to do as of now. Thanks – SQL_NoExpert Apr 10 '18 at 14:56
4

Aaron's answer provides great advice on how to work around this issue. I thought I'd add an answer to provide some more technical details.

According to Microsoft's err.exe utility, error 59 is defined in winerror.h as: An unexpected network error occurred.

If this was a problem with the session timing out, you would almost certainly be seeing STATUS_NETWORK_SESSION_EXPIRED, which is error 0xC000035C / -1073740964. Microsoft Docs states the resolution to this is:

The client's session has expired; therefore, the client MUST re-authenticate to continue accessing remote resources.

The registry value you mention in your question, HKLM\SYSTEM\CurrentControlSet\Services\lanmanworkstation\parameters, relates to the "lanmanworkstation" Windows service, also known as simply "Workstation" via the services control panel applet. This service is what initiates network connections at the workstation end. Therefore, if you need to modify that registry value, you'd modify it at the client, which in this case is the SQL Server machine. Microsoft Docs for that registry value:

Determines the duration of the secondary delay used in calculating a time-out value for outstanding operations. If the redirector does not receive a response to an outstanding operation before the resulting time-out expires, it considers the operation to have failed. The value of the SessTimeout entry can be thought of as a margin for error. If there is an unexpected delay, the redirector permits the operation this extra time to complete.

The redirector adds the value of this entry to the expected response time for a server message block (SMB). The resulting time-out is calculated dynamically, and it is approximately equal to:

[(SMB size + Size of data sent or received) / bytes per second] + SessTimeout.

The default value for this setting is 45 seconds, and can be modified in the range of 10 to 65535 seconds.

4

If you are having network reliability issues:

  1. speak to your network/SAN team (and/or use a different file share that doesn't exhibit the problem)
  2. Back up the file, temporarily, to the local SQL Server system, assuming there is adequate space. Then copy the backup to the network share, typically using a tool that can resume interrupted transfers, and delete the original when the copy has been confirmed (which usually includes validating that the backup can be restored). If a copy fails, no big deal; you just start the copy again, and you haven't lost anything.

And I agree with Max, this doesn't seem to be something that altering a session timeout will fix; that's kind of like changing a tire when your headlight is out. You might be better prepared for the next pothole, but you're still only driving with one light.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.