CORRECTIF : Une assertion de système de longrec.inl:1318 se produit lorsque vous reconstruisez ou créez un index sur une table dans SQL Server 2012

IMPORTANT : Cet article est issu d'une traduction automatique réalisée par un logiciel Microsoft et non par un traducteur professionnel. Cette traduction automatique a pu aussi être révisée par la communauté Microsoft grâce à la technologie Community Translation Framework (CTF). Pour en savoir plus sur cette technologie, veuillez consulter la page http://support.microsoft.com/gp/machine-translation-corrections/fr. Microsoft vous propose en effet des articles traduits par des professionnels, des articles issus de traductions automatiques et des articles issus de traductions automatiques révisées par la communauté Microsoft, de manière à ce que vous ayez accès à tous les articles de notre Base de connaissances dans votre langue. Il est important de noter que les articles issus de la traduction automatique, y compris ceux révisés par la communauté Microsoft, peuvent contenir des erreurs de vocabulaire, de syntaxe ou de grammaire. Microsoft ne pourra être tenu responsable des imprécisions, erreurs, ainsi que de tout dommage résultant d’une traduction incorrecte du contenu ou de son utilisation par les clients.

La version anglaise de cet article est la suivante: 3053960
Symptômes
Supposons que vous disposez d'une table contenant un FILESTREAMcolumn et une colonne LOB dans Microsoft SQL Server2012. Lorsque vous supprimez la colonne LOB et que vous essayez de reconstruire un index en clusters existant ou de créer un index ordonné en clusters, vous recevez le message d'erreur assertion système suivantes :
Date>Heure> spidID> Erreur : 17066, gravité : 16, état: 1.
Date>Heure> spidID> SQL Server Assertion : fichier :Chemin d'accès> \longrec.inl >, ligne = 1318 Échec de l'Assertion = ' outBufLen > = offsetof (InRowContent, m_varBlobCol) + inBufLen'. Cette erreur est éventuellement liée à un délai d'attente. Si l'erreur persiste après la réexécution de l'instruction, utilisez DBCC CHECKDB pour vérifier la base de données pour l'intégrité structurelle ou redémarrez le serveur pour vérifier que les structures de données en mémoire ne sont pas corrompues.
Date>Heure> spidID> Erreur : 3624, gravité : 20, état: 1.
Date>Heure> spidID> Un contrôle d'assertion a échoué. Vérifiez le journal des erreurs SQL Server pour plus de détails. En général, un échec d'assertion est dû à une corruption de données ou bogue logiciel. Pour vérifier la base de données, pensez à l'exécution de DBCC CHECKDB. Si vous avez accepté d'envoyer les images à Microsoft lors de l'installation, un mini-vidage est envoyé à Microsoft. Une mise à jour peut être disponible auprès de Microsoft dans le dernier Service Pack ou un correctif auprès du Support technique.
Résolution
Le problème a été tout d'abord résolu dans la mise à jour cumulative suivante de SQL Server.

Mise à jour cumulative 6 pour le Service Pack 2 de SQL Server 2012

À propos des mises à jour cumulatives pour SQL Server

Chaque nouvelle mise à jour cumulative pour SQL Server contient tous les correctifs logiciels et des correctifs de sécurité qui ont été inclus dans la précédente mise à jour cumulative. Découvrez les dernières mises à jour cumulatives pour SQL Server :
Statut
Microsoft a confirmé l'existence de ce problème dans les produits Microsoft répertoriés dans la section « S'applique à ».

Avertissement : Cet article a été traduit automatiquement.

Propriétés

ID d'article : 3053960 - Dernière mise à jour : 03/14/2016 10:35:00 - Révision : 2.0

Microsoft SQL Server 2012 Service Pack 2

  • kbqfe kbfix kbsurveynew kbexpertiseadvanced kbmt KB3053960 KbMtfr
Commentaires