[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