Solución:
Desde Documentación de Microsoft:
PAGEIOLATCH_SHOcurre cuando una tarea está esperando en un pestillo para un búfer que está en un
I/Osolicitud. La solicitud de pestillo está en modo compartido. Las esperas prolongadas pueden indicar problemas con el subsistema de disco.
En la práctica, esto casi siempre ocurre debido a grandes escaneos en tablas grandes. Casi nunca ocurre en consultas que usan índices de manera eficiente.
Si su consulta es así:
Select * from <table> where <col1> = <value> order by <PrimaryKey>
, compruebe que tiene un índice compuesto en (col1, col_primary_key).
Si no tiene uno, necesitará un INDEX SCAN Si el PRIMARY KEY es elegido, o un SORT si un índice en col1 esta elegido.
Ambos son muy disco I/O consumir operaciones en tablas grandes.
PAGEIOLATCH_SH el tipo de espera suele aparecer como resultado de un índice fragmentado o no optimizado.
A menudo razones de excesiva PAGEIOLATCH_SH tipo de espera son:
- El subsistema de E / S tiene un problema o está mal configurado
- Subsistema de E / S sobrecargado por otros procesos que están produciendo una alta actividad de E / S
- Mala gestión de índices
- Concepto erróneo de unidad lógica o física
- Problemas de red / latencia
- Presión de memoria
- Duplicación síncrona y AlwaysOn AG
Con el fin de tratar de resolver tener alta PAGEIOLATCH_SH tipo de espera, puede comprobar:
- SQL Server, consultas e índices, ya que muy a menudo esto se puede encontrar como una causa raíz del exceso
PAGEIOLATCH_SHtipos de espera - Para la presión de la memoria antes de saltar a cualquier solución de problemas del subsistema de E / S
Siempre tenga en cuenta que en caso de alta seguridad Mirroring o disponibilidad de compromiso síncrono en AlwaysOn AG, aumentada / excesiva PAGEIOLATCH_SH se puede esperar.
Puede encontrar más detalles sobre este tema en el artículo Manejo de tipos de espera excesivos de SQL Server PAGEIOLATCH_SH