AUTOSHRINK

Version SQL2005.
Modelo: Completa.

"Alejandro Mesa" escribió en el
mensaje news:

Miguel,

- Que version de sql server estas usando?
- Cual es el modelo de recuperacion que utiliza tu db?

El problema es que me quedo sin espacio en el HD donde tengo ubicadas las
DBs.

Es hora de que pienses en agregar mas espacio en disco y moniterear mas de
cerca tus procesos para ver cual es la causa del crecimineto de la db?


AMB

"Miguel A." wrote:

Gracias por las respuesta.

1.- El Backup que realizo es completo cada 2 Horas.

Si mal no recuerdo los distintos modelos de recuperación son estos no??:
Modelo de recuperación simple: podre recuperar base de datos utilizando
la
copia de seguridad más reciente.
Modelo de recuperación completa o el modelo de recuperación por registro
masivo, podre recuperar su base de datos hasta el punto en que se produjo
el
fallo, restaurándola con las copias de seguridad del archivo de registro
de
transacciones.

2.- Te explico.
El tamaño actual de MDF es de 230MB.
El tamaño actual del LDF es de 23GB.
El problema es que me quedo sin espacio en el HD donde tengo ubicadas las
DBs.


"Alejandro Mesa" escribió en el
mensaje news:
> Miguel,
>
>> BACKUP LOG DB WITH TRUNCATE_ONLY --> Borra LOG
>
> Esto me dice que no estas haciendo backups del log de transacciones. Si
> no
> necesitas hacer estos backups, entonces asegurate de que tu db use un
> modelo
> de recuperacion "Simple" y te evitaras tener que trucarlo manualmente.
>
> Puedes decirnos que modelo de recuperacion usa tu db?
>
>> DBCC SHRINKDATABASE (DB , 80) --> Para dejar un 80% de espacio libre.
>
> Debes usar el procedimiento sp_spaceused para ver cuanto tienes de data
> y
> cuanto libre. Entonces sql server calculara el tamanio a quedar en base
> al
> tamanio actual, al tamanio de la data y al tamanio que se quiere de
> espacio
> libre en base al tamanio de la data.
>
> Ejemplo:
>
> archivo data --> 20 bgytes
> data --> 6 gbytes
> espacio libre deseado --> 80 % que equivale a 4.8 gbytes
>
> Entonces el archivo sera reducido a 10.8 gbytes
>
> Asi que si tu archivo no es mayor que el tamanio de la data mas el 80%,
> entonces no sera reducido. Tampoco sera reducido si el tamanio final es
> menor
> que el tamanio original de la db o del ultimo tamanio asignado con
> "alter
> database" o "dbcc shrinkfile".
>
> Recuerda que este proceso puede provocar fragmentacion de la data. Asi
> que
> hazlo solo cuando sea necesario. Que importancia tiene que un db tenga
> unos
> cuantos mbytes de mas, si con el tiempo esta seguira creciendo.
>
>
> AMB
>
> "Miguel A." wrote:
>
>> Yo lo tengo segun dices, segun veo como esta el LOG lanzo el:
>>
>> BACKUP LOG DB WITH TRUNCATE_ONLY --> Borra LOG
>> DBCC SHRINKDATABASE (DB , 80) --> Para dejar un 80% de espacio libre.
>>
>>
>> "Alejandro Mesa" escribió en
>> el
>> mensaje news:
>> > Miguel,
>> >
>> > Para que cuando sql server reduzca el espacio cuando asi lo decida.
>> > No
>> > es
>> > una buena practica activar esta facilidad puesto que el proceso de
>> > reduccion
>> > consume recursos y puede interferir con tus procesos. Se recomienda
>> > darle
>> > espacio a los archivos de data y log con anticipacion y dejar que
>> > estos
>> > crezcan automaticamente si es necesario. Algunas veces hasta se
>> > evita
>> > el
>> > crecimiento automatico.
>> >
>> > Uno de los efectos de la continua reduccion de espacio en los
>> > archivos
>> > de
>> > data es la fragmentacion de paginas, osea que las paginas no estaran
>> > en
>> > orden
>> > consecutivo de acuerdo a los valores de llave que en ellas se
>> > almacenan,
>> > lo
>> > cual implica mayor tiempo en lecturas de I/O.
>> >
>> > Why you want to be restrictive with shrink of database files
>> > http://www.karaszi.com/SQLServer/in...shrink.asp
>> >
>> >
>> > AMB
>> >
>> > "Miguel A." wrote:
>> >
>> >> Para que sirve poner la DB en AUTOSHRINK????
>> >>
>> >>
>> >>
>>
>>
>>

