Select lento

Question

Hola.

Tengo un job que sube diariamente un respaldo de la BD del servidor productivo a desarrollo.

Pues bien tengo un select que en Productivo demora milesimas de segundos y en desarrollo demora 47 segundos.

El select usa PK como indice, ya lo recontrui y nada sigue demorando.

SELECT distinct RUT, Nombre = Apellido_Paterno + ' ' + Apellido_Materno + ', ' + Nombres    
, id_tipo_persona, id_Sede    
from personas p    
WHERE rtrim(id_pasaporte)=rtrim(12345) 

---

DBA SQL Server Santiago/Chile

Answer 1

Hola CMAPM

Quizás se demore porque estás poniendo alias a la tabla y en los campos no.

Intenta así:

SELECT distinct p.RUT, Nombre = p.Apellido_Paterno + ' ' + p.Apellido_Materno + ', ' Nombres    
, p.id_tipo_persona, p.id_Sede    
from personas p    
WHERE rtrim(p.id_pasaporte)=rtrim(12345) 

Saludos

 

---

Javier

Answer 2

La demora es la misma.

Insisto que lo raro que es una copia de producción y en producción demora menos de 1 segundo.

---

DBA SQL Server Santiago/Chile

Answer 3

En producción no demora y en Desarrollo sí?

---

Javier

Answer 4

Exactamente.

Produccion menos de 1 segundo.

Desarollo 45 segundos.

copio texto del post inicial:

"sube diariamente un respaldo de la BD del servidor productivo a desarrollo"

---

DBA SQL Server Santiago/Chile

Answer 5

Saludos

EL servidor de produccion y desarrollo es identico, a que me refiero con esta misma configuracion, mismo sql, mismo build, mismo tipo de discos, cantidad de ram, carga de trabajo similar, trace flags identicas?

Answer 6

La verdad es que no, son bastantes diferentes.

Productivo SQL 2005 32Gb RAM

Desarrollo SQL 2008 R2 12 GB RAM

Ahora, cuadno ejecuto cualquier SP, select, vista y demases no tengo problemas.

El Select indique devuelve SOLO 1 registro y demora 45 segundos.

---

DBA SQL Server Santiago/Chile

Answer 7

Saludos

Regla de oto, no intentes hacer comparaciones si tienes tanta diferencia solo estaras buscando a lo loco sin obtener una respuesta, en todo caso ve los planes de ejecucion de ambos y ve en que se diferencian.  

Answer 8

Entiendo Enrique.

Los planes son iguales.

Lo que no termino de entender porque demora tanto en hacer un select de 1 registro para una tabla en particular.

---

DBA SQL Server Santiago/Chile

Answer 9

Saludos

Podrias compartilos no siempre son iguales aunque parescan. 

Answer 10

Producción:

Desarrollo:

En ambos usa la PK PK_Pernonas_Resp con un costo de 99%

---

DBA SQL Server Santiago/Chile

Answer 11

Saludos Christian

Necesito los planes porque esta informacion en los iconicos en los estimados que podria varias lo que vez.  

Answer 12

