Prezados amigos,
Tenho um caso bastante peculiar, o qual acredito ser de grande valia/interesse
para compartilhar com todos.
Trata-se de um assunto bastante crítico: backup e restauração de dados.
Vou tentar descrever a situação da forma mais objetiva possível.
Então, antes mesmo de iniciar, o primeiro de tudo: o básico sobre nossas
versões:
Usamos o PostgreSql 8.0.3 rodando em um servidor linux red hat EL 4.
Os backups foram gerados utilizando o seguinte comando/parametros:
pg_dump -U postgres -b -Fc -v -f /backup.dmp pgprd 2>>backup_pg.log
>>backup_pg.log
O restore da base foi feito usando o seguinte comando/parametros:
pg_restore -U postgres -d pgprd -Fc -v "backup.dmp" 2>>/restore_pg.log
>>/restore_pg.log
Em
nosso banco de dados de produção, existe uma base de dados com
aproximadamente 290GB, aonde mais de 90% desse tamanho deve-se a
existência de arquivos binários (blobs) que foram inseridos diretamente
em uma das tabelas desta base, a qual existe especificamente com o
proposito de armazenar arquivos.
Tanto
o processo de backup como o processo de restauração ocorreram de forma
perfeita, sem adicionar, em nenhum dos casos, nem mesmo uma linha de
erro nos logs. Todo o processo de backup e restauração acontece com
perfeição e integridade.
Então, após restaurar o backup
desta base de dados com o objetivo de recuperar alguns arquivos que
estão inseridos como blob dentro desta tabela que os amrmazena, nos
deperamos com a seguinte situação:
Ao tentar baixar o blob de um
destes arquivos localmente para minha máquina (através de uma aplicação
java já madura e testada), percebo que o conteudo do arquivo (blob) que
tentei baixar não corresponde ao que deveria! Na realidade, o blob do
arquivo baixado parece apontar para um outro arquivo que existe dentro
da tabela, como se os OIDs/LOIDs não estivessem coerentes e apontando
para onde deveriam!
Para facilitar o entedimento, tomemos como exemplo:
01. Através da aplicação, solicito para baixar da base restaurada o arquivo
"alunos.pdf".
02.
Ao acessar o arquivo "alunos.pdf", recem baixado, percebo (acessando o
conteudo deste arquivo com o bloco de notas, por exemplo) que se trata
de um arquivo do WORD (e não do PDF que gostaria e que foi o que
solicitei!).
03. Ao renomear este arquivo recebm baixado
("alunos.pdf") para "alunos.doc" (mudando sua extensão), o arquivo abre
perfeitamente no word, e de forma íntegra!
04. Dessa forma, ao
invés de ter acesso ao blob do arquivo que eu especifiquei
inicialmente, é baixado o blob de algum outro arquivo presente nesta
mesma tabela que armazena arquivos.
Ou seja: solicitei para
que fosse baixado o blob do arquivo "alunos.pdf", porem, percebi que o
blob baixado não é o do arquivo que solicito, mas sim de algum outro
arquivo que está presente na tabela! Dessa forma, não se trata de
corrupção de dados ou algo parecido, trata-se de que o postgre está
apontando para blobs de arquivos que não são os originalmente
solicitados!
Obs.:
Ao tentar baixar/acessar um determinado blob de um determinado arquivo,
sempre o que é retornado é um mesmo blob de um outro determinado
arquivo, mas que nao corresponde ao blob do arquivo que foi
originalmente solicitado.
Ex.: Sempre que tento baixar o blob
do arquivo "alunos.pdf", é baixado o blob do arquivo "floresta.doc".
Então, ao perceber isso e renomear o arquivo "alunos.pdf" para
"alunos.doc" ( com o simples objetivo de associar a extensao do word a
este arquivo, no windows ) o arquivo pode ser aberto de forma perfeita
e íntegra!
O que quero dizer é que não existe corrupção de
dados. Simplesmente o que acontece é que sempre é mantida esta relação:
ao solicitar o conteúdo blob de um arquivo "X", é sempre retornado o
blob de um arquivo "Y".
Me
parece que, ao restaurar o backup, o postgres perdeu a referência
correta e "embaralhou" os ponteiros que deveriam apontar para os
arquivos certos, e agora apontam para outros arquivos que não são os
corretos, dentro da mesma tabela. Parece ser algum problema de perda de
referências relacionadas a OID/LOIDs quando o banco é restaurado.
Obs.2:
A tabela que armazena estes arquivos binários, foi criada com a opção
"WITH OIDS", que teoricamente seria o que iria garantir que, ao
restaurar o backup, os oids seriam preservados de forma íntegra. Mas
isto não está funcionando na prática.
Encontrei muito pouco material com situação parecida com esta. Um deles está no
LINK:
http://bytes.com/groups/postgresql/400042-pg_largeobject-oid-mistmach-after-restore
Mais
uma vez reitero que não existe corrupção nos dados, simplesmente as
referencias dos OIDs parecem estar embaralhadas/trocadas!
Gostaria
de trocar informações a respeito dessa questão crítica e todo e
qualquer comentário/sugestão a respeito dessa questão será muito bem
vindo.
Desde já agradeço a atenção de todos da lista!
Abraço,
Júlio Alcântara
[email protected]
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
