Échec de la sauvegarde complète sur le réseau en raison d'une erreur réseau inconnue 59
Je vois récemment l'erreur 59 inconnue de Netowrk qui enregistre les sauvegardes complètes sur un partage de fichiers sur certains des serveurs. Les sauvegardes se produisent à différents moments.
Les scripts Ola Halengren sont actuellement utilisés et l'édition serveur SQL utilisée est l'édition entreprise 2012, 2014.
Je vois qu'il y a des suggestions pour créer un DWORD avec le nom "Sesstimeout" et la valeur 360 dans HKLM\SYSTEM\CurrentControlSet\Services\lanmanworkstation\parameters.
Ma question est de savoir si nous devons créer ceci sur le serveur cible (partage de fichiers) ou le serveur d'où réside le serveur SQL
La réponse d'Aaron fournit d'excellents conseils sur la façon de contourner ce problème. J'ai pensé ajouter une réponse pour fournir des détails plus techniques.
Selon tilitaire err.exe de Microsoft , l'erreur 59 est définie dans winerror.h comme: An unexpected network error occurred.
S'il s'agissait d'un problème avec le délai d'expiration de la session, vous verriez très certainement STATUS_NETWORK_SESSION_EXPIRED, qui est l'erreur 0xC000035C/-1073740964. Microsoft Docs indique que la résolution est la suivante:
La session du client a expiré; par conséquent, le client DOIT se ré-authentifier pour continuer à accéder aux ressources distantes.
La valeur de registre que vous mentionnez dans votre question, HKLM\SYSTEM\CurrentControlSet\Services\lanmanworkstation\parameters, concerne le service Windows "lanmanworkstation", également appelé simplement "Workstation" via l'applet du panneau de configuration des services. Ce service est ce qui initie les connexions réseau à l'extrémité du poste de travail. Par conséquent, si vous devez modifier cette valeur de Registre, vous devez la modifier sur le client , qui dans ce cas est la machine SQL Server. Microsoft Docs pour cette valeur de registre:
Détermine la durée du délai secondaire utilisé dans le calcul d'une valeur de temporisation pour les opérations en attente. Si le redirecteur ne reçoit pas de réponse à une opération en attente avant l'expiration du délai d'attente résultant, il considère que l'opération a échoué. La valeur de l'entrée SessTimeout peut être considérée comme une marge d'erreur. S'il y a un retard inattendu, le redirecteur permet à l'opération de se prolonger.
Le redirecteur ajoute la valeur de cette entrée au temps de réponse attendu pour un bloc de message serveur (SMB). Le délai d'attente résultant est calculé dynamiquement et il est approximativement égal à:
[(Taille SMB + taille des données envoyées ou reçues)/octets par seconde] + SessTimeout.
La valeur par défaut de ce paramètre est de 45 secondes et peut être modifiée dans une plage de 10 à 65 535 secondes.
Si vous rencontrez des problèmes de fiabilité du réseau:
- parlez à votre équipe réseau/SAN (et/ou utilisez un partage de fichiers différent qui ne présente pas le problème)
- Sauvegardez le fichier, temporairement, sur le système SQL Server local, en supposant qu'il y a suffisamment d'espace. Copiez ensuite la sauvegarde sur le partage réseau, généralement à l'aide d'un outil qui peut reprendre les transferts interrompus, et supprimez l'original lorsque la copie a été confirmée (ce qui inclut généralement la validation de la restauration de la sauvegarde). Si une copie échoue, ce n'est pas grave; vous venez de recommencer la copie et vous n'avez rien perdu.
Et je suis d'accord avec Max, cela ne semble pas être quelque chose que la modification d'un délai d'expiration de session corrigera; c'est un peu comme changer un pneu lorsque votre phare est éteint. Vous pourriez être mieux préparé pour le prochain nid-de-poule, mais vous ne conduisez toujours qu'avec une seule lumière.