Enrique, esto ?

  |--Parallelism(Gather Streams)
       |--Compute Scalar(DEFINE:([Expr1002]=((([DB].[dbo].[Personas].[Apellido_Paterno] as [p].[Apellido_Paterno]+' ')+[DB].[dbo].[Personas].[Apellido_Materno] as [p].[Apellido_Materno])+', ')+[DB].[dbo].[Personas].[Nombres] as [p].[Nombr
            |--Clustered Index Scan(OBJECT:([DB].[dbo].[Personas].[PK_Pernonas_Resp] AS [p]), WHERE:(rtrim([DB].[dbo].[Personas].[ID_Pasaporte] as [p].[ID_Pasaporte])='12345'))

  |--Parallelism(Gather Streams)
       |--Compute Scalar(DEFINE:([Expr1002]=((([DB].[dbo].[Personas].[Apellido_Paterno] as [p].[Apellido_Paterno]+' ')+[Fichas20].[dbo].[Personas].[Apellido_Materno] as [p].[Apellido_Materno])+' ')+[DB].[dbo].[Personas].[Nombres] as [p].[Nombre
            |--Clustered Index Scan(OBJECT:([DB].[dbo].[Personas].[PK_Pernonas_Resp] AS [p]), WHERE:(rtrim([DB].[dbo].[Personas].[ID_Pasaporte] as [p].[ID_Pasaporte])='12345'))

---

DBA SQL Server Santiago/Chile

Answer 13

Saludos

No da te da estimados de los datos sobre los que trabajara, sino lo pueds mandar sera un poco dificil ayudarte a menos que busques mas informacion sobre planes de ejecucion.  

Answer 14

OK, dame una mano, necesitas los planes y yo te envié los iconos que no sirven del todo al parecer.

Me puedes indicar como hago para sacar lo que solicitas ?

Saludos Cordiales.

---

DBA SQL Server Santiago/Chile

Answer 15

Saludos

Cuando creas el plan en cualquier area del mismo da click derecho y guardalo como .sqlplan y envialo o subelo a un area compartida o te paso mi correo.  

Answer 16

Favor si me das tu correo, pues no veo como subir archivos aparte de imágenes.

Saludos.

---

DBA SQL Server Santiago/Chile

Answer 17

Saludos

[e-mail] por favor mandame de ambos y pon en el nombre si produccion o developer.  

Answer 18

Saludos

Varias cosas, uno tiene distinct el otro no, fuera de eso veo un costo de IO superior en tu area desarrollo, cuantos procesadores tiene ya que el steamno me dice mucho posiblemente sean tus discos y la velocidad de ellos. 

Answer 19

Si, le saque el distinct a uno solo para probar y se me fue volver a dejarlo como estaba.

Hay diferencia de procesadores y de maquina.

Productivo 8 VCPU es virtual.

Desarrollo 4 CPU es fisico.

Se que el de desarrollo es menos máquina, pero acá viene mu duda, solo yo lo estoy ocupando, y por eso digo que demora mucho, hago otro select de una tabla que tiene mas registros y demora bastante poco.

---

DBA SQL Server Santiago/Chile

Answer 20

Aunque es extraño pueden haber tantos puntos de quiebre y sin conocer el ambiente es dificil.

Corre en ambos un 

DBCC TRACESTATUS(-1)

Intenta hacer correr el query en serial en ambos para descartar que sea un problema por waits en un plan paralelo.

Al final pon OPTION (MAXDOP 1)

Answer 21

Lo hice.

Algo mejoró en desarrollo ahora demora 30 segundos en vez de 45.

Producción sigue siendo menos de 1 segundo.

Bien rara la situación, probare con otra tabla de 3 mill de registros.

---

DBA SQL Server Santiago/Chile

Answer 22

Saludos

Intenta lo mismo con 

SET STATISTICS IO ON
SET STATISTICS TIME ON

Creo que estas teniendo waits

Pon ambos resultados por favor  

Answer 23

Hacele un update statistics a la tabla con fullscan

Answer 24

Saludos Luis

Aunque tu recomendacion es buena me temo que este tema no esta tan facil como para que sea estadisticas y quiero pensar que es algo que ya contempló Christian.  

Answer 25

Hola,

después de leerme todas las respuestas...has pensado en si tienes algún problema de disco o algo parecido?

Y también, algo que creo que no te han pedido todavía, puedes ejecutar la consulta en ambos servidores asi:

- DBCC DROPCLEANBUFFERS

- SET STATISTICS IO ON

- lanza las querys y pega aquí ambos resultados a ver que sale

Saludos

---

JMF

Answer 26

El DBCC DROPCLEANBUFFERS no lo ejecutes en el ambiente productivo.

El otro ya lo habia pedido, no estoy seguro que sea IO es una posibilidad pero parece un error demasiado especifico.  

Answer 27

Se que es delicado y poco aconsejable ejecutarlo en producción pero a veces hay que tomar decisiones arriesgadas...todo dependerá del volumen de tráfico que reciba el servidor de todas formas.

De todas formas he visto en el plan de ejecución en modo texto que ha puesto antes y veo que en el segundo hace referencia a dos bases de datos distintas?¿?¿? a Fichas20 y a DB?¿?¿?

Podrías explicar eso CMAPM?

SalU2

---

JMF

Answer 28

Te lo he preguntado un poco más abajo pero por si no lo has visto...

porque en el segundo plan de ejecución aparecen las bases de datos Fichas20 y DB???

SalU2

---

JMF

Answer 29

Fue solo porque edite el nombre de la BD.

---

DBA SQL Server Santiago/Chile