Cómo se puede reducir el log

También puede estar ocurriendo algo que impida la reutilización del log.
Revisa los siguientes artículos:

- http://support.microsoft.com/kb/110139
- http://support.microsoft.com/kb/317375 (y sus enlaces relacionados)

En cuanto a lo de que no elimine archivos .trn antiguos, es un bug conocido.
Echa un vistazo al artículo
http://support.microsoft.com/defaul...us;Q303292

"Caminar sobre el agua y desarrollar software a partir de unas
especificaciones es fácil, si ambas están congeladas."
Edward V. Berard, ingeniero informático


"davidr" wrote in message
news:

Ya lo probé pero sigue creciendo. De hecho he puesto que borre los trn
anteriores a 1 hora pero no hace caso, los va acumulando (es un problema
menor porque con un bat los podría borrar). El log sigue creciendo. Estoy
actualizado al último parche de sql 2k..

"Carlos Sacristan" wrote:

Como te decía en el mensaje, esa periodicidad parece insuficiente para
evitar el crecimiento desmedido del log. Prueba a hacerlo cada menos
tiempo
(cada 6h, por ejemplo) hasta que des con la adecuada.

"Caminar sobre el agua y desarrollar software a partir de unas
especificaciones es fácil, si ambas están congeladas."
Edward V. Berard, ingeniero informático


"davidr" wrote in message
news:
> Se hace un backup de todos los logs una vez al día, concretamente a las
> 23:30h..
>
> "Carlos Sacristan" wrote:
>
>> ¿Cada cuánto se hace backup del log de esas bases de datos? Tal vez la
>> periodicidad no sea la adecuada para la carga que tiene. No soy
>> experto
>> en
>> Sharepoint, así que no sé qué recomendaciones se dan en ese sentido;
>> yo
>> buscaría algún documento oficial o información en algún blog fiable
>> (que
>> no
>> todos lo son) para implementar un correcto mantenimiento de las bases
>> de
>> datos de Sharepoint
>>
>>
>> "Caminar sobre el agua y desarrollar software a partir de unas
>> especificaciones es fácil, si ambas están congeladas."
>> Edward V. Berard, ingeniero informático
>>
>>
>> "davidr" wrote in message
>> news:
>> > También los hago. Te refieres a los TRN, ¿no?. Si es así también los
>> > hago
>> > y
>> > aún así me toca truncarlos.
>> > De las dos backups de las bds que no se hacen no me preocupa porque
>> > estoy
>> > copiando todo el directorio en cinta también.
>> > El log que más se llena es el de una base de datos de sharepoint.
>> > ¿Puede que tenga que ver el sharepoint para que aumente el log?.
>> > Muchas gracias.
>> >
>> > "Carlos Sacristan" wrote:
>> >
>> >> Pero no me refiero a backups completos, sino a backups del log.
>> >>
>> >> Revisa por qué no se pueden hacer backups de esas dos bases de
>> >> datos,
>> >> porque
>> >> el hecho de que tengan conexiones activas no implica que no se
>> >> pueda
>> >> realizar la operación
>> >>
>> >> "Caminar sobre el agua y desarrollar software a partir de unas
>> >> especificaciones es fácil, si ambas están congeladas."
>> >> Edward V. Berard, ingeniero informático
>> >>
>> >>
>> >> "davidr" wrote in message
>> >> news:
>> >> > Hago backups de las bases de datos todas las noches sin embargo
>> >> > dos
>> >> > de
>> >> > ellas
>> >> > no se hacen bien debido a que probablemente estén cogias, creo.
>> >> > Por
>> >> > ejemplo,
>> >> > una de ellas es la base de datos de sharepoint..
>> >> >
>> >> > "Carlos Sacristan" wrote:
>> >> >
>> >> >> El "parámetro" para controlar el log es administrarlo
>> >> >> adecuadamente,
>> >> >> lo
>> >> >> cual
>> >> >> se consigue haciendo backups del mismo con la periodicidad
>> >> >> adecuada.
>> >> >>
>> >> >> Si lo único que haces con el log es truncarlo, no tengas la base
>> >> >> de
>> >> >> datos
>> >> >> en
>> >> >> recuperación completa (o registro masivo): cámbiala a modo de
>> >> >> recuperación
>> >> >> sencillo (SIMPLE) y no tendrás esos problemas. A cambio perderás
>> >> >> la
>> >> >> posibilidad de recuperar la base de datos a un momento en el
>> >> >> tiempo
>> >> >> concreto
>> >> >> y estarás obligado a recuperarla siempre a partir de un backup
>> >> >> completo
>> >> >> (y
>> >> >> sus posibles backups diferenciales que hayas podido hacer)
>> >> >>
>> >> >> "Caminar sobre el agua y desarrollar software a partir de unas
>> >> >> especificaciones es fácil, si ambas están congeladas."
>> >> >> Edward V. Berard, ingeniero informático
>> >> >>
>> >> >>
>> >> >> "davidr" wrote in message
>> >> >> news:
>> >> >> > Hola a todos,
>> >> >> > tengo un servidor sql 2k y una serie de bases de datos
>> >> >> > montadas.
>> >> >> > Dos
>> >> >> > de
>> >> >> > hechas tienen un crecimiento bastante grande y el problema que
>> >> >> > tengo
>> >> >> > es
>> >> >> > que
>> >> >> > el archivo LDF se hace grande rápidamente y me quedo sin
>> >> >> > espacio
>> >> >> > físico.
>> >> >> > Haciendo BACKUP LOG NOMBRE_BD WITH NO LOG y luego reduciendo
>> >> >> > la
>> >> >> > base
>> >> >> > de
>> >> >> > datos
>> >> >> > NOMBRE_BD consigo reducir el LOG pero, me gustaría saber si
>> >> >> > puedo
>> >> >> > hacerlo
>> >> >> > automáticamente o existe algún parámetro para controlar el
>> >> >> > crecimiento
>> >> >> > del
>> >> >> > LOG.
>> >> >> >
>> >> >> > Gracias.
>> >> >>
>> >> >> .
>> >> >>
>> >>
>> >> .
>> >>
>>
>> .
>>

