Cómo se puede reducir el log

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.

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.

.

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.

.

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

.

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

.