none
LOG MUY GRANDE RRS feed

  • Pregunta

  • ¿Hay alguna manera de eliminar el log de transacciones muy grande?. El log alcanza casi un terabyte actualmente, y cada vez que se intenta comprimir el log incrementa en lugar de disminuir. Se ha intentado separar pero al adjuntar la base de datos sin el log marca error de incoherencia en paginas. En un reinicio de instancia inicializar la base de datos tarda aproximandamente 3.5 hrs. 

    ISC. MARTIN GUADALUPE MARTINEZ HERNÁNDEZ

    lunes, 11 de julio de 2016 17:16

Respuestas

  • En una base de datos normal y corriente, es absurdo que el log crezca de semejante manera. ¿No será que la tienes en modo Full Recovery y que no estás haciendo los backups del Log? Si es así (no haces backups del Log) entonces cámbiala al modo de recuperación Simple (se puede cambiar en vivo sin parar el funcionamiento). Una vez que esté en modo Simple, puedes usar la opcíón Shrink desde SSMS para reducir el tamaño del log.

    • Marcado como respuesta José De Alva viernes, 15 de julio de 2016 22:30
    lunes, 11 de julio de 2016 19:43
  • Saludos

    La unica manera de truncat el log de transacciones es por medio de un transactional log backup (con base en un full backup) y hacerlo con truncate, lo que puedes estar haciendo es que cuando haces shirnk al mover la data estas disparando el auto growth del log causando que cresca de una manera desmedida he visto este comportamiento cuando tienen auto-shirnk y crecimiento empiezan a "competir"

    Lo que te dice Alberto es correcto, si no haces los backups de transacciones mejor pasala a Simple, mucho de lo que estas intententado causa corrupción y perderas todo.

    Mas informacion

    http://sqlservertoolbox.blogspot.mx/2015/01/liberar-espacio-del-transactional-log.html  

    • Marcado como respuesta José De Alva viernes, 15 de julio de 2016 22:31
    martes, 12 de julio de 2016 3:47
  • El problema real se presento según el estatus actual por bugs de sql server 2014.

    Inicialmente se experimento con un problema a similar a

    El registro de transacciones para la base de datos ' <nombre de la base de datos>' está lleno debido a 'LOG_BACKUP'.

    Referencia: 

    https://support.microsoft.com/es-es/kb/3095156

    Se instalo la versión acumulativa 3 del service pack 1 (Se tenia instalado el Service Pack 1 versión acumulativa 2), se logra reducir la base de datos y a partir de ese momento ya no se puede reducir más.

    La base de datos que con el mensaje "La columna log_wait_desc muestra XTP_CHECKPOINT"

    El log se empieza incrementar drasticamente ya que tenia activado el shrink automático, se deshabilita para que el log siga creciendo, sin embargo con cada intento de shrink ya sea con modo simple o modo full recovery el log se incrementaba exponencialmente, de igual manera se deshabilito.

    Se hacen pruebas con las copias de seguridad de la base de datos de separar la base de datos para volver a adjuntar y que sql server intente crear nuevamente el archivo ldf, prueba sin éxito con mensaje de error "el numero de paginas de los archivos ldf y mdf no coinciden", esta prueba deja inservible el archivo mdf.

    Se inicia el trabajo de crear scripts en base de datos de prueba para migrar la base de datos objeto por objeto, prueba realizada con éxito. Por lo cual se decide aplicar en la base de datos de producción.

    En últimos días sale el articulo https://support.microsoft.com/es-mx/kb/3108147 donde se menciona que el estatus de la base de  datos  que se tiene se puede deber a un problema propio de SQL SERVER, mencionando instalar el service pack 2 (Saliendo el día 7/10/2016)

    Se realiza la instalación en un ambiente de prueba y se logra reducir sin problema el LOG, al aplicar el comando DBCC CHECK después marca errores de coherencia en algunas tablas, pero sin perdida de información. 

    Por lo cual podemos llegar a la conclusión de:

    Si se experimenta los siguientes Síntomas:

    1. No se puede reducir la base de datos ni con full recovery, ni modo simple

    2. Se experimenta problemas con "El registro de transacciones para la base de datos ' <nombre de la base de datos>' está lleno debido a 'LOG_BACKUP'"

    3. El LOG crece de manera exponencial

    4. El status de la base de datos esta en XTP_CHECKPOINT, aun aplicando varias veces el comando CHECKPOINT.

    5. El coordinador de transacciónes distribuidas se colapsa por lo cual hay que reiniciar el equipo

    6. En el reinicio de la instancia el tiempo de espera es muy alto para que se ponga en LINEA la base de datos.

    7. Se experimenta el mensaje de error "no hay suficiente espacio disponible"

    8. Copiar base de datos no funciona.

    9. La base de datos queda en RESTAURACIÓN.

    Solución:

    1. Deshabilitar las transacciones muy grandes y proceder con los demás pasos, y hasta concluir con el paso 5 (Considerar consultas por POWER PIVOT, Transacciones altamente costosas y largas, Consultas con alto consumo de información).

    2. Verificar que se tenga deshabillitado la propiedad de AUTOSHRINK dentro de la base de datos

    3. Realizar constantemente backup para asegurar los datos.

    4. Instalar el service pack 2 de SQLSERVER (Verificar día a día si no hay una actualización nueva del SQL SERVER)

    5. Dependerá del tamaño de la base de datos, pero si despues de instalar el service pack 2 de SQLSERVER y aplicar el comando SHRINK  se reduce el LOG pero aplicando el DBCC CHECK tiene incoherencia de datos u objetos, lo recomendable sera hacer un proceso de migración.

    6. Es considerable revisar constantemente las consultas costosas recientes y las consultas de costosas activas y mejorarlas para evitar el crecimiento del LOG.


    ISC. MARTIN GUADALUPE MARTINEZ HERNÁNDEZ


    sábado, 16 de julio de 2016 16:21

