Tiempo que tarda un Shrink

Te contesto en tu mensaje
"mediocad" wrote in message
news:

Gracias por vuestras respuestas. Entonces sería hacer esto:

1. Hago backup desde el Enterprise Manager

2. ¿Cómo se hace eso?
Alter Database Tu BBDD set recovery simple

3. Checkpoint

Backup log <mibd> with truncate_only
estos pasos ya no son necesarios (ni checkpoint ni backup log)

dbcc shrinkfile (<nombre_log1, 100)

dbcc shrinkfile (<nombre_log2, EMPTYFILE)
dbcc shrinkfile (<nombre_log3, EMPTYFILE)
y les das tiempo

Para los dos últimos ¿Cómo se pone emptyfile)
4. Esto sería:

alter database remove file <nombre_log2>
alter database remove file <nombre_log3>
Alter DAtabase TUBBDDD set Recovery FULL
y vuelves a hacer un backup.

5. Plan de mantenimiento y backups lo miraré más tarde porque he leído a
cerca de ello y tal vez no tenga que preguntar.

Gracias y un saludo

Espero que se entienda :)

Si tienes razon, pero me dio la sensacion que no lo hacia asi :-S deberia
volver a armar la prueba que hice en su momento pero es logico que lo haga
como vos decis. Volvere a probar :-), de todas maneras trato de no hacer la
practica a menos que haya problemas de espacio, pero siempre me habia
quedado la inquietud como lo hacia SQL realemente



Microsoft MVP SQLServer
www.sqltotalconsulting.com
-

"Miguel Egea" escribió en el mensaje de
noticias:

En realidad llenaría primero uno y luego otro, supongo que la prueba te
dió resultados extraños. No puede llenar ambos a la vez y garantizar la
transaccionalidad..

Saludos
Miguel Egea
"Maxi Accotto" wrote in message
news:%

Gracias Miguel, tenia entendido que por mas que sea secuencial si lo
separas tenias paralelismo, de hecho una vez intente hacerlo y lo que
observe es que los llenaba parejos, si tenia 2 transacion log en dos
filegroups no es que llenaba primero uno y luego el otro, pero
francamente nunca hice una comparacion de performance real a ver si eso
tenia algun impacto :-S


Microsoft MVP SQLServer
www.sqltotalconsulting.com
-

"Miguel Egea" escribió en el mensaje de
noticias:

eso es correcto para ficheros de datos, pero no para el log de
transacciones. El log de transacciones es una estructura secuencial y
no se aprovechara del paralelismo en ningún caso, así pues, separar logs
en varios files no hace sentido excepto para problemas de espacio.

Saludos
Miguel Egea

"Maxi Accotto" wrote in message
news:

Hola Miguel, como estas? no es buena tecnica tener 3 logs en RAIDS
distintos? esto no mejora la performance? tenia entendido que dividir
los logs en raid distintos era una tecnica de performance.

Un saludo


Microsoft MVP SQLServer
www.sqltotalconsulting.com
-

"Miguel Egea" escribió en el mensaje de
noticias:

Si no te está dando problemas no lo cortes, porque siempre introduces
un factor de incertidumbre. Aún a´si no debiera tardar eso.

Me atrevería a decirte que es normal que no se te haya reducido el
tamaño. Porque el log es una estructura circular y solo recorta cuando
está al final.

Cosas que me llaman la atención. 3 ficheros de logs no tienen ningún
sentido si no es porque te falte espacio en el sitio donde esté el
principal. Al ser una estructura secuencial no te beneficia tener 3
logs ys si te complica la administración.

Para reducirlo adecuadamente yo me leería las faqs del grupo
http://www.helpdna.net/sqlserver_faq.htm , en el artículo número1.

Saludos
Miguel Egea




"mediocad" wrote in message
news:

Hola a todos,

Ayer lancé un Shrink de mi BD y resulta que han pasado 18 horas y
sigue en
proceso. La verdad es que no sé si sigue porque después de aceptar se
quedó
la ventana en pantalla y ahí sigue. Mi BD es de 14Gb. ¿Es normal
tanto
tiempo? Tampoco he visto que se haya reducido el tamaño.