Es decir Alejandro,

en vez de truncar y establecer el modelo de recuperación a Simple, me decies
que es mejor realizar backups de log de transacciones asiduamente no??, pero
hago Backup completo cada 2 horas, no es suficiente???

"Alejandro Mesa" escribió en el
mensaje news:

Miguel,

Como te comente antes, si estas truncando el log de transacciones porque
no
te interesa hacer backup de este, entonces cambia el modelo de
recuperacion a
"Simple". Yo personalmente no recomiendo esto, sino que hagas backups del
log
de transacciones mas continuo y evitaras que este siga creciendo
indiefinidamente.


AMB


"Miguel A." wrote:

Version SQL2005.
Modelo: Completa.

"Alejandro Mesa" escribió en el
mensaje news:
> Miguel,
>
> - Que version de sql server estas usando?
> - Cual es el modelo de recuperacion que utiliza tu db?
>
>> El problema es que me quedo sin espacio en el HD donde tengo ubicadas
>> las
>> DBs.
>
> Es hora de que pienses en agregar mas espacio en disco y moniterear mas
> de
> cerca tus procesos para ver cual es la causa del crecimineto de la db?
>
>
> AMB
>
> "Miguel A." wrote:
>
>> Gracias por las respuesta.
>>
>> 1.- El Backup que realizo es completo cada 2 Horas.
>>
>> Si mal no recuerdo los distintos modelos de recuperación son estos
>> no??:
>> Modelo de recuperación simple: podre recuperar base de datos
>> utilizando
>> la
>> copia de seguridad más reciente.
>> Modelo de recuperación completa o el modelo de recuperación por
>> registro
>> masivo, podre recuperar su base de datos hasta el punto en que se
>> produjo
>> el
>> fallo, restaurándola con las copias de seguridad del archivo de
>> registro
>> de
>> transacciones.
>>
>> 2.- Te explico.
>> El tamaño actual de MDF es de 230MB.
>> El tamaño actual del LDF es de 23GB.
>> El problema es que me quedo sin espacio en el HD donde tengo ubicadas
>> las
>> DBs.
>>
>>
>> "Alejandro Mesa" escribió en
>> el
>> mensaje news:
>> > Miguel,
>> >
>> >> BACKUP LOG DB WITH TRUNCATE_ONLY --> Borra LOG
>> >
>> > Esto me dice que no estas haciendo backups del log de transacciones.
>> > Si
>> > no
>> > necesitas hacer estos backups, entonces asegurate de que tu db use
>> > un
>> > modelo
>> > de recuperacion "Simple" y te evitaras tener que trucarlo
>> > manualmente.
>> >
>> > Puedes decirnos que modelo de recuperacion usa tu db?
>> >
>> >> DBCC SHRINKDATABASE (DB , 80) --> Para dejar un 80% de espacio
>> >> libre.
>> >
>> > Debes usar el procedimiento sp_spaceused para ver cuanto tienes de
>> > data
>> > y
>> > cuanto libre. Entonces sql server calculara el tamanio a quedar en
>> > base
>> > al
>> > tamanio actual, al tamanio de la data y al tamanio que se quiere de
>> > espacio
>> > libre en base al tamanio de la data.
>> >
>> > Ejemplo:
>> >
>> > archivo data --> 20 bgytes
>> > data --> 6 gbytes
>> > espacio libre deseado --> 80 % que equivale a 4.8 gbytes
>> >
>> > Entonces el archivo sera reducido a 10.8 gbytes
>> >
>> > Asi que si tu archivo no es mayor que el tamanio de la data mas el
>> > 80%,
>> > entonces no sera reducido. Tampoco sera reducido si el tamanio final
>> > es
>> > menor
>> > que el tamanio original de la db o del ultimo tamanio asignado con
>> > "alter
>> > database" o "dbcc shrinkfile".
>> >
>> > Recuerda que este proceso puede provocar fragmentacion de la data.
>> > Asi
>> > que
>> > hazlo solo cuando sea necesario. Que importancia tiene que un db
>> > tenga
>> > unos
>> > cuantos mbytes de mas, si con el tiempo esta seguira creciendo.
>> >
>> >
>> > AMB
>> >
>> > "Miguel A." wrote:
>> >
>> >> Yo lo tengo segun dices, segun veo como esta el LOG lanzo el:
>> >>
>> >> BACKUP LOG DB WITH TRUNCATE_ONLY --> Borra LOG
>> >> DBCC SHRINKDATABASE (DB , 80) --> Para dejar un 80% de espacio
>> >> libre.
>> >>
>> >>
>> >> "Alejandro Mesa" escribió
>> >> en
>> >> el
>> >> mensaje news:
>> >> > Miguel,
>> >> >
>> >> > Para que cuando sql server reduzca el espacio cuando asi lo
>> >> > decida.
>> >> > No
>> >> > es
>> >> > una buena practica activar esta facilidad puesto que el proceso
>> >> > de
>> >> > reduccion
>> >> > consume recursos y puede interferir con tus procesos. Se
>> >> > recomienda
>> >> > darle
>> >> > espacio a los archivos de data y log con anticipacion y dejar que
>> >> > estos
>> >> > crezcan automaticamente si es necesario. Algunas veces hasta se
>> >> > evita
>> >> > el
>> >> > crecimiento automatico.
>> >> >
>> >> > Uno de los efectos de la continua reduccion de espacio en los
>> >> > archivos
>> >> > de
>> >> > data es la fragmentacion de paginas, osea que las paginas no
>> >> > estaran
>> >> > en
>> >> > orden
>> >> > consecutivo de acuerdo a los valores de llave que en ellas se
>> >> > almacenan,
>> >> > lo
>> >> > cual implica mayor tiempo en lecturas de I/O.
>> >> >
>> >> > Why you want to be restrictive with shrink of database files
>> >> > http://www.karaszi.com/SQLServer/in...shrink.asp
>> >> >
>> >> >
>> >> > AMB
>> >> >
>> >> > "Miguel A." wrote:
>> >> >
>> >> >> Para que sirve poner la DB en AUTOSHRINK????
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>>
>>
>>

