Gracias Miguel voy a chequear esa info. Saludos
El 17 de septiembre de 2013 12:30, Miguel Angel Hernandez Moreno < [email protected]> escribió: > Hola Diego > > Para saber que es lo que esta haciendo postgres consulta > pg_stat_activity > > Y te dirá si el mantenimiento esta bloqueado, o donde se esta ejecutando, > etc. > > Saludos > > El martes, 17 de septiembre de 2013, Diego Ayala escribió: > > Gracias, Eduardo, podria ser, pero tengo entendido que un lock no evita >> que se realice el vacuum. la verdad que no llegue a encontrar ningun lock a >> esa tabla, aunque lo buscare mas a fondo. >> >> >> El 17 de septiembre de 2013 11:40, Eduardo Morras >> <[email protected]>escribió: >> >>> On Tue, 17 Sep 2013 10:44:00 -0400 >>> Diego Ayala <[email protected]> wrote: >>> >>> > Buenos dias, estoy teniendo una situacion bastante particular con el >>> vacuum >>> > que se ejecuta en mi base de datos, estoy utilizando PostgreSQL 8.4.11, >>> > sobre REL 5 64 Bits, tengo 4 bases de datos, y todos los dias, a primer >>> > hora le ejeucto VACUUM VERBOSE ANALYZE, de forma manual, y para mi DB >>> > principal, lo tengo metido en un cron a las 5:00 a.m todos los dias, >>> > ademas, de tambien correr en forma manual todos los dias. lo cierto es >>> que >>> > desde hace 2 dias, cuando llego a la oficina, encuentro el VACUUM >>> ejecutado >>> > por el cron supuestamente ejecutandose, siendo que gralmente tarda 30 >>> > minutos, ya pasaron mas de 1 hora y media, y sigue, tengo configurado >>> un >>> > log de mi ejecucion de vacuum >>> > >>> > 00 05 * * 1-7 /usr/bin/vacuumdb -d db_160913 -z -v >> >>> > /var/log/pgbkp/vacuum/vacdb.log 2>&1 >>> > >>> > viendo en el log, veo que se queda y no pasa de esta tabla (tengo unas >>> 200 >>> > tablas, y esta esta por la mitad) >>> > >>> > INFO: analyzing "sisp.categoria" , esta tabla contine apenas 42 >>> registros >>> > >>> > Al cancelar el vacuum ejecutado por el cron, lo trato de ejecutar de >>> forma >>> > manual, y me sucede lo mismo. se queda al llegar a esta tabla, >>> > >>> > Hice un backup y lo restaure en otra DB de pruebas que tengo, y en >>> esta se >>> > ejeucta sin problemas el vacuum. Pense inicialmente que tal vez el >>> disco >>> > este dañado o algo por el estilo(estuve mirando todo el log de la db y >>> no >>> > encuentro nada), pero se puede hacer ABM de toda la tabla y como dije, >>> saco >>> > un bkp y lo restauro sin problemas. A que podria deberse esto, siendo >>> que >>> > mi tabla es muy pequeña, esta relacionada con tablas que tienen 2 a 3 >>> > millones de registros, pero, la ejecucion del vacuum anteriormente era >>> de 2 >>> > veces por dia. Alguien me podria indicar si tuvo algun caso asi, o a >>> que >>> > podria deberse esto. >>> >>> >>> Puede ser que una conexion de un cliente se quedara abierta y con un >>> lock en dicha tabla, impidiendo que vacuum hiciese su trabajo. Lo que no se >>> es si cuando vacuum encuentra un lock en una tabla se para o si sigue con >>> la siguiente tabla sin lock. >>> >>> > Gracias >>> > >>> > Diego >>> >>> >>> --- --- >>> Eduardo Morras <[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 > >