Si me voy al administrador de tareas y finalizo la tarea, ¿Es posible
que se
dañe la BD? Por ahora se está trabajando contra ella y no da
problema.

La idea es reducir los logs y por eso primero intenté realizar esta
tarea.
Tengo 3 logs de 12Gb, 8Gb y 102Mb

Un saludo y gracias

Hola Miguel,

Ya estoy lanzando las consultas. He realizado los pasos 1 y 2. En el segundo
dices que les de tiempo. Ha pasado una hora y media. ¿A qué debo esperar?

Al hacer "dbcc shrinkfile (<nombre_log2>, EMPTYFILE)" debo constatar en el
explorador de windows que los logs están a 0 bytes. El de 8Gb he visto que ha
pasado a 4Gb pero el de 100Mb sigue igual. ¿Cómo se que han terminado?

¿Puedo pasar a hacer alter database remove file <nombre_log2> aunque tengan
ese tamaño? Si lo hago, ¿Qué pasa? ¿Desparecen físicamente o se quitan en la
BD solos y ya no los veo desde el Enterprise Manager? ¿O tengo que
eliminarlos desde el EM?

Gracias y un saludo

"Miguel Egea" wrote:

Te contesto en tu mensaje
"mediocad" wrote in message
news:
> Gracias por vuestras respuestas. Entonces sería hacer esto:
>
> 1. Hago backup desde el Enterprise Manager
2. ¿Cómo se hace eso?
Alter Database Tu BBDD set recovery simple
> 3. Checkpoint
Backup log <mibd> with truncate_only
estos pasos ya no son necesarios (ni checkpoint ni backup log)
> dbcc shrinkfile (<nombre_log1, 100)
dbcc shrinkfile (<nombre_log2, EMPTYFILE)
dbcc shrinkfile (<nombre_log3, EMPTYFILE)
y les das tiempo
> Para los dos últimos ¿Cómo se pone emptyfile)
> 4. Esto sería:
alter database remove file <nombre_log2>
alter database remove file <nombre_log3>
Alter DAtabase TUBBDDD set Recovery FULL
y vuelves a hacer un backup.

> 5. Plan de mantenimiento y backups lo miraré más tarde porque he leído a
> cerca de ello y tal vez no tenga que preguntar.
>
> Gracias y un saludo

Espero que se entienda :)

:) Pues encantado de haber ayudado

"Maxi Accotto" wrote in message
news:%

Si tienes razon, pero me dio la sensacion que no lo hacia asi :-S deberia
volver a armar la prueba que hice en su momento pero es logico que lo haga
como vos decis. Volvere a probar :-), de todas maneras trato de no hacer
la practica a menos que haya problemas de espacio, pero siempre me habia
quedado la inquietud como lo hacia SQL realemente



Microsoft MVP SQLServer
www.sqltotalconsulting.com
-

"Miguel Egea" escribió en el mensaje de
noticias:

En realidad llenaría primero uno y luego otro, supongo que la prueba te
dió resultados extraños. No puede llenar ambos a la vez y garantizar la
transaccionalidad..

Saludos
Miguel Egea
"Maxi Accotto" wrote in message
news:%

Gracias Miguel, tenia entendido que por mas que sea secuencial si lo
separas tenias paralelismo, de hecho una vez intente hacerlo y lo que
observe es que los llenaba parejos, si tenia 2 transacion log en dos
filegroups no es que llenaba primero uno y luego el otro, pero
francamente nunca hice una comparacion de performance real a ver si eso
tenia algun impacto :-S


Microsoft MVP SQLServer
www.sqltotalconsulting.com
-

"Miguel Egea" escribió en el mensaje de
noticias:

eso es correcto para ficheros de datos, pero no para el log de
transacciones. El log de transacciones es una estructura secuencial y
no se aprovechara del paralelismo en ningún caso, así pues, separar
logs en varios files no hace sentido excepto para problemas de espacio.

