Symptômes
Une erreur d’assertion est susceptible de se produire lorsque Microsoft SQL Server exécute à plusieurs reprises une procédure stockée qui effectue les opérations suivantes :
-
Prend un objet de grande taille, comme varchar (max) ou varbinary (max), comme argument et
-
Crée une table temporaire dans le cadre de l’exécution de la procédure et
-
Utilise l’argument objet volumineux dans la table temporaire.
L’erreur d’assertion qui ressemble à ce qui suit dans le journal des erreurs SQL Server est peut-être :
ErreurSPID date/heure: 17065, gravité : 16, État : 1.
Date/heure SPID SQL Server assertion : file : filePath \filename, line = LineNumber Fail assertion = 'fFalse’tentative d’accès au handle d’objet BLOB expiré (1). Cette erreur est éventuellement liée au minutage. Si l’erreur persiste après avoir reexécuté l’instruction, utilisez DBCC CHECKDB pour vérifier l’intégrité structurelle de la base de données, ou redémarrez le serveur pour vérifier que les structures de données en mémoire ne sont pas endommagées.
Erreur SPID date/heure : 3624, gravité : 20, État : 1.
Date/heure SPID échec d’une vérification d’assertion système. Pour plus d’informations, consultez le journal des erreurs SQL Server. En règle générale, un échec d’assertion est lié à un bogue logiciel ou à des données endommagées. Pour vérifier la corruption de la base de données, envisagez d’exécuter DBCC CHECKDB. Si vous avez accepté d’envoyer des vidages à Microsoft lors de l’installation, un mini-vidage sera envoyé à Microsoft. Il est possible qu’une mise à jour soit disponible à partir de Microsoft dans le Service Pack le plus récent ou dans un correctif du support technique.
Cause
SQL Server dispose d’une logique interne pour désactiver la mise en cache des requêtes qui font référence à des objets volumineux de sorte que les exécutions suivantes ne référencent pas ces LOB (qui ont été créés au cours des exécutions antérieures et ne sont donc pas valides pour les exécutions suivantes). Cette logique ne gérait pas le cas de la résolution de nom différé (DNR) sur les tables temporaires qui ont entraîné la mise en cache de ces plans. Les tables temporaires étendues sont onéreuses à créer et SQL Server les met en cache pour pouvoir les réutiliser dans les exécutions ultérieures. Cela empêche toute recompilation de ces requêtes en raison de modifications de schéma.
En savoir plus sur la résolution de nom différé.
Résolution
Ce problème a été résolu dans les mises à jour cumulatives de SQL Server suivantes :
Mise à jour cumulative 8 pour SQL Server 2016 SP1
Mise à jour cumulative 4 pour SQL Server 2017
Mise à jour cumulative 10 pour SQL Server 2014 Service Pack 2
Chaque nouvelle mise à jour cumulative pour SQL Server contient tous les correctifs et correctifs de sécurité présents dans la build précédente. Pour obtenir la dernière mise à jour cumulative de SQL Server, procédez comme suit :
Dernière mise à jour cumulative pour SQL Server 2016
Dernière mise à jour cumulative pour SQL Server 2017
dernières mises à jour cumulatives pour SQL Server 2014
Statut
Microsoft a confirmé l'existence de ce problème dans les produits Microsoft figurant dans la liste des produits concernés par cet article.
Références
Apprenez-en davantage sur la terminologie utilisée par Microsoft pour décrire les mises à jour logicielles.
