[firebase-br] LEIAM DO INTERESSE DE TODOS DA LISTA

fortes.m em anubisystems.com fortes.m em anubisystems.com
Sáb Dez 15 13:13:46 -03 2007


Olá a todos da lista Firebase, saudações.

Como a maioria da lista já sabe ou deveria saber eu sou o Marcelo Fortes
da Anubis Systems.
E freqüento esta lista de discussão já há tempos além de outras listas
de discussão relacionadas a Firebird e InterBase.
Entusiasta que sou destes bancos antes mesmo da liberação do código
fonte da versão beta do  InterBase 6 em meados do ano de 2000, ou seja,
antes mesmo do Firebird existir como um “fork” do projeto liberado pela
Borland no SourceForge.

O propósito deste post é reunir o máximo possível de informações
pertinentes a bugs, “regressões1”, a série 2.0.3 do Firebird. 

Motivo principal: 
Desde o lançamento do Firebird 2.0 em meu caso particular, percebi que uma
série de Consultas e Stored Procedures que na série 1.5.x tinham
desempenhos soberbamente velozes, apresentavam queda de desempenho numa
escala que variáva de notória ou perceptível. Até mesmo ao nível de
inadmissíveis, observando o “PLAN” gerado pelo Firebird 2.0. Observei
que ele criava “PLANs” diferentes da série 1.5.x. O que eme levou a
concluir que  o trabalho do optimizador e gerador de PLANs do Firebird nem
sempre fazia o “PLAN” das querys fossem os mais otimizadas.

Observei com o tempo que, para a série 2.0, algumas querys deveriam ter
que ser refeitas invariavelmente, devido a basicamente 3 items, a citar:

- Continuidade de tratamento de prevenção do DBA/Desenvolvedor criar
Querys ambíguas. 
- A necessidade de construir as querys utilizando-se corretamente os
índices
- A questão de “Garbage collection” feita em “backgraoud” 
(Que eu ainda não tive tempo suficiente para pesquisar a respeito, mas
que, salvo engano, na versão 2.0.3 é possível desabilitar esta coleta de
lixo em segundo plano que degrada a desempenho, se alguém tiver, mas
detalhes, por favor, corrijam-me se cometi alguma falha aqui neste item).

Salvo estes três items ainda assim percebi perca de desempenho notória em
querys que funcionavam perfeitamente e com bom desempenho na série 1.5.x.
Quanto aos dois primeiros itens, todos nós estamos passíveis de erros
humanos e também de alguma ferramenta tipo “Query Builder” fazer uma
consulta mais complexa ainda que funcione  perfeitamente, tornar-se lenta. 

Chegaram até a me sugerir “forçar” o PLAN gerado pelo FB 2 pelo PLAN
antigo do 1.5.x Mas para mim isso é inadmissível, é  tapar o sol com a
peneira e fazer um “jeitinho” paliativo para sanar uma necessidade
urgente mas que por final, leva a  encobrir um a falha do Firebird ou uma
regressão.

Concluo que o novo PARSER e PLAN OPTMIZER têm haver diretamente com isso.

Ainda assim existe o problema nas sentenças onde existe o IN ou NOT
tentando contorna-lo passando a usar a cláusula “Exists”
Não tenho testado a última versão 2.0.3 do Firebird para checar se estas
questões de desempenho mudaram desde o Firebird 2.0 devido a inúmeros
motivos que estenderiam demais este post.

Então eu por estes motivos supracitados convoco a todos desta lista de
discussão que queiram conjuntamente comigo compartilhar suas experiências
com esta série do Firebird para tornarmos o produto o mais estável
possível e com melhor desempenho entrem em contato em PVT através do
email:

contacts em anubisystems.com

Serão válidos somente casos usando as versões 2.0.3 e 2.1 do Firebird.
De preferência comparando-se com a versão 1.5.x (versões estáveis da
série 1.5.x)
 
Preciso de uma boa descrição formal do problema assim como o banco de
dados, com a respectiva trigger ou Stored procedure ou query que tenha se
tornada lenta. Bem como a senha e nome do SYSDBA.

Outros bugs podem ser remetidos também desde que sejam detalhados e em que
condições ocorrem. 

É vital que seja descrito qual ferramenta de desenvolvimento, linguagem,
IDE e que versão fora utilizada e principalmente o meio de conexão dbx,
ibx, Fib+, IBO, UIB, Zeos, Jaybird etc...
É IMPRESCINDÍVEL que sejam relatados a arquitetura se Classic Ou
SuperServer (Embended está fora do escopo deste esforço, desculpe-me, por
favor). Bem como o sistema operacional onde o banco executa se for
GNU/Linux é obrigatório o nome da distribuição (Debian, SuSE, Mandriva,
RedHat etc.) e sua respectiva versão, além de NPTL ou não

No caso de me mandarem o algum banco este deve estar no formato de BACKUP
TRANSPORTÁVEL!

Estou em contato direto com o time de desenvolvimento do Firebird e posso
reportar os problemas por aqueles que não tenham familiaridade com o
Firebird-bugtracker ou domínio da língua inglesa para reportar o bug ou
eventual problema.

Se forem somente Scripts de Querys ou SPs, antes de mandarem qualquer
material anexo, por favor, cheque se sua Query, Trigger, Stored Procedure,
está bem escrita, se o uso dos índices está sendo feito corretamente, se
sua transação não está aberta por tempo demasiado sem que tenha sido
executado um Commit ou Rollback.

E acima de tudo em um modo que eu possa reproduzir aqui, ou seja, mandando
um esqueleto de um banco incluído DDL-SQL para que eu no mínimo possa
emular seu ambiente aqui.

Esse post tem por objetivo exclusivo termos um produto confiável, estável
e com qualidade de desempenho outrora obtidos na série 1.5.x espero ajudar
assim a todos da lista, a todos que usam este banco e querem ver ele
melhor.
Obrigado.

Atenciosamente 
Marcelo Fortes.


Notas:
1 Entende-se por regressão ou “regression” no campo das ciências da
computação, a situação em que da liberação de uma nova versão uma
funcionalidade que numa versão anterior executava corretamente, na nova
versão esta funcionalidade não executa ou executa inapropriadamente,
também pode-se entender por regressão um “bug” corrigido no passado
que em uma nova versão torna a aparecer novamente.







Mais detalhes sobre a lista de discussão lista