El log se hace muy grande luego de una gran carga de datos

hola!! no se q es grande para vos!! (decime cuantos megas) ademas hay q ver
como es el DTS si pesa ucho , q tablas toca etc, tambien habria q analizar
si este DTS cada cuanto se corre

Pero podrias luego una vez por dia reducir el log por ej:

aca tenes un ej de como reducir un log a 2gb

checkpoint
backup log fsc with truncate_only
DBCC SHRINKFILE(fsc_ss_log,2000)

bye

Maximiliano Damian Accotto
"c" escribió en el mensaje
news:048701c3b5ba$ee443da0$
Luego de una carga de datos mediante DTS bastante grande
el registro de transacciones de la Base de Datos que se
carga queda MUY grande.
Que es lo más conveniente a hacer luego de la carga para
bajar el tamaño del log????
Hay algún problema que el log se haga tan grande? Qué
harían uds?

Grande es 5 gigas...
La carga se hace diariamente...
Es un sistema de Consultas (Datawarehouse) con lo cual me
gustaría que el log sea lo más chico posible.
Son muchos DTS que se ejecutan mediante un Job...

Que me aconsejan?

hola!! no se q es grande para vos!! (decime cuantos

megas) ademas hay q ver

como es el DTS si pesa ucho , q tablas toca etc, tambien

habria q analizar

si este DTS cada cuanto se corre

Pero podrias luego una vez por dia reducir el log por ej:

aca tenes un ej de como reducir un log a 2gb

checkpoint
backup log fsc with truncate_only
DBCC SHRINKFILE(fsc_ss_log,2000)

bye

Maximiliano Damian Accotto
"c" escribió en el

mensaje

news:048701c3b5ba$ee443da0$
Luego de una carga de datos mediante DTS bastante grande
el registro de transacciones de la Base de Datos que se
carga queda MUY grande.
Que es lo más conveniente a hacer luego de la carga para
bajar el tamaño del log????
Hay algún problema que el log se haga tan grande? Qué
harían uds?


.

Hola:
Si la carga se hace a una BD tipo STAGE/INTERMEDIA y puedes volver a
generar la carga podrias considerar cambiar el modo de la BD a simple, para
que Log se trunque automaticamente, NO SE VA a reducir el espacio si hay
grandes transacciones pero esto es deseable para que la siguiente vez que se
ejecute se haga mas rapido ya que no haya que pedirle al Sistema Operativo
el espacio.
Si la BD es el DATAWAREHOUSE y debe mantenerse respaldo del mismo,
podrias al final de job realizar un respaldo de la bitacora (que
automaticamente trunca el Log) pero NO trunca el archivo del Log, porque la
siguiente vez que corra quieres que el espacio este disponible para que el
SQL pueda ampliar el Log.
Si decides truncar el archivo del Log, se hace mas lenta la ejecucion
del LOG.
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.
c escribio:

Grande es 5 gigas...
La carga se hace diariamente...
Es un sistema de Consultas (Datawarehouse) con lo cual me
gustaría que el log sea lo más chico posible.
Son muchos DTS que se ejecutan mediante un Job...

Que me aconsejan?

hola!! no se q es grande para vos!! (decime cuantos megas) ademas
hay q ver como es el DTS si pesa ucho , q tablas toca etc, tambien
habria q analizar si este DTS cada cuanto se corre

Pero podrias luego una vez por dia reducir el log por ej:

aca tenes un ej de como reducir un log a 2gb

checkpoint
backup log fsc with truncate_only
DBCC SHRINKFILE(fsc_ss_log,2000)

bye

Maximiliano Damian Accotto
"c" escribió en el mensaje
news:048701c3b5ba$ee443da0$
Luego de una carga de datos mediante DTS bastante grande
el registro de transacciones de la Base de Datos que se
carga queda MUY grande.
Que es lo más conveniente a hacer luego de la carga para
bajar el tamaño del log????
Hay algún problema que el log se haga tan grande? Qué
harían uds?


.

Si bien cada aplicación es diferente y tiene sus detalles propios,
normalmente un proceso de carga de data warehouse se realiza mediante
operaciones no logeadas (por ejemplo usar BULK INSERT). Esto acelera el
proceso de carga y evita el logging de la transacción. Teniendo en cuenta
que no hay transacción, debes prever un mecanismo para anular los registros
ingresados en caso de falla que te deje una carga parcial de los datos.

saludos
gux

Gustavo Larriera, MSFT MVP-SQL
Uruguay LatAm

This message is provided "AS IS" with no warranties expressed or implied,
and confers no rights.


