[firebase-br] RES: Backup

Alexandre camilo em apollosistemas.com.br
Ter Out 20 13:50:50 -03 2015


Não sou o Carlos, mas você pode restaurar utilizando a opção -N 
(NO_VALIDITY) só que com isto não será restaurada nenhuma validação para 
o banco, você terá que criá-las novamente.


Alexandre Camilo.



Em 20/10/2015 12:28, INFOSOL escreveu:
> 	Carlos, bom dia!!
>
> 	Já aconteceu isto e não necessariamente seria com tabelas do
> sistema.
> 	Veja meu caso.
> 	Em uma tabela foi adicionado um campo novo NOT NULL.
> 	Ex: ALTER TABLE XXXXX ADD YYYYYYY char(1) NOT NULL
>
> 	Se for feito um backup sem atribuir um valor ao campo YYYYYYYY, o
> backup é realizado, mas quando for ser feito o restore ocorrerá o erro no
> campo não pode ser NULL, e o restore não será concluído.
> 	Aproveito para perguntar se existe alguma forma de fazer, por
> exemplo:
> 	1. Apenas extrair o Metadado (isto é possível).
> 	2. Alterar o campo YYYYYYY sem a atribuição do NOT NULL
> 	3. De alguma forma restaurar o backup "pulando" a parte da criação
> do Metadados e apenas restaurando as tabelas.
> 	Não sei se me compreendeu.
>
> 	Agradeceria qualquer dica de como poder restaurar um backup que
> esteja nesta situação de um campo not null.
> 	
> 		Amilcar
>
>
>
>
>
>
>
> -----Mensagem original-----
> De: lista [mailto:lista-bounces em firebase.com.br] Em nome de Carlos H. Cantu
> Enviada em: terça-feira, 20 de outubro de 2015 09:37
> Para: FireBase
> 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.
>
> Provavelmente porque alguém alterou o campo manipulando diretamente as
> 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.
>
> Por isso mesmo, toda rotina automatizada de backup deveria testar a
> restauração também, para ter certeza de que tudo está OK. Utilitários
> 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).
>
> O erro em questão é um erro lógico, e não "físico", portanto, não há
> como você saber da existência dele durante o backup... apenas no
> restore.
>
> []s
> Carlos H. Cantu
> www.FireBase.com.br - www.firebirdnews.org
> www.warmboot.com.br - blog.firebase.com.br
>
>
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use:
> http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas:
> http://www.firebase.com.br/pesquisa_lista.html
>
>
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use: http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas: http://www.firebase.com.br/pesquisa_lista.html
>

-- 

Alexandre Camilo
+55 27 3233-4143





Mais detalhes sobre a lista de discussão lista