none
TEMPDB - Crecimiento exagerado RRS feed

  • Pregunta

  • Buenas a todos

    Tengo el siguiente escenario. Tengo mi servidor instalado Win Server 2008 particionado en 3 partes,

    C: de 100Gb para SO y SQL SErver 2008 R2

    D: 300GB para mis .mdf

    F: 100Gb para mis .ldf

     

    LA cuestion es la siguiente.

    Las bases de datos del SQL se quedaron en el disco C: entre ellos la TEMPDB

    AL ejecutar un proceso empieza a crecer hasta que me salta el siguiente mensaje de error:

         "The transaction log for database 'tempdb' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases"

    Entiendo que esto es por que quedó sin espacio físico mi disco C:. COnste que tenía 65GB de espacio libre antes de ejecutar un proceso.

     

    Bueno, lo que hice fué mover mi base TEMPDB de la siguiente manera

    TEMPDB.mdf -->> al disco D: con espacio libre de 265gb

    TEMPLOG.ldf-->> al disco F: con espacio libre de 80GB

     

    Vuelvo a ejecutar mi proceso y nuevamente vuelve a llenar mi DISCO D: en esta caso mi TEMPDB llega a los 265GB de tamano.

     

    El proceso utiliza una base de datos X dentro de mi servidor 2008, a ésta base se conecta un CUBO de Analysis Services que se encuentra en otro servidor y que esta en Versión 2000.

     

    Puedo activar la casilla AUTOSHRINK a mi TEMPDB??

     

    Desde ya GRACIAS!


    José Barrios
    jueves, 17 de noviembre de 2011 20:57

Respuestas

  • Hola.

    No, el problema no es el cubo, si no el ETL para cargar el relacional del cubo. Migrar el cubo a SSAS 2008 R2 te ayudará enormemente en cuestiones de rendimiento, por ejemplo, además de que pasarás a estar en una versión de SQL Server soportada (y SQL Server 2000 no lo es), pero no hay motivo para pensar que la migración resuelva el problema, porque no tiene pinta de ser el procesamiento del cubo lo que causa el crecimiento desmedido de tempdb.


    Alberto López Grande
    SQL Server MVP
    Visita mi blog en http://qwalgrande.blogspot.es/ Sígueme en twitter en http://twitter.com/qwalgrande

    • Marcado como respuesta José Barrios sábado, 19 de noviembre de 2011 14:25
    viernes, 18 de noviembre de 2011 20:06
    Moderador

