Risposte:
Dalla documentazione Microsoft :
PAGEIOLATCH_SH
Si verifica quando un'attività è in attesa di un latch per un buffer contenuto in una
I/O
richiesta. La richiesta di latch è in modalità condivisa. Attese lunghe possono indicare problemi con il sottosistema del disco.
In pratica, questo accade quasi sempre a causa di scansioni di grandi dimensioni su tabelle di grandi dimensioni. Non accade quasi mai nelle query che utilizzano gli indici in modo efficiente.
Se la tua query è così:
Select * from <table> where <col1> = <value> order by <PrimaryKey>
, controlla di avere un indice composto su (col1, col_primary_key)
.
Se non ne hai uno, allora avrai bisogno di un full INDEX SCAN
se PRIMARY KEY
viene scelto il, o di un SORT
se col1
viene scelto un indice su .
Entrambi sono I/O
operazioni che consumano molto disco su tabelle di grandi dimensioni.
SQL for Smarties
e Thinking in Sets
) e il mio blog ovviamente :)
PAGEIOLATCH_SH
il tipo di attesa di solito viene visualizzato come risultato di un indice frammentato o non ottimizzato.
Spesso i motivi per un PAGEIOLATCH_SH
tipo di attesa eccessivo sono:
Per provare a risolvere il problema con un PAGEIOLATCH_SH
tipo di attesa elevato , puoi controllare:
PAGEIOLATCH_SH
tipi di attesa eccessiviTenere sempre presente che in caso di mirroring ad alta sicurezza o disponibilità di commit sincrono in AlwaysOn AG, ci si PAGEIOLATCH_SH
può aspettare un aumento / eccessivo .
È possibile trovare ulteriori dettagli su questo argomento nell'articolo Gestione dei tipi di attesa eccessivi di SQL Server PAGEIOLATCH_SH