Ok, asi lo haré. Muchas gracias por tu paciencia.

"Alejandro Mesa" escribió en el
mensaje news:

Miguel,

Cuando se usa el modelo de recuperacion "Full", el backup completo no
trunca
el log, para esto se debe hacer backup del log de transacciones. Una
posible
estrategia a seguir seria hacer un backup completo diariamente y un backup
del log de transacciones cada hora.


AMB

"Miguel A." wrote:

Es decir Alejandro,

en vez de truncar y establecer el modelo de recuperación a Simple, me
decies
que es mejor realizar backups de log de transacciones asiduamente no??,
pero
hago Backup completo cada 2 horas, no es suficiente???

"Alejandro Mesa" escribió en el
mensaje news:
> Miguel,
>
> Como te comente antes, si estas truncando el log de transacciones
> porque
> no
> te interesa hacer backup de este, entonces cambia el modelo de
> recuperacion a
> "Simple". Yo personalmente no recomiendo esto, sino que hagas backups
> del
> log
> de transacciones mas continuo y evitaras que este siga creciendo
> indiefinidamente.
>
>
> AMB
>
>
> "Miguel A." wrote:
>
>> Version SQL2005.
>> Modelo: Completa.
>>
>> "Alejandro Mesa" escribió en
>> el
>> mensaje news:
>> > Miguel,
>> >
>> > - Que version de sql server estas usando?
>> > - Cual es el modelo de recuperacion que utiliza tu db?
>> >
>> >> El problema es que me quedo sin espacio en el HD donde tengo
>> >> ubicadas
>> >> las
>> >> DBs.
>> >
>> > Es hora de que pienses en agregar mas espacio en disco y moniterear
>> > mas
>> > de
>> > cerca tus procesos para ver cual es la causa del crecimineto de la
>> > db?
>> >
>> >
>> > AMB
>> >
>> > "Miguel A." wrote:
>> >
>> >> Gracias por las respuesta.
>> >>
>> >> 1.- El Backup que realizo es completo cada 2 Horas.
>> >>
>> >> Si mal no recuerdo los distintos modelos de recuperación son estos
>> >> no??:
>> >> Modelo de recuperación simple: podre recuperar base de datos
>> >> utilizando
>> >> la
>> >> copia de seguridad más reciente.
>> >> Modelo de recuperación completa o el modelo de recuperación por
>> >> registro
>> >> masivo, podre recuperar su base de datos hasta el punto en que se
>> >> produjo
>> >> el
>> >> fallo, restaurándola con las copias de seguridad del archivo de
>> >> registro
>> >> de
>> >> transacciones.
>> >>
>> >> 2.- Te explico.
>> >> El tamaño actual de MDF es de 230MB.
>> >> El tamaño actual del LDF es de 23GB.
>> >> El problema es que me quedo sin espacio en el HD donde tengo
>> >> ubicadas
>> >> las
>> >> DBs.
>> >>
>> >>
>> >> "Alejandro Mesa" escribió
>> >> en
>> >> el
>> >> mensaje news:
>> >> > Miguel,
>> >> >
>> >> >> BACKUP LOG DB WITH TRUNCATE_ONLY --> Borra LOG
>> >> >
>> >> > Esto me dice que no estas haciendo backups del log de
>> >> > transacciones.
>> >> > Si
>> >> > no
>> >> > necesitas hacer estos backups, entonces asegurate de que tu db
>> >> > use
>> >> > un
>> >> > modelo
>> >> > de recuperacion "Simple" y te evitaras tener que trucarlo
>> >> > manualmente.
>> >> >
>> >> > Puedes decirnos que modelo de recuperacion usa tu db?
>> >> >
>> >> >> DBCC SHRINKDATABASE (DB , 80) --> Para dejar un 80% de espacio
>> >> >> libre.
>> >> >
>> >> > Debes usar el procedimiento sp_spaceused para ver cuanto tienes
>> >> > de
>> >> > data
>> >> > y
>> >> > cuanto libre. Entonces sql server calculara el tamanio a quedar
>> >> > en
>> >> > base
>> >> > al
>> >> > tamanio actual, al tamanio de la data y al tamanio que se quiere
>> >> > de
>> >> > espacio
>> >> > libre en base al tamanio de la data.
>> >> >
>> >> > Ejemplo:
>> >> >
>> >> > archivo data --> 20 bgytes
>> >> > data --> 6 gbytes
>> >> > espacio libre deseado --> 80 % que equivale a 4.8 gbytes
>> >> >
>> >> > Entonces el archivo sera reducido a 10.8 gbytes
>> >> >
>> >> > Asi que si tu archivo no es mayor que el tamanio de la data mas
>> >> > el
>> >> > 80%,
>> >> > entonces no sera reducido. Tampoco sera reducido si el tamanio
>> >> > final
>> >> > es
>> >> > menor
>> >> > que el tamanio original de la db o del ultimo tamanio asignado
>> >> > con
>> >> > "alter
>> >> > database" o "dbcc shrinkfile".
>> >> >
>> >> > Recuerda que este proceso puede provocar fragmentacion de la
>> >> > data.
>> >> > Asi
>> >> > que
>> >> > hazlo solo cuando sea necesario. Que importancia tiene que un db
>> >> > tenga
>> >> > unos
>> >> > cuantos mbytes de mas, si con el tiempo esta seguira creciendo.
>> >> >
>> >> >
>> >> > AMB
>> >> >
>> >> > "Miguel A." wrote:
>> >> >
>> >> >> Yo lo tengo segun dices, segun veo como esta el LOG lanzo el:
>> >> >>
>> >> >> BACKUP LOG DB WITH TRUNCATE_ONLY --> Borra LOG
>> >> >> DBCC SHRINKDATABASE (DB , 80) --> Para dejar un 80% de espacio
>> >> >> libre.
>> >> >>
>> >> >>
>> >> >> "Alejandro Mesa"
>> >> >> escribió
>> >> >> en
>> >> >> el
>> >> >> mensaje
>> >> >> news:
>> >> >> > Miguel,
>> >> >> >
>> >> >> > Para que cuando sql server reduzca el espacio cuando asi lo
>> >> >> > decida.
>> >> >> > No
>> >> >> > es
>> >> >> > una buena practica activar esta facilidad puesto que el
>> >> >> > proceso
>> >> >> > de
>> >> >> > reduccion
>> >> >> > consume recursos y puede interferir con tus procesos. Se
>> >> >> > recomienda
>> >> >> > darle
>> >> >> > espacio a los archivos de data y log con anticipacion y dejar
>> >> >> > que
>> >> >> > estos
>> >> >> > crezcan automaticamente si es necesario. Algunas veces hasta
>> >> >> > se
>> >> >> > evita
>> >> >> > el
>> >> >> > crecimiento automatico.
>> >> >> >
>> >> >> > Uno de los efectos de la continua reduccion de espacio en los
>> >> >> > archivos
>> >> >> > de
>> >> >> > data es la fragmentacion de paginas, osea que las paginas no
>> >> >> > estaran
>> >> >> > en
>> >> >> > orden
>> >> >> > consecutivo de acuerdo a los valores de llave que en ellas se
>> >> >> > almacenan,
>> >> >> > lo
>> >> >> > cual implica mayor tiempo en lecturas de I/O.
>> >> >> >
>> >> >> > Why you want to be restrictive with shrink of database files
>> >> >> > http://www.karaszi.com/SQLServer/in...shrink.asp
>> >> >> >
>> >> >> >
>> >> >> > AMB
>> >> >> >
>> >> >> > "Miguel A." wrote:
>> >> >> >
>> >> >> >> Para que sirve poner la DB en AUTOSHRINK????
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>>
>>
>>

