none
Select lento RRS feed

  • Debate general

  • 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

    martes, 12 de julio de 2016 15:23

Todas las respuestas

  • 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

    martes, 12 de julio de 2016 15:28
  • 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

    martes, 12 de julio de 2016 15:38
  • En producción no demora y en Desarrollo sí?

    Javier

    martes, 12 de julio de 2016 15:42
  • 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

    martes, 12 de julio de 2016 15:47
  • 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?

    martes, 12 de julio de 2016 15:49
  • 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

    martes, 12 de julio de 2016 15:54
  • 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.  

    martes, 12 de julio de 2016 15:57
  • 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

    martes, 12 de julio de 2016 16:11
  • Saludos

    Podrias compartilos no siempre son iguales aunque parescan. 

    martes, 12 de julio de 2016 16:15
  • Producción:


    Desarrollo:

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


    DBA SQL Server Santiago/Chile

    martes, 12 de julio de 2016 16:27
  • Saludos Christian

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

    martes, 12 de julio de 2016 16:31
  • 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


    • Editado CMAPM martes, 12 de julio de 2016 16:37
    martes, 12 de julio de 2016 16:37
  • 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.  

    martes, 12 de julio de 2016 16:40
  • 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

    martes, 12 de julio de 2016 16:44
  • 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.  

    martes, 12 de julio de 2016 16:48
  • Favor si me das tu correo, pues no veo como subir archivos aparte de imágenes.

    Saludos.


    DBA SQL Server Santiago/Chile

    martes, 12 de julio de 2016 16:52
  • Saludos

    enriarg@gmail.com por favor mandame de ambos y pon en el nombre si produccion o developer.  

    martes, 12 de julio de 2016 16:53
  • 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. 

    martes, 12 de julio de 2016 17:10
  • 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

    martes, 12 de julio de 2016 17:52
  • 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)

    martes, 12 de julio de 2016 17:58
  • 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

    martes, 12 de julio de 2016 18:22
  • Saludos

    Intenta lo mismo con 

    SET STATISTICS IO ON
    SET STATISTICS TIME ON

    Creo que estas teniendo waits

    Pon ambos resultados por favor  

    martes, 12 de julio de 2016 18:44
  • Hacele un update statistics a la tabla con fullscan
    miércoles, 13 de julio de 2016 0:37
  • 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.  

    miércoles, 13 de julio de 2016 4:35
  • 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

    miércoles, 13 de julio de 2016 16:23
  • 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.  

    miércoles, 13 de julio de 2016 16:38
  • 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

    miércoles, 13 de julio de 2016 16:56
  • 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

    jueves, 14 de julio de 2016 7:49
  • Fue solo porque edite el nombre de la BD.

    DBA SQL Server Santiago/Chile

    jueves, 14 de julio de 2016 16:31