Ola El vacuum full atrapa la tabla y no la suelta asi que teoricamente Si, al ser pg_atibutte una tabla de catalogo es probable que este no te permita ver varias cosas e la BD
Pero es mejor bajar tus servicios unos momentos a que tu base de datos se dañe El 30 de diciembre de 2011 09:25, Juan Carlos Ramirez Zambrano < [email protected]> escribió: > > > El 30 de diciembre de 2011 09:16, Miguel Angel Hernandez Moreno < > [email protected]> escribió: > > Saludos Juan >> >> Conociendo el problema que tienes y la BD te comento >> >> Como te dijo Alvaro tienes un problema de bloat, tienes que hacer el full >> a pg_atribute >> Los mantenimientos haslos mas frecuentes a lso esquemas, yo lo hacia 3 >> veces a la semana >> Los mantenimientos a tabas mas grandes haslos aun con mas frecuencia, yo >> lo hacia diario >> La Replicacion por Streaming te llevaria el error a la Otra BD >> >> Para que tengas un buen plan de manteniminetos activa el autovacuum y a >> las tablas mas grandes >> dejaselos por cron. >> >> Contempla que si tienes desactivado el autovacuum y no le das >> mantenimientos a tu bd puede que >> la DB te pida un vacuum con una conexion stand-alone, mejor aumenta la >> frecuencia de los >> mantenimientos >> > > Que hay Miguel, se estan haicendo los mantenimientos continuas la bronca > es que ahorita a uno se pueden termianar al 100% por que causan lentitud > pero ya se tienen programados por cron cada 3 dia. > > Comenats hacer un vacuum full a pg atribute, pero esto significa que de > debe dejar fuera la base de datos? > > Saludos y Gracias > >> >> El 30 de diciembre de 2011 09:00, Alvaro Herrera <[email protected] >> > escribió: >> >>> >>> Excerpts from Juan Carlos Ramirez Zambrano's message of vie dic 30 >>> 11:07:40 -0300 2011: >>> >>> > Te comento por que ese pensó en un plan asi. >>> > >>> > La base de datos que tengo pesa al rededor de 500 GB >>> > Tiene 14 esquemas >>> > El esquema mas grande tiene 180 tablas >>> > La tabla mas grande pesa al rededor de 100 GB >>> > Otras pensan en 20 y 30 GB >>> > >>> > Se penso en separar los mantenimientos por que si se ejecuta el vacuum >>> para >>> > el pg_attribute se tarda demasiado, de echo el ultimo que se ha estado >>> > haciendo es un autovacuum que entro solo y lleva 15 horas, >>> > el ultimo autovaccum que se había realizado de esta tabla fue el sabado >>> > pasado. >>> >>> Creo que tu problema con pg_attribute es serio y amerita una limpieza >>> grande estilo VACUUM FULL. Es posible que haya mucho "bloat" en la >>> tabla que vacuum normal no podrá limpiar. >>> >>> > Y el de las tablas grandes esta tardadon hasta 5 horas pro tabla y >>> esto nos >>> > pega con lentitud. >>> >>> El que vacuum se demore mucho no debería paliarse con ejecutarse menos; >>> todo lo contrario. Debería ejecutarse lo más seguido posible. >>> >>> > Ultimamnete se han estado teniendo problemas por el comportamiento de >>> la >>> > base de datos, se ha pensado en realizar la replicaicon, pero si se >>> hace >>> > esto, se pueden heredar los problemas ? >>> >>> La replicación no sería una solución a los problemas. Te recomiendo que >>> ni lo pienses hasta que hayas solucionado tu problema con vacuum. >>> >>> -- >>> Álvaro Herrera <[email protected]> >>> - >>> Enviado a la lista de correo pgsql-es-ayuda ( >>> [email protected]) >>> Para cambiar tu suscripción: >>> http://www.postgresql.org/mailpref/pgsql-es-ayuda >>> >> >> >> >> -- >> ISC Miguel Angel Hernandez Moreno >> >> > -- ISC Miguel Angel Hernandez Moreno
