SQL Server, archivo de log muy grande

Zuljin

Zuljin

Fundador
Miembro del Equipo
Fundador
ADMIN
Se incorporó
15 Enero 2004
Mensajes
11.880
Cabros, de SQL Server cacho pocazo, así que denme una mano.

Tengo una base de datos SQL Server que consume 107 GB, de los cuales 1Gb corresponde a data y 106 GB a Transaction Logs.

Evidentemente alguna cosa no está funcionando bien, porque no es normal esto. Sin embargo, no se como bajar el tamaño de los Transaction Logs.

La Base de datos tiene Recovery Model Full.

¿Algún dato?

Gracias
 
Sort by date Sort by votes
Harima

Harima

Pegao al tarro
Se incorporó
15 Mayo 2008
Mensajes
3.962
si te lo quieres cargar asi
Código: 
USE AdventureWorks2008R2;
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE AdventureWorks2008R2
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (AdventureWorks2008R2_Log, 1);
GO
-- Reset the database recovery model.
ALTER DATABASE AdventureWorks2008R2
SET RECOVERY FULL;
GO

para entender un poco mas y como configurar el tamaño para que no cresca infinitamente lee esto y esto
 
Upvote 0
Zuljin

Zuljin

Fundador
Miembro del Equipo
Fundador
ADMIN
Se incorporó
15 Enero 2004
Mensajes
11.880
@Harima ¿truncar? ¿Así de shoro?
La base tiene respaldos pero entiendo que los respaldos deberían automáticamente ir limpiando los transaction logs (sorry, estoy pensando en modo Oracle). ¿Es correcta mi suposición?
 
Upvote 0
Harima

Harima

Pegao al tarro
Se incorporó
15 Mayo 2008
Mensajes
3.962
A lo shoro no más, SQL es de juguete comparado con Oracle, además que los logs en SQL valen champiñon, es mas saludable hacer un full diario que tratar de ponerse a hacer las cosas en modo Oracle.
 
Upvote 0
Zuljin

Zuljin

Fundador
Miembro del Equipo
Fundador
ADMIN
Se incorporó
15 Enero 2004
Mensajes
11.880
Harima dijo:
A lo shoro no más, SQL es de juguete comparado con Oracle, además que los logs en SQL valen champiñon, es mas saludable hacer un full diario que tratar de ponerse a hacer las cosas en modo Oracle.
Haz clic para expandir...

Vale. Voy a intentar eso. Un snapshot a la máquina virtual + un respaldo al volumen en el storage y me largo a hacer lo que me dices. Si fallo porfa recibe mi currículum vitae :bncry
 
Upvote 0
Harima

Harima

Pegao al tarro
Se incorporó
15 Mayo 2008
Mensajes
3.962
Zuljin dijo:
Vale. Voy a intentar eso. Un snapshot a la máquina virtual + un respaldo al volumen en el storage y me largo a hacer lo que me dices. Si fallo porfa recibe mi currículum vitae :bncry
Haz clic para expandir...
jajaja hace un backup a la bd y listo, no le pongai tanto colorsh
 
Upvote 0
fercas

fercas

Papá de Fercas JR
Se incorporó
11 Junio 2005
Mensajes
744
Zuljin, truncar el log sin saber las causas del aumento no es bueno, ya que si no detectas el problema de raíz volverá a aumentar y será pega en vano.

Revisa el tipo de crecimiento de la base, generalmente los autogrow muy pequeños generan aumentos significativos en el log.

Lo otro, revisa si tienes backup de log, eso debería vaciar el log y dejar que crezca demasiado.
Saludos

Enviado desde mi XT1058 mediante Tapatalk
 
Upvote 0
Zuljin

Zuljin

Fundador
Miembro del Equipo
Fundador
ADMIN
Se incorporó
15 Enero 2004
Mensajes
11.880
fercas dijo:
Zuljin, truncar el log sin saber las causas del aumento no es bueno, ya que si no detectas el problema de raíz volverá a aumentar y será pega en vano.

Revisa el tipo de crecimiento de la base, generalmente los autogrow muy pequeños generan aumentos significativos en el log.

Lo otro, revisa si tienes backup de log, eso debería vaciar el log y dejar que crezca demasiado.
Saludos

Enviado desde mi XT1058 mediante Tapatalk
Haz clic para expandir...

¿Influye si la base de datos está en modo Recovery Model: full ? Porque otros modos son Recovery Model: Simple y Recovery Model: Bulk Logged.
 
Upvote 0
fercas

fercas

Papá de Fercas JR
Se incorporó
11 Junio 2005
Mensajes
744
En full esta bien. Tienes backup transaccionales? Con que frecuencia se realizan?.

Los backup transaccionales deberían vaciar el log de transacciones.
Saludos

Enviado desde mi XT1058 mediante Tapatalk
 
Upvote 0
G

Gen1us

VCP
Se incorporó
16 Octubre 2012
Mensajes
1.358
No es llegar y truncar un LOG sin saber cual es su función, averigua si se está respaldando, por qué no han truncado el log y si es posible dejar este en modo simple (Después del commit se borra la línea del log).

Slds
 
Upvote 0
Zuljin

Zuljin

Fundador
Miembro del Equipo
Fundador
ADMIN
Se incorporó
15 Enero 2004
Mensajes
11.880
fercas dijo:
En full esta bien. Tienes backup transaccionales? Con que frecuencia se realizan?.

