Reducir archivo LOG

Hola
Como hago para reducir el LOG de transacciones de una base de datos, el
cual
ha crecido demasiado.
Ya hice lo que me dijeron aquí, pero no logro reducirlo:

Gracias

Diego

> Reducir el Log de Transacciones.

Soluciones rápidas al problema.

Hacer Backup del Log y reducir el fichero.

Ejecuta dos o tres veces la instrucción CHECKPOINT. Esto asegurará que
todas
las páginas de memoria se han escrito en el fichero de datos.
Luego haz un BACKUP LOG WITH TRUNCATE_ONLY para que trunque el registro de
transacciones.
Posteriormente ejecutas DBCC SHRINKFILE indicando el nombre del fichero
del
log a reducir.
(En la ayuda puedes ampliar información sobre estos dos mandatos).

Eliminar el fichero para que se genere de Nuevo (Esta solución es
demasiado
drástica, emplearla solo si falla la anterior):

Pon la base de datos en modo "single user".
Ejecuta CHECKPOINT dos o tres veces. Esto asegurará que todas las páginas
de
memoria se han escrito en el fichero de datos.
Asegúrate de que no hay conexiones abiertas a la base de datos, con lo que
no puede haber transacciones a medio ejecutar.
Utiliza sp_detach_db para desconectar dicha base de datos.
Elimina el fichero de log.
Utiliza sp_attach_db para reconectar la base de datos. SQL Server creará
un
nuevo fichero de log.
¡¡¡ IMPORTANTE !!!
Si no ejecutas el proceso completamente y en este orden, podrías tener
problemas de consistencia de información en el fichero de datos.
Por ejemplo, si apagas el equipo sin más, SQL Server no ha tenido tiempo
de
volcar las páginas de datos de la memoria al disco. Al reiniciar SQL
Server,
el problema será corregido utilizando la información contenida en el
registro de transacciones, pero si este no está presente, el archivo de
datos se dará por bueno, y podría ser realmente inconsistente.

Otro detalle importante a tener en cuenta es que el log no se limpia nunca
completamente, ya que siempre hay operaciones internas que SQL Server
necesita mantener en él.


Causas habituales del crecimiento del Log.

Si el log ha crecido mucho es porque SQL Server lo ha necesitado. Esto es
debido a una de las siguientes causas:

Eso es lo que normalmente sucede y se debería ajustar la estrategia de
backup para hacer copias del log más a menudo.
Si el crecimiento del log se debe a una ejecución (insert, update, delete)
que afecta a un gran número de registros, bien por haber lanzado un
proceso
de actualización masiva o porque alguien ha ejecutado una consulta mal
formada, que habría que detectarla (y darle un tirón de orejas al que la
haya enviado).
Las copias completas de la base de datos no truncan el registro de
transacciones. Utiliza una estrategia de copia de seguridad que mezcle
copias completas de la base de datos con copias del registro de
transacciones.

Puedes detectar las consultas enviadas a SQL Server con el Profiler.

No debes borrar el registro de transacciones manualmente salvo causa de
fuerza mayor. Lo que debes hacer es diseñar una estrategia de copia de
seguridad que sea acorde con el volumen de transacciones que tiene tu
sistema.

Problemas habituales que impiden reducir el tamaño del Log.

Los pasos para truncar el Transaction log pueden no ser tan obvios como
pueda parecer:

El registro de transacciones está compuesto por al menos dos registros
virtuales (VLF = Virtual Log Files). El truncado del registro de
transacciones se realiza VLF a VLF. Si sólo tienes dos registros virtuales
y
te ocupan todo el fichero no podrás truncarlo, aunque dudo que cada VLF
llegue a ocupar mucho espacio. (Para ampliar información sobre este punto,
consulta en la ayuda 'Trucar el Registro de transacciones', encontrarás
información detallada y un gráfico muy explicativo).

Al ejecutar una instrucción DBCC SHRINKFILE solo se le indica a SQL Server
que se quiere reducir el tamaño físico del fichero de LOG. Si el último
VLF
está al final del log, aunque el resto del fichero esté vacío, no se podrá
truncar el fichero, ya que SQL Server sólo puede reducirlo recortando por
el
final.


Supongamos que hay una estrategia de copia de seguridad que incluye copias
completas y copias del log. En este caso son las copias del log las únicas
que truncan el registro de transacciones, por lo que si se ha ejecutado o
no
DBCC SHRINKFILE, el registro no se truncará lógicamente hasta que se haga
una copia de seguridad del log (o se ejecute BACKUP LOG TuBase WITH
TRUNCATE_ONLY).

Sin embargo si el último VLF no está completo, no se podrá truncar, por lo
que se tendrá que forzar su llenado. Al ejecutar DBCC LOGINFO(TuBase) se
obtendrá una lista de VLF, si te fijas en la columna Status, 2 significa
que
no está activo o que al menos no es reutilizable. Envía alguna
actualizaciones nulas (UPDATE TuTabla SET Campo1 = Campo1, por ejemplo) y
vuelve a ejecutar el comando DBCC LOGINFO hasta que veas que hay algún
otro
VLF con status 2.

Ahora si que se puede ejecutar el BACKUP LOG para truncar el LOG y tras
esto
SQL
Server podrá recortar el fichero físicamente eliminando uno o más VLFs.


Enlaces con información de Microsoft sobre el tema.

INF: Cómo reducir el registro de transacciones de SQL Server.


A consultar en los Books On Line y ampliar información:

DBCC SHRINKFILE
DBCC SHRINKDATABASE
DBCC LOGINFO
BACKUP LOG
sp_attach_db
sp_detach_db