ARCHIVO LOG

Hola!! es muy malo eso!! jamas debes hacerlo porque se podrian pinchar las
cosas.

Lo que deberias hacer es ver porque crece pero no limitar nada de nada!! ni
la BDD tampoco, y tambien podes hacer un mantenimiento diario para reduccion
del Log y listo.


Salu2
Maxi
Buenos Aires Argentina
Desarrollador Microsoft 3 Estrellas .NET
[Maxi_accotto[arroba]speedy[punto]com[punto]ar
MSN:


"Maricarmen" escribió en el mensaje
news:

Hola el dia de ayer puse un post para preguntar sobre como truncar el

archivo de transacciones, gracias a Maximiliano y Ulises que me dieron una
gran ayuda, todo salió bien, pude truncar el archivo y reducir su tamaño,
pero ahora me queda una última duda que espero me puedan responder y es que
con este problema he pensado que a lo mejor seria conveniente no dejar que
el archivo de transacciones crezca es decir no configurarle el
autocrecimiento, es bueno o malo hacer esto? o es mejor dejar el
autocrecimiento activado y ponerle un tope de hasta donde va a poder crecer
este archivo.

Gracias por sus respuestas

ATTE. Maricarmen

Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.581 / Virus Database: 368 - Release Date: 10/02/2004

Hola Maricarmen:
Muy buenas consideraciones las que haces, lo de bueno o malo depende del
criterio administrador de BD.
Mi opinion y la forma en que normalmente es la forma en que me gusta manejar
el Log es:
a) Asignarle suficiente espacio y espacio suficiente para un crecimiento
razonable. El espacio dependera de que tanto se modifica la Base de Datos
(volatilidad), de los ciclos de la aplicacion (si tiene picos importantes en
cierres de periodo u otros), y de la politica de respaldo. Es importante ser
GENEROSO con el espacio.
b) Automatizar los respaldos de la bitacora, de preferencia lo mas
cercanos posible.
c) Configurar una Alerta Administrativa, para cuando el Log supere en un
90% (80% si la BD es muy pequena) de ocupacion.
d) Opcional: Si el sistema no cuenta con un DBA dedicado, o es un
sistema 24x7, configurar la alerta para que se ejecute un Job de respaldo
del Log, cuando se dispara la alerta anterior.
Si el Log se expande y se contrae es mal sintoma, ya que se consumen
importantes recursos que atrazan las transacciones, y hacen mas lerdo el
proceso y deberian evitarse al maximo.
Estoy asumiendo que la BD es una tipica BD de transaccional, no una
BD de importacion de datos (Stage) o una BD que sirva como Datawarehouse, ya
que estos sistemas tienen un patron de consumo del Log diferente.
Saludos,


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.

Maricarmen escribio:

Hola el dia de ayer puse un post para preguntar sobre como truncar
el archivo de transacciones, gracias a Maximiliano y Ulises que me
dieron una gran ayuda, todo salió bien, pude truncar el archivo y
reducir su tamaño, pero ahora me queda una última duda que espero me
puedan responder y es que con este problema he pensado que a lo mejor
seria conveniente no dejar que el archivo de transacciones crezca es
decir no configurarle el autocrecimiento, es bueno o malo hacer esto?
o es mejor dejar el autocrecimiento activado y ponerle un tope de
hasta donde va a poder crecer este archivo.

Gracias por sus respuestas

ATTE. Maricarmen

Gracias por la respuesta, lo tomare en cuent

Gracias Javier lo tomaré en cuenta.

No Adrian tu opinion no difiere de la mia en lo absoluto, yo creo el archivo
LOG lo suficientemente grande como para que se pueda mover la cosa!! y lo
monitoreo, igual con la BDD, ya que el pedido al SO de espacio es una tarea
donde consume muchos recursos, no se porque decis que diferimos en el
pensamiento?

quizas no quedo claro en mi mail anterior, pero si lees fijate que puse de
que no exista Un limite, no aclare que deba tener un espacio suficiente,
pero es lo que se deberia hacer, como tambien el % de crecimiento, si este
es muy poco y la base esta justa o en autocomprimir es un gran problema de
verdad.


Salu2
Maxi
Buenos Aires Argentina
Desarrollador Microsoft 3 Estrellas .NET
[Maxi_accotto[arroba]speedy[punto]com[punto]ar
MSN:


"Adrian D. Garcia" escribió en el mensaje
news:

Bueno, por el otro lado el autoincremento tiene sus costos especialmente

en

el LOG de transacciones. La operacion de asignar mas espacio fisico a los
archivos es costosa en tiempo y recursos.

Mi opinion (que difiere de la de Maxi) es crear los archivos fisicos ya

del

maximo tamaño posible (para el calculo del tamaño maximo del log es un poc
complicado pero se puede hacer) y monitorear el crecimiento para cuando
esten a un valor, por ejemplo, el 85%, tomar las medidas pertinentes.

Saludos
Adrian D. Garcia
MCSD
NDSoft Consultoria y Desarrollo

"Maximiliano D. A." <maxi_accotto[arroba]speedy[.]com[.]ar> wrote in

message

news:
> Hola!! es muy malo eso!! jamas debes hacerlo porque se podrian pinchar

las

> cosas.
>
> Lo que deberias hacer es ver porque crece pero no limitar nada de nada!!
ni
> la BDD tampoco, y tambien podes hacer un mantenimiento diario para
reduccion
> del Log y listo.
>
>
> Salu2
> Maxi
> Buenos Aires Argentina
> Desarrollador Microsoft 3 Estrellas .NET
> [Maxi_accotto[arroba]speedy[punto]com[punto]ar
> MSN:
>
>
> "Maricarmen" escribió en el

mensaje

> news:
> > Hola el dia de ayer puse un post para preguntar sobre como truncar

el

> archivo de transacciones, gracias a Maximiliano y Ulises que me dieron

una

> gran ayuda, todo salió bien, pude truncar el archivo y reducir su

tamaño,

> pero ahora me queda una última duda que espero me puedan responder y es
que
> con este problema he pensado que a lo mejor seria conveniente no dejar

que

> el archivo de transacciones crezca es decir no configurarle el
> autocrecimiento, es bueno o malo hacer esto? o es mejor dejar el
> autocrecimiento activado y ponerle un tope de hasta donde va a poder
crecer
> este archivo.
> >
> > Gracias por sus respuestas
> >
> > ATTE. Maricarmen
> >
> >
>
>
>
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.581 / Virus Database: 368 - Release Date: 10/02/2004
>
>

Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.581 / Virus Database: 368 - Release Date: 10/02/2004