"c" wrote in message
news:04db01c3b5c1$5360bc30$
Grande es 5 gigas...
La carga se hace diariamente...
Es un sistema de Consultas (Datawarehouse) con lo cual me
gustaría que el log sea lo más chico posible.
Son muchos DTS que se ejecutan mediante un Job...

Que me aconsejan?

hola!! no se q es grande para vos!! (decime cuantos

megas) ademas hay q ver

como es el DTS si pesa ucho , q tablas toca etc, tambien

habria q analizar

si este DTS cada cuanto se corre

Pero podrias luego una vez por dia reducir el log por ej:

aca tenes un ej de como reducir un log a 2gb

checkpoint
backup log fsc with truncate_only
DBCC SHRINKFILE(fsc_ss_log,2000)

bye

Maximiliano Damian Accotto
"c" escribió en el

mensaje

news:048701c3b5ba$ee443da0$
Luego de una carga de datos mediante DTS bastante grande
el registro de transacciones de la Base de Datos que se
carga queda MUY grande.
Que es lo más conveniente a hacer luego de la carga para
bajar el tamaño del log????
Hay algún problema que el log se haga tan grande? Qué
harían uds?


.

Hola Gustavo hay algunas confusiones con esto y me gustaría que las viesemos
en detalle, ya que aunque eso es lo que 'parece' luego no es así, He probado
este script en northwind (ojo que borra la tabla order details)
alter database Northwind set recovery full
go
backup log Northwind with truncate_only
go
select *from ::Fn_dblog(null,null)
go
bulk insert [order details] from 'c:\salida.csv' with( FIELDTERMINATOR=',')
go
select *from ::Fn_dblog(null,null)
go
truncate table [order details]
go
alter database Northwind set recovery bulk_logged
go
backup log Northwind with truncate_only
go
select *from ::Fn_dblog(null,null)
go
bulk insert [order details] from 'c:\salida.csv' with( FIELDTERMINATOR=',')
go
select *from ::Fn_dblog(null,null)
go
truncate table [order details]
go

y demuestra que no es exactamente así. Además con el modo de recuperaci´n
bulk_logged si que funciona así con comandos como BCP pero no bulk insert
sino no inserción masiva mediante BCP, creo que buena parte de la culpa la
tienen las traducciones al castellano. Sin embargo, con el modo de
recuperación completo, siempre se registran en el log las inserciones
incluso con bcp.

Saludos
=Miguel Egea
http://www.portalsql.com
Microsoft SQL-SERVER MVP.
Brigada Anti-Cursores
Aviso de Seguridad
http://www.microsoft.com/spain/tech...9-USER.asp
==

"Gustavo Larriera [MVP]" escribió en el
mensaje news:%

Si bien cada aplicación es diferente y tiene sus detalles propios,
normalmente un proceso de carga de data warehouse se realiza mediante
operaciones no logeadas (por ejemplo usar BULK INSERT). Esto acelera el
proceso de carga y evita el logging de la transacción. Teniendo en cuenta
que no hay transacción, debes prever un mecanismo para anular los

registros

ingresados en caso de falla que te deje una carga parcial de los datos.

saludos
gux

Gustavo Larriera, MSFT MVP-SQL
Uruguay LatAm

This message is provided "AS IS" with no warranties expressed or implied,
and confers no rights.


"c" wrote in message
news:04db01c3b5c1$5360bc30$
Grande es 5 gigas...
La carga se hace diariamente...
Es un sistema de Consultas (Datawarehouse) con lo cual me
gustaría que el log sea lo más chico posible.
Son muchos DTS que se ejecutan mediante un Job...

Que me aconsejan?
>hola!! no se q es grande para vos!! (decime cuantos
megas) ademas hay q ver
>como es el DTS si pesa ucho , q tablas toca etc, tambien
habria q analizar
>si este DTS cada cuanto se corre
>
>Pero podrias luego una vez por dia reducir el log por ej:
>
>aca tenes un ej de como reducir un log a 2gb
>
>checkpoint
>backup log fsc with truncate_only
>DBCC SHRINKFILE(fsc_ss_log,2000)
>
>bye
>
>Maximiliano Damian Accotto
>"c" escribió en el
mensaje
>news:048701c3b5ba$ee443da0$
>Luego de una carga de datos mediante DTS bastante grande
>el registro de transacciones de la Base de Datos que se
>carga queda MUY grande.
>Que es lo más conveniente a hacer luego de la carga para
>bajar el tamaño del log????
>Hay algún problema que el log se haga tan grande? Qué
>harían uds?
>
>
>.
>