.

Carlos,
la base datos la tengo como full así que no tengo claro que el problema de
que me borre los TRN venga por ahí. Un detalle: si le digo que me borre los
TRN anteriores a un día lo hace bien pero, si por ejemplo le digo que borre
los anteriores a una hora no me hace ni caso.
De momento lo que he hecho es crear un bat para borrar los TRN todas las
noches y limitar el crecimiento del log a 120 megas. Al menos para que esta
noche no me pare por falta de espacio otros programas que tengo corriendo en
ese servidor.
Muchas gracias..

"Carlos Sacristan" wrote:

También puede estar ocurriendo algo que impida la reutilización del log.
Revisa los siguientes artículos:

- http://support.microsoft.com/kb/110139
- http://support.microsoft.com/kb/317375 (y sus enlaces relacionados)

En cuanto a lo de que no elimine archivos .trn antiguos, es un bug conocido.
Echa un vistazo al artículo
http://support.microsoft.com/defaul...us;Q303292

"Caminar sobre el agua y desarrollar software a partir de unas
especificaciones es fácil, si ambas están congeladas."
Edward V. Berard, ingeniero informático


"davidr" wrote in message
news:
> Ya lo probé pero sigue creciendo. De hecho he puesto que borre los trn
> anteriores a 1 hora pero no hace caso, los va acumulando (es un problema
> menor porque con un bat los podría borrar). El log sigue creciendo. Estoy
> actualizado al último parche de sql 2k..
>
> "Carlos Sacristan" wrote:
>
>> Como te decía en el mensaje, esa periodicidad parece insuficiente para
>> evitar el crecimiento desmedido del log. Prueba a hacerlo cada menos
>> tiempo
>> (cada 6h, por ejemplo) hasta que des con la adecuada.
>>
>> "Caminar sobre el agua y desarrollar software a partir de unas
>> especificaciones es fácil, si ambas están congeladas."
>> Edward V. Berard, ingeniero informático
>>
>>
>> "davidr" wrote in message
>> news:
>> > Se hace un backup de todos los logs una vez al día, concretamente a las
>> > 23:30h..
>> >
>> > "Carlos Sacristan" wrote:
>> >
>> >> ¿Cada cuánto se hace backup del log de esas bases de datos? Tal vez la
>> >> periodicidad no sea la adecuada para la carga que tiene. No soy
>> >> experto
>> >> en
>> >> Sharepoint, así que no sé qué recomendaciones se dan en ese sentido;
>> >> yo
>> >> buscaría algún documento oficial o información en algún blog fiable
>> >> (que
>> >> no
>> >> todos lo son) para implementar un correcto mantenimiento de las bases
>> >> de
>> >> datos de Sharepoint
>> >>
>> >>
>> >> "Caminar sobre el agua y desarrollar software a partir de unas
>> >> especificaciones es fácil, si ambas están congeladas."
>> >> Edward V. Berard, ingeniero informático
>> >>
>> >>
>> >> "davidr" wrote in message
>> >> news:
>> >> > También los hago. Te refieres a los TRN, ¿no?. Si es así también los
>> >> > hago
>> >> > y
>> >> > aún así me toca truncarlos.
>> >> > De las dos backups de las bds que no se hacen no me preocupa porque
>> >> > estoy
>> >> > copiando todo el directorio en cinta también.
>> >> > El log que más se llena es el de una base de datos de sharepoint.
>> >> > ¿Puede que tenga que ver el sharepoint para que aumente el log?.
>> >> > Muchas gracias.
>> >> >
>> >> > "Carlos Sacristan" wrote:
>> >> >
>> >> >> Pero no me refiero a backups completos, sino a backups del log.
>> >> >>
>> >> >> Revisa por qué no se pueden hacer backups de esas dos bases de
>> >> >> datos,
>> >> >> porque
>> >> >> el hecho de que tengan conexiones activas no implica que no se
>> >> >> pueda
>> >> >> realizar la operación
>> >> >>
>> >> >> "Caminar sobre el agua y desarrollar software a partir de unas
>> >> >> especificaciones es fácil, si ambas están congeladas."
>> >> >> Edward V. Berard, ingeniero informático
>> >> >>
>> >> >>
>> >> >> "davidr" wrote in message
>> >> >> news:
>> >> >> > Hago backups de las bases de datos todas las noches sin embargo
>> >> >> > dos
>> >> >> > de
>> >> >> > ellas
>> >> >> > no se hacen bien debido a que probablemente estén cogias, creo.
>> >> >> > Por
>> >> >> > ejemplo,
>> >> >> > una de ellas es la base de datos de sharepoint..
>> >> >> >
>> >> >> > "Carlos Sacristan" wrote:
>> >> >> >
>> >> >> >> El "parámetro" para controlar el log es administrarlo
>> >> >> >> adecuadamente,
>> >> >> >> lo
>> >> >> >> cual
>> >> >> >> se consigue haciendo backups del mismo con la periodicidad
>> >> >> >> adecuada.
>> >> >> >>
>> >> >> >> Si lo único que haces con el log es truncarlo, no tengas la base
>> >> >> >> de
>> >> >> >> datos
>> >> >> >> en
>> >> >> >> recuperación completa (o registro masivo): cámbiala a modo de
>> >> >> >> recuperación
>> >> >> >> sencillo (SIMPLE) y no tendrás esos problemas. A cambio perderás
>> >> >> >> la
>> >> >> >> posibilidad de recuperar la base de datos a un momento en el
>> >> >> >> tiempo
>> >> >> >> concreto
>> >> >> >> y estarás obligado a recuperarla siempre a partir de un backup
>> >> >> >> completo
>> >> >> >> (y
>> >> >> >> sus posibles backups diferenciales que hayas podido hacer)
>> >> >> >>
>> >> >> >> "Caminar sobre el agua y desarrollar software a partir de unas
>> >> >> >> especificaciones es fácil, si ambas están congeladas."
>> >> >> >> Edward V. Berard, ingeniero informático
>> >> >> >>
>> >> >> >>
>> >> >> >> "davidr" wrote in message
>> >> >> >> news:
>> >> >> >> > Hola a todos,
>> >> >> >> > tengo un servidor sql 2k y una serie de bases de datos
>> >> >> >> > montadas.
>> >> >> >> > Dos
>> >> >> >> > de
>> >> >> >> > hechas tienen un crecimiento bastante grande y el problema que
>> >> >> >> > tengo
>> >> >> >> > es
>> >> >> >> > que
>> >> >> >> > el archivo LDF se hace grande rápidamente y me quedo sin
>> >> >> >> > espacio
>> >> >> >> > físico.
>> >> >> >> > Haciendo BACKUP LOG NOMBRE_BD WITH NO LOG y luego reduciendo
>> >> >> >> > la
>> >> >> >> > base
>> >> >> >> > de
>> >> >> >> > datos
>> >> >> >> > NOMBRE_BD consigo reducir el LOG pero, me gustaría saber si
>> >> >> >> > puedo
>> >> >> >> > hacerlo
>> >> >> >> > automáticamente o existe algún parámetro para controlar el
>> >> >> >> > crecimiento
>> >> >> >> > del
>> >> >> >> > LOG.
>> >> >> >> >
>> >> >> >> > Gracias.
>> >> >> >>
>> >> >> >> .
>> >> >> >>
>> >> >>
>> >> >> .
>> >> >>
>> >>
>> >> .
>> >>
>>
>> .
>>

