Compartir a través de

Solución de problemas de toda la aplicación de base de datos o SQL Server que parece funcionar lentamente

Se aplica a: SQL Server

Al ejecutar consultas en una instancia de SQL Server o en una aplicación determinada, todas las consultas son lentas. Para resolver el problema, siga estos pasos:

Paso 1: Solución de problemas de la aplicación

Compruebe la capa de aplicación. Tome una consulta de la aplicación, ejecútelo manualmente en una instancia de SQL Server y vea cómo se ejecuta. Pruebe varias consultas de esta manera. Si las consultas son más rápidas en la instancia de SQL Server, el problema podría estar en el nivel de la aplicación o de los servidores de aplicaciones.

Nota:

Tenga en cuenta las diferencias de rendimiento de las consultas entre la aplicación de base de datos y SSMS.

Si la aplicación se ejecuta en un servidor diferente, compruebe el rendimiento del servidor de aplicaciones (consulte Paso 2: Solución de problemas del sistema operativo para solucionar problemas). Es posible que tenga que interactuar con el equipo de desarrollo de aplicaciones para comprobar si hay algún problema con la aplicación.

Paso 2: Solución de problemas del sistema operativo

Compruebe si el sistema operativo en el que se ejecuta SQL Server responde lentamente. Por ejemplo, el mouse se mueve lentamente, las ventanas no responden durante largos períodos, el acceso a Escritorio remoto al servidor es lento o la conexión a un recurso compartido en el servidor es lento.

Este problema puede deberse a otro servicio o aplicación. Use Perfmon para solucionar problemas.

Para ver otros problemas de rendimiento del sistema operativo, consulte la documentación de solución de problemas de rendimiento de Windows Server.

Algunos problemas comunes son:

Este problema puede deberse a otras aplicaciones, el sistema operativo o los controladores que se ejecutan en el sistema.

Para solucionar este problema, use task Manager, Monitor de rendimiento o Resource Monitor para identificar este problema. Para obtener más información, consulte Guía de solución de problemas de uso elevado de CPU.

Paso 3: Solución de problemas de red

El problema podría estar en la capa de red, lo que provoca una comunicación lenta entre la aplicación y SQL Server. Use los métodos siguientes para solucionar este problema:

  • Un síntoma de eso podría ser ASYNC_NETWORK_IO esperar en el lado de SQL Server. Para obtener más información, consulte Solución de problemas de consultas lentas resultantes de ASYNC_NETWORK_IO tipo de espera.

  • Trabaje con el administrador de red para comprobar si hay problemas de red (firewall, enrutamiento, etc.).

  • Recopile un seguimiento de red y compruebe los eventos de restablecimiento y retransmisión de red. Para obtener información sobre la solución de problemas, consulte Problemas de red intermitentes o periódicos.

  • Habilite los contadores de Perfmon para comprobar el rendimiento de la red en el nivel de interfaz de red (NIC). Debe haber cero paquetes descartados y paquetes de error. Compruebe el ancho de banda de la interfaz de red:

    • Interfaz de red\Paquetes recibidos descartados
    • Interfaz de red\Errores recibidos de paquetes
    • Interfaz de red\Paquetes salientes descartados
    • Interfaz de red\Errores de salida de paquetes
    • Interfaz de red\Total de bytes/s
    • Interfaz de red\Ancho de banda actual

Paso 4: Solución de problemas de uso elevado de CPU en SQL Server

Si se ejecutan consultas intensivas de CPU en el sistema, pueden provocar que otras consultas se desanien de la capacidad de CPU. Sin embargo, con más frecuencia, el uso elevado de cpu procedente de consultas puede ser una indicación de que las consultas deben optimizarse. Siga estos pasos para solucionar el problema:

  1. En primer lugar, averigüe si SQL Server está causando un uso elevado de la CPU (mediante contadores perfmon).
  2. Identifique las consultas que contribuyen al uso de cpu.
  3. Actualizar estadísticas.
  4. Agregue índices que faltan.
  5. Investigue y resuelva los problemas de sensibilidad a los parámetros.
  6. Investigue y resuelva los problemas de SARGability.
  7. Deshabilite el seguimiento pesado.
  8. Corregir SOS_CACHESTORE la contención de bloqueo por subproceso.
  9. Configure la máquina virtual.
  10. Escale verticalmente el sistema agregando más CPU.

Para ver los pasos de solución de problemas detallados, consulte Solución de problemas de uso elevado de CPU en SQL Server.