Todas las respuestas

  • Hola.

    Habría que revisar la carga de ese cubo o del ETL del mismo. Seguramente tengas algún cruce con merge, ordenaciones u otras cosas parecidas que hagan que se haga un uso extensivo de la base de datos tempdb. Activar la opción AUTOSHRINK no te ayudará en nada porque no se puede reducir (está ocupada).

    Sin saber más detalles de ese proceso, sólo podemos sugerirte cuestiones generales a revisar en el proceso (merge, ordenaciones, etc.).


    Alberto López Grande
    SQL Server MVP
    Visita mi blog en http://qwalgrande.blogspot.es/ Sígueme en twitter en http://twitter.com/qwalgrande

    jueves, 17 de noviembre de 2011 21:12
    Moderador
  • Hola José. Primero que todo, compartenos el proceso que hace que la TEMPDB crezca desmesuradamente, por favor.

    Gracias y saludos,

     

     


    Guillermo Taylor F.

    IT Pro & Xbox gamer

    My blog

    jueves, 17 de noviembre de 2011 21:14
  • Jose, utilizar los comandos DBCC SHRINKDATABASE y DBCC SHRINKFILE, sobre la TEMPDB con actividad en TEMPDB puede implicar que no se pueda reducir TEMPDB o bien pueden producirse errores que tampoco permitan reducir TEMPDB con éxito. Además, mientras se está reduciendo SHRINK TEMPDB es posible que se generen bloqueos sobre otras transacciones que necesiten acceder a TEMPDB.
     Norman M. Pardell 

    ||Microsoft Certified IT Professional|| Database Administrator. Database Developer. SQL Server 2008

    viernes, 18 de noviembre de 2011 12:11
  • Buenas antes de seguir me gustaría hacer otra consulta sobre alguna posible solución... leyendo en algunos de los foros de aqui se explaya que una de las mejores practicas es la de dividir en mi base TEMPDB. http://social.msdn.microsoft.com/Forums/es-ES/sqlserveres/thread/855c1f90-3d67-4baf-adb7-4c530ab6ba1a Ya que cuento con un procesador de 4núcleos y 10Gb de RAM podría devidir en 4 archivos mi base TEMPDB. me serviría eso?? Saludos Gracias!
    José Barrios
    viernes, 18 de noviembre de 2011 13:31
  • Norman Gracias por tu respuesta! Me ha quedado claro lo que comentas. Saludos
    José Barrios
    viernes, 18 de noviembre de 2011 13:34
  • Eso puede ayudarte, por supuesto, si logras ubicar que hay contención por TEMPDB. Con la información que nos das es difícil validar esto, pero tu podrías hacerlo con una Data Management View que revise esto como sys.dm_os_waiting_tasks y validar que no te salgan PageLatch o PageIOLatch y verificando ésto, tal vez si te ayude lo del numero de archivos para TEMPDB. No podría decir cuantos archivos, porque se necesita conocer algunos parámetros de tu sistema, pero si nos los compartes, con seguridad te apoyamos.

    En el TechEd Norteamérica, http://northamerica.msteched.com/, de este año hubo una sesión muy buena de este tema, orientada hacia SQL Server 2008 R2 y 2012, pero que puede ayudarte... Se titulaba algo así como Tuning and Optimization; si la buscas en el catálogo, la encuentras en el track de bases de datos.

    Saludos,

     

     


    Guillermo Taylor F.

    IT Pro & Xbox gamer

    My blog

    viernes, 18 de noviembre de 2011 13:43
  • Voy a aplicar la particion y tedigo que tal me va. Saludos
    José Barrios
    viernes, 18 de noviembre de 2011 14:47
  •  Además de cambiar el tamaño inicial de TEMPDB es muy recomendable aumentar el número de ficheros de TEMPDB, a poder ser un fichero por cada CPU, con el objetivo de maximizar la afinidad de CPU, esto es facilitar que puedan paralelizarse operaciones de entrada/salida (IOs) y así obtener una mejora de rendimiento. Claro está, que si cada fichero pudiese estar en un disco diferente, y cada uno de estos discos se accediese a través de un camino (path) de fibra distinto (es decir, diferentes puertos de fibra de las HBAs), estaríamos facilitando al máximo la optimización del acceso a disco de TEMPDB.

      Por ejemplo, Si tenemos una máquina con 8 CPUs y necesitamos 8 GB de TEMPDB, la recomendación que deberíamos seguir es configurar TEMPDB con 8 ficheros de datos, cada uno de ellos con un tamaño inicial de 1GB.
     
     si no sabemos cuánto puede crecer, no le pongas restricción de tamaño. Ponle que crezca automáticamente, de 100 en 100 Mb, hasta que tengas un tamaño fijado basándote en el comportamiento y las necesidades del servidor, dependerá de cómo evolucione, pueden ser 2Gb, 10 o 40. Si lo limitas a 2Gb, en cuanto se alcance ese tamaño, tu servidor empezará a fallarte. Cuando ya tengas un tamaño más establecido, el que sea, entonces ya sí puedes dejarlo fijo, si así lo estimas, aunque previamente a eso tendrás que establecer un sistema de alertas que te permita detectar con suficiente margen de tiempo que esta base de datos está alcanzando su límite de tamaño.

     Norman M. Pardell 

    ||Microsoft Certified IT Professional|| Database Administrator. Database Developer. SQL Server 2008



    • Editado Normannp viernes, 18 de noviembre de 2011 14:56
    viernes, 18 de noviembre de 2011 14:54
  • Norman, tengo un servidor que tiene cuatro CPUS osea cuatro archivos para mi TEMPDB debería crear no? en cuanto al tamaño inicial en que me baso? Espacio en disco ?
    José Barrios
    viernes, 18 de noviembre de 2011 15:25
  • Numero de archivos pone 4, en general la regla es 1 por CPU pero nunca superando un limite de 8 o 16 (segun el autor varía). Pero en tu caso sería 4.

    El tamaño inicial ponele algo a ojo que segun tu experiencia funcione en el dia a dia obviando este caso, lo importante no es el inicial sino el crecimiento. Es una muy mala practica ponerle autogrow con porcentaje, sino que debes ponerle un autogrow indicando algun numero fijo, por ejemplo 256Mb.

    Una vez terminado el proceso esta bueno controlar como quedaron los archivos porque no es bueno que queden de diferentes tamaños (así como al comienzo debes setear a todos en el mismo tamaño inicial)


    Lic. Andrés M. Aiello | DBA MS SQL - Oracle | http://aiellodba.blogspot.com | @AndresAiello
    viernes, 18 de noviembre de 2011 18:54
  • Hola.

    En cualquier caso, José, ten claro que dividir el fichero de datos de TEMPDB en cuatro ficheros NO resolverá tu problema de crecimiento desmedido. Eso es una cuestión de cierta relevancia, pero sin duda menor que el asunto principal, que además no quedará resuelto porque además de la división hay que concretar el tamaño, y justamente es el tamaño lo que no conocemos, ya que un proceso hace crecer de forma desproporcionada la base de datos.

    Danos detalles de ese problema, el otro ya tendrás tiempo de abordarlo y además no podrás cerrarlo hasta que no solventes el grave.


    Alberto López Grande
    SQL Server MVP
    Visita mi blog en http://qwalgrande.blogspot.es/ Sígueme en twitter en http://twitter.com/qwalgrande

    viernes, 18 de noviembre de 2011 19:12
    Moderador
  • LIC. ANDRES, gracias por su respuesta. Me ha sido de mucha importancia. ALBERTO a modo de detallarte mas el escenario: Tengo un CUBO en Analysis Services 2000 en un servidor "A" que se conecta a una base de datos "BASE1", ésta base se encuentra alojada en el servidor "B" donde tengo mi SQL2008R2. En el server "A" está programado un job que se encarga de ejecutar un DTS y éste a su vez lo que hace es procesar mi cubo en el servidor "A". Durante el proceso la base de datos TEMPDB del servidor "B" es la que crece en forma desmedida, sin embargo en el server "A" donde se ejcuta el cubo no es asi. Si me indicas que tipo de detalles necesitan solo me avisan y veré de proveerlos para tener mayor información. GRACIAS por su tiempo!
    José Barrios
    viernes, 18 de noviembre de 2011 19:49
  • Hola.

    Sí, hacen falta conocer los detalles del DTS, qué es lo que hace y cómo lo hace, porque es lo que está generando el problema. Revisa lo que atañe al servidor B en ese paquete. Te comenté a modo de sugerencia general que revisaras la presencia de ordenaciones de tablas de gran tamaño, cruces merge, etc. Pero pueden ser muchas otras cosas.


    Alberto López Grande
    SQL Server MVP
    Visita mi blog en http://qwalgrande.blogspot.es/ Sígueme en twitter en http://twitter.com/qwalgrande

    viernes, 18 de noviembre de 2011 20:01
    Moderador
  • Por otro lado, tendría alguna incidencia el hecho de que haga intractuar diferentes versiones de SQL y AS en mis dos servidores. Ya que en uno como dige anteriormente tengo SQL 2000 y en el otro 2008R2. Si migro mi cubo a 2008 seguiré ayudará a solucionarlo?
    José Barrios
    viernes, 18 de noviembre de 2011 20:02
  • Hola.

    No, el problema no es el cubo, si no el ETL para cargar el relacional del cubo. Migrar el cubo a SSAS 2008 R2 te ayudará enormemente en cuestiones de rendimiento, por ejemplo, además de que pasarás a estar en una versión de SQL Server soportada (y SQL Server 2000 no lo es), pero no hay motivo para pensar que la migración resuelva el problema, porque no tiene pinta de ser el procesamiento del cubo lo que causa el crecimiento desmedido de tempdb.


    Alberto López Grande
    SQL Server MVP
    Visita mi blog en http://qwalgrande.blogspot.es/ Sígueme en twitter en http://twitter.com/qwalgrande

    • Marcado como respuesta José Barrios sábado, 19 de noviembre de 2011 14:25
    viernes, 18 de noviembre de 2011 20:06
    Moderador
  • Alberto, hemos podido salvar esta situación, lo que hice fue verificar las tablas que utiliza, en este caso las más grandes y he ingresado a mi cubo y lo volví reindexar. Una vez finalizado esto volví a ejecutar mi CUBO y funcionó sin problemas. Y mi base TEMPDB ya no crece en forma desmedida.

     

    MUCHAS GRACIAS A TODOS POR LA AYUDA!!!

    SALUDOS!


    José Barrios
    sábado, 19 de noviembre de 2011 14:25
  • Ya que estamos en hilo, y me parece interesante, añadir mas cosas se almacenan en la tempdb y la pueden hacer crecer: tablas temporales locales o globales, variables de tabla o cursores, (en lo que atañe a Objetos de usuarios). tambien Objetos internos creados por el Motor de base de datos de SQL Server como por ejemplo, tablas de trabajo para almacenar resultados intermedios para obtener  GROUP BY, ORDER BY o UNION de una cosnulta... Tambien hacen crecer la temdb, si se tiene activado en alguna base de datos el versionado de filas (row versioning) o el aislamiento de instantáneas. Así como conjuntos de resultados de múltiples MARS y desencadenadores AFTER. Operaciones de combinación hash o de agregado hash. O incluso Resultados de orden intermedio de operaciones como crear o volver a generar índices (si se ha especificado SORT_IN_TEMPDB

     Norman M. Pardell 

    ||Microsoft Certified IT Professional|| Database Administrator. Database Developer. SQL Server 2008

    sábado, 19 de noviembre de 2011 22:20
  • Hola José.

    Yo tengo SQL Server 2008 R2 trabajando con Dynamics AX4 y otras bases de datos de diferentes app, cambie ya TEMPDB a otro drive y si le doy mas espacio, mas espacio consume (si le doy 50 GB se los come, si le doy 250 GB se los come), como puedo saber que es lo que hace que crezca tan desmedidamente a tal grado que me tira Dynamics y tengo que reiniciar el servidor!!! Ayuda....

    martes, 8 de octubre de 2013 17:00