Re: [pgbr-geral] ERROR: out of shared memory in pg_dump

[Euler Taveira]

Em 28 de junho de 2017 21:49, Euler Taveira  escreveu:

>
> O pg_dump faz um bloqueio (AccessShareLock) para cada tabela que irá
> copiar. Como ele faz isso numa única transação, o parâmetro
> max_locks_per_transaction deve ser no mínimo igual ao número de tabelas a
> serem copiadas.
>

Essa sentença ficou incorreta (possivelmente por falta de cafeína?). Quis
dizer que o valor de max_locks_per_transaction deve ser suficiente para que
o cálculo max_locks_per_transaction * (max_connections +
max_prepared_transactions) seja no mínimo igual ao número de tabelas a
serem copiadas. (Foi exatamente o que o Fabrizio disse no outro email).
Quanto ao cálculo correto:

max_locks_per_transaction * (max_connections + max_prepared_transactions) =
objetos_atuais

aumentando x locks para satisfazer o pg_dump teríamos:

max_locks_per_transaction' * (max_connections + max_prepared_transactions)
= objetos_atuais + x
max_locks_per_transaction' = (objetos_atuais + x) / (max_connections +
max_prepared_transactions)

Considerando os valores padrão (max_connections = 100;
max_prepared_transactions = 0 ; max_locks_per_transaction = 64),
objetos_atuais seria 6400. x = 181 esquemas x 233 tabelas = 42173.

max_locks_per_transaction' = (6400 + 42173) / (100 + 0) ~ 486

É sempre bom deixar uma margem de segurança porque
max_locks_per_transaction precisa de um reinício do serviço.


-- 
   Euler Taveira   Timbira -
http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] ERROR: out of shared memory in pg_dump

[Fabrízio de Royes Mello]

Em 29 de junho de 2017 18:00, Douglas Fabiano Specht <
douglasfabi...@gmail.com> escreveu:
>
>
> Fabrizio,
> obrigado pela sua reposta
> vou ajustar para 500, pois deu 432 o calculo e sei que esse banco pode
ser acrescentado mais schemas.(42000/50+64) + 64 = 432 .

Esqueci de mencionar que as "sequences" devem entrar no cálculo daquele
"número de tabelas" porque elas internamente são uma tabela.


> sobre sua duvida, hoje estamos fazendo dump como estrategia de backup, o
que está errado..(eu ja li o otimo artigo do Telles) #1.

Ok, mas como é a arquitetura desse seu database? Tipo cada schema seria
como um "cliente" ou algo do gênero?? Porque se cada schema pode ser
tratado isoladamente não teria porque vc fazer um dump de todo database em
um único pg_dump, vc poderia fazer um script para ler os schemas e fazer
dumps individuais por schema.

Vc poderia usar os Syncronized Snapshots [1] também pra não precisar ficar
fazendo esses ajustes e ter dados consistentes... obviamente que nao
conheço seu modelo e não sei se os objetos nos schemas tem dependencias
(FKs), então estou pensando em modelos com schemas isolados.


> pretendo nos próximos dias implantar backup físico\logico.

Ótimo


> como estamos com 5 servidores de banco de dados, vc teria alguma
ferramenta para recomendar que faça essa gerência de backup em vários
servidores e uma maneira mais facil?
>

Para backup físico recomendo vc dar uma olhada no pgBackRest [2] ou o
Barman [3].

Att,

[1]
https://www.postgresql.org/docs/9.5/static/functions-admin.html#FUNCTIONS-SNAPSHOT-SYNCHRONIZATION
[2] http://www.pgbackrest.org/
[3] http://www.pgbarman.org/

--
   Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] ERROR: out of shared memory in pg_dump

[Douglas Fabiano Specht]

Em 29 de junho de 2017 17:45, Fabrízio de Royes Mello <
fabri...@timbira.com.br> escreveu:

>
> Em 29 de junho de 2017 11:35, Euler Taveira 
> escreveu:
> >
> > Em 28 de junho de 2017 22:35, Douglas Fabiano Specht <
> douglasfabi...@gmail.com> escreveu:
> >>>
> >>>
> >> Euler,
> >> esse valor é para cada schema 233 tabelas ou 41000 tabelas no geral de
> todos os schemas..?
> >
> >
> > É a quantidade de tabelas por execução do pg_dump. Então seria 181
> schemas x 233 tabelas.
> >
>
> Não é *exatamente* este valor porque o PostgreSQL cria um hash na memória
> compartilhada (TopMemoryContext) para alocar esses locks e o tamanho dela é
> definido por:
>
> max_locks_per_transaction * (max_connections + max_prepared_transactions)
>
> Quero dizer com isso que não é necessário colocar no
> "max_locks_per_transaction" o valor da multplicação que o Euler comentou
> que é demasiado e ocupara memória compartilhada sem necessidade. Em um
> cenário como o seu que são muitas tabelas para efetuar dump poderi então
> fazer o seguinte cálculo:
>
> (numero_de_tabelas / (max_connections + max_prepared_transactions)) + 64
>
> Desta forma quando rodar o dump vc terá slots suficientes para locks e
> também a folga de 64 para sua aplicacao continuar funcionando... porém eis
> que me surge uma dúvida??
>
> - Vc precisa fazer um dump de TODOS schemas ao mesmo tempo???
>
>