Saludos
Miguel Egea

"Maxi Accotto" wrote in message
news:

Hola Miguel, como estas? no es buena tecnica tener 3 logs en RAIDS
distintos? esto no mejora la performance? tenia entendido que dividir
los logs en raid distintos era una tecnica de performance.

Un saludo


Microsoft MVP SQLServer
www.sqltotalconsulting.com
-

"Miguel Egea" escribió en el mensaje de
noticias:

Si no te está dando problemas no lo cortes, porque siempre introduces
un factor de incertidumbre. Aún a´si no debiera tardar eso.

Me atrevería a decirte que es normal que no se te haya reducido el
tamaño. Porque el log es una estructura circular y solo recorta
cuando está al final.

Cosas que me llaman la atención. 3 ficheros de logs no tienen ningún
sentido si no es porque te falte espacio en el sitio donde esté el
principal. Al ser una estructura secuencial no te beneficia tener 3
logs ys si te complica la administración.

Para reducirlo adecuadamente yo me leería las faqs del grupo
http://www.helpdna.net/sqlserver_faq.htm , en el artículo número1.

Saludos
Miguel Egea




"mediocad" wrote in message
news:

Hola a todos,

Ayer lancé un Shrink de mi BD y resulta que han pasado 18 horas y
sigue en
proceso. La verdad es que no sé si sigue porque después de aceptar
se quedó
la ventana en pantalla y ahí sigue. Mi BD es de 14Gb. ¿Es normal
tanto
tiempo? Tampoco he visto que se haya reducido el tamaño.

Si me voy al administrador de tareas y finalizo la tarea, ¿Es
posible que se
dañe la BD? Por ahora se está trabajando contra ella y no da
problema.

La idea es reducir los logs y por eso primero intenté realizar esta
tarea.
Tengo 3 logs de 12Gb, 8Gb y 102Mb

Un saludo y gracias

Supongo que ya no te hará falta, lo siento estuve de viaje ¿como ha salido?

Saludos
miguel Egea

"mediocad" wrote in message
news:

Hola Miguel,

Ya estoy lanzando las consultas. He realizado los pasos 1 y 2. En el
segundo
dices que les de tiempo. Ha pasado una hora y media. ¿A qué debo esperar?

Al hacer "dbcc shrinkfile (<nombre_log2>, EMPTYFILE)" debo constatar en
el
explorador de windows que los logs están a 0 bytes. El de 8Gb he visto que
ha
pasado a 4Gb pero el de 100Mb sigue igual. ¿Cómo se que han terminado?

¿Puedo pasar a hacer alter database remove file <nombre_log2> aunque
tengan
ese tamaño? Si lo hago, ¿Qué pasa? ¿Desparecen físicamente o se quitan en
la
BD solos y ya no los veo desde el Enterprise Manager? ¿O tengo que
eliminarlos desde el EM?

Gracias y un saludo

"Miguel Egea" wrote:

Te contesto en tu mensaje
"mediocad" wrote in message
news:
> Gracias por vuestras respuestas. Entonces sería hacer esto:
>
> 1. Hago backup desde el Enterprise Manager
2. ¿Cómo se hace eso?
Alter Database Tu BBDD set recovery simple
> 3. Checkpoint
Backup log <mibd> with truncate_only
estos pasos ya no son necesarios (ni checkpoint ni backup log)
> dbcc shrinkfile (<nombre_log1, 100)
dbcc shrinkfile (<nombre_log2, EMPTYFILE)
dbcc shrinkfile (<nombre_log3, EMPTYFILE)
y les das tiempo
> Para los dos últimos ¿Cómo se pone emptyfile)
> 4. Esto sería:
alter database remove file <nombre_log2>
alter database remove file <nombre_log3>
Alter DAtabase TUBBDDD set Recovery FULL
y vuelves a hacer un backup.

> 5. Plan de mantenimiento y backups lo miraré más tarde porque he leído
> a
> cerca de ello y tal vez no tenga que preguntar.
>
> Gracias y un saludo

Espero que se entienda :)