[firebase-br] Verificar erros no banco de dados

[Sandro Souza]

Tem certeza que conseguiu restaurar no FB 3.0 um backup feito por um FB 2.5?

Quando eu tentei fazer isso, fiquei mega surpreso ao ver uma mensagem de
erro informando que o FB 3.0 não suportava o formato daquele backup feito
pelo 2.5.

O mesmo aconteceu quando eu tentei acessar uma base de dados feita no FB
2.5, usando o FB 3.0.

A mensagem de erro que foi retornada foi algo do tipo: unsupported on-disk
structure for file found 11.2, support 12.0.

Significa que o FB 3.0 suporta a versão 12 do ODS (o formato interno da
base de dados, ODS = on-disk structure = estrutura no disco), mas não
suporta a versão 11.2 (a versão do ODS do FB 2.5).

Foi a primeira vez que eu vi esse tipo de erro no Firebird.

Como programador, posso dizer que é algo impensável, e diria até que é
inaceitável!

Como assim não suporta uma versão mais antiga?

Esse tipo de erro extraterrestre eu só vi com relação ao M$$$ SQL Server.

Realmente não aceitou restaurar um backup feito em uma versão anterior, e
isso é um dos motivos pelo qual eu realmente não gosto do M$$$ SQL Server.

Fiquei pasmo ao ver isso acontecer com o FB 3.0.

E já que estamos falando dessas diferenças, eu exportei um script com toda
a geração de uma base de dados que tenho em FB 2.5, e dessa forma, criei
uma nova base de dados vazia no FB 3.0 e executei o script para recriar
exatamente a mesma base de dados, mas agora toda 100% no FB 3.0.

Durante a execução do script, aconteceram alguns erros, pois por incrível
que pareça, os nomes de algumas constraints estavam conflitando, e eram
constraints cujo nome eu não havia definido, e portanto, o próprio FB gerou
um nome aleatório para elas.

Quando eu comecei a verificar isso, notei que no FB 3.0, o fato de você
informar que uma coluna é obrigatória (NOT NULL) automaticamente cria uma
CONSTRAINT de NOT NULL para aquela coluna, o que não existia antes do FB
3.0, e o nome que o FB 3.0 estava criando para essas novas constraints (que
não existiam) estava conflitando com os nomes de outras constraints que iam
ser criadas mais à frente dentro do mesmo script.

Nesse ponto ficou parecendo com alguns SGBDs como o Oracle e o M$$$ SQL
Server, que também tem constraints do tipo NOT NULL.

Entendo que ficou mais compatível com esses outros SGBDs, e também facilita
remover a obrigatoriedade de qualquer coluna, apenas excluindo a respectiva
regra de NOT NULL, assim como facilita criar a obrigatoriedade de qualquer
coluna, criando uma regra/constraint de NOT NULL.

Mas sinceramente, ter que adicionar uma cláusula de NOT NULL, ou removê-la,
depois que a tabela já está criada, com todo respeito, é um sinal claro que
a base de dados não foi bem planejada como deveria.

Deixando isso pra lá, o que mais me chamou a atenção, foi o tempo que o FB
3.0 levou para executar todo o script de criação da base de dados, com
direito a todos os INSERTs dos dados, para deixá-la exatamente como estava
antes dessa migração.

Eu não acreditei no que vi, levou muito mais tempo que o FB 2.5.

Eu fiz questão de repetir o processo para ver se eu estava errando em algum
ponto, mas realmente levou muito mais tempo para executar todo o script.

Eu executei tudo em um notebook da Dell com 8Gib de RAM, 8 núcleos e
rodando o Ubuntu Linux 18.04 de 64 bits, e executei o mesmo processo usando
o FB 2.5 dentro de uma máquina virtual na BudgetVM.com, com 2Gib de RAM, 2
núcleos e rodando o Ubuntu Linux 16.04 de 64 bits.

Para a minha surpresa, o FB 2.5 executou o mesmo script bem mais rápido que
o 3.0, mesmo estando em um ambiente, teoricamente, bem inferior ao ambiente
local em que eu estava.

Mestre Cantu, por favor corrija-me se eu estiver falando besteira, mas que
eu saiba, até o FB 2.5, ele era feito em C puro, sem orientação a objetos,
e o FB 3.0 foi reescrito em C++, e como é C++, tem suporte a orientação a
objetos, inclusive contando com um objeto específico para funcionar como
string (a classe std::string).

Como eu programo também nessas linguagens, eu sei que a implementação
interna das classes em C++ não é das melhores, e como consequência,
infelizmente, você obtém aplicações com uma performance inferior às mesmas
aplicações escritas puramente em C, e ao invés de usar objetos, usando a
forma anterior, que são apenas estruturas (struct) e ponteiros para essas
estruturas.

Por um lado, programar usando a orientação a objetos do C++ é muito mais
conveniente para os desenvolvedores, pois você pode usar todos os
benefícios da orientação a objetos, facilitando bastante o desenvolvimento.

É bem melhor que fazer tudo, quase que com duas pedras para fazer fogo,
como é no caso do C puro.

Mas tecnicamente falando, a qualidade do produto final, ou seja, da
aplicação é muito melhor com C que com C++, puramente por questões de
performance.

Não quer dizer que, em um futuro próximo, a equipe de desenvolvimento do
C++ não consiga otimizar a implementação de classes de forma a eliminar
esse incômodo.

Também não posso afirmar que é isso, ou apenas isso, que tenha causado a
queda de performance que eu vi na prática, e que me assustou bastante.

Como o meu perfil é muito mais "por questões técnicas", eu preferi
continuar no bom e velho FB 2.5 que ainda bate um bolão.

No dia em que as novas versões do FB realmente me mostrarem uma performance
melhor que a do 2.5, eu migrarei minhas bases de dados para a versão mais
nova, com toda a certeza.

Mas até lá, com certeza ficarei no FB 2.5, pois o que interessa no fim das
contas, é a performance.

Cliente nenhum se interessa pela forma que você implementou a solução, e
quão sofisticada e bonita é ela por dentro.

Todo o que interessa a ele é que funcione e o mais rápido possível.

Desculpem-me pelo desabafo, mas realmente estou muito preocupado como o
rumo que o FB está tomando.

Em qui., 9 de abr. de 2020 às 12:02, Guto Gleberty <gutogleberty em gmail.com>
escreveu:

> Bom dia, não consigo verificar/reparar erros no banco de dados 3.0 com os
> comandos abaixo:
>
> gfix -v -f G2FARMA.FDB -user SYSDBA -pass masterkey
> gfix -m -i G2FARMA.FDB -user SYSDBA -pass masterkey
>
> o banco foi criado no firebird 2.5 e feito a migração para o firebird 3.0
> através de um backup/restauração
> ______________________________________________
> 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
>