none
Consulta que se bloquea a si misma en modo CXPACKET RRS feed

  • Pregunta

  •  Hola, gracias a la orientación que ustedes me an dado en otros hilos ahora tengo mas información para analizar.
     Les comento, tengo MSSQL 2008 que tengo problemas de tiempo agotado en inserciones de algunas tablas, lo que me a llevado a analizar los inter bloqueos del servidor, algunos casos me an sido obvios (optimizando el query), pero hay a veces que veo sesiones que se bloquean a si misma en modo CXPACKET, que luego otras  son bloqueadas por la primera en modo LCK_M_S durante mas de 60 segundos.

    Entiendo el concepto del bloqueo, pero no logro ver que pudo optimizar.. o donde esta el problema, les doy un ejemplo:

    La sesión 74 se bloquea a si misma en modo  CXPACKET

    SQL: 

    SELECT      m.zona,    m.cliente,    datediff(day, min(m.fechaven), getDate()) AS diasmora   
    FROM v_qimputaciz m (readpast)
    WHERE ((m.acobrar) > (0)) AND ((m.zona) = ('01')) AND ((m.cliente) = ('013792'))
    GROUP BY m.zona, m.cliente
    Luego tengo la sesion 77 que es bloqueda por  74  durante 119s en modo LCK_M_S

    SQL:

    SELECT TOP 500 cliente AS c0, razon AS c1, dni AS c2, cuit AS c3, telefono AS c4, domicilio AS c5, localidad AS c6, provincia AS c7
    FROM V_Clientes2 (readpast)
    WHERE (((((((upper(convert(nvarchar(255),cliente,103))) + (upper(convert(nvarchar(255),razon,103)))) + (upper(convert(nvarchar(255),dni,103)))) + (upper(convert(nvarchar(255),cuit,103)))) + (upper(convert(nvarchar(255),telefono,103)))) + (upper(convert(nvarchar(255),domicilio,103)))) like ('%HENOCH%')) AND (((((V_Clientes2.DBSCHEMAID) = ('')) or ((V_Clientes2.DBSCHEMAID) is null)) or ((V_Clientes2.DBSCHEMAID) = ('00000000000000000001')))) ORDER BY cliente


    En si las  consultas no son muy eficientes v_qimputaciz tiene 4 anidamientos de vistas donde hace JOIN a 4 tablas y V_Clientes2 hace un join de 3 tablas. La DB es de un ERP donde todos los campos clave son tipo char y tienen muchos group by :)

    Como debería analizar el problema?  las consultas son poco eficientes pero no requieren 120s para completarse.. es solo que a veces sucede... 

    Gracias

     







    viernes, 15 de julio de 2016 15:49

Respuestas

  • Saludos

    Me podrias compartir cuantos procesadores tiene tu server, no es solo cambiar el nivel de paralelismo al azar y ver que funciona, si lo ponesen 1 estarias serializando todas tus consultas, esto no quiere decir que sea muy lentas, en algunos casos una consulta serial es mas rapida que une paralela, de hecho en general se recomienda que los sistemas OLTP sean seriales, mientras los OLAP sean paralelos.

    Intenta planes dinamicos como los de ola hallegren

    https://ola.hallengren.com/

    Y luego llama en job agent con

    sqlcmd -E -S $(ESCAPE_SQUOTE(SRVR)) -d master -Q "EXECUTE [dbo].[IndexOptimize] @Databases = 'USER_DATABASES', @FragmentationLow = NULL, @FragmentationMedium = NULL, @FragmentationHigh = NULL, @UpdateStatistics = 'ALL' , @OnlyModifiedStatistics = N'N', @LogToTable = N'Y'" -b



    • Marcado como respuesta José De Alva martes, 26 de julio de 2016 17:30
    jueves, 21 de julio de 2016 14:56
  • Buenas tarde!

    Mira yo segui el siguiente articulo y entendi que estaba pasando con los wait CXPACKET.

    Troubleshooting the CXPACKET wait type in SQL Server

    Espero que te sirva amigo

    Saludos!


    Carlos Ignacio Aguero. DBA SQL Server. Toda mi respeto al pueblo Peruano por la ayuda prestada en la guerra de Malvinas.

    • Propuesto como respuesta José De Alva miércoles, 20 de julio de 2016 22:16
    • Marcado como respuesta José De Alva martes, 26 de julio de 2016 17:30
    viernes, 15 de julio de 2016 16:08

