none
ExecuteReader demora consulta RRS feed

  • Pregunta

  • Buenas tardes a todos,

    Tengo un problema al ejecutar un procedimiento almacenado, al ejecutarlo tarda como 25 segundos en terminar la instrucción, sin embargo si ejecuto el mismo procedimiento almacenado en el SSMS solo tarda un segundo en devolver todos los datos... para ejecutar el procedimiento almacenado utilizo la siguiente instrucción:

    exec procAlmanacenado p1, p2, p3, p4...

    los parámetros son los mismos que le paso al sqlcommand... :S

    Tenéis alguna idea de que puede estar pasando??

    Un saludo,

    miércoles, 11 de abril de 2012 13:56

Respuestas

  • la query que ejecutas relacioan muchas tablas ?

    y alguna podria llegar hacerlo sin los campos clave o indices

    o quizas tiene algun filtro estilo like que podria aplciarse sobre un campo que no es indice

    quizas debas realizar un rebuild de los indices de sql server a esta db en produccion

    saludos


    Leandro Tuttini

    Blog
    Buenos Aires
    Argentina


    miércoles, 11 de abril de 2012 14:42

Todas las respuestas

  • para ejecutar el procedimiento almacenado utilizo la siguiente instrucción: exec procAlmanacenado p1, p2, p3, p4...

    eso no esta correcto, no debes usar el exec con el SqlCommand

    tendrias que usar

    DataTabla dt = new DataTable(); using (SqlConnection conn = new SqlConnection("connectionstring")) { SqlCommand cmd = new SqlCommand("<storedprocedure>", conn); cmd.CommandType = SqlCommandType.StoredProcedure; cmd.Parameters.AddWithValue("@param1", valor); SqlDataReader reader = cmd.ExecuteReader();

    while(reader.Read()){

    //resto del codigo

    } }

    como veras solo pones el nombre del SP y solo eso

    recuerda ademas que la cantidad de registros deben ser tomados y parseados eso lleva su tiempo de lectura

    saludos


    Leandro Tuttini

    Blog
    Buenos Aires
    Argentina

    miércoles, 11 de abril de 2012 14:02
  • Eso es, lo estoy haciendo tal y como indicas.

    Lo del exec  procAlmanacenado p1, p2,p3.... lo hago en el SSMS para comprobar cual es el tiempo de respuesta del procedimiento almacenado, es decir, para simular la consulta que lanza el ExecuteReader. En este caso del SSMS tarda 1 segundo en devolver los datos. Sin embargo, cuando lanzo el ExecuteReader la consulta tarda como 25 segundos, es decir, la instruccion del ExecuteReader tarda 25 segundos.

    Un saludo,

    miércoles, 11 de abril de 2012 14:08
  • claro pero el SMSS muestra el resultado en plano, tu en codigo estas seguramente parseando cada campo de cada registro

    eso lleva su tiempo, mas si los registros son muchos

    que numero de registro parseas ? porque si dices 10 es una cosa pero si son 1000 es muy diferente

    saludos


    Leandro Tuttini

    Blog
    Buenos Aires
    Argentina

    miércoles, 11 de abril de 2012 14:12
  • la consulta me devuelve 805 registros, pero he ejecutado la misma consulta sobre un Backup de la base de datos para contrastar datos y en el caso del Backup devuelve 642 registros el SSMS tarda 1 segundo, la instrucción del ExecuteReader tarda menos de 2 segundo.

    entiendo que el ExecuteReader demore un poco el tiempo de la consulta por el parseo, pero no hasta ese extremo por una diferencia de algo mas de 150 registros..

    Un saludo,

    miércoles, 11 de abril de 2012 14:22
  • si la verdad es raro

    imagino podria ser algun tema de indices, has validado si aplicando algun rebuil de los indices de la db se mejora el tiempo?

    has validado realziar esto mismo desde otra pc, o no hacerlo desde codigo sino compila y realizalo directo desde el .exe, registrando tiempo de inicio y fin

    saludos


    Leandro Tuttini

    Blog
    Buenos Aires
    Argentina

    • Propuesto como respuesta Carles Vila miércoles, 11 de abril de 2012 15:36
    • Votado como útil Carles Vila miércoles, 11 de abril de 2012 15:49
    miércoles, 11 de abril de 2012 14:28
  • Buenas Daniel y perdona Leandro por la intromisión... la tabla tiene algún campo que sea VARBINARY/IMAGE? A veces no solo el número de registros influye en la velocidad, si no el tamaño de cada uno de ellos...

    Un saludo,

    Miguel.

    miércoles, 11 de abril de 2012 14:30
  • rebuild de los indices no creo que sea necesario ya que la consulta en el SSMS tarda 1 segundo.

    si, he probado ha hacer esto mismo desde otra pc, tal y como dices la versión de producción tarda muchísimo debido a esta consulta, sin embargo la versión de preproduccion tarda como 5 veces menos en ejecutarse.

    Al depurar la versión de producción desde mi pc accediendo a la BBDD de producción puedo ver como tarda unos 25 segundos en la instrucción del ExecuteReader.

    Espero tu respuesta, un saludo,

    miércoles, 11 de abril de 2012 14:36
  • la query que ejecutas relacioan muchas tablas ?

    y alguna podria llegar hacerlo sin los campos clave o indices

    o quizas tiene algun filtro estilo like que podria aplciarse sobre un campo que no es indice

    quizas debas realizar un rebuild de los indices de sql server a esta db en produccion

    saludos


    Leandro Tuttini

    Blog
    Buenos Aires
    Argentina


    miércoles, 11 de abril de 2012 14:42
  • Hola Leandro,

    Esta pregunta es de las del millon. Lanzo la piedra y escondo la mano:).

    @Daniel Simal.

    Pasa el código Sql del procAlmanacenado

    Veras lo que aprendes:)

    Saludos,


    phurtado
    Mi Blog Blog
    Sigueme en Twitter

    miércoles, 11 de abril de 2012 15:12
    Moderador
  • la query solo relaciona 3 tablas y no tiene ningún filtro like.

    he hecho el rebuild del indice de la tabla y ahora lo hace perfecto.

    ¡¡¡¡¡¡MIL GRACIAS!!!!!!

    Un saludo,

    miércoles, 11 de abril de 2012 15:25
  • los indices son todo un tema

    cada tanto por mantenimiento es bueno hacer una reconstruccion para asegurar la performance

    es mas en las tareas de mantenimieto que puedes definir en sql server tiene esta opcion


    Leandro Tuttini

    Blog
    Buenos Aires
    Argentina

    miércoles, 11 de abril de 2012 15:34
  • Hola Leandro,

    Sabes, como que me parece extraño. Tres tablas y pocos registros, mal rendimiento. Apunto más a una mala Join o bien a un indice mal montado.

    Te lo digo porque en situaciones parecidas me he encontrado y no es un rebuild sino definir un indice que no estaba.

    Saludos,


    phurtado
    Mi Blog Blog
    Sigueme en Twitter

    miércoles, 11 de abril de 2012 15:42
    Moderador
  • Te lo digo porque en situaciones parecidas me he encontrado y no es un rebuild sino definir un indice que no estaba.

    o estaba el indice pero no aplicaba como corresponde, y el rebuild lo encamina

    Tres tablas y pocos registros

    recorrer 800 registros es un numero, para la db seguro pero para el cursosr de un reader puede generar demora


    Leandro Tuttini

    Blog
    Buenos Aires
    Argentina

    miércoles, 11 de abril de 2012 15:47
  • Hola Leandro.

    recorrer 800 registros es un numero, para la db seguro pero para el cursosr de un reader puede generar demora

    Nunca, lo que pasa es que  hay más registros y creo que más tablas y mal acceso a ellas. 800 no es un numero y si no compruebalo sin indices ni pk y veras.

    Saludos,


    phurtado
    Mi Blog Blog
    Sigueme en Twitter

    miércoles, 11 de abril de 2012 15:50
    Moderador