Mi templog.ldf es enorme (45 gb). ¿Qué debo hacer si hay algo?

Tengo una instalación de SQL 2005 y mi archivo templog.ldf sigue creciendo para consumir todo el espacio libre en la unidad en la que se encuentra. A veces se detendrá con unos pocos MB libres, pero a veces va más allá, siendo este el disco c, creo que este comportamiento puede estar implicado en algunos otros problemas que he estado viendo.

Mi pregunta es, ¿qué debo hacer? Puedo mover el registro a otra unidad, pero tengo razones para suponer que no hará lo mismo allí. Supongo que este comportamiento es probable como resultado de algo que puedo cambiar y que 45 gb es un tamaño inusual para que llegue el registro tempdb. Usamos muchas tablas temporales y funciones con valores de tabla en nuestro código, por lo que hay muchas posibilidades de usar tempdb, puedo entender el crecimiento de la base de datos tempdb pero no entiendo la razón del crecimiento del templog.

Hasta ahora, he ejecutado DBCC OPENTRAN ('tempdb') para ver si alguna transacción anterior está pendiente, no es así. He leído sobre cómo reducir el tempdb y lo he hecho varias veces, pero realmente me pregunto qué puedo hacer para evitar que esto suceda en primer lugar o más detalles sobre por qué podría estar creciendo tanto en El primer lugar.

== EDITOS ==

1) El tempdb está usando un modelo de recuperación simple

2) El crecimiento en el registro temporal se produce durante un par de horas en la mañana cuando tenemos algunas consultas programadas en ejecución, básicamente una carga de informes que se queda sin horario de oficina para el día siguiente. El tamaño del archivo crece constantemente durante este tiempo. Controlamos cuántos informes simultáneos se ejecutan al mismo tiempo, al aumentar la cantidad de informes simultáneos aumenta la velocidad a la que crece el registro.

Verifique sus consultas de informes. ¿Tienes alguno que tenga DISTINCT en ellos? ¿Alguno de ellos tiene una unión cartesiana?

¿Alguna de las consultas de informes accede a los servidores vinculados como miembros de una unión? Si es así, esto puede hacer que el registro tempdb y la base de datos crezcan.

Cuando los informes se ejecutan en la mañana, ¿alguno de ellos falla?

Tuvimos un problema similar, después de haber llamado PSS a Microsoft y de haber investigado a fondo el problema, hemos dividido la siguiente causa y resolución posibles.

Porque:

La causa probable de los síntomas se debe a los discos / lun en los que se colocan las bases de datos de los usuarios que tienen problemas graves de respuesta de E / S; Esto hace que el punto de control automático en las bases de datos de los usuarios tarde mucho en finalizar.

Ahora, el punto de control en tempdb ocurre solo cuando el registro de tempdb se llena en un 70% y también tiene una prioridad menor que los puntos de control de la base de datos del usuario. Por lo tanto, de manera efectiva cuando se emite un punto de control automático en la base de datos del usuario y se está intentando completar, debido al uso intensivo de tempdb, el archivo de registro tempdb se llena rápidamente; con un 70% de uso de registro, se produce el punto de control tempdb pero se pone en cola detrás del punto de control de la base de datos del usuario.

En el tiempo que tarda el punto de control de la base de datos del usuario en finalizar, el archivo de registro tempdb se sigue llenando y, si se establece el crecimiento automático, el archivo de registro crece cuando requiere más espacio. Esta es la razón por la cual el archivo de registro sigue creciendo.

En resumen, la causa raíz más posible de los síntomas que describe se debe a una respuesta de E / S deficiente de los discos / lun para su usuario y / o archivos de registro / base de datos tempdb.

Solución:

Resolvimos el problema mientras solucionábamos el subsistema de E / S configurando una alerta que se disparó cuando el archivo de registro tempdb se llenó en un 75% y, en respuesta, ejecutó un trabajo que forzó un "PUNTO DE CONTROL" manual (que tiene prioridad sobre el sistema automático puntos de control), borrando el registro tempdb evitando que crezca automáticamente indefinidamente. Todavía es una buena idea dejar el archivo de registro en crecimiento automático para cualquier otra eventualidad. Además, le recomiendo encarecidamente que considere reducir el tamaño del archivo de registro tempdb a algo significativo según su entorno después de aplicar la corrección.

