locked
Respuesta de la base de datos muy muy lenta RRS feed

  • Pregunta

  •  

    Hola a todos,

     

    ´Tengo una aplicación web asp que tira de una base de datos sql server 2000 en un cliente. Esta aplicación se encuentra en explotación. Siempre ha funcionado sin problemas y desde hace unas semanas, el listado web con información de una tabla concreta tarda mas de 2 minutos en listarse. El resto de tablas sin problemas. He estado haciendo mil pruebas y no encuentro la solución.

     

    He estado probando el mismo aplicativo y con una base de datos idéntica pero en otro servidor y la información se lista rápidamente,

     

    Durante la larga espera para listar dicha tabla en la web.. el resto de aplicación no responde hasta que no finalice la lentísima solicitud de listado

     

    ¿Alguien me puede ayudar?, ¿Que puede ocurrir?

     

    Espero su respuestas

     

    Muchas gracias y un cordial saludo,

    viernes, 9 de mayo de 2008 10:34

Respuestas

  •  

    Hola  qwalgrande,

     

    Ya lo he solucionado, el problema estaba en la conexión a la base de datos. Por algún motivo se perdía cuando ejecutaba una segunda sql anidada. Lo he solucionado dando otra conexión a dicha sql.

     

    Quiero darte las gracias por tu tiempo y tu ayuda desinteresada.

     

    Sin mas, recibe un cordial saludo

     

    Muchas gracias Smile

    miércoles, 14 de mayo de 2008 13:58
  • Hola.

     

    Lamento discrepar en parte contigo en este punto. Hay que ordenar si, y sólo si la aplicación lo requiere por el motivo que sea. Si no es necesario ordenar, no se ordena, ya que como bien dices, ordenar cuesta, en ocasiones mucho.

     

    Ahora bien, si es necesario ordenar es mejor que lo haga el servidor de bases de datos, que lo hará mucho mejor que el cliente, cuyas prestaciones no tienes por qué conocer. Es más, esa ordenación en cliente se relaciona en muchos casos con cursores, algo que siempre se ha de evitar.

     

    Alberto López Grande.

    jueves, 5 de junio de 2008 19:54
    Moderador