Todas las respuestas

  • En una base de datos normal y corriente, es absurdo que el log crezca de semejante manera. ¿No será que la tienes en modo Full Recovery y que no estás haciendo los backups del Log? Si es así (no haces backups del Log) entonces cámbiala al modo de recuperación Simple (se puede cambiar en vivo sin parar el funcionamiento). Una vez que esté en modo Simple, puedes usar la opcíón Shrink desde SSMS para reducir el tamaño del log.

    • Marcado como respuesta José De Alva viernes, 15 de julio de 2016 22:30
    lunes, 11 de julio de 2016 19:43
  • Gracias por Responder, la base que tiene el problema es productiva y su nivel de transaccionalidad es muy alto. Sin embargo el problema radica cuando se aplica el comando shrink debido a que en lugar de reducir se incrementa el tamaño de log. Ya se realizo con full recovery aplicando un backup del log y haciendo el shrink y con modo simple aplicando el shrink.

    No se puede reducir el archivo de registro 2 (mibase_log) porque no hay el espacio mínimo de registro necesario.

    Dado que se experimenta el mismo problema con la base de datos desde hace unos días, se esta comando como base una copia cuando el log cuando estaba en 180 GB dentro de un servidor de prueba con un 1TB de espacio y nos marca el mismo error. 


    ISC. MARTIN GUADALUPE MARTINEZ HERNÁNDEZ

    martes, 12 de julio de 2016 0:25
  • Saludos

    La unica manera de truncat el log de transacciones es por medio de un transactional log backup (con base en un full backup) y hacerlo con truncate, lo que puedes estar haciendo es que cuando haces shirnk al mover la data estas disparando el auto growth del log causando que cresca de una manera desmedida he visto este comportamiento cuando tienen auto-shirnk y crecimiento empiezan a "competir"

    Lo que te dice Alberto es correcto, si no haces los backups de transacciones mejor pasala a Simple, mucho de lo que estas intententado causa corrupción y perderas todo.

    Mas informacion

    http://sqlservertoolbox.blogspot.mx/2015/01/liberar-espacio-del-transactional-log.html  

    • Marcado como respuesta José De Alva viernes, 15 de julio de 2016 22:31
    martes, 12 de julio de 2016 3:47
  • El problema real se presento según el estatus actual por bugs de sql server 2014.

    Inicialmente se experimento con un problema a similar a

    El registro de transacciones para la base de datos ' <nombre de la base de datos>' está lleno debido a 'LOG_BACKUP'.

    Referencia: 

    https://support.microsoft.com/es-es/kb/3095156

    Se instalo la versión acumulativa 3 del service pack 1 (Se tenia instalado el Service Pack 1 versión acumulativa 2), se logra reducir la base de datos y a partir de ese momento ya no se puede reducir más.

    La base de datos que con el mensaje "La columna log_wait_desc muestra XTP_CHECKPOINT"

    El log se empieza incrementar drasticamente ya que tenia activado el shrink automático, se deshabilita para que el log siga creciendo, sin embargo con cada intento de shrink ya sea con modo simple o modo full recovery el log se incrementaba exponencialmente, de igual manera se deshabilito.

    Se hacen pruebas con las copias de seguridad de la base de datos de separar la base de datos para volver a adjuntar y que sql server intente crear nuevamente el archivo ldf, prueba sin éxito con mensaje de error "el numero de paginas de los archivos ldf y mdf no coinciden", esta prueba deja inservible el archivo mdf.

    Se inicia el trabajo de crear scripts en base de datos de prueba para migrar la base de datos objeto por objeto, prueba realizada con éxito. Por lo cual se decide aplicar en la base de datos de producción.

    En últimos días sale el articulo https://support.microsoft.com/es-mx/kb/3108147 donde se menciona que el estatus de la base de  datos  que se tiene se puede deber a un problema propio de SQL SERVER, mencionando instalar el service pack 2 (Saliendo el día 7/10/2016)

    Se realiza la instalación en un ambiente de prueba y se logra reducir sin problema el LOG, al aplicar el comando DBCC CHECK después marca errores de coherencia en algunas tablas, pero sin perdida de información. 

    Por lo cual podemos llegar a la conclusión de:

    Si se experimenta los siguientes Síntomas:

    1. No se puede reducir la base de datos ni con full recovery, ni modo simple

    2. Se experimenta problemas con "El registro de transacciones para la base de datos ' <nombre de la base de datos>' está lleno debido a 'LOG_BACKUP'"

    3. El LOG crece de manera exponencial

    4. El status de la base de datos esta en XTP_CHECKPOINT, aun aplicando varias veces el comando CHECKPOINT.

    5. El coordinador de transacciónes distribuidas se colapsa por lo cual hay que reiniciar el equipo

    6. En el reinicio de la instancia el tiempo de espera es muy alto para que se ponga en LINEA la base de datos.

    7. Se experimenta el mensaje de error "no hay suficiente espacio disponible"

    8. Copiar base de datos no funciona.

    9. La base de datos queda en RESTAURACIÓN.

    Solución:

    1. Deshabilitar las transacciones muy grandes y proceder con los demás pasos, y hasta concluir con el paso 5 (Considerar consultas por POWER PIVOT, Transacciones altamente costosas y largas, Consultas con alto consumo de información).

    2. Verificar que se tenga deshabillitado la propiedad de AUTOSHRINK dentro de la base de datos

    3. Realizar constantemente backup para asegurar los datos.

    4. Instalar el service pack 2 de SQLSERVER (Verificar día a día si no hay una actualización nueva del SQL SERVER)

    5. Dependerá del tamaño de la base de datos, pero si despues de instalar el service pack 2 de SQLSERVER y aplicar el comando SHRINK  se reduce el LOG pero aplicando el DBCC CHECK tiene incoherencia de datos u objetos, lo recomendable sera hacer un proceso de migración.

    6. Es considerable revisar constantemente las consultas costosas recientes y las consultas de costosas activas y mejorarlas para evitar el crecimiento del LOG.


    ISC. MARTIN GUADALUPE MARTINEZ HERNÁNDEZ


    sábado, 16 de julio de 2016 16:21