Todas las respuestas

  • Buenas tarde!

    Mira yo segui el siguiente articulo y entendi que estaba pasando con los wait CXPACKET.

    Troubleshooting the CXPACKET wait type in SQL Server

    Espero que te sirva amigo

    Saludos!


    Carlos Ignacio Aguero. DBA SQL Server. Toda mi respeto al pueblo Peruano por la ayuda prestada en la guerra de Malvinas.

    • Propuesto como respuesta José De Alva miércoles, 20 de julio de 2016 22:16
    • Marcado como respuesta José De Alva martes, 26 de julio de 2016 17:30
    viernes, 15 de julio de 2016 16:08
  • Saludos

    Basicamente lo que ha de estar pasando es que tus estadisticas estan desactualizadas (actualizalas con fullscan), que tu nivel de paralelismo lo tienes en 0 con un max threshold de 5, es un comportamiento raro sino te interesa el paralelismo hazla con un maxdop a 1 y evitemos el paralelismo.

    Aunque al ser vistas tendriamos que evaluar el codigo interno. 

    viernes, 15 de julio de 2016 18:26
  • Hola Jose y Enrique

    Disculpen que no he contestado, no he tenido tiempo de leer con tranquilidad para comprender... (agradezco mucho lo escrito)
    Enrique:  todos los domingos se crean los indices de nuevo (REBUILD) y se actualiza la estadísticas (FULLSCAN) desde un plan de mantenimiento de MSSSQL, por las dudas mire el log del plan y se ejecutan las lineas:

    ALTER INDEX [ZONASPK] ON [dbo].[ZONAS] REBUILD PARTITION = ALL WITH ( PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON, ONLINE = OFF, SORT_IN_TEMPDB = OFF )
    UPDATE STATISTICS [dbo].[ZONASPK] WITH FULLSCAN

    Por el nivel de paralelismo y max threshold, siguiendo tus recomendaciones  ahora lo tengo en 2 max threshold en 50, pero sigue sucediendo.. aunque menos porque he ido mejorando algunas querys... (al tener un log e los querys bloquedos)

    si el max threshold lo pongo en 1, debería esperar una baja de performance importante?

    Saludos.


     



    jueves, 21 de julio de 2016 11:57
  • Saludos

    Me podrias compartir cuantos procesadores tiene tu server, no es solo cambiar el nivel de paralelismo al azar y ver que funciona, si lo ponesen 1 estarias serializando todas tus consultas, esto no quiere decir que sea muy lentas, en algunos casos una consulta serial es mas rapida que une paralela, de hecho en general se recomienda que los sistemas OLTP sean seriales, mientras los OLAP sean paralelos.

    Intenta planes dinamicos como los de ola hallegren

    https://ola.hallengren.com/

    Y luego llama en job agent con

    sqlcmd -E -S $(ESCAPE_SQUOTE(SRVR)) -d master -Q "EXECUTE [dbo].[IndexOptimize] @Databases = 'USER_DATABASES', @FragmentationLow = NULL, @FragmentationMedium = NULL, @FragmentationHigh = NULL, @UpdateStatistics = 'ALL' , @OnlyModifiedStatistics = N'N', @LogToTable = N'Y'" -b



    • Marcado como respuesta José De Alva martes, 26 de julio de 2016 17:30
    jueves, 21 de julio de 2016 14:56
  • Hola, disculpen la demora.
    El mssql esta en una VM de VMWare con 8 cores, donde el nivel de paralelismo es 2 (a mi entender esta bien), lo que si fue al azar fue el max threshold (no encontré forma fácil de medirlo, todabia no he podido leer los link de Jose)
    Lei sobre max threshold y OLTP vs OLAP, pero como es un ERP  es un sistema híbrido OLTP/OLAP, la semana que viene pongo max threshold = 1 para ver que onda.
    Tambien voy a probar los ola hallegren :)

    Saludos.

    miércoles, 27 de julio de 2016 12:02