Una ultima pregunta. He realizaod en el laboratorio ahora un backup del
registro de transacciones, me dice que lo hace ok, pero el tamaño no
disminuye, como debo de hacerlo???

"Miguel A." escribió en el mensaje
news:O%

Ok, asi lo haré. Muchas gracias por tu paciencia.

"Alejandro Mesa" escribió en el
mensaje news:

Miguel,

Cuando se usa el modelo de recuperacion "Full", el backup completo no
trunca
el log, para esto se debe hacer backup del log de transacciones. Una
posible
estrategia a seguir seria hacer un backup completo diariamente y un
backup
del log de transacciones cada hora.


AMB

"Miguel A." wrote:

Es decir Alejandro,

en vez de truncar y establecer el modelo de recuperación a Simple, me
decies
que es mejor realizar backups de log de transacciones asiduamente no??,
pero
hago Backup completo cada 2 horas, no es suficiente???

"Alejandro Mesa" escribió en
el
mensaje news:
> Miguel,
>
> Como te comente antes, si estas truncando el log de transacciones
> porque
> no
> te interesa hacer backup de este, entonces cambia el modelo de
> recuperacion a
> "Simple". Yo personalmente no recomiendo esto, sino que hagas backups
> del
> log
> de transacciones mas continuo y evitaras que este siga creciendo
> indiefinidamente.
>
>
> AMB
>
>
> "Miguel A." wrote:
>
>> Version SQL2005.
>> Modelo: Completa.
>>
>> "Alejandro Mesa" escribió
>> en el
>> mensaje news:
>> > Miguel,
>> >
>> > - Que version de sql server estas usando?
>> > - Cual es el modelo de recuperacion que utiliza tu db?
>> >
>> >> El problema es que me quedo sin espacio en el HD donde tengo
>> >> ubicadas
>> >> las
>> >> DBs.
>> >
>> > Es hora de que pienses en agregar mas espacio en disco y moniterear
>> > mas
>> > de
>> > cerca tus procesos para ver cual es la causa del crecimineto de la
>> > db?
>> >
>> >
>> > AMB
>> >
>> > "Miguel A." wrote:
>> >
>> >> Gracias por las respuesta.
>> >>
>> >> 1.- El Backup que realizo es completo cada 2 Horas.
>> >>
>> >> Si mal no recuerdo los distintos modelos de recuperación son estos
>> >> no??:
>> >> Modelo de recuperación simple: podre recuperar base de datos
>> >> utilizando
>> >> la
>> >> copia de seguridad más reciente.
>> >> Modelo de recuperación completa o el modelo de recuperación por
>> >> registro
>> >> masivo, podre recuperar su base de datos hasta el punto en que se
>> >> produjo
>> >> el
>> >> fallo, restaurándola con las copias de seguridad del archivo de
>> >> registro
>> >> de
>> >> transacciones.
>> >>
>> >> 2.- Te explico.
>> >> El tamaño actual de MDF es de 230MB.
>> >> El tamaño actual del LDF es de 23GB.
>> >> El problema es que me quedo sin espacio en el HD donde tengo
>> >> ubicadas
>> >> las
>> >> DBs.
>> >>
>> >>
>> >> "Alejandro Mesa"
>> >> escribió en
>> >> el
>> >> mensaje news:
>> >> > Miguel,
>> >> >
>> >> >> BACKUP LOG DB WITH TRUNCATE_ONLY --> Borra LOG
>> >> >
>> >> > Esto me dice que no estas haciendo backups del log de
>> >> > transacciones.
>> >> > Si
>> >> > no
>> >> > necesitas hacer estos backups, entonces asegurate de que tu db
>> >> > use
>> >> > un
>> >> > modelo
>> >> > de recuperacion "Simple" y te evitaras tener que trucarlo
>> >> > manualmente.
>> >> >
>> >> > Puedes decirnos que modelo de recuperacion usa tu db?
>> >> >
>> >> >> DBCC SHRINKDATABASE (DB , 80) --> Para dejar un 80% de espacio
>> >> >> libre.
>> >> >
>> >> > Debes usar el procedimiento sp_spaceused para ver cuanto tienes
>> >> > de
>> >> > data
>> >> > y
>> >> > cuanto libre. Entonces sql server calculara el tamanio a quedar
>> >> > en
>> >> > base
>> >> > al
>> >> > tamanio actual, al tamanio de la data y al tamanio que se quiere
>> >> > de
>> >> > espacio
>> >> > libre en base al tamanio de la data.
>> >> >
>> >> > Ejemplo:
>> >> >
>> >> > archivo data --> 20 bgytes
>> >> > data --> 6 gbytes
>> >> > espacio libre deseado --> 80 % que equivale a 4.8 gbytes
>> >> >
>> >> > Entonces el archivo sera reducido a 10.8 gbytes
>> >> >
>> >> > Asi que si tu archivo no es mayor que el tamanio de la data mas
>> >> > el
>> >> > 80%,
>> >> > entonces no sera reducido. Tampoco sera reducido si el tamanio
>> >> > final
>> >> > es
>> >> > menor
>> >> > que el tamanio original de la db o del ultimo tamanio asignado
>> >> > con
>> >> > "alter
>> >> > database" o "dbcc shrinkfile".
>> >> >
>> >> > Recuerda que este proceso puede provocar fragmentacion de la
>> >> > data.
>> >> > Asi
>> >> > que
>> >> > hazlo solo cuando sea necesario. Que importancia tiene que un db
>> >> > tenga
>> >> > unos
>> >> > cuantos mbytes de mas, si con el tiempo esta seguira creciendo.
>> >> >
>> >> >
>> >> > AMB
>> >> >
>> >> > "Miguel A." wrote:
>> >> >
>> >> >> Yo lo tengo segun dices, segun veo como esta el LOG lanzo el:
>> >> >>
>> >> >> BACKUP LOG DB WITH TRUNCATE_ONLY --> Borra LOG
>> >> >> DBCC SHRINKDATABASE (DB , 80) --> Para dejar un 80% de espacio
>> >> >> libre.
>> >> >>
>> >> >>
>> >> >> "Alejandro Mesa"
>> >> >> escribió
>> >> >> en
>> >> >> el
>> >> >> mensaje
>> >> >> news:
>> >> >> > Miguel,
>> >> >> >
>> >> >> > Para que cuando sql server reduzca el espacio cuando asi lo
>> >> >> > decida.
>> >> >> > No
>> >> >> > es
>> >> >> > una buena practica activar esta facilidad puesto que el
>> >> >> > proceso
>> >> >> > de
>> >> >> > reduccion
>> >> >> > consume recursos y puede interferir con tus procesos. Se
>> >> >> > recomienda
>> >> >> > darle
>> >> >> > espacio a los archivos de data y log con anticipacion y dejar
>> >> >> > que
>> >> >> > estos
>> >> >> > crezcan automaticamente si es necesario. Algunas veces hasta
>> >> >> > se
>> >> >> > evita
>> >> >> > el
>> >> >> > crecimiento automatico.
>> >> >> >
>> >> >> > Uno de los efectos de la continua reduccion de espacio en los
>> >> >> > archivos
>> >> >> > de
>> >> >> > data es la fragmentacion de paginas, osea que las paginas no
>> >> >> > estaran
>> >> >> > en
>> >> >> > orden
>> >> >> > consecutivo de acuerdo a los valores de llave que en ellas se
>> >> >> > almacenan,
>> >> >> > lo
>> >> >> > cual implica mayor tiempo en lecturas de I/O.
>> >> >> >
>> >> >> > Why you want to be restrictive with shrink of database files
>> >> >> > http://www.karaszi.com/SQLServer/in...shrink.asp
>> >> >> >
>> >> >> >
>> >> >> > AMB
>> >> >> >
>> >> >> > "Miguel A." wrote:
>> >> >> >
>> >> >> >> Para que sirve poner la DB en AUTOSHRINK????
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>>
>>
>>

