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

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

Reducir el Log de Transacciones.
http://www.helpdna.net/bosqlfaq01.htm


AMB

"Diego M® Romero" wrote:

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

Hola, eso funciona muy bien, de todas maneras te lo resumo asi:

use basededatos
Go

checkpoint
backup log base with truncate_only
DBCC SHRINKFILE(archivolog,tamaño)
Go

sp_helpdb basededatos


Salu2
Maxi


"Diego M® Romero" escribió en el mensaje
news:%
> 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

> 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

> 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

> 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

> 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

> 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,

> 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

> 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

> 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

> 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

> truncar el fichero, ya que SQL Server sólo puede reducirlo recortando

> el
> final.
>
>
> Supongamos que hay una estrategia de copia de seguridad que incluye

> completas y copias del log. En este caso son las copias del log las

> que truncan el registro de transacciones, por lo que si se ha ejecutado

> no
> DBCC SHRINKFILE, el registro no se truncará lógicamente hasta que se

> 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

> 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)

> 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
>
>
>
>
>

No se que estoy haciendo mal, pero no me funciona lo siguiente:
use dblog
Go
checkpoint
backup log dblog with truncate_only
DBCC SHRINKFILE('sbuLog')
Go

Lo siguiente, es la información de la base de datos:
1.
sbuLog C:\Archivos de programa\Microsoft SQL Server\MSSQL\Data\dbLog.mdf
PRIMARY 4544 KB Unlimited 10% data only
sbuLogLog
2 C:\Archivos de programa\Microsoft SQL Server\MSSQL\Data\dbLoglog.ldf
NULL 10920 KB Unlimited 10% log only

Agradezco me pueda dar un ejemplo.


Diego

"Maxi" escribió en el mensaje
news:
> Hola, eso funciona muy bien, de todas maneras te lo resumo asi:
>
> use basededatos
> Go
>
> checkpoint
> backup log base with truncate_only
> DBCC SHRINKFILE(archivolog,tamaño)
> Go
>
> sp_helpdb basededatos
>
>
> Salu2
> Maxi
>
>
> "Diego M® Romero" escribió en el mensaje
> news:%
> > 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
> >
> >
> >
> >
> >
>
>