.

Ya, si el bug no hace referencia a que la base de datos no esté en modo
FULL, sino que al menos una de la base de datos del plan de mantenimiento
común esté en modo SIMPLE.

En cuanto al tamaño del log... ¿has mirado si tienes algún proceso que
impida la reutilización del mismo (replicación, transacción abierta, etc.),
tal y como detallan esos dos enlaces que te pasé ?

"Caminar sobre el agua y desarrollar software a partir de unas
especificaciones es fácil, si ambas están congeladas."
Edward V. Berard, ingeniero informático


"davidr" wrote in message
news:

Carlos,
la base datos la tengo como full así que no tengo claro que el problema de
que me borre los TRN venga por ahí. Un detalle: si le digo que me borre
los
TRN anteriores a un día lo hace bien pero, si por ejemplo le digo que
borre
los anteriores a una hora no me hace ni caso.
De momento lo que he hecho es crear un bat para borrar los TRN todas las
noches y limitar el crecimiento del log a 120 megas. Al menos para que
esta
noche no me pare por falta de espacio otros programas que tengo corriendo
en
ese servidor.
Muchas gracias..

"Carlos Sacristan" wrote:

También puede estar ocurriendo algo que impida la reutilización del log.
Revisa los siguientes artículos:

- http://support.microsoft.com/kb/110139
- http://support.microsoft.com/kb/317375 (y sus enlaces relacionados)