> Att,
>
> --
>Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
>PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>

Fabrizio,
obrigado pela sua reposta
vou ajustar para 500, pois deu 432 o calculo e sei que esse banco pode ser
acrescentado mais schemas.(42000/50+64) + 64 = 432 .
sobre sua duvida, hoje estamos fazendo dump como estrategia de backup, o
que está errado..(eu ja li o otimo artigo do Telles) #1.
pretendo nos próximos dias implantar backup físico\logico.
como estamos com 5 servidores de banco de dados, vc teria alguma ferramenta
para recomendar que faça essa gerência de backup em vários servidores e uma
maneira mais facil?

#1:https://savepoint.blog.br/2010/05/06/dump-nao-e-backup/




-- 

Douglas Fabiano Specht
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] ERROR: out of shared memory in pg_dump

[Fabrízio de Royes Mello]

Em 29 de junho de 2017 11:35, Euler Taveira  escreveu:
>
> Em 28 de junho de 2017 22:35, Douglas Fabiano Specht <
douglasfabi...@gmail.com> escreveu:
>>>
>>>
>> Euler,
>> esse valor é para cada schema 233 tabelas ou 41000 tabelas no geral de
todos os schemas..?
>
>
> É a quantidade de tabelas por execução do pg_dump. Então seria 181
schemas x 233 tabelas.
>

Não é *exatamente* este valor porque o PostgreSQL cria um hash na memória
compartilhada (TopMemoryContext) para alocar esses locks e o tamanho dela é
definido por:

max_locks_per_transaction * (max_connections + max_prepared_transactions)

Quero dizer com isso que não é necessário colocar no
"max_locks_per_transaction" o valor da multplicação que o Euler comentou
que é demasiado e ocupara memória compartilhada sem necessidade. Em um
cenário como o seu que são muitas tabelas para efetuar dump poderi então
fazer o seguinte cálculo:

(numero_de_tabelas / (max_connections + max_prepared_transactions)) + 64

Desta forma quando rodar o dump vc terá slots suficientes para locks e
também a folga de 64 para sua aplicacao continuar funcionando... porém eis
que me surge uma dúvida??

- Vc precisa fazer um dump de TODOS schemas ao mesmo tempo???


Att,

--
   Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Transferir Banco Postgres para outra máquina

[Euler Taveira]

Em 29 de junho de 2017 14:32, Rafael Bragatto Gratz <
raf...@projetasistemas.com.br> escreveu:

> Considerando duas máquinas com hardware e versões de postgresql
> diferentes, o processo com menor down-grade seria com o pg_dumpall​ ou há
> alguma outra forma de ser feito?
>
> Não. s/down-grade/downtime/


> No meu caso seria migração do postgresql da versão 9.0 para  a 9.6
>

O menor downtime pode ser conseguido com o uso de replicação lógica (Slony,
Londiste, Bucardo, ...).


-- 
   Euler Taveira   Timbira -
http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] SELECT simples lento dentro da procedure e rápido fora dela

[Fabrízio de Royes Mello]

Em 28 de junho de 2017 22:57, Ronaldo Bernardes Pereira <
ronaldobernar...@gmail.com> escreveu:
>
> ... [corte] ...
>
>
> --===   Como acredito que você irá resolver seu problema, seque
considerações
>
> O problema encontrado é que o PostgreSQL fez um CAST da coluna (gn)
(Filter: ((gn)::text = '900'::text)) para atender o tipo de argumento
da FUNCTION que era do tipo text e no caso a coluna que ele comparava era
do tipo char. Como o tamanho do campo tipo text pode ser muito maior do que
um campo tipo char,  houve então o CAST implícito pelo PostgreSQL e com
isso única alternativa que ele tinha nesse caso era fazer um seq scan, pois
o índice não atendia para esse caso.
>

Show de bola Ronaldo... excelente análise e retorno... é por esse tipo de
"cuidado" e "dedicação" sem compromisso que nunca deixo de acreditar em
comunidades.

Só por favor evite o top-posting.