Espero que esto ayude.

¿Cuál es el modelo de recuperación establecido en la base de datos temporal? Si no está configurado en Simple, configúrelo en Simple. Esto debería evitar que crezca. Si ya está configurado en Simple, entonces diría que hay un problema subyacente que debe abordarse y cualquier intento de reducir el archivo es simplemente tratar los síntomas del problema y no la causa raíz.

He pasado las últimas horas leyendo y tomando notas sobre esto

http://technet.microsoft.com/en-gb/library/cc966545.aspx

Hay muchos detalles allí y sugerencias para resolver problemas. Parece que a menos que su tempdb se expanda y nunca deje de crecer, probablemente solo esté ocupando la cantidad de espacio que necesita y debería haberse configurado inicialmente para tener ese tamaño. Hay una sección sobre la estimación del espacio requerido para su tempdb, así como el seguimiento de lo que podría estar ocupando espacio en tempdb. Como resultado de esto, lo primero que voy a hacer es mover tempdb a un disco más grande y ver qué pasa desde allí.

Hay una sección titulada 'Espacio requerido para el registro de tempdb' que indica qué características usan el registro, hay otra sección anterior que detalla el superconjunto de características que usan tempdb.

La sección titulada 'Monitoreo de E / S' tiene algunas ideas sobre los contadores de rendimiento para ver, un vistazo rápido a mi servidor los colocó en el territorio que probablemente tenga un cuello de botella. Los monitorearé por un tiempo y veré cómo funcionan las cosas. El archivo de registro tempdb también tenía menos del 50% de utilización, lo que encaja con la idea de que se expandió bajo carga esta mañana y ha retenido ese espacio desde entonces.

Continúo sobre la base de que el tamaño al que crece es el tamaño que necesita ser, controle este tamaño en el futuro y asegúrese de que haya espacio para el crecimiento en cualquier unidad en la que se encuentre. Según lo sugerido por algunos aquí, analizaré lo que se está ejecutando a medida que el registro temporal se expande y veré si hay algo que pueda modificarse allí. También vigilaré esos contadores de rendimiento de io para ver si hay que lidiar con algo.

Hubo otra sección interesante adicional titulada 'Actualización a SQL Server 2005' que indica que tempdb se usa para más cosas en 2005 que en 2000 (ambas características nuevas y características existentes que anteriormente no usaban tempdb). Recientemente me actualicé a 2005, por lo que esto podría ser parte de la razón por la que esto se ha convertido de repente en un problema. Sin embargo, no recuerdo haber visto esto en ningún otro lugar con referencia a la actualización a 2005, lo cual es un poco doloroso.

Esto es probablemente causado por una consulta Cross Join fuera de control. Su mejor opción es usar Profiler para encontrarlo y luego arreglarlo.

La otra forma de encontrarlo es restringir el tamaño del archivo de registro TempDB y luego esperar para ver qué consulta falla. Sin embargo, apuesto que está ya fallando y nadie le está diciendo.

Si reinicia el motor SQL, el archivo se establecerá en el tamaño inicial. Debe poner un tamaño máximo en todos sus archivos de crecimiento automático.

Algunas consultas SQL o procesos almacenados están haciendo cosas malas: lo único que puede hacer es crear un perfil de tempdb para capturar el evento "Base de datos: crecimiento automático del archivo de registro", y cuando eso suceda, use el generador de perfiles y consultas en tablas como sysprocesses para encontrar ¿Cuál es el mal proceso?

Desafortunadamente, se debe al trabajo de detectives a la antigua para rastrear el proceso deshonesto.

¿Has intentado cambiar el tamaño de los archivos de registro tempdb con DBCC SHRINKFILE ()? Si es así, ¿cuánto tiempo lleva pasar de [valor muy pequeño] a 45 GB o más?