2015-02-18 14:18 GMT-02:00 Bruno Pio <[email protected]>: > > >> > >> >>> Quanto a consulta, o retorno foi: >>> >>> 13124322;"nf_{ssdmed";13124322;"v" >>> >>> >> Esse é um nome bem estranho, e no caso é uma view. Tem como saber no >> histórico da aplicação algo sobre essa view? Está em uso? De onde veio? Etc. >> > > > Segundo o desenvolvedor, não é utilizada nenhuma view com esse nome, o que > ele disse que utiliza são cursores. O que existe é uma tabela com o nome de > nf_issdmed. > > Isso pra mim é muito suspeito. Tem certeza de que não foi alguém criou uma view com o nome errado, não conseguiu excluir e tentou fazer alguma alteração direta no catálogo?
Outra coisa, usaram (pode ser há muito tempo) o pg_resetxlog nessa instância? > >> >> >>> ERRO: cabeçalho de página é inválido no bloco 2046 da relação >>>>> base/10928130/13581760 >>>> >>>> >>>> Provavelmente é uma tabela corrompida (se fosse um índice o REINDEX >>>> resolveria), pode verificar de qual se trata usando a seguinte consulta: >>>> >>>> SELECT oid, relname, relfilenode, relkind >>>> FROM pg_class >>>> WHERE relfilenode = 13581760; >>>> >>>> Suspeito que seja a mesma da consulta acima, mas temos que conferir. >>>> >>> >>> O retorno dessa consulta foi: >>> >>> 2840;"pg_toast_2619";13581760;"t" >>> >>> >> Ok. Então é uma tabela TOAST, precisamos então mapear a qual tabela esta >> pertence: >> >> SELECT oid, relname, relfilenode, relkind >> FROM pg_class >> WHERE reltoastrelid = 2840; >> > > O retorno desse SELECT foi: > > 2619;"pg_statistic";13581757;"r" > > Por curiosidade, eu executei um SELECT * FROM pg_statistic; que me > retornou o mesmo erro relatado anteriormente: > > ********** Error ********** > > ERRO: cabeçalho de página é inválido no bloco 2046 da relação > base/10928130/13581760 > SQL state: XX001 > > Que vi que significa Data Corrupted, é isso mesmo? > De fato é a mesma relação. Esse erro ocorre devido à tabela TOAST corrompida. Felizmente é a pg_statistic, os dados dela podem ser recriados. De qualquer forma sua base tem problemas de corrupção, eu recomendo você tentar fazer um backup usando o pg_dump dessa instância inteira (todas as bases). Faça o backup, depois remova tudo (rm -rf $PGDATA), recrie uma instância vazia (initdb ou pg_createcluster) e restaure o backup. É de fato a única forma de garantir que não há corrupção de dados. Agora, para fazer o pg_dump você tem que se livrar dos problemas atuais, quanto à pg_statistic eu imagino que não será um problema, já que os dados dela não são incluídos no pg_dump. Quanto à view, essa sim pode ser um problema. Primeiramente eu tentaria executar um REINDEX da pg_class, se isso não funcionar, nos resta executar um DELETE na pg_class desse registro especificamente (para isso você deverá se conectar como um superusuário e habilitar o allow_system_table_mods). **IMPORTANTE*:* execute imediatamente um backup físico, antes de tentar qualquer atualização nas tabelas de catálogo ou qualquer intervenção manual. 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
