J'obtiens parfois "Impossible de continuer l'analyse avec en NOLOCKraison du mouvement des données" avec certains gros travaux, qui ont WITH (NOLOCK)sur les requêtes sélectionnées.
Je comprends que cela a quelque chose à voir avec la tentative de sélection de données lorsqu'il y a eu un fractionnement de page qui a fait que les données ne sont plus là où elles étaient censées être - je suppose que c'est ce qui se passe dans mon environnement.
Comment pourrais-je reproduire cela?
J'essaie de contourner l'erreur à court terme et de réessayer lorsque cela se produit, mais je ne peux pas le tester si je ne peux pas le reproduire. Existe-t-il un moyen raisonnablement fiable de provoquer cela?
Lorsque cela se produit, l'exécution de la requête à nouveau aboutit - donc je n'ai pas vraiment de soucis concernant la corruption permanente des données ou de la base de données. Certaines des tables de la requête (ainsi que leurs index) sont souvent supprimées, recréées et repeuplées, donc je suppose que c'est quelque chose lié à cela.
La suppression NOLOCKest mon problème à long terme. La raison a NOLOCKété avancée en premier lieu parce que les requêtes sont si mauvaises qu'elles bloquaient les transactions au jour le jour, tout NOLOCKcomme un pansement pour arrêter les blocages (qui fonctionnaient). J'ai donc besoin d'un pansement sur un pansement jusqu'à ce que nous puissions trouver une solution permanente.
Si je pouvais le reproduire avec un Hello World, j'envisagerais probablement de placer le pansement dans le travail en moins d'une heure. Impossible de supprimer la recherche et le remplacement NOLOCK, car je recommencerais à récupérer les blocages de l'application, ce qui est pire pour moi qu'un échec occasionnel.
L'utilisation de l'isolement des instantanés validés en lecture est une bonne possibilité - je vais devoir travailler avec notre équipe de base de données pour obtenir plus de détails à ce sujet. Une partie de notre problème est que nous n'avons pas d'expert SQL Server pour gérer ce genre de choses, et je ne comprends pas assez bien les niveaux d'isolement pour effectuer ce changement en ce moment.
DEADLOCK_PRIORITYà LOWdes emplois, de sorte que s'il y a des blocages, les emplois échouent, et non les applications. Après cela, vous pouvez rechercher les blocages et découvrir pourquoi ils se produisent, et résoudre ce problème. Cela pourrait être une solution très simple, comme permuter l'ordre de deux instructions. Quel que soit le problème, ce NOLOCKn'est pas la solution , alors arrêtez d'essayer de le forcer juste parce que c'est le plus simple.
NOLOCKces emplois? 601 devrait être le moindre de vos soucis si les résultats de ces requêtes sont censés être exacts . Paul White montre un exemple particulièrement terrible de lecture de données qui ne devrait pas être possible ici .