Re: [pgsql-es-ayuda] Vacuum
Gracias Gerardo / Hellmuth, efectivamente, tenia una conexión en "idle
in transaction" desde hacia un me, al matarla y volver con el vacuum
manual (el full) todo volvió a la normalidad.
On 2017-06-05 10:18, Hellmuth Vargas wrote:
Hola Diego
En primer lugar, esto sucede porque
- autovacuum inactivo
- no tenga programado tareas de mantenimiento diarias con VACUUM ó
*- Exista una transacción antigua, sin resolver, que no ha permitido
la ejecución del mantenimiento respectivo.*
Ahora bien, porque la tabla presenta este tamaño si tan solo tiene
algunos registros?, PostgreSQL, implementan un mecanismo llamado MVCC,
lo que permite mantener varias "versiones" de un registro vigentes en
el espacio de una transacción en particular (para cumplir con los
postulados *ACID*-*A*tomicity, *C*onsistency, *I*solation and
*D*urability: Atomicidad, Consistencia, *Aislamiento* y Durabilidad en
español): cada vez que se actualiza una fila, en realidad la fila es
marcada como obsoleta y se inserta la nueva versión de la misma, por
lo tanto, una tabla con muchas actualizaciones podría tener un tamaño
grande con respecto a la cantidad de registros vigentes que en
realidad contiene y ahí es donde entra el VACUUM y específicamente el
autovacuum, el cual monitorea las operaciones en las tablas y realiza
el mantenimiento sobre las mismas marcando las filas obsoletas como
disponibles para contener nuevos registros (siempre y cuando no exista
una transacción pendiente que la emplee) para su reutilización
posterior o incluso (en el caso del VACUUM FULL) devuelve este
espacio al sistema operativo.
Como primer aproximación, verifique en la visita pg_stat_activity si
existen transacciones muy viejas aun sin resolver
El 5 de junio de 2017, 07:39, Gerardo Herzig<gher...@fmed.uba.ar
<mailto:gher...@fmed.uba.ar>> escribió:
- Mensaje original -
> De: "Diego" <diego...@gmail.com <mailto:diego...@gmail.com>>
> Para: pgsql-es-ayuda@postgresql.org
<mailto:pgsql-es-ayuda@postgresql.org>
> Enviados: Lunes, 5 de Junio 2017 8:43:18
> Asunto: [pgsql-es-ayuda] Vacuum
>
> Buenos días Postgresistas,
>
> Hoy les escribo para consultarles sobre una situación que me
pasa con
> una tabla.
> Esta tabla tiene 31 registros y 3 campos, una pk y un indice,
después de
> un tiempo me doy cuenta que ocupa 595 MBs y 577 MBs de indices.
>
> Le hice un Vacuum manual a la tabla y arrojo lo siguiente sin
reducir el
> tamaño:
>
>
Vacuum "a secas" no elimina espacio, mas bien lo reorganiza. Lo
que vos queres se logra con VACUUM FULL, o recreandola (en la
manera supongo que hiciste).
HTH,
Gerardo
-
Enviado a la lista de correo pgsql-es-ayuda
(pgsql-es-ayuda@postgresql.org <mailto:pgsql-es-ayuda@postgresql.org>)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
<http://www.postgresql.org/mailpref/pgsql-es-ayuda>
--
Cordialmente,
Ing. Hellmuth I. Vargas S.
Re: [pgsql-es-ayuda] Vacuum
Hola Diego En primer lugar, esto sucede porque - autovacuum inactivo - no tenga programado tareas de mantenimiento diarias con VACUUM ó *- Exista una transacción antigua, sin resolver, que no ha permitido la ejecución del mantenimiento respectivo.* Ahora bien, porque la tabla presenta este tamaño si tan solo tiene algunos registros?, PostgreSQL, implementan un mecanismo llamado MVCC, lo que permite mantener varias "versiones" de un registro vigentes en el espacio de una transacción en particular (para cumplir con los postulados *ACID*-*A*tomicity, *C*onsistency, *I*solation and *D*urability: Atomicidad, Consistencia, *Aislamiento* y Durabilidad en español): cada vez que se actualiza una fila, en realidad la fila es marcada como obsoleta y se inserta la nueva versión de la misma, por lo tanto, una tabla con muchas actualizaciones podría tener un tamaño grande con respecto a la cantidad de registros vigentes que en realidad contiene y ahí es donde entra el VACUUM y específicamente el autovacuum, el cual monitorea las operaciones en las tablas y realiza el mantenimiento sobre las mismas marcando las filas obsoletas como disponibles para contener nuevos registros (siempre y cuando no exista una transacción pendiente que la emplee) para su reutilización posterior o incluso (en el caso del VACUUM FULL) devuelve este espacio al sistema operativo. Como primer aproximación, verifique en la visita pg_stat_activity si existen transacciones muy viejas aun sin resolver El 5 de junio de 2017, 07:39, Gerardo Herzig<gher...@fmed.uba.ar> escribió: > > > - Mensaje original - > > De: "Diego" <diego...@gmail.com> > > Para: pgsql-es-ayuda@postgresql.org > > Enviados: Lunes, 5 de Junio 2017 8:43:18 > > Asunto: [pgsql-es-ayuda] Vacuum > > > > Buenos días Postgresistas, > > > > Hoy les escribo para consultarles sobre una situación que me pasa con > > una tabla. > > Esta tabla tiene 31 registros y 3 campos, una pk y un indice, después de > > un tiempo me doy cuenta que ocupa 595 MBs y 577 MBs de indices. > > > > Le hice un Vacuum manual a la tabla y arrojo lo siguiente sin reducir el > > tamaño: > > > > > > Vacuum "a secas" no elimina espacio, mas bien lo reorganiza. Lo que vos > queres se logra con VACUUM FULL, o recreandola (en la manera supongo que > hiciste). > > HTH, > Gerardo > > - > Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org > ) > Para cambiar tu suscripción: > http://www.postgresql.org/mailpref/pgsql-es-ayuda > -- Cordialmente, Ing. Hellmuth I. Vargas S.
Re: [pgsql-es-ayuda] Vacuum
- Mensaje original - > De: "Diego" <diego...@gmail.com> > Para: pgsql-es-ayuda@postgresql.org > Enviados: Lunes, 5 de Junio 2017 8:43:18 > Asunto: [pgsql-es-ayuda] Vacuum > > Buenos días Postgresistas, > > Hoy les escribo para consultarles sobre una situación que me pasa con > una tabla. > Esta tabla tiene 31 registros y 3 campos, una pk y un indice, después de > un tiempo me doy cuenta que ocupa 595 MBs y 577 MBs de indices. > > Le hice un Vacuum manual a la tabla y arrojo lo siguiente sin reducir el > tamaño: > > Vacuum "a secas" no elimina espacio, mas bien lo reorganiza. Lo que vos queres se logra con VACUUM FULL, o recreandola (en la manera supongo que hiciste). HTH, Gerardo - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripci�n: http://www.postgresql.org/mailpref/pgsql-es-ayuda
[pgsql-es-ayuda] Vacuum
Buenos días Postgresistas, Hoy les escribo para consultarles sobre una situación que me pasa con una tabla. Esta tabla tiene 31 registros y 3 campos, una pk y un indice, después de un tiempo me doy cuenta que ocupa 595 MBs y 577 MBs de indices. Le hice un Vacuum manual a la tabla y arrojo lo siguiente sin reducir el tamaño: INFO: haciendo vacuum a «intercambio.o_registros» INFO: «o_registros»: se encontraron 0 versiones eliminables de filas y 10500455 no eliminables en 76218 páginas DETAIL: 10500424 versiones muertas de filas no pueden ser eliminadas aún. CPU 21.83s/14.73u sec elapsed 62.91 sec. INFO: analizando «intercambio.o_registros» INFO: «o_registros»: se procesaron 3 de 76162 páginas, que contenían 3 filas vigentes y 4135367 filas no vigentes; 3 filas en la muestra, 6364358 total de filas estimadas Query returned successfully with no result in 02:25 minutes. Si bien, cree una tabla al lado pase los registros y renombre todo, me queda la duda... ¿por que? ¿alguna sugerencia? Desde ya, muchísimas gracias!
RE: [pgsql-es-ayuda] Vacuum a una tablas
Hola Jaime y Fernando, ...gracias por las respuestas , justo ayer leí sobre lo que me indica Jaime y me di cuenta de lo que dices, lo solucione llamando al vacuum desde un script en bash que recibe como parámetro el nombre de la tabla. Saludos -Mensaje original- De: jcasa...@systemguards.com.ec [mailto:jcasa...@systemguards.com.ec] En nombre de Jaime Casanova Enviado el: sábado, 27 de abril de 2013 23:16 Para: Fernando Hevia CC: Mario Alberto Soto Cordones; Ayuda; pgsql-es-ayuda-ow...@postgresql.org Asunto: Re: [pgsql-es-ayuda] Vacuum a una tablas 2013/4/27 Fernando Hevia fhe...@gmail.com: Si se puede ejecutar vacuum en una función. Sería un buen comienzo que postees el comando tal cual lo ejecutas y el error que arroja. no, no se puede Mira las notas en http://www.postgresql.org/docs/9.2/static/sql-vacuum.html VACUUM cannot be executed inside a transaction block. -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación Phone: +593 4 5107566 Cell: +593 987171157 - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripción: http://www.postgresql.org/mailpref/pgsql-es-ayuda
[pgsql-es-ayuda] Vacuum a una tablas
Hola Lista: Estoy tratando de hacer un vacuum a una tabla cuyo nombre se pasa por parámetro dentro de un script o una unción, en ninguno de los 2 casos me funciona, solo me funciona el vacuumdb, pero eso no es lo que quiero ..alguien me puede ayudar Saludos Mario Soto
Re: [pgsql-es-ayuda] Vacuum a una tablas
2013/4/27 Mario Alberto Soto Cordones marioa.soto.cordo...@gmail.com ** ** Hola Lista: ** ** Estoy tratando de hacer un vacuum a una tabla cuyo nombre se pasa por parámetro dentro de un script o una unción, en ninguno de los 2 casos me funciona, solo me funciona el vacuumdb, pero eso no es lo que quiero ** ** ..alguien me puede ayudar ** Si se puede ejecutar vacuum en una función. Sería un buen comienzo que postees el comando tal cual lo ejecutas y el error que arroja.
RE: [pgsql-es-ayuda] Vacuum a una tablas
SQL state: 0A000 Hint: Use a BEGIN block with an EXCEPTION clause instead. Context: PL/pgSQL function respalda_msj line 52 at SQL statement De: Fernando Hevia [mailto:fhe...@gmail.com] Enviado el: sábado, 27 de abril de 2013 12:27 Para: Mario Alberto Soto Cordones CC: Ayuda; pgsql-es-ayuda-ow...@postgresql.org Asunto: Re: [pgsql-es-ayuda] Vacuum a una tablas 2013/4/27 Mario Alberto Soto Cordones marioa.soto.cordo...@gmail.com Hola Lista: Estoy tratando de hacer un vacuum a una tabla cuyo nombre se pasa por parámetro dentro de un script o una unción, en ninguno de los 2 casos me funciona, solo me funciona el vacuumdb, pero eso no es lo que quiero ..alguien me puede ayudar Si se puede ejecutar vacuum en una función. Sería un buen comienzo que postees el comando tal cual lo ejecutas y el error que arroja.
Re: [pgsql-es-ayuda] Vacuum a una tablas
2013/4/27 Fernando Hevia fhe...@gmail.com: Si se puede ejecutar vacuum en una función. Sería un buen comienzo que postees el comando tal cual lo ejecutas y el error que arroja. no, no se puede Mira las notas en http://www.postgresql.org/docs/9.2/static/sql-vacuum.html VACUUM cannot be executed inside a transaction block. -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación Phone: +593 4 5107566 Cell: +593 987171157 - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripción: http://www.postgresql.org/mailpref/pgsql-es-ayuda
Re: [pgsql-es-ayuda] Vacuum, analyze y reindex
Alvaro, En el caso de generar indices que sería lo recomendable, re generarlos antes del VACUUM FREEZE ANALYZE, o despues de ese paso? Saludos y Gracias Eduardo. 2012/11/22 Alvaro Herrera alvhe...@2ndquadrant.com Sergio Valdes Hurtado escribió: Una cosa importante que me olvidé de mencionar, es que esta base de datos es una epecie de data warehouse y estas cargas masivas de datos son las únicas transacciones que agregan o quitan data, todo lo demas son consultas de selección. Yo haría algo así: DELETE masivo VACUUM INSERT masivo VACUUM FREEZE ANALYZE Asegúrate de tener maintenance_work_mem lo más alto que puedas permitirte. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org ) Para cambiar tu suscripción: http://www.postgresql.org/mailpref/pgsql-es-ayuda -- Eduardo Arenas Castillo. Jefe Unidad de Gestión de Información Ancora UC - Red de Centros de Salud Familiar of. + 56 2 587 93 03 - cel. +56 9 6629 1618
Re: [pgsql-es-ayuda] Vacuum, analyze y reindex
Eduardo Arenas C. escribió: Alvaro, En el caso de generar indices que sería lo recomendable, re generarlos antes del VACUUM FREEZE ANALYZE, o despues de ese paso? Si los vas a borrar, hazlo antes de la eliminación masiva y agrégalos después que todo está listo. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripción: http://www.postgresql.org/mailpref/pgsql-es-ayuda
Re: [pgsql-es-ayuda] Vacuum, analyze y reindex
Alvaro, ok gracias saludos eduardo 2012/11/27 Alvaro Herrera alvhe...@2ndquadrant.com Eduardo Arenas C. escribió: Alvaro, En el caso de generar indices que sería lo recomendable, re generarlos antes del VACUUM FREEZE ANALYZE, o despues de ese paso? Si los vas a borrar, hazlo antes de la eliminación masiva y agrégalos después que todo está listo. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Eduardo Arenas Castillo. Jefe Unidad de Gestión de Información Ancora UC - Red de Centros de Salud Familiar of. + 56 2 587 93 03 - cel. +56 9 6629 1618
Re: [pgsql-es-ayuda] Vacuum, analyze y reindex
Y con que frecuencia realizas vacuum y analyze? Ten en cuenta que realizar analyze permitirá actualizar los planes de ejecución de la base de datos y mediante vacuum eliminas las tuplas muertas, disminuyendo espacio en disco y mejorando el rendimiento. Yo particularmente tengo el autovacuum del server activado para que estas tareas se lleven a cabo por si solas automáticamente. Saludos. - Mensaje original - Estimados, uso postgres 9.1 en Windows y una vez al mes se hace un proceso de carga de datos a una serie de tablas en una base de datos. El proceso consiste en borrar la data del año y cargarla actualizada nuevamente, utilizando Kettle de Pentaho. Luego de la carga realizo un Vacuum de la base de datos y no utilizo ninguna opción del vacuum. Aqui van mis dudas: ¿Esta bien que haga ese vacuum sin opciones, o será conveniente usar alguna de las tres opciones del vacuum (Full, Freeze, Analyze)? ¿Será necesario ejecutar un reindex? ¿Será necesario ejecutar un analyze? Saludos cordiales a todos y gracias de antemano por su ayuda. -- Sergio Valdés H. 10mo. ANIVERSARIO DE LA CREACION DE LA UNIVERSIDAD DE LAS CIENCIAS INFORMATICAS... CONECTADOS AL FUTURO, CONECTADOS A LA REVOLUCION http://www.uci.cu http://www.facebook.com/universidad.uci http://www.flickr.com/photos/universidad_uci
Re: [pgsql-es-ayuda] Vacuum, analyze y reindex
Ten en cuenta que cuando borrasun voluen alto de data el indice puede sufrir de bloat. En esta pagina hay uaconsulta para ver los objetos con bloat http://wiki.postgresql.org/wiki/Show_database_bloat si el indice esta en la lsita entonces realiza un reindex --- On Thu, 11/22/12, Sergio Valdes Hurtado svh.pg...@gmail.com wrote: From: Sergio Valdes Hurtado svh.pg...@gmail.com Subject: [pgsql-es-ayuda] Vacuum, analyze y reindex To: Lista PostgreSql pgsql-es-ayuda@postgresql.org Date: Thursday, November 22, 2012, 1:36 PM Estimados, uso postgres 9.1 en Windows y una vez al mes se hace un proceso de carga de datos a una serie de tablas en una base de datos. El proceso consiste en borrar la data del año y cargarla actualizada nuevamente, utilizando Kettle de Pentaho. Luego de la carga realizo un Vacuum de la base de datos y no utilizo ninguna opción del vacuum. Aqui van mis dudas: ¿Esta bien que haga ese vacuum sin opciones, o será conveniente usar alguna de las tres opciones del vacuum (Full, Freeze, Analyze)? ¿Será necesario ejecutar un reindex? ¿Será necesario ejecutar un analyze? Saludos cordiales a todos y gracias de antemano por su ayuda. -- Sergio Valdés H.
Re: [pgsql-es-ayuda] Vacuum, analyze y reindex
El autovacuum esta activado, pero no realizo analyze. Además ejecuto un vacuum manualmente despues del proceso de carga, ya que en algunas tablas se eliminan y graban alrededor de 3 millones de registros. Saludos El 22 de noviembre de 2012 10:44, Lazaro Ruben Garcia Martinez lgarc...@uci.cu escribió: Y con que frecuencia realizas vacuum y analyze? Ten en cuenta que realizar analyze permitirá actualizar los planes de ejecución de la base de datos y mediante vacuum eliminas las tuplas muertas, disminuyendo espacio en disco y mejorando el rendimiento. Yo particularmente tengo el autovacuum del server activado para que estas tareas se lleven a cabo por si solas automáticamente. Saludos. -- Estimados, uso postgres 9.1 en Windows y una vez al mes se hace un proceso de carga de datos a una serie de tablas en una base de datos. El proceso consiste en borrar la data del año y cargarla actualizada nuevamente, utilizando Kettle de Pentaho. Luego de la carga realizo un Vacuum de la base de datos y no utilizo ninguna opción del vacuum. Aqui van mis dudas: ¿Esta bien que haga ese vacuum sin opciones, o será conveniente usar alguna de las tres opciones del vacuum (Full, Freeze, Analyze)? ¿Será necesario ejecutar un reindex? ¿Será necesario ejecutar un analyze? Saludos cordiales a todos y gracias de antemano por su ayuda. -- Sergio Valdés H. http://www.uci.cu/ -- Sergio Valdés H.
Re: [pgsql-es-ayuda] Vacuum, analyze y reindex
Para el analyze automático, puedes revisar los siguientes parámetros de configuración, además autovacuum debe estar en on. Saludos. - Mensaje original - El autovacuum esta activado, pero no realizo analyze. Además ejecuto un vacuum manualmente despues del proceso de carga, ya que en algunas tablas se eliminan y graban alrededor de 3 millones de registros. Saludos El 22 de noviembre de 2012 10:44, Lazaro Ruben Garcia Martinez lgarc...@uci.cu escribió: Y con que frecuencia realizas vacuum y analyze? Ten en cuenta que realizar analyze permitirá actualizar los planes de ejecución de la base de datos y mediante vacuum eliminas las tuplas muertas, disminuyendo espacio en disco y mejorando el rendimiento. Yo particularmente tengo el autovacuum del server activado para que estas tareas se lleven a cabo por si solas automáticamente. Saludos. Estimados, uso postgres 9.1 en Windows y una vez al mes se hace un proceso de carga de datos a una serie de tablas en una base de datos. El proceso consiste en borrar la data del año y cargarla actualizada nuevamente, utilizando Kettle de Pentaho. Luego de la carga realizo un Vacuum de la base de datos y no utilizo ninguna opción del vacuum. Aqui van mis dudas: ¿Esta bien que haga ese vacuum sin opciones, o será conveniente usar alguna de las tres opciones del vacuum (Full, Freeze, Analyze)? ¿Será necesario ejecutar un reindex? ¿Será necesario ejecutar un analyze? Saludos cordiales a todos y gracias de antemano por su ayuda. -- Sergio Valdés H. -- Sergio Valdés H. 10mo. ANIVERSARIO DE LA CREACION DE LA UNIVERSIDAD DE LAS CIENCIAS INFORMATICAS... CONECTADOS AL FUTURO, CONECTADOS A LA REVOLUCION http://www.uci.cu http://www.facebook.com/universidad.uci http://www.flickr.com/photos/universidad_uci
Re: [pgsql-es-ayuda] Vacuum, analyze y reindex
Una cosa importante que me olvidé de mencionar, es que esta base de datos es una epecie de data warehouse y estas cargas masivas de datos son las únicas transacciones que agregan o quitan data, todo lo demas son consultas de selección. El 22 de noviembre de 2012 11:46, Lazaro Ruben Garcia Martinez lgarc...@uci.cu escribió: Para el analyze automático, puedes revisar los siguientes parámetros de configuración, además autovacuum debe estar en on. Saludos. -- El autovacuum esta activado, pero no realizo analyze. Además ejecuto un vacuum manualmente despues del proceso de carga, ya que en algunas tablas se eliminan y graban alrededor de 3 millones de registros. Saludos El 22 de noviembre de 2012 10:44, Lazaro Ruben Garcia Martinez lgarc...@uci.cu escribió: Y con que frecuencia realizas vacuum y analyze? Ten en cuenta que realizar analyze permitirá actualizar los planes de ejecución de la base de datos y mediante vacuum eliminas las tuplas muertas, disminuyendo espacio en disco y mejorando el rendimiento. Yo particularmente tengo el autovacuum del server activado para que estas tareas se lleven a cabo por si solas automáticamente. Saludos. -- Estimados, uso postgres 9.1 en Windows y una vez al mes se hace un proceso de carga de datos a una serie de tablas en una base de datos. El proceso consiste en borrar la data del año y cargarla actualizada nuevamente, utilizando Kettle de Pentaho. Luego de la carga realizo un Vacuum de la base de datos y no utilizo ninguna opción del vacuum. Aqui van mis dudas: ¿Esta bien que haga ese vacuum sin opciones, o será conveniente usar alguna de las tres opciones del vacuum (Full, Freeze, Analyze)? ¿Será necesario ejecutar un reindex? ¿Será necesario ejecutar un analyze? Saludos cordiales a todos y gracias de antemano por su ayuda. -- Sergio Valdés H. http://www.uci.cu/ -- Sergio Valdés H. http://www.uci.cu/ -- Sergio Valdés H.
Re: [pgsql-es-ayuda] Vacuum, analyze y reindex
Sergio Valdes Hurtado escribió: Una cosa importante que me olvidé de mencionar, es que esta base de datos es una epecie de data warehouse y estas cargas masivas de datos son las únicas transacciones que agregan o quitan data, todo lo demas son consultas de selección. Yo haría algo así: DELETE masivo VACUUM INSERT masivo VACUUM FREEZE ANALYZE Asegúrate de tener maintenance_work_mem lo más alto que puedas permitirte. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripción: http://www.postgresql.org/mailpref/pgsql-es-ayuda
[pgsql-es-ayuda] Vacuum analize no actualiza el campo last vacuum de la tabla
Buenos días a todos, Estoy ejecutando un [ vacuumdb --analyze --table \ARQ076\ SBU ] desde la consola del servidor Linux, donde está instalado el Postgres 8.2, pero cuando acaba el vacuum, consulto la tabla por PgAdmin y los campos Last Vacuum y Last Analyze continúan en blanco. Los campos Last Autovacuum y Last Autoanalyze se mantienen con fechas más antiguas. ¿Hay alguna forma de actualizar estos campos o debería ser automático? Saludos a todos, Antonio Salas Mena - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripci�n: http://www.postgresql.org/mailpref/pgsql-es-ayuda
Re: [pgsql-es-ayuda] Vacuum analize no actualiza el campo last vacuum de la tabla
Bueno, mi recomendación es que actualices tu PostgreSQL. Ayer mismo salió la 9.2, por lo que si no me equivoco, ya se le debe haber quitado el soporte a la versión 8.2. Ahora, con relación a tu problema, ¿Qué versión de PgAdmin estás usando? On 09/11/2012 08:05 AM, viart wrote: Buenos días a todos, Estoy ejecutando un [ vacuumdb --analyze --table \ARQ076\ SBU ] desde la consola del servidor Linux, donde está instalado el Postgres 8.2, pero cuando acaba el vacuum, consulto la tabla por PgAdmin y los campos Last Vacuum y Last Analyze continúan en blanco. Los campos Last Autovacuum y Last Autoanalyze se mantienen con fechas más antiguas. ¿Hay alguna forma de actualizar estos campos o debería ser automático? Saludos a todos, Antonio Salas Mena - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripci�n: http://www.postgresql.org/mailpref/pgsql-es-ayuda 10mo. ANIVERSARIO DE LA CREACION DE LA UNIVERSIDAD DE LAS CIENCIAS INFORMATICAS... CONECTADOS AL FUTURO, CONECTADOS A LA REVOLUCION http://www.uci.cu http://www.facebook.com/universidad.uci http://www.flickr.com/photos/universidad_uci -- Marcos Luis Ortíz Valmaseda *Data Engineer Sr. System Administrator at UCI* about.me/marcosortiz http://about.me/marcosortiz My Blog http://marcosluis2186.posterous.com Tumblr's blog http://marcosortiz.tumblr.com/ @marcosluis2186 http://twitter.com/marcosluis2186 10mo. ANIVERSARIO DE LA CREACION DE LA UNIVERSIDAD DE LAS CIENCIAS INFORMATICAS... CONECTADOS AL FUTURO, CONECTADOS A LA REVOLUCION http://www.uci.cu http://www.facebook.com/universidad.uci http://www.flickr.com/photos/universidad_uci
RE: [pgsql-es-ayuda] Vacuum analize no actualiza el campo last vacuum de la tabla
Hola Marcos, Ya estamos en eso, en actualizar para la 9.2, pero por en cuanto tenemos que dejar trabajando el actual servidor. Uso el PgAdmin 1.14.1. Acabamos de reiniciar el servidor y, los campos que comento, se actualizaron y ahora si están mostrando los valores correctos. Pero aun me parece raro que se actualicen al momento. saludos, Antonio Salas Mena De: Marcos Ortiz [mailto:mlor...@uci.cu] Enviado el: martes, 11 de septiembre de 2012 16:20 Para: viart CC: 'Lista PostgreSQL en Español' Asunto: Re: [pgsql-es-ayuda] Vacuum analize no actualiza el campo last vacuum de la tabla Bueno, mi recomendación es que actualices tu PostgreSQL. Ayer mismo salió la 9.2, por lo que si no me equivoco, ya se le debe haber quitado el soporte a la versión 8.2. Ahora, con relación a tu problema, ¿Qué versión de PgAdmin estás usando? On 09/11/2012 08:05 AM, viart wrote: Buenos días a todos, Estoy ejecutando un [ vacuumdb --analyze --table \ARQ076\ SBU ] desde la consola del servidor Linux, donde está instalado el Postgres 8.2, pero cuando acaba el vacuum, consulto la tabla por PgAdmin y los campos Last Vacuum y Last Analyze continúan en blanco. Los campos Last Autovacuum y Last Autoanalyze se mantienen con fechas más antiguas. ¿Hay alguna forma de actualizar estos campos o debería ser automático? Saludos a todos, Antonio Salas Mena - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripci�n: http://www.postgresql.org/mailpref/pgsql-es-ayuda 10mo. ANIVERSARIO DE LA CREACION DE LA UNIVERSIDAD DE LAS CIENCIAS INFORMATICAS... CONECTADOS AL FUTURO, CONECTADOS A LA REVOLUCION http://www.uci.cu http://www.facebook.com/universidad.uci http://www.flickr.com/photos/universidad_uci -- Marcos Luis Ortíz Valmaseda Data Engineer Sr. System Administrator at UCI about.me/marcosortiz My Blog http://marcosluis2186.posterous.com Tumblr's blog http://marcosortiz.tumblr.com/ @marcosluis2186 http://twitter.com/marcosluis2186 http://www.uci.cu/
Re: [pgsql-es-ayuda] Vacuum analize no actualiza el campo last vacuum de la tabla
Excerpts from viart's message of mar sep 11 09:05:57 -0300 2012: Buenos días a todos, Estoy ejecutando un [ vacuumdb --analyze --table \ARQ076\ SBU ] desde la consola del servidor Linux, donde está instalado el Postgres 8.2, pero cuando acaba el vacuum, consulto la tabla por PgAdmin y los campos Last Vacuum y Last Analyze continúan en blanco. Los campos Last Autovacuum y Last Autoanalyze se mantienen con fechas más antiguas. ¿Hay alguna forma de actualizar estos campos o debería ser automático? Debería ser automático. Es posible que estés topando con algún bug en el pgstat que se queda colgado -- uno de estos (en Windows) fue encontrado y corregido en 9.2, pero los intentos de portar el parche a versiones anteriores no han sido fructíferas. No dijiste si estabas usando Windows. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripci�n: http://www.postgresql.org/mailpref/pgsql-es-ayuda
Re: [pgsql-es-ayuda] Vacuum analize no actualiza el campo last vacuum de la tabla
Excerpts from Marcos Ortiz's message of mar sep 11 11:19:47 -0300 2012: Bueno, mi recomendación es que actualices tu PostgreSQL. Ayer mismo salió la 9.2, por lo que si no me equivoco, ya se le debe haber quitado el soporte a la versión 8.2. 8.2 dejó de tener soporte en diciembre pasado. El momento de dejar de dar soporte a una versión no depende de cuándo se libera una versión futura, sino que la regla es cinco años después de haber sido liberada. Se desprende que tenemos 9.2 sólo hasta septiembre de 2017. Ahora, con relación a tu problema, ¿Qué versión de PgAdmin estás usando? Es difícil que esto sea relevante. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripci�n: http://www.postgresql.org/mailpref/pgsql-es-ayuda
[pgsql-es-ayuda] Vacuum full reduce almacenamiento y analize no
Buenas tardes. Deseo contarles acerca de una situación que se me ha presentado con postgres para que por favor me comenten su opinión al respecto. Contamos con una base de datos que almacena documentos escaneados y cuenta actualmente con un tamaño de 180 GB. Como sistema de contingencia contamos con una réplica de la BD en un Centro de datos extrerno. Contamos con la misma versión de postgres y del sistema operativo en los dos ambientes productiov y conitingencia. Se ha observado que el tamaño de la BD productiva tiene un tamaño de 180 GB y la de contingencia 205 GB. Entonces se ejecuto un vacuumdb --full nombrebaseddatos sobre postgres en contingencia y ahora muestra un tamaño de 178 GB. Sin embargo en la noche se ejecuta un proceso batch que carga las novedades generadas durante el día en la bd productiva a la base de datos de contingencia. Después del proceso de carga, se observa que la bd productiva continúa con 180 GB y la base de datos de contingencia creció de 178 GB a 186 GB. a pesar de que en la madrugada después de la carga de las novedades a la bd de contingencia se ejecuta vacuumdb --analyze -a Versión de Postgres -- 8.4.1 Linux Red hat 5.3 64 bits Debo ejecutar siempre vacuumdb --full basededatos ? A que se debe el crecimiento excesivo de la bd de contingencia.?
Re: [pgsql-es-ayuda] Vacuum full reduce almacenamiento y analize no
On 08/10/2011 06:29 PM, Julio Cesar Ayala Guarin wrote: madrugada después de la carga de las novedades a la bd de contingencia se ejecuta vacuumdb --analyze -a Esto solamente ejecuta ANALYZE para actualizar las estadisticas usadas por el planner Versión de Postgres -- 8.4.1 Actualiza al menos a la ultima version de 8.4, es bien rapido y sencillo y te va a ahorrar dolores de cabeza probablemente en el futuro Linux Red hat 5.3 64 bits Debo ejecutar siempre vacuumdb --full basededatos ? VACUUM FULL es lo unique que va a disminuir el tamaño de la BD, el resto marca solamente el espacio como disponible. Tene en cuenta que VACUUM FULL toma un bloqueo exclusivo asi que nadie ni nada mas puede usar la BD mientras se ejecuta (o es por tabla? no recuerdo ahora mismo). A que se debe el crecimiento excesivo de la bd de contingencia.? auto_vacuum deshabilitado? un transaccion abierta que no permite que haga su trabajo? no se, investiga por ese ladopor algun motivo auto_vacuum pareciera que no esta realizando el trabajo que debiera Espero haber sido de ayuda, si tenes mas dudas simplemente mandalas e intentare contestarte. Saludos Rodrigo Gonzalez - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripción: http://www.postgresql.org/mailpref/pgsql-es-ayuda
RE: [pgsql-es-ayuda] Vacuum
Una pregunta...No se suppone que autovacuum eliminaria la necesidad de este vacuum. Lo digo porque he cambiado todo eso y ya no lo usoHay que seguir usando vacuum ? *---* *-Edwin Quijada *-Developer DataBase *-JQ Microsistemas *-Soporte PostgreSQL *-www.jqmicrosistemas.com *-809-849-8087 *---* Date: Thu, 26 May 2011 16:47:47 -0300 From: msile...@easymail.net.ar To: alvhe...@alvh.no-ip.org CC: pgsql-es-ayuda@postgresql.org Subject: Re: [pgsql-es-ayuda] Vacuum Clarísimo, muchas gracias!. El 26/05/2011 16:45, Alvaro Herrera escribió: Esta parte es de analyze, y corresponde a la muestra aleatoria de páginas que se recorren para obtener estadísticas. No tiene nada que ver con las páginas que vacuum necesita para limpiar la - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripci�n: http://www.postgresql.org/mailpref/pgsql-es-ayuda
Re: [pgsql-es-ayuda] Vacuum
Es correcto, lo que sucede es que, tenemos tablas muy grandes con split, por lo que evito usar el autovacuum, ya que no puedo omitir estas tablas (que tienen solo inserts) pero juntan mensualmente cerca de 20 millones de registros. Saludos. El 27/05/2011 16:05, Edwin Quijada escribió: eliminaria la necesidad de este vacuum. Lo digo porque he cambiado todo eso y ya no lo uso Hay que seguir usando vacuum ? - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripci�n: http://www.postgresql.org/mailpref/pgsql-es-ayuda
RE: [pgsql-es-ayuda] Vacuum
Excerpts from Edwin Quijada's message of vie may 27 15:05:49 -0400 2011: Una pregunta...No se suppone que autovacuum eliminaria la necesidad de este vacuum. Lo digo porque he cambiado todo eso y ya no lo usoHay que seguir usando vacuum ? No es obligatorio. Si no quieres usar autovacuum puedes desactivarlo, pero si te funciona bien entonces no necesitas nada más. Pero _alguien_ tiene que ejecutar vacuum, ya sea tú manualmente (o vía cron etc), o bien autovacuum. -- Álvaro Herrera alvhe...@alvh.no-ip.org - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripci�n: http://www.postgresql.org/mailpref/pgsql-es-ayuda
Re: [pgsql-es-ayuda] Vacuum
Excerpts from Mario Sileone's message of vie may 27 15:17:53 -0400 2011: Es correcto, lo que sucede es que, tenemos tablas muy grandes con split, por lo que evito usar el autovacuum, ya que no puedo omitir estas tablas (que tienen solo inserts) pero juntan mensualmente cerca de 20 millones de registros. Puedes usar autovacuum para todas las tablas excepto esas, obviamente. El sistema no es tan estúpido. -- Álvaro Herrera alvhe...@alvh.no-ip.org - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripci�n: http://www.postgresql.org/mailpref/pgsql-es-ayuda
Re: [pgsql-es-ayuda] Vacuum
La verdad no he encontrado la manera con los parámetros que vi del autovacuum , como sería eso? me interesa muchisimo saberlo. Gracias de Antemano El 27/05/2011 16:28, Alvaro Herrera escribió: Excerpts from Mario Sileone's message of vie may 27 15:17:53 -0400 2011: Es correcto, lo que sucede es que, tenemos tablas muy grandes con split, por lo que evito usar el autovacuum, ya que no puedo omitir estas tablas (que tienen solo inserts) pero juntan mensualmente cerca de 20 millones de registros. Puedes usar autovacuum para todas las tablas excepto esas, obviamente. El sistema no es tan estúpido. - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripci�n: http://www.postgresql.org/mailpref/pgsql-es-ayuda
Re: [pgsql-es-ayuda] Vacuum
Excerpts from Mario Sileone's message of vie may 27 15:43:01 -0400 2011:
La verdad no he encontrado la manera con los parámetros que vi del
autovacuum , como sería eso? me interesa muchisimo saberlo.
insert into pg_autovacuum values ('tu_tabla'::regclass, false, -1, -1, ...)
(completar con -1)
--
Álvaro Herrera alvhe...@alvh.no-ip.org
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripci�n:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
[pgsql-es-ayuda] Vacuum
Estimada lista, tengo una consulta con respecto al vacuum. resulta que todos los dias, hacemos un vacuum a toda la base de datos para evitar el wraparound, pero generalmente, hacemos en forma manual también algunos vacuum durante el día a tablas puntuales de gran carga. mi duda viene por lo siguiente: cuando sale el mensaje del vacuum, nos dice: scanned 3000 of 9458 pages La pregunta es, siempre se escanean 3000 páginas por más que se tengan mas? esto afecta al resultado o el vacuum es igualmente efectivo? Saludos y gracias - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripción: http://www.postgresql.org/mailpref/pgsql-es-ayuda
Re: [pgsql-es-ayuda] Vacuum
Excerpts from Mario Sileone's message of jue may 26 15:10:04 -0400 2011: Estimada lista, tengo una consulta con respecto al vacuum. resulta que todos los dias, hacemos un vacuum a toda la base de datos para evitar el wraparound, pero generalmente, hacemos en forma manual también algunos vacuum durante el día a tablas puntuales de gran carga. Bien. mi duda viene por lo siguiente: cuando sale el mensaje del vacuum, nos dice: scanned 3000 of 9458 pages La pregunta es, siempre se escanean 3000 páginas por más que se tengan mas? esto afecta al resultado o el vacuum es igualmente efectivo? Esta parte es de analyze, y corresponde a la muestra aleatoria de páginas que se recorren para obtener estadísticas. No tiene nada que ver con las páginas que vacuum necesita para limpiar la tabla. -- Álvaro Herrera alvhe...@alvh.no-ip.org - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripci�n: http://www.postgresql.org/mailpref/pgsql-es-ayuda
Re: [pgsql-es-ayuda] Vacuum
Clarísimo, muchas gracias!. El 26/05/2011 16:45, Alvaro Herrera escribió: Esta parte es de analyze, y corresponde a la muestra aleatoria de páginas que se recorren para obtener estadísticas. No tiene nada que ver con las páginas que vacuum necesita para limpiar la - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripci�n: http://www.postgresql.org/mailpref/pgsql-es-ayuda
[pgsql-es-ayuda] vacuum
Estamos teniendo problemas con el vacuum y nos esta obligando a cambiar el valor de «max_fsm_pages» muy seguido queriamos saber si hay alguna manera de mantenerlo mas bajo y tambien en una base mediana que valor tendria que ser correcto. Los límites actuales son: 293345 entradas de página, 1000 relaciones, usando 1784 kB.NOTICE: el número de entradas de página (441200) excede max_fsm_pages (293345) HINT: Considere incrementar el parámetro de configuración «max_fsm_pages» a un valor por sobre 441200.Total query runtime: 119906 ms. Muchas Gracias. Ariel.
Re: [pgsql-es-ayuda] vacuum
El mar, 05-04-2011 a las 17:30 +, Ariel Centeno escribió: Estamos teniendo problemas con el vacuum y nos esta obligando a cambiar el valor de «max_fsm_pages» muy seguido queriamos saber si hay alguna manera de mantenerlo mas bajo y tambien en una base mediana que valor tendria que ser correcto. Los límites actuales son: 293345 entradas de página, 1000 relaciones, usando 1784 kB.NOTICE: el número de entradas de página (441200) excede max_fsm_pages (293345) HINT: Considere incrementar el parámetro de configuración «max_fsm_pages» a un valor por sobre 441200.Total query runtime: 119906 ms. En el mensaje te sale el valor que debes colcar. -- Saludos, Gilberto Castillo Edificio Beijing. Miramar Trade Center. Etecsa. Miramar, La Habana.Cuba. --- This message was processed by Kaspersky Mail Gateway 5.6.28/RELEASE running at host imx2.etecsa.cu Visit our web-site: http://www.kaspersky.com, http://www.viruslist.com - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripción: http://www.postgresql.org/mailpref/pgsql-es-ayuda
Re: [pgsql-es-ayuda] vacuum
Excerpts from Ariel Centeno's message of mar abr 05 14:30:11 -0300 2011: Estamos teniendo problemas con el vacuum y nos esta obligando a cambiar el valor de «max_fsm_pages» muy seguido queriamos saber si hay alguna manera de mantenerlo mas bajo y tambien en una base mediana que valor tendria que ser correcto. Los límites actuales son: 293345 entradas de página, 1000 relaciones, usando 1784 kB.NOTICE: el número de entradas de página (441200) excede max_fsm_pages (293345) HINT: Considere incrementar el parámetro de configuración «max_fsm_pages» a un valor por sobre 441200.Total query runtime: 119906 ms. No lo incrementes a exactamente el valor que te dice: dale el triple de lo que te sugiere. Verifica que no tengas demasiado espacio muerto. Haz vacuum más a menudo. Actualiza a 9.0. -- Álvaro Herrera alvhe...@alvh.no-ip.org - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripci�n: http://www.postgresql.org/mailpref/pgsql-es-ayuda
Re: [pgsql-es-ayuda] vacuum a las tablas
Miguel, Yo empezaria viendo si tenes algun lock que este atascando el proceso de vacuum. Podes hacerlo con un ps -fu postgres | grep waiting desde el shell del servidor ( esto si no estas en windows ). Si en el resultado aparece el proceso vacuum, hay un lockeo que hay que estudiar La otra forma , mas precisa y tambien compatible con windows es hacer una consulta a la vista de sistema pg_locks que guarda informacion de los lockeos actuales. Una primera aproximacion seria asi: select * from pg_locks where granted is false Si aparecen filas hay un lockeo que esta atascando a otro. Todo esto suponiendo que hay un lockeo, pero puede ser tambien que vacuum tarde mucho por otra razon, otra razon podria ser una configuracion baja del parametro maintenance_work_mem Saludos Dorian 2011/1/10 Miguel Angel Hernandez Moreno miguel.hdz@gmail.com: saludos lista disculpen estoy dando un mantniemiento a una tabla y resulta que se esta tardando mucho tiempo y tengo la ligera duda si es por que pase algo en la bd o es normal El mensaje que me imprime en terminal es el siguiente INFO: vacuuming pg_toast.pg_toast_17710 que me recomiendan? Estoy haciendo un vacuum analyze desde psql. tengo postgresql 8.4 -- ISC Miguel Angel Hernandez Moreno - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripción: http://www.postgresql.org/mailpref/pgsql-es-ayuda
[pgsql-es-ayuda] vacuum a las tablas
saludos lista disculpen estoy dando un mantniemiento a una tabla y resulta que se esta tardando mucho tiempo y tengo la ligera duda si es por que pase algo en la bd o es normal El mensaje que me imprime en terminal es el siguiente INFO: vacuuming pg_toast.pg_toast_17710 que me recomiendan? Estoy haciendo un vacuum analyze desde psql. tengo postgresql 8.4 -- ISC Miguel Angel Hernandez Moreno
Re: [pgsql-es-ayuda] vacuum a la base de datos???
hola, disculpa y entoncses ya esta corriendo el vacuum desde lo que es pgagmin mi duda es si este vacuum se hace solo a los catalogos o a los catalogos y a las tablas?? El 14 de diciembre de 2010 01:15, Miguel Angel Hernandez Moreno miguel.hdz@gmail.com escribió: como efectuo el vacuum?? por termina?? que sentencia se pondria en terminal?? o desde pgpadmin, click derecho y mantenimientosvacuum El 13 de diciembre de 2010 23:54, Jaime Casanova ja...@2ndquadrant.comescribió: 2010/12/14 Miguel Angel Hernandez Moreno miguel.hdz@gmail.com: hay algun riesgo de que pierda mi informacion al hacer el vacuum?? nunca entenderé esta pregunta... que sentido tendría que la base te exija realizar una operación potencialmente peligrosa? mas bien, tienes riesgo de perder tu información si no ejecutas VACUUM... bueno, la verdad es que probablemente no perderías la información (pero no podrías verla hasta que ejecutes VACUUM, lo que en esencia es lo mismo) o si tienes una versión relativamente nueva de postgres, por ejemplo 8.1 o superior (btw, la 8.1 ya tiene mas de 5 años) probablemente antes de que eso ocurra el servicio de postgres se detendrá y te impedirá arrancar a menos que sea en modo standalone para ejecutar VACUUM. en todo caso, te ahorraras muchos problemas si le haces caso a la base y ejecutas VACUUM en la base feria -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte y capacitación de PostgreSQL -- ISC Miguel Angel Hernandez Moreno -- ISC Miguel Angel Hernandez Moreno
Re: [pgsql-es-ayuda] vacuum a la base de datos???
2010/12/14 Miguel Angel Hernandez Moreno miguel.hdz@gmail.com: hola, disculpa y entoncses ya esta corriendo el vacuum desde lo que es pgagmin mi duda es si este vacuum se hace solo a los catalogos o a los catalogos y a las tablas?? si estas conectado como el usuario postgres (o algun otro superusuario) y ejecutaste VACUUM sin ningun argumento deberia estarse ejecutando sobre toda la base (catalogos y tablas de usuario) -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte y capacitación de PostgreSQL - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripci�n: http://www.postgresql.org/mailpref/pgsql-es-ayuda
Re: [pgsql-es-ayuda] vacuum a la base de datos???
oye tengo en vacuum parado, hay un autovacuum worker process que tiene el vacuum en waiting que puedo hacer para darle mayor velocidad a esto El 14 de diciembre de 2010 08:10, Jaime Casanova ja...@2ndquadrant.comescribió: 2010/12/14 Miguel Angel Hernandez Moreno miguel.hdz@gmail.com: hola, disculpa y entoncses ya esta corriendo el vacuum desde lo que es pgagmin mi duda es si este vacuum se hace solo a los catalogos o a los catalogos y a las tablas?? si estas conectado como el usuario postgres (o algun otro superusuario) y ejecutaste VACUUM sin ningun argumento deberia estarse ejecutando sobre toda la base (catalogos y tablas de usuario) -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte y capacitación de PostgreSQL -- ISC Miguel Angel Hernandez Moreno
Re: [pgsql-es-ayuda] vacuum a la base de datos???
Excerpts from Miguel Angel Hernandez Moreno's message of mar dic 14 12:30:01 -0300 2010: oye tengo en vacuum parado, hay un autovacuum worker process que tiene el vacuum en waiting Seguramente quiere procesar una tabla que el otro está procesando. Sólo puede haber un vacuum sobre una misma tabla en un momento dado. Dale un SIGINT al proceso de autovacuum para que continúe con otra tabla. que puedo hacer para darle mayor velocidad a esto Quizás podrías rebajar el autovacuum_vacuum_cost_delay a 10 o menos. Otra cosa que tienes que fijarte es si el vacuum de alguna tabla está muriendo con un error. -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripci�n: http://www.postgresql.org/mailpref/pgsql-es-ayuda
Re: [pgsql-es-ayuda] vacuum a la base de datos???
*Quizás podrías rebajar el autovacuum_vacuum_cost_delay a 10 o menos. *con eso se tiene alguna idea de cuanto se tardaria si mi bd comprimida pesa alrededor de medio tera *Otra cosa que tienes que fijarte es si el vacuum de alguna tabla está muriendo con un error.* donde puedo fijarme El 14 de diciembre de 2010 09:51, Alvaro Herrera alvhe...@commandprompt.com escribió: Excerpts from Miguel Angel Hernandez Moreno's message of mar dic 14 12:30:01 -0300 2010: oye tengo en vacuum parado, hay un autovacuum worker process que tiene el vacuum en waiting Seguramente quiere procesar una tabla que el otro está procesando. Sólo puede haber un vacuum sobre una misma tabla en un momento dado. Dale un SIGINT al proceso de autovacuum para que continúe con otra tabla. que puedo hacer para darle mayor velocidad a esto Quizás podrías rebajar el autovacuum_vacuum_cost_delay a 10 o menos. Otra cosa que tienes que fijarte es si el vacuum de alguna tabla está muriendo con un error. -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- ISC Miguel Angel Hernandez Moreno
Re: [pgsql-es-ayuda] vacuum a la base de datos???
2010/12/14 Miguel Angel Hernandez Moreno miguel.hdz@gmail.com: Otra cosa que tienes que fijarte es si el vacuum de alguna tabla está muriendo con un error. donde puedo fijarme en los logs -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte y capacitación de PostgreSQL - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripci�n: http://www.postgresql.org/mailpref/pgsql-es-ayuda
Re: [pgsql-es-ayuda] vacuum a la base de datos???
ok aparentemento todo va bien solo para confirmar: el vacuum era solo vacuum a secas que puedo ejecutar desde pgadmin cuando acabe el vacuum ya no hay nada mas que hacer, solo vuelvo a permitir los accesos de lectura y escritua de la bd y si ya el vacuum se esta haciendo a las tablas y ya no al catalogo, podria cortar el proceso y con el puro catalogo bastaria??? grax El 14 de diciembre de 2010 10:29, Jaime Casanova ja...@2ndquadrant.comescribió: 2010/12/14 Miguel Angel Hernandez Moreno miguel.hdz@gmail.com: Otra cosa que tienes que fijarte es si el vacuum de alguna tabla está muriendo con un error. donde puedo fijarme en los logs -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte y capacitación de PostgreSQL -- ISC Miguel Angel Hernandez Moreno
Re: [pgsql-es-ayuda] vacuum a la base de datos???
2010/12/14 Miguel Angel Hernandez Moreno miguel.hdz@gmail.com: ok aparentemento todo va bien solo para confirmar: el vacuum era solo vacuum a secas que puedo ejecutar desde pgadmin si cuando acabe el vacuum ya no hay nada mas que hacer, solo vuelvo a permitir los accesos de lectura y escritua de la bd y porque los bloqueaste? vacuum es inofensivo y no afecta a las demas operaciones de la bd... pueden haber escrituras y lecturas concurrentemente con el vacuum y si ya el vacuum se esta haciendo a las tablas y ya no al catalogo, podria cortar el proceso y con el puro catalogo bastaria??? no -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte y capacitación de PostgreSQL - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripci�n: http://www.postgresql.org/mailpref/pgsql-es-ayuda
Re: [pgsql-es-ayuda] vacuum a la base de datos???
ok toncs ntiendo k lo que estoy haciendo es correcto solo que tengo que ser paciente *y porque los bloqueaste? vacuum es inofensivo y no afecta a las demas operaciones de la bd... pueden haber escrituras y lecturas concurrentemente con el vacuum * porque yo en una hora consumo 1 millon de transacciones, esto por que ayer cuando nos dimos cuenta nos quedaban 8 millones y casi a la hora cuando bajamos los procesos ya quedaban 7 millones El 14 de diciembre de 2010 14:25, Jaime Casanova ja...@2ndquadrant.comescribió: 2010/12/14 Miguel Angel Hernandez Moreno miguel.hdz@gmail.com: ok aparentemento todo va bien solo para confirmar: el vacuum era solo vacuum a secas que puedo ejecutar desde pgadmin si cuando acabe el vacuum ya no hay nada mas que hacer, solo vuelvo a permitir los accesos de lectura y escritua de la bd y porque los bloqueaste? vacuum es inofensivo y no afecta a las demas operaciones de la bd... pueden haber escrituras y lecturas concurrentemente con el vacuum y si ya el vacuum se esta haciendo a las tablas y ya no al catalogo, podria cortar el proceso y con el puro catalogo bastaria??? no -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte y capacitación de PostgreSQL -- ISC Miguel Angel Hernandez Moreno
[pgsql-es-ayuda] vacuum a la base de datos???
*WARNING: database feria must be vacuumed within 8213017 transactions* me marca ese WARNING, si hiciera un pg_dump afectaria en las transaciones, podria perder el respaldo si se llegasen a cumplir las transaciones limite?? y el vacuum a la base de datos lo puedo hacer desde pgadmin?? -- ISC Miguel Angel Hernandez Moreno
Re: [pgsql-es-ayuda] vacuum a la base de datos???
2010/12/13 Miguel Angel Hernandez Moreno miguel.hdz@gmail.com: WARNING: database feria must be vacuumed within 8213017 transactions me marca ese WARNING, si hiciera un pg_dump afectaria en las transaciones, podria perder el respaldo si se llegasen a cumplir las transaciones limite?? pg_dump abre una transaccion a la base de datos asi que la respuesta seria si y el vacuum a la base de datos lo puedo hacer desde pgadmin?? es una sentencia sql asi que la puedes ejecutar desde cualquier cliente... asi que no hay excusas, EJECUTALO YA!!! -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte y capacitación de PostgreSQL - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripci�n: http://www.postgresql.org/mailpref/pgsql-es-ayuda
Re: [pgsql-es-ayuda] vacuum a la base de datos???
como efectuo el vacuum?? por termina?? que sentencia se pondria en terminal?? o desde pgpadmin, click derecho y mantenimientosvacuum El 13 de diciembre de 2010 23:54, Jaime Casanova ja...@2ndquadrant.comescribió: 2010/12/14 Miguel Angel Hernandez Moreno miguel.hdz@gmail.com: hay algun riesgo de que pierda mi informacion al hacer el vacuum?? nunca entenderé esta pregunta... que sentido tendría que la base te exija realizar una operación potencialmente peligrosa? mas bien, tienes riesgo de perder tu información si no ejecutas VACUUM... bueno, la verdad es que probablemente no perderías la información (pero no podrías verla hasta que ejecutes VACUUM, lo que en esencia es lo mismo) o si tienes una versión relativamente nueva de postgres, por ejemplo 8.1 o superior (btw, la 8.1 ya tiene mas de 5 años) probablemente antes de que eso ocurra el servicio de postgres se detendrá y te impedirá arrancar a menos que sea en modo standalone para ejecutar VACUUM. en todo caso, te ahorraras muchos problemas si le haces caso a la base y ejecutas VACUUM en la base feria -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte y capacitación de PostgreSQL -- ISC Miguel Angel Hernandez Moreno
Re: [pgsql-es-ayuda] Vacuum: pg_statistic_relid_att_index, duplicate key violates
Jaime El autovacuum está en off desde un principio.la carga es tan pequeña y específica, por decirlo de alguna forma, que se decidió que se hicieran vacuums en estas cargas que se daban cada 10 minutos ya que era el momento en el que se limpiaban dos tablas y se generaban updates en otras. tenemos otras plataformas en las que el autovacuum sí está habilitado y realiza su trabajo perfectamente..pero en esta aplicación por sus particularidades se decidió que el vacuum fuera controlado es sólo eso. Cuándo dices catalogos del sistema te refieres a los particulares que usa la aplicación??o a aquellos que son de tipo administrativo del motor postgres? En los de la aplicación sólo existen esos vacuums que he mencionado a los administrativos (pg_catalog..u otros..no sé).. no!, a esos no les he hecho vacuums... Lo de la corrupción, no se preocupen... no tiene que ver con el motor, la versión o el uso del autovacuum como lo dije en correos previos la corrupción se debe a la forma como se está haciendo una replicación a otro nodo que está pasivo. El motivo inicial de este correo era solamente solucionar lo inmediato que era arreglar el error que devolvía el vacuum sobre una tabla específica (Seguía funcionando bien la aplicación... pero me interesaba eliminar ese error porque a la larga seguramente me iba a afectar en el desempeño..).. lo del modelo de replicación y causa de la corrupción es más extenso y lo veré después...y seguramente les volveré a consultar... Gracias a todos los que hicieron sus aportes. Lo bueno de esta lista (y no soy listero frecuente) es que vas por A... y vuelves con A, B y C... Saludos AP. El 9 de febrero de 2010 00:45, Jaime Casanova jcasa...@systemguards.com.ecescribió: 2010/2/8 Andrés P.P. solopostg...@gmail.com: 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. esto quiere decir que apagaste el auto vacuum o que no lo has configurado mas alla del predeterminado? si lo que hiciste fue apagar autovacuum (autovacuum = off en el postgresql.conf) deberias estar haciendo un vacuum de los catalogos del sistema cada cierto tiempo... lo estas haciendo? No estoy seguro si eso podria causar el tipo de corrupcion que mencionas pero si podria traer problemas... ahora, si como menciona Alvaro es un bug habria que saber si esta solucionado ya o no... dices que usas 8.2.3 y veo que en: 8.2.4 se arreglo esto: Fix potential-data-corruption bug in how VACUUM FULL handles UPDATE chains (Tom, Pavan Deolasee) y en 8.2.5: Prevent index corruption when a transaction inserts rows and then aborts close to the end of a concurrent VACUUM on the same table (Tom) -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157
Re: [pgsql-es-ayuda] Vacuum: pg_statistic_relid_att_index, duplicate key violates
2010/2/9 Andrés P.P. solopostg...@gmail.com: Jaime El autovacuum está en off desde un principio. [...] Cuándo dices catalogos del sistema te refieres a los particulares que usa la aplicación??o a aquellos que son de tipo administrativo del motor postgres? En los de la aplicación sólo existen esos vacuums que he mencionado a los administrativos (pg_catalog..u otros..no sé).. no!, a esos no les he hecho vacuums... a los que estan en el esquema pg_catalog, hazles vacuum cada tanto... -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- TIP 6: �Has buscado en los archivos de nuestra lista de correo? http://archives.postgresql.org/pgsql-es-ayuda
[pgsql-es-ayuda] Vacuum: pg_statistic_relid_att_index, duplicate key violates
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
Re: [pgsql-es-ayuda] Vacuum: pg_statistic_relid_att_index, duplicate key violates
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. ¿Qué versión de postgres es? *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* Hmm, esto no debería suceder. Lo que yo haría sería truncate pg_statistic; analyze; 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?? Si hay corrupción en la tabla lo mejor es partir de cero. No tienes cómo saber que el índice es válido a menos que lo reconstruyas totalmente. Finalmente, el vacuum analyze lo podría reemplazar por el vacuum que uso sobre la tabla del problema solamente. Te recomiendo el truncate para vaciar completamente pg_statistic y luego un analyze para volver a llenarlo. Estoy claro que independiente de la solución... hay un problema en la aplicación que está causando esta corrupción... No, la aplicación no tiene ninguna manera de intervenir en la validez de pg_statistic. Yo más bien dudaría de algún bug en Postgres, en el kernel, o bien problemas de hardware. -- Alvaro Herrera Vendo parcela en Valdivia: http://rie.cl/?a=255568 Es filósofo el que disfruta con los enigmas (G. Coli) -- TIP 7: no olvides aumentar la configuración del free space map
Re: [pgsql-es-ayuda] Vacuum: pg_statistic_relid_att_index, duplicate key violates
Marcos Lo de hacer el ciclo del vacuum cada 10 minutos es que estos Vacuum están en un script que se ejecuta via crontab y están asociados a 2 tablas que se vacían (truncate) completamente y luego se cargan con archivos que la aplicación va dejando cada 10 minutos. en ese sentido no sé si el truncate cumple los mismos requisitos que un delete como para hacer necesario o no el vacuum por esa razón se incluyó el vacuum después de la carga justo en el momento anterior a que se ejecute una función que calcula cosas con esa data. Gracias por tu comentario. Alvaro... Es postgres 8.2.3sip, es antigua pero hasta ahora ha tenido un desempeño muy regular y satisfactorio... claramente hay que ver un tema en la replicación a otro nodo que seria la causal de esta corrupción (es un cuento largo... asi que lo dejo para después).. La solución que planteas se parece a lo que encontré en google yo había pensando en algo parcialpero claro, talvez estoy mirando muy livianamente la corrupción existente...sip, lo haré como tú dices después de limpiar la pg_statistics ejecuto el analyze sólo?.. qué diferencia hay entre un analyze y un vacuum analyze para esta situación particular (de puro curioso no más pregunto esto...). Finalmente... No, no es la aplicación... me expresé mal.. es la solución que se aplicó para la replicación que hay con otro Server.. Gracias Alvaro.. Saludos. El 8 de febrero de 2010 17:23, Alvaro Herrera alvhe...@alvh.no-ip.orgescribió: 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. ¿Qué versión de postgres es? *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* Hmm, esto no debería suceder. Lo que yo haría sería truncate pg_statistic; analyze; 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?? Si hay corrupción en la tabla lo mejor es partir de cero. No tienes cómo saber que el índice es válido a menos que lo reconstruyas totalmente. Finalmente, el vacuum analyze lo podría reemplazar por el vacuum que uso sobre la tabla del problema solamente. Te recomiendo el truncate para vaciar completamente pg_statistic y luego un analyze para volver a llenarlo. Estoy claro que independiente de la solución... hay un problema en la aplicación que está causando esta corrupción... No, la aplicación no tiene ninguna manera de intervenir en la validez de pg_statistic. Yo más bien dudaría de algún bug en Postgres, en el kernel, o bien problemas de hardware. -- Alvaro Herrera Vendo parcela en Valdivia: http://rie.cl/?a=255568 Es filósofo el que disfruta con los enigmas (G. Coli)
Re: [pgsql-es-ayuda] Vacuum: pg_statistic_relid_att_index, duplicate key violates
Andrés P.P. escribió: después de limpiar la pg_statistics ejecuto el analyze sólo?.. qué diferencia hay entre un analyze y un vacuum analyze para esta situación particular (de puro curioso no más pregunto esto...). La diferencia es que VACUUM ANALYZE va a hacer un vacuum de cada tabla, y después un ANALYZE, en cambio ANALYZE hará sólo ANALYZE, que es mucho más rápido. Como no es conveniente tener mucho tiempo el sistema sin estadísticas, lo mejor es que hagas lo más rápido para salir del problema. Si te hace falta un vacuum puedes hacerlo después, por separado. -- Alvaro Herrera Vendo parcela en Valdivia: http://valdivia.vivastreet.cl/loteos-lotes+valdivia/parcela-en-cabo-blanco--valdivia/19288372 Industry suffers from the managerial dogma that for the sake of stability and continuity, the company should be independent of the competence of individual employees. (E. Dijkstra) -- TIP 2: puedes desuscribirte de todas las listas simultáneamente (envía unregister TuDirecciónDeCorreo a majord...@postgresql.org)
Re: [pgsql-es-ayuda] Vacuum: pg_statistic_relid_att_index, duplicate key violates
Ahh..ok!.. Te pregunté esa diferencia de curioso ya que la BD es realmente pequeña y la mayor actividad se reduce justamente a estos ciclos de carga que se dan cada 10 minutos... y cada procesamiento no supera los 10 o 30 segundos (entre truncar las tablas, cargar las tablas con data nueva y ejecutar las funciones que usan esa data para actualizar data en otras tablas..). Respecto a las dimensiones de la BD... PGDATA: 524 MB De las 4 tablas que les mencioné inicialmente afectas a Vacuum: la más poblada tiene 10 registros( principalmente inserts..y muy pocos update) y las otras son pequeñísimas.. De hecho, la tabla en cuestión se vacía y se carga con aproximadamente 1000 registros... en cada ciclo. Por lo anterior había pensando en que era factible usar el vacuum analyze. ya que haciéndolo en el momento justo no creo que afecte en otras areas... pero es mejor asegurarse, asi que seguiré tu consejo. Gracias Alvaro. AP. El 8 de febrero de 2010 17:44, Alvaro Herrera alvhe...@alvh.no-ip.orgescribió: Andrés P.P. escribió: después de limpiar la pg_statistics ejecuto el analyze sólo?.. qué diferencia hay entre un analyze y un vacuum analyze para esta situación particular (de puro curioso no más pregunto esto...). La diferencia es que VACUUM ANALYZE va a hacer un vacuum de cada tabla, y después un ANALYZE, en cambio ANALYZE hará sólo ANALYZE, que es mucho más rápido. Como no es conveniente tener mucho tiempo el sistema sin estadísticas, lo mejor es que hagas lo más rápido para salir del problema. Si te hace falta un vacuum puedes hacerlo después, por separado. -- Alvaro Herrera Vendo parcela en Valdivia: http://valdivia.vivastreet.cl/loteos-lotes+valdivia/parcela-en-cabo-blanco--valdivia/19288372 Industry suffers from the managerial dogma that for the sake of stability and continuity, the company should be independent of the competence of individual employees. (E. Dijkstra)
Re: [pgsql-es-ayuda] Vacuum: pg_statistic_relid_att_index, duplicate key violates
Andrés P.P. escribió: Por lo anterior había pensando en que era factible usar el vacuum analyze. ya que haciéndolo en el momento justo no creo que afecte en otras areas... pero es mejor asegurarse, asi que seguiré tu consejo. De ser factible, es factible. -- Alvaro Herrera Vendo parcela en Valdivia: http://www.portalinmobiliario.com/propiedades/fichas.asp?PropID=749682 No hay hombre que no aspire a la plenitud, es decir, la suma de experiencias de que un hombre es capaz -- TIP 2: puedes desuscribirte de todas las listas simultáneamente (envía unregister TuDirecciónDeCorreo a majord...@postgresql.org)
Re: [pgsql-es-ayuda] Vacuum: pg_statistic_relid_att_index, duplicate key violates
2010/2/8 Andrés P.P. solopostg...@gmail.com: 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. esto quiere decir que apagaste el auto vacuum o que no lo has configurado mas alla del predeterminado? si lo que hiciste fue apagar autovacuum (autovacuum = off en el postgresql.conf) deberias estar haciendo un vacuum de los catalogos del sistema cada cierto tiempo... lo estas haciendo? No estoy seguro si eso podria causar el tipo de corrupcion que mencionas pero si podria traer problemas... ahora, si como menciona Alvaro es un bug habria que saber si esta solucionado ya o no... dices que usas 8.2.3 y veo que en: 8.2.4 se arreglo esto: Fix potential-data-corruption bug in how VACUUM FULL handles UPDATE chains (Tom, Pavan Deolasee) y en 8.2.5: Prevent index corruption when a transaction inserts rows and then aborts close to the end of a concurrent VACUUM on the same table (Tom) -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda
Re: [pgsql-es-ayuda] Vacuum, rules y Selects en tablas heredadas.
Muchas gracias Alvaro por tu respuesta, suponía que el VACUUM FULL era el único que evitaba el wraparound. Con respecto a las rules con selects hay una manera genérica de desviar solo el nombre de la tabla o se debe definir cada consulta que se realiza en el DO INSTEAD ? Si tengo 3 consultas diferentes, debo realizar reglas para cada una de ellas? Desde ya muchas gracias por todo. - Original Message - From: Alvaro Herrera alvhe...@alvh.no-ip.org To: Mario Sileone msile...@easymail.net.ar Cc: pgsql-es-ayuda@postgresql.org Sent: Wednesday, February 03, 2010 4:35 PM Subject: Re: [pgsql-es-ayuda] Vacuum, rules y Selects en tablas heredadas. Mario Sileone escribió: La consulta es la siguiente: Temiendo el famoso wraparound de los 2 billones de transacciones que nos ha sucedido una vez, queríamos tener la posibilidad de hacer un vacuum full a toda la base de datos durante producción, y al tener tablas separadas por meses supusimos (mal) que el bloqueo de las tablas heredadas seria único, y no afectaría a la tabla A, pero no resultó así. ¿Esto es correcto o quizás nosotros realizamos mal el split con los rules entre las tablas? el vacuum en este caso bloquea todas las dependencias (tablas heredadas) también?. La solución es simple: no uses VACUUM FULL. -- Alvaro Herrera Vendo parcela en Valdivia: http://valdivia.vivastreet.cl/loteos-lotes+valdivia/parcela-en-cabo-blanco--valdivia/19288372 inflex really, I see PHP as like a strange amalgamation of C, Perl, Shell crab inflex: you know that amalgam means mixture with mercury, more or less, right? crab i.e., deadly poison -- TIP 5: ¿Has leído nuestro extenso FAQ? http://www.postgresql.org/docs/faqs.FAQ.html
Re: [pgsql-es-ayuda] Vacuum, rules y Selects en tablas heredadas.
- Original Message - From: Jaime Casanova jcasa...@systemguards.com.ec To: Mario Sileone msile...@easymail.net.ar Cc: Alvaro Herrera alvhe...@alvh.no-ip.org; pgsql-es-ayuda@postgresql.org Sent: Thursday, February 04, 2010 11:56 AM Subject: Re: [pgsql-es-ayuda] Vacuum, rules y Selects en tablas heredadas. 2010/2/4 Mario Sileone msile...@easymail.net.ar: Con respecto a las rules con selects hay una manera genérica de desviar solo el nombre de la tabla o se debe definir cada consulta que se realiza en el DO INSTEAD ? Si tengo 3 consultas diferentes, debo realizar reglas para cada una de ellas? que es lo que quieres lograr? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 mi tabla padre se llama reportes, de allí heredo a tablas mensuales llamadas rep_12_2009, rep_01_2010, y asi sucesivamente, teniendo una tabla por mes. Lo que hago es en reportes, crear reglas que me dicen, si hay un INSERT en reportes, y la fecha es de diciembre del 2009, la regla inserta el reporte en la tabla rep_12_2009, y asi sucesivamente con todos los inserts por fecha. Cuando realizo una consulta sobre la tabla reportes, esta misma revisa tanto reportes, como todas las tablas heredadas rep_XX_, de acuerdo a un explain analyze que realicé. Lo que quiero lograr es, con una regla similar a la de INSERTS, que los selects vayan directamente a las tablas heredadas que corresponden, sin pasar por todas. Ejemplo: si realizo una consulta de reportes desde el 10 de diciembre del 2009 al 2 de enero del 2010, que no revise las tablas rep_ desde enero del 2000 hasta diciembre del 2010. Espero haberme explicado bien, y muchas gracias desde ya. Saludos Cordiales Mario Sileone. -- TIP 6: �Has buscado en los archivos de nuestra lista de correo? http://archives.postgresql.org/pgsql-es-ayuda
Re: [pgsql-es-ayuda] Vacuum, rules y Selects en tablas heredadas.
2010/2/4 Mario Sileone msile...@easymail.net.ar: Lo que quiero lograr es, con una regla similar a la de INSERTS, que los selects vayan directamente a las tablas heredadas que corresponden, sin pasar por todas. Ejemplo: si realizo una consulta de reportes desde el 10 de diciembre del 2009 al 2 de enero del 2010, que no revise las tablas rep_ desde enero del 2000 hasta diciembre del 2010. set constraint_exclusion to on; select * from reportes where clave_particion http://www.postgresql.org/docs/8.4/static/ddl-partitioning.html mira la subseccion: 5.9.4. Partitioning and Constraint Exclusion -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda
Re: [pgsql-es-ayuda] Vacuum, rules y Selects en tablas heredadas.
- Original Message - From: Jaime Casanova jcasa...@systemguards.com.ec To: Mario Sileone msile...@easymail.net.ar Cc: Alvaro Herrera alvhe...@alvh.no-ip.org; pgsql-es-ayuda@postgresql.org Sent: Thursday, February 04, 2010 12:26 PM Subject: Re: [pgsql-es-ayuda] Vacuum, rules y Selects en tablas heredadas. 2010/2/4 Mario Sileone msile...@easymail.net.ar: Lo que quiero lograr es, con una regla similar a la de INSERTS, que los selects vayan directamente a las tablas heredadas que corresponden, sin pasar por todas. Ejemplo: si realizo una consulta de reportes desde el 10 de diciembre del 2009 al 2 de enero del 2010, que no revise las tablas rep_ desde enero del 2000 hasta diciembre del 2010. set constraint_exclusion to on; select * from reportes where clave_particion http://www.postgresql.org/docs/8.4/static/ddl-partitioning.html mira la subseccion: 5.9.4. Partitioning and Constraint Exclusion -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 Excelente Jaime, muchisimas gracias por tu respuesta! Saludos Mario Sileone -- TIP 5: �Has le�do nuestro extenso FAQ? http://www.postgresql.org/docs/faqs.FAQ.html
[pgsql-es-ayuda] Vacuum, rules y Selects en tablas heredadas.
Estimados: Implementamos unas tablas heredadas para un split de información de acuerdo a fechas en un Postgres 8.2. Los resultados con los rules han sido buenos, los inserts a una tabla A se realizan a las tablas heredadas A_01_2010, A_02_2010, etc, separadas por meses. El motivo de esto ha sido que, al crecer de a varios millones de registros por mes, necesitabamos tener la información mas separada para tanto tareas de mantenimiento, eliminación de datos disponibles, etc. La consulta es la siguiente: Temiendo el famoso wraparound de los 2 billones de transacciones que nos ha sucedido una vez, queríamos tener la posibilidad de hacer un vacuum full a toda la base de datos durante producción, y al tener tablas separadas por meses supusimos (mal) que el bloqueo de las tablas heredadas seria único, y no afectaría a la tabla A, pero no resultó así. ¿Esto es correcto o quizás nosotros realizamos mal el split con los rules entre las tablas? el vacuum en este caso bloquea todas las dependencias (tablas heredadas) también?. Asimismo, no pudimos implementar una regla para SELECT debido a que, al ser las consultas complejas y diferentes para esta tabla, no encontré la manera de realizar un DO INSTEAD genérico para solamente cambiar la tabla de consulta. Agradecido desde ya por su tiempo. Saludos Cordiales Mario Sileone. Jefe de Backoffice EasyMail S.A.
[pgsql-es-ayuda] vacuum lento
Hola lista; tengo la siguiente duda, ejecuto un vacuum analyze todas las noches sobre una base de datos de unos 120 GB aprox. el cual tarda casi 6 hs, he tocado y modificado parámetros del conf. pero el tiempo sigue sin bajar y está superponiendose con otras tareas croneadas en el servidor, ¿es una buena opción hacer un pg_dump - drop database - pg_restore? ¿necesitaría hacer un vacuum despues del restore o los dump son limpios? Gracias por su ayuda!
Re: [pgsql-es-ayuda] vacuum lento
2010/1/30 Sergio Gabriel Rodriguez sgrodrig...@gmail.com: Hola lista; tengo la siguiente duda, ejecuto un vacuum analyze todas las noches sobre una base de datos de unos 120 GB aprox. el cual tarda casi 6 hs, he tocado y necesitas hacer el vacuum de la base de datos todas las noches? porque no dejas que autovacuum se encargue y tu solo hazle vacuum mas periodico a las que en verdad necesites... modificado parámetros del conf. pero el tiempo sigue sin bajar y está moviste maintainence_work_mem si tienes memoria subele... especialmente si a esa hora no esperas mucha actividad de usuarios superponiendose con otras tareas croneadas en el servidor, ¿es una buena opción hacer un pg_dump - drop database - pg_restore? ¿necesitaría hacer un vacuum despues del restore o los dump son limpios? el vacuum solo es necesario si ejecutas update o delete... en un dump parece poco probable que vayas a hacer alguna de las dos, verdad? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- TIP 8: explain analyze es tu amigo
[pgsql-es-ayuda] vacuum verbose
Postgrerianos, he realizado un vacuum verbose analyze y al terminar me da el espacio libre contiene 587131 paginas en 30 relaciones ... 560960 entradas de pagina son necesarias pra registrar todo el espacio libre los limites actuales son 2159795 entradas de pagina, 1000 relaciones, usando 12720kb.. esto es el max_fsm_pages?, pregunto porque ahora no me recomienda incrementarlo como alguna vez lo hizo.. como resuelvo esto? Yahoo! Cocina Recetas prácticas y comida saludable http://ar.mujer.yahoo.com/cocina/ -- TIP 10: no uses HTML en tu pregunta, seguro que quien responda no podrá leerlo
Re: [pgsql-es-ayuda] vacuum verbose
Gabriel Ferro escribió: Postgrerianos, he realizado un vacuum verbose analyze y al terminar me da el espacio libre contiene 587131 paginas en 30 relaciones ... 560960 entradas de pagina son necesarias pra registrar todo el espacio libre los limites actuales son 2159795 entradas de pagina, 1000 relaciones, usando 12720kb.. esto es el max_fsm_pages?, pregunto porque ahora no me recomienda incrementarlo como alguna vez lo hizo.. Está OK. -- Alvaro Herrera http://www.flickr.com/photos/alvherre/ There was no reply (Kernel Traffic) -- TIP 5: ¿Has leído nuestro extenso FAQ? http://www.postgresql.org/docs/faqs.FAQ.html