Los backup transaccionales deberían vaciar el log de transacciones.
Saludos

Enviado desde mi XT1058 mediante Tapatalk
Haz clic para expandir...

Se realizan una vez al día. Los respaldos los realizamos con una herramienta de respaldos general, que tiene plugins para cada producto: respaldo de oracle, respaldo de SQL Server, Respaldo de Vmware, respaldo de exchange, etc. Entonces hay que meterle mano a la configuración del respaldo de cada producto.

De repente me falta activarle una o dos cosas al respaldo de SQL Server para que automáticamente me limpie los transactions logs. Voy a leer la documentación de la herramienta sobre los respaldos de SQL Server.
 
Upvote 0
Sago7

Sago7

Tibetan Mod
Miembro del Equipo
MOD
Se incorporó
5 Julio 2006
Mensajes
6.157
De que es la base de datos?.
El truncar me parece q no funciona en full. Yo he tenido q cambiar a simple y recién ahí realizar la operación.

Sent from my XT1040
 
Upvote 0
fercas

fercas

Papá de Fercas JR
Se incorporó
11 Junio 2005
Mensajes
744
Zuljin dijo:
Se realizan una vez al día. Los respaldos los realizamos con una herramienta de respaldos general, que tiene plugins para cada producto: respaldo de oracle, respaldo de SQL Server, Respaldo de Vmware, respaldo de exchange, etc. Entonces hay que meterle mano a la configuración del respaldo de cada producto.

De repente me falta activarle una o dos cosas al respaldo de SQL Server para que automáticamente me limpie los transactions logs. Voy a leer la documentación de la herramienta sobre los respaldos de SQL Server.
Haz clic para expandir...
No conozco es herramienta, pero si hace backup transaccionales, debe limpiar automáticamente el log, no debes configurar nada. Revisa si se esta haciendo efectivamente un backup del log.

Ojo, en sql server hay 3 tipos de backup:
Full, diferencial y log. El full y el diff no truncan el log y ojo, este truncate es automático.

Revisa si necesitas point in time restore. Sólo en ese caso necesitan un recovery modelo full. Si hacen sólo full backups y no les importa perder Info en caso de desastre, pueden cambiarse a un recovery simple y así soluciona el crecimiento del log.

Si necesitas point in time y solo tienes backup full, igual perderás la data del día. Necesitas backup log para un restore sin pérdidas de datos.

Por último, un buen DBA no propone truncar log, porque genera más problemas que soluciones.

Al truncar el log pierdes el sln chain de los backup diff y transacciones y ahí dejas la pura pata.

Saludos




Enviado desde mi XT1058 mediante Tapatalk
 
Upvote 0
fercas

fercas

Papá de Fercas JR
Se incorporó
11 Junio 2005
Mensajes
744
Harima dijo:
A lo shoro no más, SQL es de juguete comparado con Oracle, además que los logs en SQL valen champiñon, es mas saludable hacer un full diario que tratar de ponerse a hacer las cosas en modo Oracle.
Haz clic para expandir...
Para mi, sql server no es de juguete. Por que opinas así? No vale decir que sql 6 o 7 eran malos. Desde 2008 en adelante es un monstruo.



Enviado desde mi XT1058 mediante Tapatalk
 
Upvote 0
Zuljin

Zuljin

Fundador
Miembro del Equipo
Fundador
ADMIN
Se incorporó
15 Enero 2004
Mensajes
11.880
fercas dijo:
No conozco es herramienta, pero si hace backup transaccionales, debe limpiar automáticamente el log, no debes configurar nada. Revisa si se esta haciendo efectivamente un backup del log.

Ojo, en sql server hay 3 tipos de backup:
Full, diferencial y log. El full y el diff no truncan el log y ojo, este truncate es automático.

Revisa si necesitas point in time restore. Sólo en ese caso necesitan un recovery modelo full. Si hacen sólo full backups y no les importa perder Info en caso de desastre, pueden cambiarse a un recovery simple y así soluciona el crecimiento del log.

Si necesitas point in time y solo tienes backup full, igual perderás la data del día. Necesitas backup log para un restore sin pérdidas de datos.

Por último, un buen DBA no propone truncar log, porque genera más problemas que soluciones.

Al truncar el log pierdes el sln chain de los backup diff y transacciones y ahí dejas la pura pata.

Saludos




Enviado desde mi XT1058 mediante Tapatalk
Haz clic para expandir...

Estoy viendo que la herramienta tiene configurados puros backups full de tipo VDI. Le agregué unos respaldos del transaction log que automágicante limpian el log.

If you selected a Backup Type of Transaction log, use the Transaction log options frame to specify whether the inactive portion of the log must be truncated:

Normal – Select this option if you want the plug-in to truncate the inactive portion of the log file and make it available for re-use. This is the default for Transaction log backups.

No Truncate – Select this option to avoid truncation of the log during backup. Selecting this option is equivalent to performing a Tail-Log backup.


Ahora largué un respaldo full y luego voy a tirar ese respaldo incremental, que según dice la documentación hace la magia de limpiar la parte inactiva del log file y lo deja disponible para reusarlo.
 
Upvote 0
fercas

fercas

Papá de Fercas JR
Se incorporó
11 Junio 2005
Mensajes
744
Me o ofrezco a arreglar su te queda la cagada. Con pizzas soy Feliz

Enviado desde mi XT1058 mediante Tapatalk
 
Upvote 0
You must log in or register to reply here.
Subir