Todas las respuestas

  • Hola.

     

    Tiene pinta de dos cosas, un plan de ejecución no muy bueno y bloqueos. Para reducir los bloqueos, baja el nivel de aislamiento a read uncommitted para obtener el listado. Puedes poner al inicio de la consulta "set transaction isolation level read uncommitted" o toma la consulta y coloca "with(nolock)" tras cada tabla (select * from mitabla t with(nolock)).

     

    Si tras realizar este cambio que te comento de los bloqueos el rendimiento no mejora ostensiblemente (lo cual incluye que el resto de la aplicación funcione mientras se lanza la consulta), sería cuestión de que nos pasaras el plan de ejecución de la consulta, a ver qué se puede hacer.

     

    Alberto López Grande.

    domingo, 11 de mayo de 2008 16:39
    Moderador
  •  

    Hola qwalgrande y muchas gracias por tu ayuda,

     

    He puesto en las sql lo que comentas del bloque y no se soluciona el problema. He pedido al departamento de sistemas que me pasen en plan de ejecución de la consulta. En cuento lo tengo te lo haré saber.

     

    Muchas gracias de nuevo,

     

    Un cordial saludo.

    lunes, 12 de mayo de 2008 14:37
  • Hola.

     

    Entre tanto, ¿puedes pasarnos la consulta tal y como la has dejado?

     

    Alberto López Grande

    lunes, 12 de mayo de 2008 21:03
    Moderador
  •  

    Hola de nuevo,

     

    Como no se como mandarte la imagen te lo paso por texto:

     

    Query 1: Query cost (relative to the batch): 62,50%

    Query text: SELECT idevento, titulo, entradilla, noticia, fechaevento, anexo FROM Agenda order by fechaevento desc

     

    SELECT    <-------    Compute Scalar    <-------     Sort     <-------     AGENDA.PK_AGEND...

    Cost: 0%                 Cost: 0%                      Cost: 20%              Cost: 80%

     

     

     

    Query 1: Query cost (relative to the batch): 37,50%

    Query text: SELECT count(*) AS num_anexos FROM agenda_doc where idevento = 142

    SELECT    <-------    Compute Scalar    <-------     Stream Aggregat...    <-------     AGENDA_DOC.PK_A...

    Cost: 0%                 Cost: 0%                               Cost: 0%              Cost: 100%

     

     

     

    Espero que te sirva de ayuda,

     

    Saludos y muchas gracias de nuevo.

     

     

    martes, 13 de mayo de 2008 8:10
  • Hola.

    Si esto es todo, no puedo creer que tarde 2 minutos, salvo que sea por bloqueos o porque la tabla AGENDA tenga millones de registros, en cuyo caso, la solución pasaría por otras vías.

    ¿Puedes hacer la siguiente prueba?

    Ejecuta lo siguiente:

    set statistics io on

    SELECT idevento, titulo, entradilla, noticia, fechaevento, anexo FROM Agenda with(nolock) order by fechaevento desc
    SELECT count(*) AS num_anexos FROM agenda_doc with(nolock) where idevento = 142

    Dime cuánto tarda, el número de registros que devuelve y las líneas que devuelve que no son los datos de la consulta (informe de lecturas).

    Alberto López Grande.
    martes, 13 de mayo de 2008 12:49
    Moderador
  •  

    Hola,

     

    Te paso la información que me solicitadas:

     

    set statistics io on

    SELECT idevento, titulo, entradilla, noticia, fechaevento, anexo FROM Agenda with(nolock) order by fechaevento Desc

     

     

    Application Profile Statistics                

      Timer resolution (milliseconds)           0          0

      Number of INSERT, UPDATE, DELETE statements           0          0

      Rows effected by INSERT, UPDATE, DELETE statements 0          0

      Number of SELECT statements         1          1

      Rows effected by SELECT statements          144      144

      Number of user transactions   2          2

      Average fetch time     0          0

      Cumulative fetch time 0          0

      Number of fetches     0          0

      Number of open statement handles    0          0

      Max number of opened statement handles      0          0

      Cumulative number of statement handles        0          0

                           

    Network Statistics                  

      Number of server roundtrips  1          1

      Number of TDS packets sent 1          1

      Number of TDS packets received      88        88

      Number of bytes sent 286      286

      Number of bytes received      338510            338510

                           

    Time Statistics             

      Cumulative client processing time       0          0

      Cumulative wait time on server replies            9          9

     

     

     

     

    y la otra es:

     

    set statistics io on

    SELECT count( * ) AS num_anexos FROM agenda_doc with(nolock) where idevento = 142

     

     

     

    Application Profile Statistics

                              Timer resolution (milliseconds)

    0          0            Number of INSERT, UPDATE, DELETE statements

    0          0            Rows effected by INSERT, UPDATE, DELETE statements

    0          0            Number of SELECT statements

    1          1            Rows effected by SELECT statements

    1          1            Number of user transactions

    2          2            Average fetch time

    0          0            Cumulative fetch time

    0          0            Number of fetches

    0          0            Number of open statement handles

    0          0            Max number of opened statement handles

    0          0            Cumulative number of statement handles

    0          0         

                            Network Statistics

                              Number of server roundtrips

    1          1            Number of TDS packets sent

    1          1            Number of TDS packets received

    1          1            Number of bytes sent

    218      218        Number of bytes received

    269      269     

                            Time Statistics

                              Cumulative client processing time

    3          3            Cumulative wait time on server replies

     

     

     

    Muchas gracias por tu tiempo y recibe un cordial saludo,

    martes, 13 de mayo de 2008 16:24
  • Hola.

     

    No es eso lo que esperaba que me enviaras (estas son las estadísticas de ejecución, no las de io). Mira en la pestaña "messages". Aún así, no tiene pinta de tardar mucho.

     

    Alberto López Grande

    martes, 13 de mayo de 2008 21:25
    Moderador
  •  

    Hola  qwalgrande,

     

    Ya lo he solucionado, el problema estaba en la conexión a la base de datos. Por algún motivo se perdía cuando ejecutaba una segunda sql anidada. Lo he solucionado dando otra conexión a dicha sql.

     

    Quiero darte las gracias por tu tiempo y tu ayuda desinteresada.

     

    Sin mas, recibe un cordial saludo

     

    Muchas gracias Smile

    miércoles, 14 de mayo de 2008 13:58
  • Talvez una última cosa, la ordenación hace mas lento el query, te recomendaría traer los datos tal y como vienen de la BD y luego ordenarlos del lado del cliente, de este modo no cargaras demasiado tu BD y aprovecharás los recursos del cliente.
    miércoles, 4 de junio de 2008 15:37
  • Hola.

     

    Lamento discrepar en parte contigo en este punto. Hay que ordenar si, y sólo si la aplicación lo requiere por el motivo que sea. Si no es necesario ordenar, no se ordena, ya que como bien dices, ordenar cuesta, en ocasiones mucho.

     

    Ahora bien, si es necesario ordenar es mejor que lo haga el servidor de bases de datos, que lo hará mucho mejor que el cliente, cuyas prestaciones no tienes por qué conocer. Es más, esa ordenación en cliente se relaciona en muchos casos con cursores, algo que siempre se ha de evitar.

     

    Alberto López Grande.

    jueves, 5 de junio de 2008 19:54
    Moderador