Acabo de hacer estos pasos:
Use DB
CHECKPOINT
EXEC sp_addumpdevice 'disk','DB1','g:\DB.bak'
BACKUP DATABASE DB TO DB1
BACKUP LOG DB TO DB1

y tiene el mismo tamaño.
debo de realizar ahora el DBCC SHRINKFILE (DB_log,80) ???

"Miguel A." escribió en el mensaje
news:O$

Una ultima pregunta. He realizaod en el laboratorio ahora un backup del
registro de transacciones, me dice que lo hace ok, pero el tamaño no
disminuye, como debo de hacerlo???

"Miguel A." escribió en el mensaje
news:O%

Ok, asi lo haré. Muchas gracias por tu paciencia.

"Alejandro Mesa" escribió en el
mensaje news:

Miguel,

Cuando se usa el modelo de recuperacion "Full", el backup completo no
trunca
el log, para esto se debe hacer backup del log de transacciones. Una
posible
estrategia a seguir seria hacer un backup completo diariamente y un
backup
del log de transacciones cada hora.


AMB

"Miguel A." wrote:

Es decir Alejandro,

en vez de truncar y establecer el modelo de recuperación a Simple, me
decies
que es mejor realizar backups de log de transacciones asiduamente no??,
pero
hago Backup completo cada 2 horas, no es suficiente???

