Melhor Opção para Backup/Restore
Olá,
Recentemente postei o topico abaixo ´por engano do forum de Delphi´ e acho que por isso ainda não foi respondido:
Fiz um backup com o gbak e ...blz ... (((FB 1.5)))
mas na hora de restaurar da o seguinte erro(s):
gbak: cannot commit index RDB$FOREIGN22
gbak: ERROR: violation of FOREIGN KEY constraint ´PK_PEDIDO´ on table ´PEDIDO´
gbak: ERROR: action cancelled by trigger (3) to preserve data integrity
gbak: ERROR: Cannot deactivate primary index
gbak: Exiting before completion due to errors
Esse banco ta muito pequeno...por enquanto...por isso estou querendo corrigir isso logo. Vc já teve problema parecido? Como resolveu?
Grato.
Devido a ocorrência desse probleminha(ão) pois o restore Cria a tabela de Pedidos VAZIA!!!! Testei fazer o backup com a ajuda do nosso amigo IBEXPERT. Não no SERVICES/BACKUP mas EXTRAINDO O METADATA no menu TOOLS....o que me pareceu bastante interessante pois extraiu os dados num arquivo txt ja prontinho para ser recriado noutro banco tirando os dados dessa CAIXA PRETA que é o arquivo FDB e FBK !!! e deixando o mesmo portável para qualquer banco ou para ele mesmo. Depois de criar o arquivo txt (sql), compactei o mesmo com winrar... Gostaria de saber a opinião de vocês a esse respeito e se tem alguma forma de fazer uma rotina em DELPHI que faça esse trabalho ´extrair metadata´ com os dados como o IBEXPERT faz.
Acho que esse é o melhor backup.
Abraço a todos e..por favor, se você tem uma opinião sobre isto não deixe de postar
Recentemente postei o topico abaixo ´por engano do forum de Delphi´ e acho que por isso ainda não foi respondido:
Fiz um backup com o gbak e ...blz ... (((FB 1.5)))
mas na hora de restaurar da o seguinte erro(s):
gbak: cannot commit index RDB$FOREIGN22
gbak: ERROR: violation of FOREIGN KEY constraint ´PK_PEDIDO´ on table ´PEDIDO´
gbak: ERROR: action cancelled by trigger (3) to preserve data integrity
gbak: ERROR: Cannot deactivate primary index
gbak: Exiting before completion due to errors
Esse banco ta muito pequeno...por enquanto...por isso estou querendo corrigir isso logo. Vc já teve problema parecido? Como resolveu?
Grato.
Devido a ocorrência desse probleminha(ão) pois o restore Cria a tabela de Pedidos VAZIA!!!! Testei fazer o backup com a ajuda do nosso amigo IBEXPERT. Não no SERVICES/BACKUP mas EXTRAINDO O METADATA no menu TOOLS....o que me pareceu bastante interessante pois extraiu os dados num arquivo txt ja prontinho para ser recriado noutro banco tirando os dados dessa CAIXA PRETA que é o arquivo FDB e FBK !!! e deixando o mesmo portável para qualquer banco ou para ele mesmo. Depois de criar o arquivo txt (sql), compactei o mesmo com winrar... Gostaria de saber a opinião de vocês a esse respeito e se tem alguma forma de fazer uma rotina em DELPHI que faça esse trabalho ´extrair metadata´ com os dados como o IBEXPERT faz.
Acho que esse é o melhor backup.
Abraço a todos e..por favor, se você tem uma opinião sobre isto não deixe de postar
Raul Seixas
Curtidas 0
Respostas
Joaoshi
18/05/2008
Colega, parece que desta forma não são copiados os campos [b:2776a4245b]BLOB[/b:2776a4245b]
GOSTEI 0
Raul Seixas
18/05/2008
Ola joaoshi,
você tem razão, os campos blob não vêm... que pena pois já estava contente com a possibilidade de fazer backups portáveis e transparentes uma vez que com o gbak tive o problema citado mais acima quando fui fazer o restore. Sinceramente estou desanimado com o firebird por causa desse erros com backup/restore. Fiz dois projetos com esse banco e tive problema nos dois!!
tentei fazer o backup com o IBEXPERT e ele dá esse erro:
[b:24cf1a2afa]Unsuccessful execution caused by system error that does not preclude successful execution of subsequent statements.
messege length error (encontred 196, expected 192)[/b:24cf1a2afa].
fazendo com o gbak, ele não dá nenhuma mensagem de erro no backup mas o restore dá conforme citei acima.
Pra não ficar completamente sem backup, estou fazendo a cópia do arquivo .FDB depois de dar um stop no servidor mas já vi alguns posts aqui que não recomendam essa prática por dar possibilidade de corrupção no banco mas essa é a única maneira que encontrei de não ficar sem um backup.
Talvez algum colega já teve esse problema e conseguiu resolver...
Fico no aguardo
você tem razão, os campos blob não vêm... que pena pois já estava contente com a possibilidade de fazer backups portáveis e transparentes uma vez que com o gbak tive o problema citado mais acima quando fui fazer o restore. Sinceramente estou desanimado com o firebird por causa desse erros com backup/restore. Fiz dois projetos com esse banco e tive problema nos dois!!
tentei fazer o backup com o IBEXPERT e ele dá esse erro:
[b:24cf1a2afa]Unsuccessful execution caused by system error that does not preclude successful execution of subsequent statements.
messege length error (encontred 196, expected 192)[/b:24cf1a2afa].
fazendo com o gbak, ele não dá nenhuma mensagem de erro no backup mas o restore dá conforme citei acima.
Pra não ficar completamente sem backup, estou fazendo a cópia do arquivo .FDB depois de dar um stop no servidor mas já vi alguns posts aqui que não recomendam essa prática por dar possibilidade de corrupção no banco mas essa é a única maneira que encontrei de não ficar sem um backup.
Talvez algum colega já teve esse problema e conseguiu resolver...
Fico no aguardo
GOSTEI 0
Builder
18/05/2008
Experimente este utilitário para Backup/Restore, que utiliza o gbak (é um excelente frontend):
http://sydhnney.wordpress.com/2007/08/12/gerbackup-backup-banco-de-dados-firebird/
No caso de cópia direta do arquivo (copiar o .fdb), o ideal é parar as aplicações e o servidor firebird para que seja mais rápido e não ocorra problemas com quebra de integridade ou corrupção de dados.
Em qualquer uma das formas de backup acima descritas, o ideal é sempre testar o backup em uma máquina (jamais na máquina servidora, de produção), para verificar se realmente o arquivo fdb está ok. Já vi vários casos de cópias de segurança (no geral, não me refiro ao firebird) que na hora de restaurar o arquivo e utilizar, o processo simplesmente falhou (erros de CRC, arquivo não reconhecido pela aplicação, loops eternos de restauração, etc.).
Considere também a possibilidade de usar somente mídias graváveis (nada de dvd-rw, cd-rw). Você terá mais cds/dvs, com diferentes estágios do banco de dados, o que possibilita mais chances de recuperar informações (se o backup atual falhar, pegue o anterior, se falhar, pegue o anterior, o anterior...). Um erro, dependendo da situação poderá levar algum tempo para ser detectado (e por consequência os dados incorretos serão gravados no backup). Com os preços de cd-r e dvd-r, o processo de backup para arquivos compactados de até 4.7 gb, ficou irrisório. Compre um tubo com 100 unidades e fique tranquilo por um bom tempo.
Se estiver distribuindo sua aplicação a clientes, oriente os mesmos sobre a rotina de backup e a periodicidade, armazenamento das informações (mídias de backup) fora do ambiente da empresa e em local apropriado (prevenção contra incêndios, roubos, sabotagem, etc.). E principalmente, oriente sobre o processo de testar o backup afim de verificar se o mesmo está sendo concluído com sucesso.
Houveram muitas melhorias entre a versão 1.5 e a 2.x do Firebird, portanto, se sua aplicação permitir (compatibilidade com os componentes de acesso, código, etc.) considere a possibilidade de trabalhar com a nova versão (teste bem antes de colocar em ambiente de produção).
http://blogs.liws.com.br/cesar/?p=85
http://blogs.liws.com.br/cesar/?p=88
Abraços,
Anderson:.
http://sydhnney.wordpress.com/2007/08/12/gerbackup-backup-banco-de-dados-firebird/
No caso de cópia direta do arquivo (copiar o .fdb), o ideal é parar as aplicações e o servidor firebird para que seja mais rápido e não ocorra problemas com quebra de integridade ou corrupção de dados.
Em qualquer uma das formas de backup acima descritas, o ideal é sempre testar o backup em uma máquina (jamais na máquina servidora, de produção), para verificar se realmente o arquivo fdb está ok. Já vi vários casos de cópias de segurança (no geral, não me refiro ao firebird) que na hora de restaurar o arquivo e utilizar, o processo simplesmente falhou (erros de CRC, arquivo não reconhecido pela aplicação, loops eternos de restauração, etc.).
Considere também a possibilidade de usar somente mídias graváveis (nada de dvd-rw, cd-rw). Você terá mais cds/dvs, com diferentes estágios do banco de dados, o que possibilita mais chances de recuperar informações (se o backup atual falhar, pegue o anterior, se falhar, pegue o anterior, o anterior...). Um erro, dependendo da situação poderá levar algum tempo para ser detectado (e por consequência os dados incorretos serão gravados no backup). Com os preços de cd-r e dvd-r, o processo de backup para arquivos compactados de até 4.7 gb, ficou irrisório. Compre um tubo com 100 unidades e fique tranquilo por um bom tempo.
Se estiver distribuindo sua aplicação a clientes, oriente os mesmos sobre a rotina de backup e a periodicidade, armazenamento das informações (mídias de backup) fora do ambiente da empresa e em local apropriado (prevenção contra incêndios, roubos, sabotagem, etc.). E principalmente, oriente sobre o processo de testar o backup afim de verificar se o mesmo está sendo concluído com sucesso.
Houveram muitas melhorias entre a versão 1.5 e a 2.x do Firebird, portanto, se sua aplicação permitir (compatibilidade com os componentes de acesso, código, etc.) considere a possibilidade de trabalhar com a nova versão (teste bem antes de colocar em ambiente de produção).
http://blogs.liws.com.br/cesar/?p=85
http://blogs.liws.com.br/cesar/?p=88
Abraços,
Anderson:.
GOSTEI 0