> --=== -->> Sugestões:
>
> 1 - Qual o tipo da coluna nfce_chave_acesso_fk e chave_acesso para
entender melhor o problema?
>
> 2 - Colocar o tipo do argumento da FUNCTION com o mesmo tipo da coluna,
para não ocorrer CAST implícito das colunas nfce_chave_acesso_fk ou
chave_acesso
>
> 3 - Caso não tenha como mudar o tipo do argumento da FUNCTION, então
realizar o CAST explicito na variável (chave) no corpo FUNCTION na linha (
 PERFORM num_cupom FROM cf_cupom WHERE nfce_chave_acesso_fk = chave;)
>
> Ex: PERFORM num_cupom FROM cf_cupom WHERE nfce_chave_acesso_fk =
chave::bpchar;
>
> 4 - Executar e nos passar o resultado
>
>

Ótimo... e pior é que esse tipo de equívoco é mais comum do que parece e
nos passou totalmente desapercebido... porém lá no início da thread
deveriamos ter mais informações como a estrutura das tabelas envolvidas
então todos consideraram que os tipos de dados eram iguais e que outro
problema deveria estar ocorrendo... mas novamente nós como "seres humanos"
tendenciamos a complicar as coisas ao invés de simplificar.

Se puder depois @Alexsander dar um feedback, caso a sugestão do Ronaldo
ajudou para ai termos um bom histórico na nossa lista de discussão para
consultas futuras.

Att,

--
   Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Transferir Banco Postgres para outra máquina

[Emanuel Araújo]

>
>
> Ambiente Linux CentOS 6
> Postgres 9.1
> Somente 1 Database, tamanho 415 GB
> Peculiaridade : 95% desse tamanho são binários de arquivos anexados ao
> banco
> Atualmente o pg_dump leva 22h para terminar
>
> Eu preciso transferir esse banco (no menor tempo possível) para outro
> equipamento similar.
>
> Favor sugerir dicas da melhor forma que os senhores indicam
>
> 1 - pg_dumpall - pg_restore ?
> 2 - recursos de replicação ?
> 3 - rsync ?
> 4 - outros métodos ???
>
>
Pelo que eu entendi, você quer apenas migrar o banco de uma maquina para a
outra, correto?  Sem muitas delongas e sem muitos detalhes do que seria
mais apropriado como atualizar a versão do PostgreSQL, etc ...

1. Instalar o mesmo SO e a mesma versão do PostgreSQL na máquina nova.
2. Parar o PostgreSQL e copiar o DIR data via rsync mesmo.  O tempo de
cópia vai depender da sua infra de rede (claro).
3. Sobe o banco no novo servidor.

Se for apenas isso, vejo como a forma mais simples possível.

Abraço.




-- 


*Atenciosamente,Emanuel Araújo*

*Linux Certified, DBA PostgreSQL*
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Transferir Banco Postgres para outra máquina

[Rafael Bragatto Gratz]

Considerando duas máquinas com hardware e versões de postgresql diferentes,
o processo com menor down-grade seria com o pg_dumpall​ ou há alguma outra
forma de ser feito?

No meu caso seria migração do postgresql da versão 9.0 para  a 9.6

Atenciosamente
Rafael Bragatto Gratz

Projeta - Sistemas Orientados ao Seu Mundo
www.projetasistemas.com.br
Tel/Fax: (27) 3026-5959
Celular:  (27) 99244-4200

Em 27 de junho de 2017 18:30, Douglas Ghirelli 
escreveu:

>
>
> Em sáb, 24 de jun de 2017 às 21:19, Euler Taveira 
> escreveu:
>
>> Em 24 de junho de 2017 16:26, Luiz Henrique 
>> escreveu:
>>
>>>
>>> Desejo transferir de forma definitiva.
>>
>>
>> Uma das formas mais rápidas seria utilizando replicação. Para isso o
>> hardware/SO deve ser (quase) igual. Uma vez montada a replicação [1], basta
>> escolher uma janela de manutenção e fazer o failover (pg_ctl promote).
>>
>>
>> [1] http://eulerto.blogspot.com.br/2017/02/replicacao-o-que-mudou.html
>>
>>
>>
> Dando um feedback, recentemente fiz a migração entre regiões na AWS,
> trazendo meu serviços para South América (São Paulo), e utilizei a técnica
> q o Euler descreveu, funcionou muito bem e o downtime foi mínimo.
>
>
>
>
>
>>
>> --
>>Euler Taveira   Timbira -
>> http://www.timbira.com.br/
>>PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
>> 
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
> --
> Douglas Paulo Ghirelli
> Profissional de Tecnologia da Informação
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] ERROR: out of shared memory in pg_dump

[Euler Taveira]

Em 28 de junho de 2017 22:35, Douglas Fabiano Specht <
douglasfabi...@gmail.com> escreveu:

>
>> Euler,
> esse valor é para cada schema 233 tabelas ou 41000 tabelas no geral de
> todos os schemas..?
>

É a quantidade de tabelas por execução do pg_dump. Então seria 181 schemas
x 233 tabelas.


-- 
   Euler Taveira   Timbira -
http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral