Log de transacciones
Tengo un problema con el log de transacciones.
Tengo una base de datos a la cual se le había asignado para la 2GB Y PARA EL LOG 6GB, DESDE DICIEMBRE he tenido el problema QUE se me ha venido creciendo el log de forma potencial. A finales de diciembre lo crecí a 10 gb, ES LA HORA QUE ACTUALMENTE ESTA EN 16GB POR QUE CONSTANTEMENTE ME HA TOCADO CRECERLO YA QUE SQL ME LO HA PEDIDO.
No entiendo por que si en 12 mese no lo aumente de 6gb ahora en menos de dos meses me ha tocado crecerlo 10gb.
Para optimizar esto, cuando aumento el tamaño del log, simultáneamente le HE R realizADO un backup al log de transacciones PERO NO ME HA FUNCIONADO.
¿Cómo puedo hacer para que esto no me vuelva a pasar durante un tiempo, o como puedo optimizar la base de datos para solucionar esto?
C
¿Cómo puedo disminuir el tamaño del log para que quede más de acuerdo a la que esta ocuppando, se puede o no hacer esto?
Tengo una base de datos a la cual se le había asignado para la 2GB Y PARA EL LOG 6GB, DESDE DICIEMBRE he tenido el problema QUE se me ha venido creciendo el log de forma potencial. A finales de diciembre lo crecí a 10 gb, ES LA HORA QUE ACTUALMENTE ESTA EN 16GB POR QUE CONSTANTEMENTE ME HA TOCADO CRECERLO YA QUE SQL ME LO HA PEDIDO.
No entiendo por que si en 12 mese no lo aumente de 6gb ahora en menos de dos meses me ha tocado crecerlo 10gb.
Para optimizar esto, cuando aumento el tamaño del log, simultáneamente le HE R realizADO un backup al log de transacciones PERO NO ME HA FUNCIONADO.
¿Cómo puedo hacer para que esto no me vuelva a pasar durante un tiempo, o como puedo optimizar la base de datos para solucionar esto?
C
¿Cómo puedo disminuir el tamaño del log para que quede más de acuerdo a la que esta ocuppando, se puede o no hacer esto?
1 respuesta
Respuesta de kaleta
1
Voy a dar por sentado que estás usando SQL Server 2000 y que el modelo de recuperación es "Full Recovery Model", o sea el que más operaciones registra en el transaction log.
Cualquier cosa corregime...
1.- Haces un backup del transaction log. Supongamos que la base de datos es Clientes (y que esa nomenclatura se mantiene en los archivos de log... bla, bla)
En el Query Analyzer ejecutás:
BACKUP LOG Clientes TO disk='E:\SQLBackup\CLientes_Log.bkp'
Y ahora tenés un backup del transaction log sin truncarlo.
2.- También en el Query Analyzer:
DBCC ShrinkFile (Contracts, tamaño)
Tamaño corresponde al que desearías que tenga el transaction log. Por ejemplo: si fijás tamaño = 20 correspondería reducir el log a 20 MBytes.
No es la única forma pero si es la que no pierde información de backup.
Con el paso 1 solo queda la porción ACTIVA del log y con el paso 2 compactas el archivo físico.
En cuanto al resto de las dudas, primero probá esto y después seguimos si quieres.
Me voy a trabajar y vuelvo en unas horas, contame como te fue...
Cualquier cosa corregime...
1.- Haces un backup del transaction log. Supongamos que la base de datos es Clientes (y que esa nomenclatura se mantiene en los archivos de log... bla, bla)
En el Query Analyzer ejecutás:
BACKUP LOG Clientes TO disk='E:\SQLBackup\CLientes_Log.bkp'
Y ahora tenés un backup del transaction log sin truncarlo.
2.- También en el Query Analyzer:
DBCC ShrinkFile (Contracts, tamaño)
Tamaño corresponde al que desearías que tenga el transaction log. Por ejemplo: si fijás tamaño = 20 correspondería reducir el log a 20 MBytes.
No es la única forma pero si es la que no pierde información de backup.
Con el paso 1 solo queda la porción ACTIVA del log y con el paso 2 compactas el archivo físico.
En cuanto al resto de las dudas, primero probá esto y después seguimos si quieres.
Me voy a trabajar y vuelvo en unas horas, contame como te fue...
Lo que sucede es que el tamaño del log se me esta creceindo de un día para otro y me toca cambiarlo, como puedo auditar para saber que operación me esta llenendo el registro, en esta semana he aumentado el tamaño del log en dos ocasiones, y le he aumentado de 1gb, eso no debería ser así.
El transaction log registra las operaciones de la base de datos, si crece mucho es porque esa base de datos tiene mucha actividad. ¿Cuál es la actividad que más lo hace crecer? Y, por ejemplo la sentencia SELECT INTO, BULK INSERT, la carga masiva de datos (DTS, bcp), creación de índices, etc...
¿Cómo podes reducir el tamaño?
Cambiando de "Recovery Model" a Bulk Logged que no lleva registro de las actividades que te cité (y de otras cuantas referidas a campos ntext, por ej.) Aún así servirá para un backup/restore
Y si ya no querés que lleve registro de nada, elegí el modelo "Simple Recovery" que trunca el log cada vez que una operación se realiza exitosamente. Eso si: no sirve para un backup. No la recomiendo.
¿Y entonces? Probá mi sugerencia original. Si funciona correctamente, definí un JOB con esas instrtucciones y crea un SCHEDULE para que lo realice varias veces al día o cuando el servidor esré IDLE...
Alguien o algo está modificando o cargando muchos datos continuamente en esa base de datos. Si aún seguís intrigado con QUE ES LO QUE PASA podes usar el SQL SERVER PROFILER para que registre toda la actividad de esa base de datos y puedas darte cuenta de lo que está pasando. Es artesanal a menos que puedas cazar alguna instrucción sospechosa al vuelo!
Ahora si, me voy a trabajar! :-)
¿Cómo podes reducir el tamaño?
Cambiando de "Recovery Model" a Bulk Logged que no lleva registro de las actividades que te cité (y de otras cuantas referidas a campos ntext, por ej.) Aún así servirá para un backup/restore
Y si ya no querés que lleve registro de nada, elegí el modelo "Simple Recovery" que trunca el log cada vez que una operación se realiza exitosamente. Eso si: no sirve para un backup. No la recomiendo.
¿Y entonces? Probá mi sugerencia original. Si funciona correctamente, definí un JOB con esas instrtucciones y crea un SCHEDULE para que lo realice varias veces al día o cuando el servidor esré IDLE...
Alguien o algo está modificando o cargando muchos datos continuamente en esa base de datos. Si aún seguís intrigado con QUE ES LO QUE PASA podes usar el SQL SERVER PROFILER para que registre toda la actividad de esa base de datos y puedas darte cuenta de lo que está pasando. Es artesanal a menos que puedas cazar alguna instrucción sospechosa al vuelo!
Ahora si, me voy a trabajar! :-)
