Prezados,

Como o espaço disponível era crítico foi executado as seguintes ações:

1) registro de um novo serviço com uma porta diferente em outro disco
2) Dump dos metadados para outro disco
3) copy da tabela sem os blobls para a nova base
4) e transferência dos blobs  via DBLINK.

desde já agradeço todas informações enviadas pelo grupo, foi importante
para a tomada da decisão para a resolução do problema.




Em 9 de maio de 2016 20:15, Fabrízio de Royes Mello <[email protected]
> escreveu:

> On 09-05-2016 19:40, [email protected] wrote:
> >
> >
> > 2016-05-10 9:39 GMT+12:00 Fabrízio de Royes Mello
> > <[email protected] <mailto:[email protected]>>:
> >
> >     On 09-05-2016 18:33, Ursulino Barboza wrote:
> >     > Fabio,
> >     >
> >     > Foi rodado o vacuum analyse, pois não existe espaço no disco para
> rodar
> >     > o vacuum FULLL.
> >     >
> >     > esta tabela está com um crescimento grande porque existe um campo
> blob.
> >     >
> >
> >
> >     E na 8.4 nem adianta vc rodar o Vacuum Full porque ele é muito ruim
> até
> >     essa versão. Rode o CLUSTER para recriar os datafiles ou conforme já
> >     mencionado o pg_repack. De qualquer forma vc precisa de espaço para
> essa
> >     manutenção.
> >
> >     Em um caso extremo pegaria uma janela de manunteção e dai um
> >     DUMP/RESTORE se estiver muito critico e nao tiver espaço para
> manobra.
> >
> >
> >
> > Só para acrescentar.. eu também possuo este problema...
> >
> > Mas no meu caso, o pg_toast ocupa 1.7 TB (Minha DB é 2.2TB no total)
> >
> > Também possuo blobs e por isto do crescimento...
> > Mas não fiz nenhuma manutenção na DB
> >
> > Se eu fizer um dump e restaurar a Base, irei ganhar espaco em disco?
> > Irei ganhar esses TB?
> >
>
> Veja o que mencionei no inicio dessa thread em [1], deve ser levado em
> consideração se a ocupação física é por inchaço ou não... o PostgreSQL
> tem mecanismos para manter o inchaço controlável (tanto que o padrão do
> autovacuum_scale_factor é 0.2, ou seja, 20% é tolerável).
>
> Att,
>
> [1]
> https://listas.postgresql.org.br/pipermail/pgbr-geral/2016-May/043006.html
>
> --
>    Fabrízio de Royes Mello         Timbira - http://www.timbira.com.br/
>    PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
>
>
> _______________________________________________
> pgbr-geral mailing list
> [email protected]
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
Att,


Ursulino Barboza de Souza Neto
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a