[firebase-br] RES: Backup
Carlos H. Cantu
listas em warmboot.com.br
Ter Out 20 14:27:48 -03 2015
I> Carlos, bom dia!!
I> Já aconteceu isto e não necessariamente seria com tabelas
I> do sistema.
I> Veja meu caso.
I> Em uma tabela foi adicionado um campo novo NOT NULL.
I> Ex: ALTER TABLE XXXXX ADD YYYYYYY char(1) NOT NULL
Mas quando já existe dados na tabela, aí é sua responsabilidade de
logo em seguida dar um update nos registros colocando um valor no novo
campo, ou criando o campo com um valor default.
I> Aproveito para perguntar se existe alguma forma de fazer, por
I> exemplo:
I> 1. Apenas extrair o Metadado (isto é possível).
Para extrair a metadata de um backup, sem recuperar os dados:
gbak -r -m
I> 2. Alterar o campo YYYYYYY sem a atribuição do NOT NULL
I> 3. De alguma forma restaurar o backup "pulando" a parte da criação
I> do Metadados e apenas restaurando as tabelas.
I> Não sei se me compreendeu.
I> Agradeceria qualquer dica de como poder restaurar um backup que
I> esteja nesta situação de um campo not null.
Você pode restaurar com a opção -n (para remover todas as clausulas
not null), colocar um valor no campo, e fazer um PUMP dos dados para
uma base vazia com a metadata completa.
A IBSurgeon tem uma ferramenta chamada IBBackupSurgeon que permite
editar um arquivo de backup, extraindo os dados ou mesmo modificando
alguma coisa. O IBBS faz parte do HQBird, que pode ser comprado com
desconto na loja online da FireBase.
[]s
Carlos H. Cantu
www.FireBase.com.br - www.firebirdnews.org
www.warmboot.com.br - blog.firebase.com.br
I> -----Mensagem original-----
I> De: lista [mailto:lista-bounces em firebase.com.br] Em nome de Carlos H. Cantu
I> Enviada em: terça-feira, 20 de outubro de 2015 09:37
I> Para: FireBase
I> Assunto: Re: [firebase-br] Backup
MG>> Ao executar um backup pelo GBACK o backup acontece perfeitamente. Porém
MG>> ao recuperar não recupera. O problema é simples.. é apenas um campo que
MG>> foi criado e passou a ser obrigatório porém está sem dado algum.
I> Provavelmente porque alguém alterou o campo manipulando diretamente as
I> tabelas de sistema, o que não deveria ser feito.
MG>> 1) Quando automatizamos o backup queremos que a rotina se torne simples,
MG>> rápida. Contudo se o backup permite ser feito com esse erro. Somente
MG>> vamos poder identificá-lo no momento de restaurar, caso aconteça algo
MG>> com o BD original.
I> Por isso mesmo, toda rotina automatizada de backup deveria testar a
I> restauração também, para ter certeza de que tudo está OK. Utilitários
I> com o DataGuard, fazem isso automaticamente.
MG>> 2) Existe alguma forma de prepararmos o backup para que finalize com
MG>> erro caso encontre problemas de integridade de dados? (no momento de
MG>> fazer o backup e não no momento de restaurá-lo).
I> O erro em questão é um erro lógico, e não "físico", portanto, não há
I> como você saber da existência dele durante o backup... apenas no
I> restore.
I> []s
I> Carlos H. Cantu
I> www.FireBase.com.br - www.firebirdnews.org
I> www.warmboot.com.br - blog.firebase.com.br
Mais detalhes sobre a lista de discussão lista