Re: [firebase-br] *FIREBIRD BUG* Restauração (Cantu)

[Eduardo Jedliczka (TeamFB)]

Não sou o Cantu, mas vou dar o meu pitaco.

não é um bug... isto é uma regra!!!

O FireBird não aceita, a exemplo do Oracle e outros SGDB ter triggers / SPs 
"inválidas". Ou o banco está 100% íntegro ou está "com problemas".

Eu nunca especifiquei um "PLAN" num select, exceto quando meu select estava 
muito mal escrito (neste caso o ganho de espeficificar o PLAN foi grande, 
mas ao acertar o select, a diferença foi mínima)... Principalmente em 
Triggers e SP que podem fazer um banco não-restaurável.

Só mais uma coisa, as novas versões do FB testam para saber se o plano 
especificado atende o select, ou seja, o banco também reconstrói a lista 
dele de planos, e, num select otimizado e bem escrito que não tenha 
problemas com o PLAN, pode-se ficar ligeiramente mais lento quando o PLAN 
for especificado.

======================
Eduardo Jedliczka
Membro do TeamFB - FireBase
Apucarana - PR
======================
"Posso não concordar com nada do que dizes.
Mas defenderei até a morte o seu direito de dizê-lo"
(Voltaire 1694-1778)

----- Original Message ----- 
From: "JJW Informática Ltda. - Roberto" <roberto em jjwinformatica.com.br>
To: "FireBase" <lista em firebase.com.br>
Sent: Monday, December 04, 2006 10:13 AM
Subject: [firebase-br] *FIREBIRD BUG* Restauração (Cantu)


Bom dia cantu, gostaria de relatar um bug sobre o firebird (acredito que
seja) na restauração.

Bem, neste final de semana  tive um cliente com o base de dados corrompida e
o mesmo não estava fazendo os backups corretamente, logo tive que dar um
jeito em arrumar a base atual.
A base corrompeu por ter ocorrido uma queda de energia e o nobreak não
aguentou.
Iniciei executando o gifx -mend -full -ignore para preparar o base
corrompida para backup. Após executar o backup, fiz a restauração
DESATIVANDO OS ÍNDICES, bem agora que começou minha dor de cabeça. O
processo de restauração funcionou até o momento em que (pelo -verbose no
restore) começaram a ser criados todos os ínidices ao final da restauração
(em modo INACTIVE é claro...).
Ao restaurar um dos relacionamentos, um erro ocorreu (agora não me lembro da
descrição do mesmo) relatando que uma chave não pode ser "criada" por
dependica de um "PLAN".
Bem, após horas e horas de GFIX, GAB -B e GABK -C, abri o glorioso IBExpert
e procurei no Metadata pela palavra "PLAN", aí então encontrei Stored
Procedures com select's utilizando o comando PLAN sobre a chave extrangeira
que havia sido relatada no erro durante a restauração dos índices. Então
coloquei em comentário essas Stored Procedures para que seus selects não
fossem executados com os PLAN's pré definidos sobre a Chave!
Fix um backup e restaurei a base desativando novamente os índices, e olha
só, FUNCIONOU!
Arrumei as inconsistências e reativei os indices. Base 100% funcional
novamente.

Bem, estou relatando tudo isso para saber se isso realmente é correto, o
restore desativando os índices não pode ser executado/concluído se existirem
select's com PLAN's????


Atenciosamente,

Roberto G. Vieweg Neto
JJW Informática Ltda
Av Getúlio Vargas, 370 - Centro - Timbó/SC - CEP: 89120-000
Fone: (47)3382-0629 - Fax: (47)3382-6604 - suporte em jjwinformatica.com.br


______________________________________________
FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
Para editar sua configuração na lista, use o endereço 
http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
Para consultar mensagens antigas: http://firebase.com.br/pesquisa