Obrigado estou testando, o sistema é virtaulizado e estou trabalhando em uma cópia, podem mandar as dicas que são bem vindas
Em 31 de julho de 2012 13:11, Tiago Adami <[email protected]> escreveu: > Em 31 de julho de 2012 11:18, Flavio Henrique Araque Gurgel > <[email protected]> escreveu: > > > > Em 31-07-2012 08:59, Tiago Adami escreveu: > >> 2012/7/31 Fabio<[email protected]>: > >> O seu problema está na tabela "pg_toast_78248" e não necessáriamente > >> na tabela com os dados. Então: > > > > Opa opa > > pg_toast_* tem dados sim. > > As tabelas toast guardam dados acima de um certo tamanho, 8 kiB por > padrão. > > Correto. Quis dizer é que não é na "tabela principal", do esquema do > usuário/aplicativo, ou seja, "documento_elaborado". Me expressei mal. > > >> 1) Carregue o banco de dados em modo "standalone" - sem ser pelo > >> serviço e sim pelo console com o executável "postgres". Lembre de > >> modificar o parâmetro "listen_adress=localhost" no seu > >> "postgresql.conf"; > >> 2) Execute o reindexdb com a opção "-s" (apenas catálogo do sistema) > >> 3) Se ocorrer algum erro, poste aqui. Se o comando for realizado com > >> sucesso, tente realizar o dump novamente. > > > > Sinto muito mas isso não vai resolver. > > Quando existe erro "invalid page header..." houve corrupção dos dados em > > disco. > > Exato, isso significa que "se" conseguir recuperar os dados alguma > coisa irá faltar. > > > Não há o que fazer, houve perda de dados. > (...) corte > > Respondi com certa pressa que esqueci de mencionar o parâmetro > "zero_damaged_pages" [1]. Ele irá ignorar os blocos defeituosos e > permanentemente marcá-los como inexistentes. Ou seja: *destruir todas > as linhas que estão na página*. Carregando o banco em modo > "standalone" e reindexando o catálogo eu já consegui zerar os blocos > inválidos e realizar um pg_dump recuperando dados parcialmente. > Pensando melhor, talvez o "reindexdb -s" não ajude muito nestes casos > porque o problema foi em uma tabela, e não em um índice... mas até > hoje é o procedimento que realizo neste tipo de situação e obtenho > sucesso na maioria das vezes. > > NOTA: É importantíssimo lembrar que, antes de tentar estas dicas que > passei, faça um backup real (não pelo pg_dump) dos arquivos do seu > cluster com o serviço do SGBD desativado (toda a pasta *data*). Usando > o "zero_damaged_pages" o resultado pode ser catastrófico e não há como > desfazer suas alterações. > > [1] > http://www.postgresql.org/docs/8.3/static/runtime-config-developer.html > > -- > TIAGO J. ADAMI > http://www.adamiworks.com > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > -- Fabio Serafim da Silva Engenheiro de Software
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
