Problemas con Postgresql vers. 7.4 !!!

[Patricio Rojas O.]

Angelo,

On lun, 2005-11-21 at 12:50 -0300, Alvaro Herrera wrote:
> angelo astorga escribió:
> > Hola Lista, Tengo una BD en postgresql vers. 7.4
> > trabajando con un sistema, donde existen SELECT y
> > UPDATE concurrente cada 20 seg. durante todo el día
> > (peor caso)... con el tiempo nos hemos dado cuenta que
> > el sistema se pone bastante lento y dicha lentitud,
> > tiene mucha relación con la BD, de hecho hemos
> > encontrado una o dos tablas corruptas, que al eliminar

Todas las bases de datos de alguna forma tienen dentro una aplicación
que se llama "Update Stadistics" (debe activarse manualmente), un
actualizador de estadísticas que debe activarse todas las noches en
proceso batch. Las estadisticas tienen que ver con el arbol binario de
cómo se almacenan en el disco duro los índices, el factor de relleno,
etc.


> > y volver a crearlas, el sistema se pone mas rapido...
> > Nuestra pregunta va asociada a esta ultima afirmación,
> > es decir, esta versión de postgresql tiene algun tipo
> > de falla relacionada con el tema de corrupción de
> > tablas en el tiempo ¿¿??, debido a su uso concurrente
> > y continuo dentro del dia...¿¿??
> 

> Tablas corruptas?  Como se manifiesta esta corrupcion?  Me interesa
> mucho el asunto, si puedes dar mas informacion seria muy bueno.
> 
> En respuesta a tu pregunta: no, se supone que las tablas no se corrompen
> por el uso.  Si eso sucede, es un bug o una falla de hardware (estas
> ultimas son mas frecuentes de lo que uno cree).
> 
> Que version exacta de Postgres tienes?  Pega aca la salida de "SELECT
> version()" completa, por favor.
> 
> > Por otra parte y a modo de comentario, realizamos
> > primero ANALYZE a la BD y posteriormente VACUUM sobre
> > cada tabla y en forma diaria... La BD esta montada
> > sobre un server con CPU neon, hdd scsi y 1 Gb RAM y
> > los select y update, se hacen sobre los campos que
> > corresponden... este ultimo comentario, lo hago por el
> > tema de corrupción, ya que he escuchado que no es
> > bueno hacer el analyze y vacuum en forma diaria...¿?
> 
> Vamos a ver, VACUUM es una operacion que es absolutamente necesaria, ya
> sea en forma diaria o cada X minutos o una vez a la semana.  La
> frecuencia depende de que tantos UPDATE/DELETE haya sobre la tabla.  
> Quizas tu problema es que tienes que hacer VACUUM sobre esas dos tablas
> mas a menudo.  De que tamaño es la tabla, y que tantos UPDATEs se hacen?


Ahora optimizar una base de datos requiere de sintinizar todo el
conjunto como tarjeta de red, tiempo de acceso al disco duro, cantidad
de memoria del servidor, configuración de la base de datos, estrategia
de bloqueo, tamaño de buffer de la bd.

saludos.
-- 
Patricio Rojas : tronx76 en gmail.com
Public key     : http://www.threboll.com/gpgkey_tronx76_at_gmail_com.asc
Key fingerprint: 9745 FEE4 91AF F375 A06E  F9EE 0DD3 263D D6C0 1D05