________________________________
Hace poco atras se comento y se hizo referencia al peligro de hacer vacuum full
en bases de datos en producion, vee el historial
aqui hago referncia a una respuesta que envio Jaime al respecto
"esa es una de las razones por las que el VACUUM FULL no se recomienda.
Pero la mas importante según creo yo (aunque existe la teoria, aun sin
confirmar, de que me puedo equivocar ;) es que el VACUUM FULL necesita
de bloqueos muy estrictos y por supuesto no se puede hacer mientras
los usuarios estan trabajando... VACUUM normal en cambio puede
convivir con las demas transacciones y operaciones normales de la base
de datos.
http://www.postgresql.org/docs/8.3/static/routine-vacuuming.html
VACUUM FULL is recommended for cases where you know you have deleted
the majority of rows in a table, so that the steady-state size of the
table can be shrunk substantially with VACUUM FULL's more aggressive
approach. Use plain VACUUM, not VACUUM FULL, for routine vacuuming for
space recovery.
"
El 30 de enero de 2009 8:30, Gabriel Ferro <gabrielrfe...@yahoo.com.ar>
escribió:
Siguiendo con el problema de BD muy grandes....
Se me dio por hacer un vacuum verbose analyze que funciono batante rapido, pero
luego se me dio por hacer un vacuum full y hace como 20 hs que esta
corriendo... como me olvide de verbose no tengo ni idea que cornos esta
haciendo.... lo tendre que detener con ctrl+c?, se puede sin peligro?.. que me
recomendarian?... talvez usar cluster para cada tabla?
________________________________
--
Cesar Erices Vergara
Ingeniero en Gestión Informática
Analista de Sistema
Santiago - Chile
Ok.. pero aun no esta en produccion.. justamente la quiero tener lista y
optimizada para esto.
Yahoo! Cocina
Recetas prácticas y comida saludable
http://ar.mujer.yahoo.com/cocina/
