Opa,
Em 30 de setembro de 2013 13:36, Adriano Espinoza de Oliveira < [email protected]> escreveu: > Pessoal está parcialmente resolvido meu problema, não postei a resposta > antes por falta de tempo mesmo. > Na madrugada de quinta para sexta-feria não tive tempo fazer o dump e o > restore, até tentei, mas a janela de tempo era curta e os sistema tinha q > voltar as 06:00hs, então optei por tentar o reindex total, inclusive das > tabelas do sistema, e resolveu. > Fiz base a base e de lá pra cá está tudo bem, o servidor não está caindo > mais. > > Mas tenho alguns questionamentos: > > Hoje vi a seguinte mensagem hoje, então suponho que ainda tenho algum > problema com indices, alguma dica? > > 10.11.0.2 2013-09-30 13:08:59 BRT [24107]: [1-1] db=nutracom,user=postgres > WARNING: could not remove relation 1663/105809227/572918907: Arquivo ou > diretório não encontrado > 10.11.0.2 2013-09-30 13:08:59 BRT [24107]: [2-1] db=nutracom,user=postgres > WARNING: could not remove relation 1663/105809227/572918903: Arquivo ou > diretório não encontrado > 10.11.0.2 2013-09-30 13:08:59 BRT [24107]: [3-1] db=nutracom,user=postgres > WARNING: could not remove relation 1663/105809227/572918901: Arquivo ou > diretório não encontrado > 10.11.0.2 2013-09-30 13:08:59 BRT [24107]: [4-1] db=nutracom,user=postgres > WARNING: could not remove relation 1663/105809227/572918899: Arquivo ou > diretório não encontrado > 10.11.0.2 2013-09-30 13:08:59 BRT [24107]: [5-1] db=nutracom,user=postgres > WARNING: could not remove relation 1663/105809227/572918894: Arquivo ou > diretório não encontrado > 10.11.0.2 2013-09-30 13:08:59 BRT [24107]: [6-1] db=nutracom,user=postgres > WARNING: could not remove relation 1663/105809227/572918896: Arquivo ou > diretório não encontrado > 10.11.0.2 2013-09-30 13:08:59 BRT [24107]: [7-1] db=nutracom,user=postgres > WARNING: could not remove relation 1663/105809227/572918898: Arquivo ou > diretório não encontrado > 10.11.0.2 2013-09-30 13:08:59 BRT [24107]: [8-1] db=nutracom,user=postgres > WARNING: could not remove relation 1663/105809227/572918892: Arquivo ou > diretório não encontrado > > > Durante o reindex, utilizando o comando " reindexdb -a", o reindex foi > interrompido com a msg abaixo, passei a reindexar base a base e tudo bem, > até chegar em uma determinada tabela, que não sei qual é, ele foi > interrompido. > Provavelmente é algum lixo ou backup pontual de um select ou coisa assim > que foi feita no banco, mas como posso identificar essa tabela? > > [local] 2013-09-27 03:48:32 BRT [11290]: [290-1] db=cimed,user=postgres > NOTICE: table "itens_faltas_pcp" was reindexed > [local] 2013-09-27 03:48:32 BRT [11290]: [291-1] db=cimed,user=postgres > NOTICE: table "dash_board_vendas_local" was reindexed > [local] 2013-09-27 03:48:32 BRT [11290]: [292-1] db=cimed,user=postgres > ERROR: could not create unique index > [local] 2013-09-27 03:48:32 BRT [11290]: [293-1] db=cimed,user=postgres > DETAIL: Table contains duplicated values. > Provavelmente a corrupção dos índices causou registros duplicados na tabela. Faça o seguinte SELECT (usando o campo a chave primária que é provalvemente é onde está o problema). SET enable_indexscan TO OFF; SET enable_bitmapscan TO OFF; SET enable_tidscan TO OFF; Assim você força uma leitura sequencial. SELECT campodachaveprimaria,count(1) FROM tabela GROUP BY campodachaveprimaria HAVING count(1)>1; Se o resultado for positivo é um problema, e você vai ter que corrigir os seus dados na mão. > > > Agradeço a todos, > > Adriano Espinoza > > > > Em 30 de setembro de 2013 13:13, Adriano Espinoza de Oliveira < > [email protected]> escreveu: > > >> >> >> Em 29 de setembro de 2013 09:51, Matheus de Oliveira < >> [email protected]> escreveu: >> >> >>> >>> >>> 2013/9/27 Jean Pereira <[email protected]> >>> >>>> On 09/26/2013 07:57 PM, Matheus de Oliveira wrote: >>>> >>>> >>>> >>>> >>>> 2013/9/26 Adriano Espinoza de Oliveira <[email protected]> >>>> >>>>> Boa tarde pessoal. >>>>> >>>>> >>>> Boa noite... =D >>>> >>>> >>>> >>>>> Hje de manhã tivemos "too many clients" no banco, eu não esta na >>>>> empresa, e o adm de redes foi lá e derrubou um monte de conexões do >>>>> postgres que ele achou q eram antigas... >>>>> >>>>> >>>> Bom, a alguns anos atrás, fiz isso também, se não me engano também >>>> era na versão 8.x (não lembro exato porque faz tempo, talvez seja a 7.x). >>>> >>>> >>>> Derrubou como? Se foi um "kill -9" é bom dar um "kill -9 `pidof >>>> cara_que_fez_isso`"... =P >>>> >>>> >>>> Estou brincando viu, vamos lá ... >>>> >>>> O banco ficou inacessível, ele fez um restart do banco, que não >>>>> subiu. Teve que apagar o PID na unha e depois o banco subiu... >>>>> >>>>> >>>> Ok. Normal... >>>> >>>> >>>> >>>>> Depois disso, quando cheguei, notei que o banco estava se >>>>> derrubando e subindo sozinho, exibindo essas mensagens: >>>>> >>>>> * 2013-09-26 12:09:25 BRT [18539]: [1-1] db=,user= LOG: server >>>>> process (PID 23040) was terminated by signal 6* >>>>> * 2013-09-26 12:09:25 BRT [18539]: [2-1] db=,user= LOG: terminating >>>>> any other active server processes* >>>>> *10.11.0.2 2013-09-26 12:09:25 BRT [23043]: [3-1] >>>>> db=cimed,user=postgres WARNING: terminating connection because of crash >>>>> of >>>>> another server process* >>>>> *(...)* >>>>> >>>>> >>>> (...) >>>> >>>> >>>> Como um velho conhecido meu fala, o kill é o ultimo do ultimo caso. >>>> >>> >>> Na verdade o kill em si não é tão problemático assim, você pode, >>> tranquilamente usar um `kill -SIGTERM` num backend do postgres para fazer >>> com que ele cancele a operação e feche a conexão normalmente, é o que o >>> `pg_terminate_backend` faz (só não tenho certeza absoluta que na 8.1 já era >>> assim, mas creio que sim), ou ainda, executar um `kill -SIGINT` e fazer com >>> que ele só cancele a operação corrente, o que é equivalente ao >>> `pg_cancel_backend`. >>> >>> Inclusive, você pode fazer o mesmo com o postmaster [2]. >>> >>> Agora, o `kill -9` (SIGKILL) não pode ser "ouvido" pelo PostgreSQL, >>> então é abrupto e não dá chance do pobre elefante se proteger, podendo >>> levar à problemas mais sérios (como esse). >>> >>> >>> >> >> Pois é Matheus, costumamos falar que o Kill -9 é igual tiro na cabeça: >> "estraga o velório". kkkk >> >> Tenho certeza que o adm que fez isso não vai fazer mais.. >> >> >> >>> Já que você deve ter conexões reservadas ao postgres, e o mesmo >>>> consegue matar conexão por dentro do banco. >>>> >>>> >>> Esse é um ponto muito importante. Vejo muita gente usando o superusuário >>> para como usuário da aplicação, isso é COMPLETAMENTE ERRADO. Inclusive pela >>> mensagem de warning do colega, parece que esse era o caso... ouch... >>> >>> [1] >>> http://www.postgresql.org/docs/current/static/functions-admin.html#FUNCTIONS-ADMIN-SIGNAL-TABLE >>> [2] http://www.postgresql.org/docs/8.1/static/postmaster-shutdown.html >>> >>> Atenciosamente, >>> -- >>> Matheus de Oliveira >>> Analista de Banco de Dados >>> Dextra Sistemas - MPS.Br nível F! >>> www.dextra.com.br/postgres >>> >>> >>> _______________________________________________ >>> pgbr-geral mailing list >>> [email protected] >>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >>> >>> >> > > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > Abraços -- JotaComm http://jotacomm.wordpress.com
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
