Es normal el tamaño del LDF

13/09/2005 - 19:55 por Jorge A. Forti A. | Informe spam
Saludos al grupo.
Es normal que el archivo LDF mida 25GB y el MDF solo 68MB?

Si me pueden orientar porque pasa esto para mejorar mis tablas.

Gracias de antemano

Preguntas similare

Leer las respuestas

#1 bajopalabra
13/09/2005 - 21:09 | Informe spam
en este foro
me dijeron que debería ser entre el 20 y 30%
y que depende mucho de las consultas/procesos
que tengas
es recomendable limpiar el log periódicamente
mira buckup log truncate, shrink ... etc
y mira también dbcc sqlperf(logspace)


atte, Hernán

"Jorge A. Forti A." escribió en el mensaje
news:
Saludos al grupo.
Es normal que el archivo LDF mida 25GB y el MDF solo 68MB?

Si me pueden orientar porque pasa esto para mejorar mis tablas.

Gracias de antemano


Respuesta Responder a este mensaje
#2 Alejandro Mesa
13/09/2005 - 23:43 | Informe spam
es recomendable limpiar el log periódicamente
mira buckup log truncate, shrink ... etc



Eso no es recomendable, lo que es recomendable es escojer el modelo de
recuperacion correcto y en caso de este ser FULL o BULK_LOGGED, hacer backup
del archivo de transacciones con mas frecuencia para que la parte inactiva se
limpie y la activa pueda seguir creciendo dentro del archivo. Aunque sea
tedioso, lo importante es tratar que el log no crezca mas alla de lo
necesario. Si usas "backup log truncate" entonces no te interesa hacer backup
del log de transacciones y por tanto seria mejor usar el modelo de
recuperacion SIMPLE (no recomendado en base de datos en produccion). Si lo
encojes, este volvera a crecer y este crecimiento consume recursos e influye
en el rendimento de tu bd. Si sql server hace crecer el log de transacciones
durante una operacion costosa, entonces la demora sera mayor.


AMB

"bajopalabra" wrote:

en este foro
me dijeron que debería ser entre el 20 y 30%
y que depende mucho de las consultas/procesos
que tengas
es recomendable limpiar el log periódicamente
mira buckup log truncate, shrink ... etc
y mira también dbcc sqlperf(logspace)


atte, Hernán

"Jorge A. Forti A." escribió en el mensaje
news:
> Saludos al grupo.
> Es normal que el archivo LDF mida 25GB y el MDF solo 68MB?
>
> Si me pueden orientar porque pasa esto para mejorar mis tablas.
>
> Gracias de antemano
>
>



Respuesta Responder a este mensaje
#3 Alejandro Mesa
13/09/2005 - 23:50 | Informe spam
Jorge,

Que modelo de recuperacion (recovery model) usa tu bd?

Ejemplo:

select databasepropertyex(N'northwind', 'Recovery')

Si la respuesta es ''FULL", entonces la proxima pregunta seria:

Con que frequencia haces backup del log de transacciones?


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

How to stop the transaction log of a SQL Server database from growing
unexpectedly
http://support.microsoft.com/?kbid‡3235


AMB

"Jorge A. Forti A." wrote:

Saludos al grupo.
Es normal que el archivo LDF mida 25GB y el MDF solo 68MB?

Si me pueden orientar porque pasa esto para mejorar mis tablas.

Gracias de antemano



Respuesta Responder a este mensaje
#4 bajopalabra
14/09/2005 - 00:39 | Informe spam
hola
buena forma de desasnarme en este tema
perdón por el mal consejo
alejandro, por qué es necesario backupear el log ?
conviene dejarlo con crecimiento ilimitado ?
es entonces un buen porcentaje 20 - 30 % del mdf, para el archivo ldf
yo, por lo visto, estoy usando método FULL

( pd: voy a leer esos links )


atte, Hernán

"Alejandro Mesa" escribió en el
mensaje news:
> es recomendable limpiar el log periódicamente
> mira buckup log truncate, shrink ... etc

Eso no es recomendable, lo que es recomendable es escojer el modelo de
recuperacion correcto y en caso de este ser FULL o BULK_LOGGED, hacer


backup
del archivo de transacciones con mas frecuencia para que la parte inactiva


se
limpie y la activa pueda seguir creciendo dentro del archivo. Aunque sea
tedioso, lo importante es tratar que el log no crezca mas alla de lo
necesario. Si usas "backup log truncate" entonces no te interesa hacer


backup
del log de transacciones y por tanto seria mejor usar el modelo de
recuperacion SIMPLE (no recomendado en base de datos en produccion). Si lo
encojes, este volvera a crecer y este crecimiento consume recursos e


influye
en el rendimento de tu bd. Si sql server hace crecer el log de


transacciones
durante una operacion costosa, entonces la demora sera mayor.


AMB

"bajopalabra" wrote:

> en este foro
> me dijeron que debería ser entre el 20 y 30%
> y que depende mucho de las consultas/procesos
> que tengas
> es recomendable limpiar el log periódicamente
> mira buckup log truncate, shrink ... etc
> y mira también dbcc sqlperf(logspace)
>
>
> atte, Hernán
>
> "Jorge A. Forti A." escribió en el mensaje
> news:
> > Saludos al grupo.
> > Es normal que el archivo LDF mida 25GB y el MDF solo 68MB?
> >
> > Si me pueden orientar porque pasa esto para mejorar mis tablas.
> >
> > Gracias de antemano
> >
> >
>
>
>
Respuesta Responder a este mensaje
#5 Alejandro Mesa
14/09/2005 - 16:43 | Informe spam
bajopalabra,

