L'exécution de la requête "" a échoué avec l'erreur suivante: "L'index" "(partition 1) sur la table" "ne peut pas être réorganisé car le verrouillage au niveau de la page est désactivé."
Le plan de maintenance doit tenter une ALTER INDEX REORGANIZE, qui est une opération en ligne. Pour supprimer la fragmentation (les pages ne sont pas dans l'ordre), les pages doivent être verrouillées et déplacées, ce qui n'est pas possible si le verrouillage des pages a été désactivé. La seule façon de défragmenter sans verrouillage de page est de verrouiller la partition entière, ce qui n'est pas possible pour RÉORGANISER en ligne uniquement.
Quelle est la différence entre les deux schémas de verrouillage et quelles sont leurs conséquences réelles (en production)?
Vous devez comprendre ce qu'est un enregistrement et une page pour évaluer l'impact de l'interdiction d'un type de verrou particulier. Si vous ne connaissez pas les composants internes du stockage SQL Server, commencez par Anatomie d'un enregistrement et Anatomie d'une page . En termes très simples:
- lignes = enregistrements
- les lignes sont stockées dans des pages de 8 Ko
Si vous deviez modifier les types de verrouillage autorisés:
- Désactiver les verrous de page = verrous de ligne et de table uniquement
- Désactiver les verrous de ligne = verrous de page et de table uniquement
- Désactiver les deux = verrous de table uniquement
Il y a deux scénarios dont je sais où il peut être avantageux de refuser un type de verrou. Cela ne signifie pas qu'il n'y en a pas d'autres, j'espère que quelqu'un d'autre interviendra avec des exemples.
Une table de recherche fréquemment consultée, qui change rarement - En désactivant les verrous de niveau de page et de ligne, tous les lecteurs prendront un verrou de table partagé. C'est plus rapide / moins cher que l'intention partagée habituellement sur la table, suivie par l'intention partagée sur une page et enfin un verrou partagé sur une ou plusieurs lignes spécifiques.
Prévention d'un scénario de blocage spécifique - Si vous rencontrez des blocages provoqués par des processus simultanés acquérant des verrous qui se trouvent fréquemment sur la même page, le refus des verrous de ligne entraîne la prise de verrous de page à la place. Un seul processus peut alors accéder à la page à la fois, l'autre doit attendre.
Le premier exemple est la micro-optimisation et il est peu probable qu'il produise des avantages mesurables sur un système typique. Le second résoudra ce scénario de blocage particulier, mais peut introduire des effets secondaires inattendus, par exemple en supprimant la concurrence dans une autre section de code. Difficile d'évaluer pleinement l'impact, approchez avec prudence!
Par défaut, les deux doivent être activés et cela ne doit pas être modifié sans motif valable.