Prezado Fabrizio,
Complementando o e-mail anterior, temos o seguinte cenário:
Existe a tabela public.conteudo, a qual armazena os nomes dos conteudos (
arquivos ) bem como o OID/LOID dos respectivos arquivos.
A tabela conteudo a que me refiro tem a seguinte estrutura:
CREATE TABLE conteudo
(
"CD_CONTEUDO" integer,
"NAME" character varying(255) NOT NULL,
"CONTENT" integer NOT NULL
)
WITH OIDS;
Seria algo como fazer o upload de um arquivo para o postgre através de uma
aplicação, a qual, ao finalizar este upload para o banco irá retornar um
OID/LOID , que então é armazenado nesta tabela chamda "conteudo" no campo
"CONTENT". Seria como ter uma relação de PK/FK utilizando o campo OID para
sabermos que OID faz referencia a qual arquivo.
O que acontece é que, o backup foi gerado sem o parâmetro "-o" ( que pelo que
nos consta, iria garantir que ao restaurar o backup, os OIDs poderiam ser
mantidos e assim o relacionamento de PK/FK com o campo "CONTENT" que usa os
OIDS como FK fosse preservado.
O nosso problema consiste em achar alguma forma na qual seja possível novamente
ter integridade nessa relação de PK/FK que está sendo utilizada para relacionar
os OIDs/LOIDs dos arquivos cadastrados no banco de dados, pois as FKS de OIDs
cadastradas na tabela de conteudo, agora apontam para arquivos diversos, já que
os oids originais não foram preservados no backup.
Gerar um novo backup usando a opção "-o" resolveria nosso problema, mas
acontece que não temos mais como fazer isso pois os dados já foram deletados e
por isso não temos como gerar novamente um backup usando a opção "-o" para
assim preservar os OIDs corretos.
Assim, em nossa situação, acontece que quando solicitamos para baixar (fazer o
download) de um arquivo chamado "abcd.doc", o conteudo (blob) retornado é o de
outro arquivo "efgh.doc", devido ao problema de que quando restauramos o
backup, novos OIDs foram criados e os antigos não foram preservados.
Sabemos que TODOS eles estão de forma íntegra em nossa base de dados, porém,
como os OIDs não foram preservados no backup, perdemos o relacionamento que,
por exemplo, diria que o OID no. 123456 corresponde ao arquivo "abcd.doc".
Dessa forma, temos um cenário bastante peculiar, pois sabemos que todos os
arquivos que precisamos está em um banco de dados íntegro, mas devido ao fato
dos OIDs não terem sido preservados, como consequencia o relacionamento que
utilizavamos para dizer qual OID correspondia a um determinado arquivo, não
estamos conseguindo recuperar esses dados. Mesmo sabendo que eles se encontram
presentes em nosso banco de dados restaurado a partir de um backup.
Fabrizzio, voce teria alguma sugestão para nos indicar neste cenário?
Desde já agradeço por sua ajuda!
Abraço,
Att. Júlio Alcântara
--- Em sex, 13/3/09, Julio Tavares <[email protected]> escreveu:
De: Julio Tavares <[email protected]>
Assunto: Problema com OIDs/LOIDs ao restaurar base de dados com blobs
Para: [email protected]
Data: Sexta-feira, 13 de Março de 2009, 20:16
Prezado Fabrizio,
Encontrei seu site/blog navegando na internet, e gostaria de compartilhar
com você as seguintes informações ( também postei essa mensagem na
lista postgre brasil).
Gostaria de trocar informações a respeito de um problema que estamos passando.
Como vi em seu blog uma situação parecida, de problema com blobs/oids/loids,
resolvi lhe enviar este e-mail .
Segue abaixo a situação:
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
