El 08/02/2010 21:08, Andrés P.P. escribió:
Hola!
Perdonen lo extenso..Creo tener la solución al siguiente problema pero
lo quiero validar con Uds. antes de aplicarlo.
Tengo una BD pequeña en la cual hay 4 tablas que tiene actividad cada
10 minutos que incluyen update y delete y en las cuales se ejecuta un
vacuum en cada uno de esos ciclos (10 minutos).... no ha sido
necesario configurar un autovacuum ya que el nivel de carga es bajo.
La BD en general funciona bien, sin embargo en esta actividad que se
da cada 10 minutos existe la siguiente linea:
*vacuum full analyze bd_catalog.tab_tmp_carga; <-- esta tabla se vacía
y carga en cada ciclo...poca data..*
..su ejecución está enviando el siguiente error:
*ERROR: duplicate key violates unique constraint
"pg_statistic_relid_att_index"*
al truncar la tabla SÍ puedo realizar el vacuum sin problemas, pero en
cuanto ingresa data vuelve a aparecer el error al momento del vacuum..
También intenté borrar la tabla , pero me dio error:
*drop table bd_catalog.tab_tmp_carga;
ERROR: cache lookup failed for relation 41335
*
Al revisar el contenido de la tabla pg_statistic me encuentro con lo
siguiente:
*/select starelid,staattnum, count(*) from pg_statistic group by
starelid,staattnum having count(*)>1;
starelid | staattnum | count
----------+-----------+-------
16918 | 1 | 2
16918 | 3 | 2
16927 | 2 | 2
16927 | 3 | 2
16927 | 4 | 2
/*
Como decía, la carga es baja y la aplicación sigue funcionando "bien",
sin embargo me preocupa que no se esté realizando el vacuum porque a
la larga empezará a afectar el desempeño. Hace unos años atrás me pasó
algo similar y lo que hice fue recrear la BD, cargar un respaldo del
momento con la data y ejecutar los vacuum sobre los objetos necesarios
y listo... fueron unos 10 minutos en todo el proceso y desde entonces
no se habían presentado problema. Sin embargo, ahora quiero aplicar
una solución que sea más correcta de acuerdo a lo que Uds. me
confirmen o me indiquen.
Solución:
Googleando me encontré con la siguiente solución:
*/delete from pg_statistic;
reindex table pg_statistic;
vacuum analyze;
/*
... no he querido traerme un full backup para ver si se trae el error
consigo y probar la solución en desarrollo.
En fin..
Consultas:
Si hago lo que encontré en google estaría eliminando todas las
estadísticas... cierto??.. es posible solo borrar lo que necesite
para la tabla con el problema en particular??... cómo hago esa
asociación?.... es necesario el reindex en caso que el delete sea
parcial??.. Finalmente, el "vacuum analyze" lo podría reemplazar por
el vacuum que uso sobre la tabla del problema solamente.
Estoy claro que independiente de la solución... hay un problema en la
aplicación que está causando esta corrupción... pero eso lo dejaré
para otra futura consulta ya que trata sobre replicación...(pero
insisto..es otro cuento..).
Gracias desde ya.. y nuevamente, perdonen lo extenso.
Saludos
Andrés
Te pregunto algo. ¿Si tienes pocos UPDATES/INSERT/DELETE por qué existe
la necesidad de ejecutar VACUUM ANALYZE cada 10 mins?
Realmente no veo por qué. VACUUM se usa frecuentemente cuando existen
muchas consultas DML, pero el tiempo que veo acá, es muy pequeño a mi
entender, y no hay necesidad de hacer eso en ese tiempo.
No recomiendo borrar el contenido de pg_statitic, ya que puede servirte
de mucho, además que ayuda al optimizador para la ejecución del plan de
las consultas; por lo que estarías trabajando sin estadísticas, por lo
que el optimizador pudiera no trabajar correctamente. No tengo mucho
conocimiento del tema, pero al menos es lo que creo.
Mi recomendación sería incrementar el tiempo de ejecución de VACUUM ANALYZE
Saludos
--
--------------------------------------------------------------------------------
"Para ser realmente grande, hay que estar con la gente, no por encima de ella."
Montesquieu
Ing. Marcos Luís Ortíz Valmaseda
PostgreSQL System DBA&& DWH -- BI Apprentice
Centro de Tecnologías de Almacenamiento y Análisis de Datos (CENTALAD)
Universidad de las Ciencias Informáticas
Linux User # 418229
-- PostgreSQL --
"TIP 4: No hagas 'kill -9' a postmaster"
http://www.postgresql-es.org
http://www.postgresql.org
http://www.planetpostgresql.org
-- DWH + BI --
The Data WareHousing Institute
http://www.tdwi.org
http://www.tdwi.org/cbip
---------------------------------------------------------------------------------