Paso 5: Solución de problemas de E/S excesiva que provoca la lentitud en SQL Server

Otra razón común para la lentitud general percibida de las cargas de trabajo de SQL Server es problemas de E/S. La lentitud de E/S puede afectar a la mayoría o todas las consultas del sistema. Use los métodos siguientes para solucionar el problema:

  • Compruebe si hay problemas de hardware:

    • Configuración incorrecta de SAN (conmutador, cables, HBA, almacenamiento).
    • Capacidad de E/S superada (desequilibrada en toda la red SAN, no solo almacenamiento back-end, compruebe el rendimiento de E/S de todos los servidores que comparten la SAN).
    • Controladores o problemas de firmware o actualizaciones.

  • Compruebe si hay consultas de SQL Server poco óptimas que provocan una gran cantidad de E/S y saturan volúmenes de disco con solicitudes de E/S.

    • Busque las consultas que causan un gran número de lecturas lógicas (o escrituras) y ajuste esas consultas para minimizar la E/S de disco mediante índices adecuados es el primer paso.
    • Mantenga las estadísticas actualizadas a medida que proporcionan al optimizador de consultas información suficiente para elegir el mejor plan.
    • El rediseño de consultas y, a veces, las tablas pueden ayudar con una E/S mejorada.

  • Controladores de filtro: la respuesta de E/S de SQL Server puede verse afectada gravemente si los controladores de filtro del sistema de archivos procesan tráfico intensivo de E/S.

    • Excluya las carpetas de datos del examen antivirus y tenga problemas de controladores de filtro corregidos por proveedores de software para evitar un impacto en el rendimiento de E/S.

  • Otras aplicaciones: otra aplicación de la misma máquina con SQL Server puede saturar la ruta de acceso de E/S con solicitudes de lectura o escritura excesivas. Esta situación puede insertar el subsistema de E/S más allá de los límites de capacidad y provocar la lentitud de E/S para SQL Server. Identifique la aplicación y ajustela o muévala en otro lugar para eliminar su efecto en la pila de E/S. Este problema también puede deberse a que las aplicaciones se ejecutan en otras máquinas, pero comparten la misma SAN con esta máquina sql Server. Trabaje con el administrador de SAN para equilibrar el tráfico de E/S (consulte Comprobación de problemas de hardware).

Para obtener una solución detallada de problemas relacionados con la E/S con SQL Server, consulte Solución de problemas de rendimiento lento de SQL Server causados por problemas de E/S.

Paso 6: Solución de problemas de memoria

Una memoria baja en el sistema en general o dentro de SQL Server puede dar lugar a una lentitud cuando las consultas esperan concesiones de memoria (RESOURCE_SEMAPHORE) o memoria de compilación (RESOURCE_SEMAPHORE_QUERY_COMPILE). Use los métodos siguientes para solucionar el problema:

  • Compruebe si hay memoria externa en el nivel de sistema operativo mediante contadores de Perfmon:

    • Memoria\MBytes disponibles
    • Proceso(*)\Conjunto de trabajo (todas las instancias)
    • Proceso(*)\Bytes privados (todas las instancias)

  • Para la presión de memoria interna, use consultas de SQL Server para consultar sys.dm_os_memory_clerks o usar DBCC MEMORYSTATUS.

  • Compruebe si hay errores 701 en el registro de errores de SQL Server.

Para obtener pasos detallados de solución de problemas, consulte Solución de problemas de memoria insuficiente o de memoria insuficiente en SQL Server.

Paso 7: Solución de problemas de bloqueo

La adquisición de bloqueos se usa para proteger los recursos de un sistema de base de datos. Si los bloqueos se adquieren durante mucho tiempo y otras sesiones terminan esperando esos bloqueos, se enfrenta a un escenario de bloqueo.

El bloqueo corto se produce en sistemas de base de datos como SQL Server todo el tiempo. Pero el bloqueo prolongado, especialmente cuando la mayoría o todas las consultas están esperando un bloqueo, podría dar lugar a que todo el servidor se perciba como no responde.

Siga estos pasos para solucionar el problema:

  1. Identifique la sesión de bloqueo principal examinando la columna blocking_session_id en sys.dm_exec_requests salida de DMV o la columna BlkBy en sp_who2 la salida del procedimiento almacenado.

  2. Busque las consultas que ejecuta la cadena de bloqueo principal (lo que contiene bloqueos durante un período prolongado).

    Si ninguna consulta se ejecuta activamente en la sesión de bloqueo principal, podría haber habido una transacción huérfana debido a problemas de la aplicación.

  3. Rediseñe o ajuste la consulta de bloqueo principal para que se ejecute más rápido o reduzca el número de consultas dentro de una transacción.

  4. Examine el aislamiento de transacción usado en la consulta y ajuste.