Voy a tratar de dar una explicacion simple a un tema bien complicado pero
muy importante de sql server. El log de transacciones contiene un registro
serial de todas las transacciones ejecutadas contra la bd. Este no guarda la
informacion de las filas / columnas, sino la sentencia usada para manipular
la bd (sin contar la sentencia select). EL archivo de transacciones esta
dividido logicamente por pequeños segmentos llamados archivos de log
virtuales y son la unidad usada para truncar el log. Existe una parte activa
(transacciones que no se les ha hecho commit o roll back, o que no se han
escrito hacia el disco) y una parte inactiva (lo contrario) la cual puede
ser reusada cuando la activa la necesita, siempre y cuando se haya hecho un
backup de ellas si el modelo de recuperacion en uso lo requiere. Cuando
trabajamos con un modelo de recuperacion "simple", la parte inactiva es y
truncada automaticamente despues de cada "checkpoint" (por favor leer en los
libros en linea). Cuando estamos usando un modelo "bulk_logged" o "full",
esta parte inactiva no se reusa sin antes hacerle un backup al log de
transacciones, y por lo tanto el archivo de transacciones seguira creciendo
porque sql server no puede reusar la parte inactiva. Estos backups deben
tener una secuencia, la cual que si se rompe dejeria inutil los backups.

Si el archivo log crecio demasiado por falta de backups del log y ademas no
es importante para la persona o institucion mantener esta secuencia de
backups del archivo de transaccion, entonces podemos usar:

backup log nombre_de_la_bd with truncate_only

pero en caso contrario debemos hacer el backup y si es necesario, usar "dbcc
shrinkfile" para achicar el archivo. Si hacemos los backups del log con mas
frecuencia, entonces la parte inactiva puede ser reusada con mas frecuencia y
por tanto el log no crecera demasiado (este crece cuando no tiene mas parte
inactiva para reusar). El log de transacciones puede crecer por diversos
motivos, asi que achicarlo no garantiza que sql server lo haga crecer
nuevamente cuando lo necesite y esta operacion es costosa, sobre todo porque
sql server lo puede hacer en medio de una carga fuerte sobre el servidor. Lo
practico seria darle un tamanio adecuado y tratar de que este no cresca mas
de lo necesario mediante backups, transacciones cortas, etc.

Vamos a oner un ejemplo:

Tenemos un log con cinco log virtuales. Sql server ha usado tres de ellos,
antes de usar el cuarto hacemos un backup de log (marca los tres primeros
para ser reusados), asi que cuando usamos el cuarto, los tres primeros ya
pueden ser reusados. Usamos el quinto y sql server regresa al primero para
ser reusado, completa los tres primeros y como no hay mas para reusar, hace
crecer el log. Mientras no hagamos backup del log, no se podra reusar mas la
parte inactiva y el log seguira y seguira creciendo.

Recuerda, esto solo pasa cuando usamos los modelos de recuperacion
"bulk_logged" o "full" porque para ellos es importante tener un backup
continuo de la secuencia de transacciones en caso de querer restaurar la base
de datos hasta un punto especifico..

Espero te ayude la explicacion.


AMB

"bajopalabra" wrote:

hola
buena forma de desasnarme en este tema
perdón por el mal consejo
alejandro, por qué es necesario backupear el log ?
conviene dejarlo con crecimiento ilimitado ?
es entonces un buen porcentaje 20 - 30 % del mdf, para el archivo ldf
yo, por lo visto, estoy usando método FULL

( pd: voy a leer esos links )


atte, Hernán

"Alejandro Mesa" escribió en el
mensaje news:
> > es recomendable limpiar el log periódicamente
> > mira buckup log truncate, shrink ... etc
>
> Eso no es recomendable, lo que es recomendable es escojer el modelo de
> recuperacion correcto y en caso de este ser FULL o BULK_LOGGED, hacer
backup
> del archivo de transacciones con mas frecuencia para que la parte inactiva
se
> limpie y la activa pueda seguir creciendo dentro del archivo. Aunque sea
> tedioso, lo importante es tratar que el log no crezca mas alla de lo
> necesario. Si usas "backup log truncate" entonces no te interesa hacer
backup
> del log de transacciones y por tanto seria mejor usar el modelo de
> recuperacion SIMPLE (no recomendado en base de datos en produccion). Si lo
> encojes, este volvera a crecer y este crecimiento consume recursos e
influye
> en el rendimento de tu bd. Si sql server hace crecer el log de
transacciones
> durante una operacion costosa, entonces la demora sera mayor.
>
>
> AMB
>
> "bajopalabra" wrote:
>
> > en este foro
> > me dijeron que debería ser entre el 20 y 30%
> > y que depende mucho de las consultas/procesos
> > que tengas
> > es recomendable limpiar el log periódicamente
> > mira buckup log truncate, shrink ... etc
> > y mira también dbcc sqlperf(logspace)
> >
> >
> > atte, Hernán
> >
> > "Jorge A. Forti A." escribió en el mensaje
> > news:
> > > Saludos al grupo.
> > > Es normal que el archivo LDF mida 25GB y el MDF solo 68MB?
> > >
> > > Si me pueden orientar porque pasa esto para mejorar mis tablas.
> > >
> > > Gracias de antemano
> > >
> > >
> >
> >
> >



email Siga el debate Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaRespuesta Tengo una respuesta
Search Busqueda sugerida