En cuanto a lo de que no elimine archivos .trn antiguos, es un bug
conocido.
Echa un vistazo al artículo
http://support.microsoft.com/defaul...us;Q303292

"Caminar sobre el agua y desarrollar software a partir de unas
especificaciones es fácil, si ambas están congeladas."
Edward V. Berard, ingeniero informático


"davidr" wrote in message
news:
> Ya lo probé pero sigue creciendo. De hecho he puesto que borre los trn
> anteriores a 1 hora pero no hace caso, los va acumulando (es un
> problema
> menor porque con un bat los podría borrar). El log sigue creciendo.
> Estoy
> actualizado al último parche de sql 2k..
>
> "Carlos Sacristan" wrote:
>
>> Como te decía en el mensaje, esa periodicidad parece insuficiente para
>> evitar el crecimiento desmedido del log. Prueba a hacerlo cada menos
>> tiempo
>> (cada 6h, por ejemplo) hasta que des con la adecuada.
>>
>> "Caminar sobre el agua y desarrollar software a partir de unas
>> especificaciones es fácil, si ambas están congeladas."
>> Edward V. Berard, ingeniero informático
>>
>>
>> "davidr" wrote in message
>> news:
>> > Se hace un backup de todos los logs una vez al día, concretamente a
>> > las
>> > 23:30h..
>> >
>> > "Carlos Sacristan" wrote:
>> >
>> >> ¿Cada cuánto se hace backup del log de esas bases de datos? Tal vez
>> >> la
>> >> periodicidad no sea la adecuada para la carga que tiene. No soy
>> >> experto
>> >> en
>> >> Sharepoint, así que no sé qué recomendaciones se dan en ese
>> >> sentido;
>> >> yo
>> >> buscaría algún documento oficial o información en algún blog fiable
>> >> (que
>> >> no
>> >> todos lo son) para implementar un correcto mantenimiento de las
>> >> bases
>> >> de
>> >> datos de Sharepoint
>> >>
>> >>
>> >> "Caminar sobre el agua y desarrollar software a partir de unas
>> >> especificaciones es fácil, si ambas están congeladas."
>> >> Edward V. Berard, ingeniero informático
>> >>
>> >>
>> >> "davidr" wrote in message
>> >> news:
>> >> > También los hago. Te refieres a los TRN, ¿no?. Si es así también
>> >> > los
>> >> > hago
>> >> > y
>> >> > aún así me toca truncarlos.
>> >> > De las dos backups de las bds que no se hacen no me preocupa
>> >> > porque
>> >> > estoy
>> >> > copiando todo el directorio en cinta también.
>> >> > El log que más se llena es el de una base de datos de sharepoint.
>> >> > ¿Puede que tenga que ver el sharepoint para que aumente el log?.
>> >> > Muchas gracias.
>> >> >
>> >> > "Carlos Sacristan" wrote:
>> >> >
>> >> >> Pero no me refiero a backups completos, sino a backups del log.
>> >> >>
>> >> >> Revisa por qué no se pueden hacer backups de esas dos bases de
>> >> >> datos,
>> >> >> porque
>> >> >> el hecho de que tengan conexiones activas no implica que no se
>> >> >> pueda
>> >> >> realizar la operación
>> >> >>
>> >> >> "Caminar sobre el agua y desarrollar software a partir de unas
>> >> >> especificaciones es fácil, si ambas están congeladas."
>> >> >> Edward V. Berard, ingeniero informático
>> >> >>
>> >> >>
>> >> >> "davidr" wrote in message
>> >> >> news:
>> >> >> > Hago backups de las bases de datos todas las noches sin
>> >> >> > embargo
>> >> >> > dos
>> >> >> > de
>> >> >> > ellas
>> >> >> > no se hacen bien debido a que probablemente estén cogias,
>> >> >> > creo.
>> >> >> > Por
>> >> >> > ejemplo,
>> >> >> > una de ellas es la base de datos de sharepoint..
>> >> >> >
>> >> >> > "Carlos Sacristan" wrote:
>> >> >> >
>> >> >> >> El "parámetro" para controlar el log es administrarlo
>> >> >> >> adecuadamente,
>> >> >> >> lo
>> >> >> >> cual
>> >> >> >> se consigue haciendo backups del mismo con la periodicidad
>> >> >> >> adecuada.
>> >> >> >>
>> >> >> >> Si lo único que haces con el log es truncarlo, no tengas la
>> >> >> >> base
>> >> >> >> de
>> >> >> >> datos
>> >> >> >> en
>> >> >> >> recuperación completa (o registro masivo): cámbiala a modo de
>> >> >> >> recuperación
>> >> >> >> sencillo (SIMPLE) y no tendrás esos problemas. A cambio
>> >> >> >> perderás
>> >> >> >> la
>> >> >> >> posibilidad de recuperar la base de datos a un momento en el
>> >> >> >> tiempo
>> >> >> >> concreto
>> >> >> >> y estarás obligado a recuperarla siempre a partir de un
>> >> >> >> backup
>> >> >> >> completo
>> >> >> >> (y
>> >> >> >> sus posibles backups diferenciales que hayas podido hacer)
>> >> >> >>
>> >> >> >> "Caminar sobre el agua y desarrollar software a partir de
>> >> >> >> unas
>> >> >> >> especificaciones es fácil, si ambas están congeladas."
>> >> >> >> Edward V. Berard, ingeniero informático
>> >> >> >>
>> >> >> >>
>> >> >> >> "davidr" wrote in message
>> >> >> >> news:
>> >> >> >> > Hola a todos,
>> >> >> >> > tengo un servidor sql 2k y una serie de bases de datos
>> >> >> >> > montadas.
>> >> >> >> > Dos
>> >> >> >> > de
>> >> >> >> > hechas tienen un crecimiento bastante grande y el problema
>> >> >> >> > que
>> >> >> >> > tengo
>> >> >> >> > es
>> >> >> >> > que
>> >> >> >> > el archivo LDF se hace grande rápidamente y me quedo sin
>> >> >> >> > espacio
>> >> >> >> > físico.
>> >> >> >> > Haciendo BACKUP LOG NOMBRE_BD WITH NO LOG y luego
>> >> >> >> > reduciendo
>> >> >> >> > la
>> >> >> >> > base
>> >> >> >> > de
>> >> >> >> > datos
>> >> >> >> > NOMBRE_BD consigo reducir el LOG pero, me gustaría saber si
>> >> >> >> > puedo
>> >> >> >> > hacerlo
>> >> >> >> > automáticamente o existe algún parámetro para controlar el
>> >> >> >> > crecimiento
>> >> >> >> > del
>> >> >> >> > LOG.
>> >> >> >> >
>> >> >> >> > Gracias.
>> >> >> >>
>> >> >> >> .
>> >> >> >>
>> >> >>
>> >> >> .
>> >> >>
>> >>
>> >> .
>> >>
>>
>> .
>>

.