Para obtener una solución detallada de problemas de escenarios de bloqueo, consulte Descripción y resolución de problemas de bloqueo de SQL Server.

Paso 8: Solución de problemas del programador (sin rendimiento, programador interbloqueado, agente de escucha de IOCP sin rendimiento, monitor de recursos)

SQL Server usa un mecanismo de programación cooperativo (Programadores) para exponer sus subprocesos al sistema operativo para programar en la CPU. Si hay problemas relacionados con los programadores de SQL, los subprocesos de SQL Server podrían dejar de procesar consultas, inicios de sesión, cierres de sesión, etc. Como resultado, SQL Server podría parecer que no responde, parcialmente o completamente, en función del número de programadores afectados. Los problemas del programador pueden deberse a una amplia gama de problemas, incluidos errores de producto, controladores externos y de filtro, y problemas de hardware.

Siga estos pasos para solucionar estos problemas:

  1. Compruebe si hay errores en el registro de errores de SQL Server como los siguientes en el momento de la falta de respuesta notificada de SQL Server:

    • ***********************************************
*
* BEGIN STACK DUMP:
* 03/10/22 21:16:35 spid 22548
*
* Non-yielding Scheduler
*
***********************************************

    • **********************************************
*
* BEGIN STACK DUMP:
* 03/25/22 08:50:29 spid 355
*
* Deadlocked Schedulers
*
* ********************************************


    • * *******************************************************************************                                
*                                                                                                                
* BEGIN STACK DUMP:                                                                                              
* 09/07/22 23:01:04 spid 0                                                                                     
*                                                                                                                
* Non-yielding IOCP Listener                                                                                     
*                                                                                                                
* *******************************************************************************   

    • * ********************************************
*
* BEGIN STACK DUMP:
* 07/25/22 11:44:21 spid 2013
*
* Non-yielding Resource Monitor
*
* ********************************************

  2. Si encuentra uno de estos errores, identifique la versión de actualización acumulativa (CU) de SQL Server que está usando. Compruebe si hay algún problema corregido en las RU enviadas después de la CU actual. Para ver las correcciones de SQL Server, consulte Actualizaciones más recientes disponibles para las versiones admitidas actualmente de SQL Server. Para obtener una lista de correcciones detallada, puede descargar este archivo de Excel.

  3. Use Solución de problemas de programación y rendimiento de SQL Server para obtener más ideas.

  4. Compruebe si hay escenarios de bloqueo intensivo o consultas de paralelismo masivo que pueden provocar programadores de interbloqueo. Para obtener información detallada, vea The Tao of a Deadlocked Scheduler.

  5. En el caso de un agente de escucha IOCP que no produce ningún rendimiento, compruebe si el sistema tiene poca memoria y SQL Server se está paginando. Otra razón podría ser antivirus o software de prevención de intrusiones intercepta las llamadas API de E/S y ralentiza la actividad del subproceso. Para obtener más información, consulte ¿Escucha ioCP realmente escucha? y Problemas de rendimiento y coherencia cuando se cargan determinados módulos o controladores de filtro.

  6. En el caso de los problemas de Resource Monitor, es posible que no tenga que preocuparse necesariamente por este problema en algunos casos. Para obtener más información, vea Resource Monitor especifica una condición que no produce en un servidor que ejecuta SQL Server.

  7. Si estos recursos no ayudan, busque el volcado de memoria creado en el subdirectorio \LOG y abra una incidencia de soporte técnico con CSS de Microsoft cargando el volcado de memoria para su análisis.

Paso 9: Buscar el generador de perfiles intensivo de recursos o seguimientos XEvent

Busque eventos extendidos activos o seguimientos de SQL Server Profiler, especialmente aquellos con filtrado en columnas de texto (nombre de base de datos, nombre de inicio de sesión, texto de consulta, etc.). Si es posible, deshabilite los seguimientos y compruebe si mejora el rendimiento de las consultas. En función del evento seleccionado, cada subproceso puede consumir CPU adicional que provoque una lentitud general. Para identificar los seguimientos activos para eventos extendidos, consulte sys.dm_xe_sessions y para seguimientos de Profiler, consulte sys.traces.

SELECT * FROM sys.dm_xe_sessions
GO
SELECT * FROM sys.traces