none
Problema rendimiento SQL-Server 2008 R2 RRS feed

  • Debate general

  • Tengo una instalación de SQL-Server 2008 R2, corriendo bajo Windows Server 2010 R2, instalado en un servidor multi-Xeon E5, 64 Bits, 64 Mb RAM, RAI 5 con espejo. El número medio de usuarios concurrentes es de 500.

    Pues bien, la BD ha estado funcionando perfectamente hasta hace, aproximadamente, tres meses. Cuando, sin razón aparente alguna, su rendimiento baja extremadamente, aún en consultas sencillas. Se recupera habitualmente sin necesidad de intervención por mi parte, aunque algunas veces sea necesario eliminar manualmente los bloqueos. Lo extraño del caso es que no ocurre ni todos los días, ni a ninguna hora concreta, ni con determinado número de usuarios activos, ni debido a la inclusión de nuevos procedimientos o consultas, ni cuando se ejecuta una consulta o procedimiento determinado ya existente, ni por cambios en la parametrización, ni cualquier otra circunstancia mesurable. Me refiero, dicho en palabras llanas, a que de repente se ralentiza sin más. Curiosamente ocurre a nivel de SQL-Server, pues el servidor como tal máquina no acusa bajada de rendimiento alguna, de hecho el uso de sus recursos se mantiene en niveles bajos. He revisado la instancia de SQL-Server en todos los parámetros y configuraciones posibles, sin encontrar explicación alguna.

    Agradecería cualquier sugerencia, pues reconozco estar completamente a ciegas en este asunto.

    • Tipo cambiado José De Alva miércoles, 20 de julio de 2016 22:18
    viernes, 15 de julio de 2016 12:03

