Réponses:
À partir de la documentation Microsoft :
PAGEIOLATCH_SH
Se produit lorsqu'une tâche attend sur un verrou pour un tampon qui se trouve dans une
I/O
demande. La demande de verrouillage est en mode partagé. De longues attentes peuvent indiquer des problèmes avec le sous-système de disque.
En pratique, cela se produit presque toujours en raison de grands scans sur de grandes tables. Cela n'arrive presque jamais dans les requêtes qui utilisent efficacement les index.
Si votre requête ressemble à ceci:
Select * from <table> where <col1> = <value> order by <PrimaryKey>
, vérifiez que vous disposez d'un index composite activé (col1, col_primary_key)
.
Si vous n'en avez pas, vous aurez besoin soit d'un plein INDEX SCAN
si le PRIMARY KEY
est choisi, soit d'un SORT
si un index sur col1
est choisi.
Les deux sont I/O
des opérations très consommatrices de disque sur de grandes tables.
SQL for Smarties
et Thinking in Sets
) et mon blog bien sûr :)
PAGEIOLATCH_SH
Le type d'attente est généralement le résultat d'un index fragmenté ou non optimisé.
Les raisons d'un PAGEIOLATCH_SH
type d'attente excessif sont souvent :
Afin d'essayer de résoudre le problème du PAGEIOLATCH_SH
type d'attente élevé , vous pouvez vérifier:
PAGEIOLATCH_SH
types d'attente excessifsGardez toujours à l'esprit qu'en cas de mise en miroir de sécurité élevée ou de disponibilité de validation synchrone dans AlwaysOn AG, une augmentation / un excès PAGEIOLATCH_SH
peut être attendu.
Vous pouvez trouver plus de détails sur ce sujet dans l'article Gestion des types d'attente excessifs de SQL Server PAGEIOLATCH_SH