ExecuteReader demora consulta

Question

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,

Answer 1

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

Answer 2

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,

Answer 3

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

Answer 4

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,

Answer 5

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

Answer 6

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.

Answer 7

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,

Answer 8

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

Answer 9

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

Answer 10

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,

Answer 11

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

Answer 12

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

Answer 13

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

Answer 14

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