SQL Server Performance

Mal rendimiento 2005

Discussion in 'Preguntas sobre SQL Server en Español.' started by pecobeconen, Dec 4, 2007.

  1. pecobeconen New Member

    Poseo una aplicacion en vb6 la cual estuvo trabajando sobre un SQL SERVER 2000. El mismo fue migrado a un SQL SERVER 2005 y desde la aplicacion las consultas se han vuelto muy lentas.
    Si ejecuto grandes consultas, como un "Select Column1, Column2, Column3 from Tabla where Column1 between @param1 and @param2" (cientos de miles de filas) dentro de un SP en el QA local o en un QA remoto, el mismo se ejecuta en 1 segundo y no veo consumo de "Procesador" en el servidor, pero si lo ejecuto desde la aplcacion, el mismo demora hasta 100 veces mas, y terminando varias veces con Tiempo Espera Agotado. Tambien se puede visualizar q la utilizacion de "Procesador" es exesiva, llendo al 100% por varios segundos para luego descender.
    El servidor posee habilitados los protocolos de SharedMemory y TCP/IP (tambien hemos probado colocando a Named Pipes pero no vimos mejoras).
    La conexion utilizada es ADO y esta seteada asi:
    .CursorLocation = adUseClient
    .ConnectionString = "Provider=SQLNCLI;Data Source=" & IP_Port & ";Initial Catalog=" & Base_Conex & ";User Id=" & User & ";Password=" & Pass & ";"
    .ConnectionTimeout = 10
    Desde ya muchas gracias.
    Pedro!
  2. Luis Martin Moderator

    Has ejecutado el full update statistics después del cambio?
  3. pecobeconen New Member

    Desde ya muchas gracias.-
    Posterior al cambio he realizado sp_updatestats , y DBCC UPDATEUSAGE; tambien he regenerado los indices, y he realizado un GRAN plan de mantenimiento con sus pasos. Shink, Reorganize, Rebuild y Update.
    Tambien he probado hacerlos por separado y/o manualmente.
    En todos los casos el problema persiste.
    Para volver a explicarlo, cuando ejecuto desde QA (local o remotamente) una simpe consulta demora 0 segundos, al ejecutarla por la aplicacion, la misma tarda muchisimas veces mas y hasta llega a causar tiempo espera agotado, (o sea en la linea, COMMAND.Excecute).
    El servidor se encuentra en mi misma red (igualmente es la misma conexion fisica q se utiliza para usar el QA remotamente), solo lo aclaro por las dudas, aunque suene muy obvio.
    Gracias, Pedro!
  4. Luis Martin Moderator

    Que se ejecute más rápidamente en QA resulta razonable, pero no a esos niveles.
    El problema debe estar en la aplicación y no en el 2005. Te suguiero que lo consultes con los desarrolladores de la aplicación.
    Por otro lado sería interesante probar si lo que tu ejecutas en el QA es lo mismo que muestra el Profiler cuando lo ejecutas desde la aplicación.
  5. pecobeconen New Member

    Los desarrolladores de la aplicacion soy yo mismo! [:#]
    En el profiler, las 2 conexiones son similares:
    Esta es la conexion por QA:
    -- network protocol: TCP/IP
    set quoted_identifier on
    set arithabort on
    set numeric_roundabort off
    set ansi_warnings on
    set ansi_padding on
    set ansi_nulls on
    set concat_null_yields_null on
    set cursor_close_on_commit off
    set implicit_transactions off
    set language Español
    set dateformat dmy
    set datefirst 1
    set transaction isolation level read committed

    mientas q la conexion por la aplicacion, la unica modificacion que tiene es en set arithabort off.
    Al ejecutar desde ambos lados el SP, que parametros controlo en el profiler? Te paso los de CPU, Reads, Wirtes, Duration
    Para el QA son: 47, 1998, 0, 65
    y para la aplicacion: 2188, 66770, 0, 2230
    Como se ve, son muy distintos! [:(] (los valores son promedios despues de 20 intentos)
    Gracias, Pedro!
  6. Luis Martin Moderator

    Ejecuta el Profiler con:
    TSQL: Batch completed
    SP:Completed
    Columns: Duration, cpu, reads.
  7. pecobeconen New Member

    Bueno, con dichos parametros (y habiendo agrandado el rango de FECHAS, los valores son)
    duration, cpu, reads
    64, 47, 1994 (desde QA remoto)
    11983, 362209, 11968 (desde aplicacion)
    Lo que veo distinto es, en la columna textData:
    exec PA_ProcedimientoAlmacenado '27/8/2006', '4/12/2007', 1 (desde QA Remoto)
    exec PA_ProcedimientoAlmacenado 'Ago 27 2006 12:00:00:000AM', 'Dic 4 2007 12:00:00:000AM', 1 (desde Aplicacion)
    no se si tendra algo que ver o no, pero es lo unico q se ve distinto.
    Muchas Gracias, Pedro!
  8. Luis Martin Moderator

    Lo primero que haría es poner las fechas en el mismo formato.
    Si nada cambia entonces la cosa se complica. A mi me algo parecido: usando XP tardaba una enormidad, usando w98 no tardaba nada. Rarísimo.
    Pero, si en QA pones:
    set statistics io on
    exec PA_........
    set statistics io off
    Verás en los mensajes las lecturas físicas realizadas y otros datos. Dudo que esas lecturas se acerquen a 300000 como te pasa desde la aplicación.
  9. pecobeconen New Member

    Bueno, vamos por partes.
    Mi PA, estaba declarado como
    ALTER PROCEDURE PA_MiPa @Fecha1 smalldatetime, @Fecha2 smalldatetime AS
    SET NOCOUNT ON
    SELECT Column1, Column2, Column3 FROM Tabla WHERE Column1 >= @Fecha1 AND Column1 <= @Fecha2 (tambien se habia probado con between)
    Con el PA armado de dicha manera, veia (utilizando el profiler) que desde el QA y la aplicacion se llamaban distinto, desde el QA directamente "exec PA_MiPa '28/08/2006', '04/12/2007'" pero desde la Aplicacion, el profiler mostraba "exec PA_MiPa 'Ago 28 2006 12:00:00:000AM','Dic 4 2007 12:00:00:000AM'" entocnes, como en el post previo me dijiste, modifique el tipo de DATOS de los parametros, de smalldatetime a char(10) y bueno, salio andando de manera exelente. A los mismos "tiempos", "costos", etc, q ejecutandose desde el QA.
    Ahora pregunto: no debo colocar ni declarar parametros como smalldatetime? hay alguna explicacion del porq? En SQL 2000 esto no me pasaba, es algo de configuracion que tengo mal en la instalacion del 2005 o en el Restora de la base ex2000 a 2005?
    Muchisimas gracias, Pedro!
  10. Luis Martin Moderator

    Pedro,
    Me alegra que hayas solucionado el problema.
    Con respecto a tu pregunta, lamentablemente, no tengo tanta experiencia en 2005.
    Lo que se me ocurre es que Microsoft tiene en su Web un utilitario para revisar el cambio de 2000 a 2005 y las sugerencias de cómo arreglar los problemas que el utilitario encuentre.
    Otra alternativa es escribir tu pregunta en Inglés ya que, en castellano, soy el único que responde preguntas.
    Saludos,
  11. pecobeconen New Member

    Ok, muchisimas gracias por las respuestas y tu tiempo.
    Un abrazo, Pedo!!
  12. eltriki New Member

    Wenas ya se que es demasiado tarde, pero para poder detectar este tipo de errores desde aplicaciones.. podrias utilizar la herramienta de SQL Server 2005 DATABASE tunning Advisor, con ella tienes toda la informacion acerca de la query detectada y el propio gestor te da recomendaciones de como tienes que tunnear la query con costes en cada una de las opciones.
    hechale un vistazo aqui...
    http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?culture=es-AR&EventID=1032366303&CountryCode=AR
    Un saludo
    By Triki

Share This Page