Todas las respuestas

  • Saludos,

    Como estan tus planes de mantenimiento?

    Que build tienes?

    Raid 5 no es exactamente el mas rapido, que velocidades y tiempos de respuesta tienes?

    Algun error en el log de errores?

    Mencionas bloqueos esto indica indices o mala porgramacion?

    Mencionas parametros que medidas estas usando en tus sp para mitigar esto?

    viernes, 15 de julio de 2016 14:58
  • El SQL 2008 recibió un parche hace poco, no recuerdo exactamente cuando, al menos a nosotros nos salió y lo instalamos pero todo normal quizas porque el uso sea de poca intensidad. Busca en Windows Update y si hubiera algún parche reciente desinstalalo, podría ser eso.
    viernes, 15 de julio de 2016 15:16
  • Hola.

    Además de proporcionarnos lo que indica Enrique, también identifica si hay momentos particulares del día en que esto sucede y si durante esos momentos hay algunas instrucciones T-SQL que estén asociadas a dicho comportamiento.

    Saludos,


    Guillermo Taylor F.
    MVP SQL Server & IT Pro
    Mi Blog

    viernes, 15 de julio de 2016 17:58
  • Hola, yo tenia un problema similar, y la lentitud se debía a problemas con las estadísticas. Te sugiero que la revises y de ser posible hagas pruebas de estress con y sin estadísticas. Las estadísticas se pueden estar creando de manera automática (Por experiencia la mantengo des habilitado, pero con un monitoreo constante para revisar  y crear solo las necesarias).

    Otra posible causa es problema de latencia con los disco duros (Inclusive daño). Intenta revisar en tu infraestructura los tiempos de respuesta cuando la base de datos este lenta, de igual manera dale mantenimiento a todos los indices para revisar que no estén fragmentados y a aquellos que no sirvan eliminalos, la insercción y actualización de registros puede ser la causa de esta fragmentación. Revisa los comandos de DMV para revisar la latencia dentro de SQL SERVER. 


      

    ISC. MARTIN GUADALUPE MARTINEZ HERNÁNDEZ

    sábado, 16 de julio de 2016 16:38
  • Saludos

    Estadísticas es un tema muy complejo y no recomendaría crear estadísticas personales a menos que tengas un grado alto de conocimiento tanto de sql server como de la misma información a la que le vas a crear las estadísticas.

    Es posible que sean estadísticas desactualizadas y podrias actualizarlas con full scan pero no crear estadísticas indiscriminadamente.

    domingo, 17 de julio de 2016 23:36
  • Hola de nuevo.

    Al respecto sobre el problema"Rendimiento SQL-Servar 2008" que he reportado, amplio información porsi puede ayudar en la sugerencia de soluciones:

    - Originalmente era una BD SQL-Server 2005 que se migró (no upgrade) a 2008 R2, mediante BackUp / Restore. En 2005 funcionaba perfectamente. Diera la impresión, aunque no se puede establecer una relación inequívoca, de que al cambiar a 2008 la BD ha ido teniendo el comportamiento descrito. Repito que los problemas dieran la impresión de haberse presentado a raíz de la migración, pero no inmediatamente después.

    - El nivel de compatibilidad de la BD se estableció a 80 (2000). Es decir: tal como estaba cuando la versión era 2005.

    - La versión desde la que se migró era: Microsoft SQL Server 2005 - 9.00.5000.00 (X64)  Dec 10 2010 10:38:40  Developer Edition (64-bit) on Windows NT 6.1 (Build 7601: Service Pack 1)

    - La versión actual de SQL-Server es: Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64) Apr  2 2010 15:48:46 Enterprise Edition (64-bit) on Windows NT 6.2 <X64> (Build 9200: )

    - Habida cuenta de la existencia de varias consultas, subconsultas y procedimientos anidados, el único parámetro del servidor SQL revisado finalmente ha sido el grado de paralelismo, estableciéndolo a 15.

    - No existe una tabla, procedimiento y/o consulta específica que ralentice la BD. Me refiero a que una misma funciona perfectamente hoy a plena carga de usuarios, mientras que (por ejemplo) mañana se "atasca", siendo incapáz de resolver los bloqueos, estando apenas una docena de usuarios conectados. Tampoco se relaciona con un usuario o grupo de usuairos concreto.

    lunes, 18 de julio de 2016 10:01
  • Hola.

    Si entendí bien, la BD en cuestión la tienes en SQL Server 2008 R2 RTM con nivel de compatibilidad 80. ¿Es correcto?

    Por favor, ejecuta la siguiente instrucción sobre la BD en cuestión y nos compartes el resultado:

    SELECT name, compatibility_level   
    FROM sys.databases   
    WHERE name = db_name();

    Muchas veces no es tema del motor, sino de instrucciones que de pronto funcionaban bien en versiones anteriores a la de este caso, 2008 R2, y que en ésta se sugiere modificar o cambiar. Esto no podemos saberlo obviamente. Por favor leer el siguiente documento para entender muy bien si alguna de las instrucciones T-SQL con las que se accede a la BD requieren modificación:

    http://download.microsoft.com/download/3/0/D/30DB8D46-8ACF-442A-99A2-0F4CE74AE14D/SQL_Server_2008_R2_Upgrade_Technical_Reference_Guide.docx

    Es un documento largo, pero seguro te ayudará a entender mejor si se debe hacer algo directamente con la BD que te ayude en esta situación en particular.

    Saludos,


    Guillermo Taylor F.
    MVP SQL Server & IT Pro
    Mi Blog


    lunes, 18 de julio de 2016 14:36
  • Hola.

    Efectivamente la tenía en compatibilidad 80(2000) aunque la he cambiado esta misma mañana a 90(2005), pues me lo han aconsejado así. Aunque parece que no ha mejorado especialmente. En cualquie caso la instrucción comentada devuelve, como es obvio: GestAverias    90

    Revisaré el documento Word al que se hace alusión.

    Un saludo.

    lunes, 18 de julio de 2016 15:13
  • Saludos

    El estimador de cardinalidad no fue modificado hasta 2012 aunque algunas meoras a travez del tiempo pueden estarte impactando, en todo caso como se ha mencionado en anterioridad no puedes esperar el mismo desempeño al cambiar de version.

    Aunque tenemos que ver algunas cosas

    Tu nivel de compatibilidad es recomendable que sea 100 que es el nativo de SQL Server 2008 R2

    Deberias de instalar como minimo el SP3 este tiene mejoras de rendimiento, y estabilidad que en este momento te faltan.

    Deberias de hacer un  checkdb con data purity

    Si no vez errores aqui haz un rebuild de los indices y luego un update de estadisticas con full scan, luego ya prueba y dinos como va.

    Claro considerando que encuentres esto como una opcion y tengas la facilidad de realizarlo.

    lunes, 18 de julio de 2016 15:31
  • Hola.

    Probaremos esto: SP3, CheckDB, UpdateStatistics...

    Comentaré como ha ido.

    Un saludo.

    lunes, 18 de julio de 2016 16:10
  • Hola.

    Ante todo consideremos (olvidé comentarlo) que se trata de una BD "heredada", en el sentido de haberme hecha cargo de ella, sin que se me facilitara información de ningún tipo acerca de su diseño en tablas, vistas, desencadenadores, etc. Por si fuera poco es atacda por un software sobre el que, como en el caso de la BD, tampoco he recibido documentación.

    Al final, tras instalar SP3, ejecutar un CheckDB, UpdateStatistics, etc. el rendimiento mejoró en algo, aunque no significativamente. Fué entonces cuando me percaté del ingente número de bloqueos e interbloqueos que debía resolver el motor de SQL. Finalmente este era el verdadero problema: consultas que bloqueban "a saco" sin en menor control, aunque no implicaran UPDATES. Todo venía de un mal diseño en las vistas e instrucciones SQL que se enviaban desde el software. Conforme he ido cambiándolas, se han ido resolviendo los problemas de rendimiento.

    Problema solucionado.

    Sirva mi experiencia a otros administradores de BBDD. Controlar WITH (NOLOCK) en donde corresponda, transacciones READ UNCOMMITTED, etc.

    Gracias todos por vuestras sugerencias.

    jueves, 28 de julio de 2016 8:19