"Alejandro Mesa" escribió en
el
mensaje news:
> Miguel,
>
> Como te comente antes, si estas truncando el log de transacciones
> porque
> no
> te interesa hacer backup de este, entonces cambia el modelo de
> recuperacion a
> "Simple". Yo personalmente no recomiendo esto, sino que hagas backups
> del
> log
> de transacciones mas continuo y evitaras que este siga creciendo
> indiefinidamente.
>
>
> AMB
>
>
> "Miguel A." wrote:
>
>> Version SQL2005.
>> Modelo: Completa.
>>
>> "Alejandro Mesa" escribió
>> en el
>> mensaje news:
>> > Miguel,
>> >
>> > - Que version de sql server estas usando?
>> > - Cual es el modelo de recuperacion que utiliza tu db?
>> >
>> >> El problema es que me quedo sin espacio en el HD donde tengo
>> >> ubicadas
>> >> las
>> >> DBs.
>> >
>> > Es hora de que pienses en agregar mas espacio en disco y
>> > moniterear mas
>> > de
>> > cerca tus procesos para ver cual es la causa del crecimineto de la
>> > db?
>> >
>> >
>> > AMB
>> >
>> > "Miguel A." wrote:
>> >
>> >> Gracias por las respuesta.
>> >>
>> >> 1.- El Backup que realizo es completo cada 2 Horas.
>> >>
>> >> Si mal no recuerdo los distintos modelos de recuperación son
>> >> estos
>> >> no??:
>> >> Modelo de recuperación simple: podre recuperar base de datos
>> >> utilizando
>> >> la
>> >> copia de seguridad más reciente.
>> >> Modelo de recuperación completa o el modelo de recuperación por
>> >> registro
>> >> masivo, podre recuperar su base de datos hasta el punto en que se
>> >> produjo
>> >> el
>> >> fallo, restaurándola con las copias de seguridad del archivo de
>> >> registro
>> >> de
>> >> transacciones.
>> >>
>> >> 2.- Te explico.
>> >> El tamaño actual de MDF es de 230MB.
>> >> El tamaño actual del LDF es de 23GB.
>> >> El problema es que me quedo sin espacio en el HD donde tengo
>> >> ubicadas
>> >> las
>> >> DBs.
>> >>
>> >>
>> >> "Alejandro Mesa"
>> >> escribió en
>> >> el
>> >> mensaje
>> >> news:
>> >> > Miguel,
>> >> >
>> >> >> BACKUP LOG DB WITH TRUNCATE_ONLY --> Borra LOG
>> >> >
>> >> > Esto me dice que no estas haciendo backups del log de
>> >> > transacciones.
>> >> > Si
>> >> > no
>> >> > necesitas hacer estos backups, entonces asegurate de que tu db
>> >> > use
>> >> > un
>> >> > modelo
>> >> > de recuperacion "Simple" y te evitaras tener que trucarlo
>> >> > manualmente.
>> >> >
>> >> > Puedes decirnos que modelo de recuperacion usa tu db?
>> >> >
>> >> >> DBCC SHRINKDATABASE (DB , 80) --> Para dejar un 80% de espacio
>> >> >> libre.
>> >> >
>> >> > Debes usar el procedimiento sp_spaceused para ver cuanto tienes
>> >> > de
>> >> > data
>> >> > y
>> >> > cuanto libre. Entonces sql server calculara el tamanio a quedar
>> >> > en
>> >> > base
>> >> > al
>> >> > tamanio actual, al tamanio de la data y al tamanio que se
>> >> > quiere de
>> >> > espacio
>> >> > libre en base al tamanio de la data.
>> >> >
>> >> > Ejemplo:
>> >> >
>> >> > archivo data --> 20 bgytes
>> >> > data --> 6 gbytes
>> >> > espacio libre deseado --> 80 % que equivale a 4.8 gbytes
>> >> >
>> >> > Entonces el archivo sera reducido a 10.8 gbytes
>> >> >
>> >> > Asi que si tu archivo no es mayor que el tamanio de la data mas
>> >> > el
>> >> > 80%,
>> >> > entonces no sera reducido. Tampoco sera reducido si el tamanio
>> >> > final
>> >> > es
>> >> > menor
>> >> > que el tamanio original de la db o del ultimo tamanio asignado
>> >> > con
>> >> > "alter
>> >> > database" o "dbcc shrinkfile".
>> >> >
>> >> > Recuerda que este proceso puede provocar fragmentacion de la
>> >> > data.
>> >> > Asi
>> >> > que
>> >> > hazlo solo cuando sea necesario. Que importancia tiene que un
>> >> > db
>> >> > tenga
>> >> > unos
>> >> > cuantos mbytes de mas, si con el tiempo esta seguira creciendo.
>> >> >
>> >> >
>> >> > AMB
>> >> >
>> >> > "Miguel A." wrote:
>> >> >
>> >> >> Yo lo tengo segun dices, segun veo como esta el LOG lanzo el:
>> >> >>
>> >> >> BACKUP LOG DB WITH TRUNCATE_ONLY --> Borra LOG
>> >> >> DBCC SHRINKDATABASE (DB , 80) --> Para dejar un 80% de espacio
>> >> >> libre.
>> >> >>
>> >> >>
>> >> >> "Alejandro Mesa"
>> >> >> escribió
>> >> >> en
>> >> >> el
>> >> >> mensaje
>> >> >> news:
>> >> >> > Miguel,
>> >> >> >
>> >> >> > Para que cuando sql server reduzca el espacio cuando asi lo
>> >> >> > decida.
>> >> >> > No
>> >> >> > es
>> >> >> > una buena practica activar esta facilidad puesto que el
>> >> >> > proceso
>> >> >> > de
>> >> >> > reduccion
>> >> >> > consume recursos y puede interferir con tus procesos. Se
>> >> >> > recomienda
>> >> >> > darle
>> >> >> > espacio a los archivos de data y log con anticipacion y
>> >> >> > dejar que
>> >> >> > estos
>> >> >> > crezcan automaticamente si es necesario. Algunas veces hasta
>> >> >> > se
>> >> >> > evita
>> >> >> > el
>> >> >> > crecimiento automatico.
>> >> >> >
>> >> >> > Uno de los efectos de la continua reduccion de espacio en
>> >> >> > los
>> >> >> > archivos
>> >> >> > de
>> >> >> > data es la fragmentacion de paginas, osea que las paginas no
>> >> >> > estaran
>> >> >> > en
>> >> >> > orden
>> >> >> > consecutivo de acuerdo a los valores de llave que en ellas
>> >> >> > se
>> >> >> > almacenan,
>> >> >> > lo
>> >> >> > cual implica mayor tiempo en lecturas de I/O.
>> >> >> >
>> >> >> > Why you want to be restrictive with shrink of database files
>> >> >> > http://www.karaszi.com/SQLServer/in...shrink.asp
>> >> >> >
>> >> >> >
>> >> >> > AMB
>> >> >> >
>> >> >> > "Miguel A." wrote:
>> >> >> >
>> >> >> >> Para que sirve poner la DB en AUTOSHRINK????
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>>
>>
>>