Consegui só com base_backup mesmo. Por aqui também estamos alterando tudo
pra filesystem, por que os arquivos em banco atrapalham todo o meio de
campo. Também já começamos a preparação pra um novo servidor com o Pgsql
9.5.
Em 22 de novembro de 2016 10:05, Luiz Carlos L. Nogueira Jr. <
Matheus,
Tem sim. Já estamos assim, com o "banco de binários" em filesystem, só que
algumas tabelas que ainda tem binários ainda permanecem no banco e ocupam
uns 70% dele.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
2016-11-22 9:09 GMT-02:00 Luiz Carlos L. Nogueira Jr. <
lcnogueir...@gmail.com>:
> Mas com o PJE o -J não adianta muito, de 2 pra cima fica tudo igual por
> causa das tabelas de binários que são bem maiores que as outras.
> Nossa base está em 400GB e tivemos essa característica.
>
Só por
Marcell,
Tenta recriar a view materializada e fazer de novo o dump/restore.
Mas com o PJE o -J não adianta muito, de 2 pra cima fica tudo igual por
causa das tabelas de binários que são bem maiores que as outras.
Nossa base está em 400GB e tivemos essa característica.
Nós estamos na Versão
On 19-11-2016 14:05, Matheus de Oliveira wrote:
>
> <..corte..>
>
> [1]
> https://www.postgresql.org/docs/current/static/populate.html#POPULATE-PG-DUMP
>
Interessante que na documentação ainda recomendam apenas um ANALYZE após
o restore, sendo que somente ele não cria os FSM então não seremos
2016-11-18 9:45 GMT-02:00 Marcell Ribeiro :
> /usr/local/bin/pg_restore -U usuario -d banco -v
> /disco1/backup_andamento.tar
>
> Já testei com -j e sem, não vi diferença nenhuma. Não uso compressão
> durante o dump por que li que algumas vezes pode dar problema.
>
Que
On 18-11-2016 19:57, Marcell Ribeiro wrote:
> Percebi que os restores estão "travando" quando surge uma msg dizendo
> que não pôde criar uma view materializada por que "relation "TABELA"
> does not exist", sendo que a tabela existe sim. Não tô entendendo mais nada.
>
Você não informou a versão
Percebi que os restores estão "travando" quando surge uma msg dizendo que
não pôde criar uma view materializada por que "relation "TABELA" does not
exist", sendo que a tabela existe sim. Não tô entendendo mais nada.
Erro:
pg_restore: creating MATERIALIZED VIEW DATA vwm_x
pg_restore:
Testei com -j 4. É PJE sim. FreeBSD 9.3, 16GB de RAM, Intel(R) Xeon(R) CPU
E5-2665 0 @ 2.40GHz com 8 núcleos.
Em 18 de novembro de 2016 09:55, Luiz Carlos L. Nogueira Jr. <
lcnogueir...@gmail.com> escreveu:
> O aplicativo não seria o PJE, né?
> Coloca tua configuração de máquina, pf (CPU,
Em 18 de novembro de 2016 09:08, Marcell Ribeiro
escreveu:
> Bom dia galera, estou fazendo um pg restore mas está demorando cerca de 7
> horas pra restaurar apenas um tar de 60gb,
>
> Que parâmetros eu poderia mudar no postgresql.conf pra melhorar isso? Já
> pesquisei
O aplicativo não seria o PJE, né?
Coloca tua configuração de máquina, pf (CPU, memória, SO, etc)
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Em 18 de novembro de 2016 09:45, Marcell Ribeiro
escreveu:
> /usr/local/bin/pg_restore -U usuario -d banco -v
> /disco1/backup_andamento.tar
>
> Já testei com -j e sem, não vi diferença nenhuma. Não uso compressão
> durante o dump por que li que algumas vezes pode dar
Em 18 de novembro de 2016 10:25, Cleiton Luiz Domazak <
cleitondoma...@gmail.com> escreveu:
> Numa situação de restore esse tuning é recomendado. após o restore não faz
>> sentido deixar essas configurações.
>>
>
> Mas a minha colocação é justamente durante o processo. Durante esse
> processo
2016-11-18 10:08 GMT-02:00 Sebastian Webber :
>
>
> Em 18 de novembro de 2016 09:42, Cleiton Luiz Domazak <
> cleitondoma...@gmail.com> escreveu:
>
>>
>>
>> 2016-11-18 9:35 GMT-02:00 Sebastian Webber :
>>
>>>
>>>
>>> Em 18 de novembro de 2016 09:08,
Em 18 de novembro de 2016 09:42, Cleiton Luiz Domazak <
cleitondoma...@gmail.com> escreveu:
>
>
> 2016-11-18 9:35 GMT-02:00 Sebastian Webber :
>
>>
>>
>> Em 18 de novembro de 2016 09:08, Marcell Ribeiro <
>> marcell.ribe...@gmail.com> escreveu:
>>
>>> Bom dia galera, estou
Tive esse mesmo problema e vi que tinha uma tabela que o tamanho era bem
maior que a média de outras tabelas, aí o -j não ajudou, pois tudo acabava
e só ficava no restore dela.
Mas o que demora mais no meu restore é a criação dos índices, que se
coincidirem serem muitos nessa tabela grande.
/usr/local/bin/pg_restore -U usuario -d banco -v
/disco1/backup_andamento.tar
Já testei com -j e sem, não vi diferença nenhuma. Não uso compressão
durante o dump por que li que algumas vezes pode dar problema.
Em 18 de novembro de 2016 08:35, Sebastian Webber
escreveu:
>
2016-11-18 9:35 GMT-02:00 Sebastian Webber :
>
>
> Em 18 de novembro de 2016 09:08, Marcell Ribeiro <
> marcell.ribe...@gmail.com> escreveu:
>
>> Bom dia galera, estou fazendo um pg restore mas está demorando cerca de 7
>> horas pra restaurar apenas um tar de 60gb,
>>
>
>
>
Em 18 de novembro de 2016 09:08, Marcell Ribeiro
escreveu:
> Bom dia galera, estou fazendo um pg restore mas está demorando cerca de 7
> horas pra restaurar apenas um tar de 60gb,
>
Quais parametros tu usou na chamada do pg_restore?
>
> Que parâmetros eu poderia
Em 18 de novembro de 2016 09:08, Marcell Ribeiro
escreveu:
> Bom dia galera, estou fazendo um pg restore mas está demorando cerca de 7
> horas pra restaurar apenas um tar de 60gb,
>
Seria interessante, colocar as configurações do servidor, visto que cada
Bom dia galera, estou fazendo um pg restore mas está demorando cerca de 7
horas pra restaurar apenas um tar de 60gb,
Que parâmetros eu poderia mudar no postgresql.conf pra melhorar isso? Já
pesquisei no google e alterei alguns mas ainda não deu certo não sei por
que.
--
[image: --]
Marcell
21 matches
Mail list logo