Risposte:
Dalla documentazione Microsoft :
PAGEIOLATCH_SHSi verifica quando un'attività è in attesa di un latch per un buffer contenuto in una
I/Orichiesta. 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 SCANse PRIMARY KEYviene scelto il, o di un SORTse col1viene scelto un indice su .
Entrambi sono I/Ooperazioni che consumano molto disco su tabelle di grandi dimensioni.
SQL for Smartiese 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_SHtipo di attesa eccessivo sono:
Per provare a risolvere il problema con un PAGEIOLATCH_SHtipo di attesa elevato , puoi controllare:
PAGEIOLATCH_SHtipi di attesa eccessiviTenere sempre presente che in caso di mirroring ad alta sicurezza o disponibilità di commit sincrono in AlwaysOn AG, ci si PAGEIOLATCH_SHpuò aspettare un aumento / eccessivo .
È possibile trovare ulteriori dettagli su questo argomento nell'articolo Gestione dei tipi di attesa eccessivi di SQL Server PAGEIOLATCH_SH