Esta semana o time de desenvolvimento do Firebird liberou a versão 2.1.2. O foco deste sub-release é estabilidade. Não tem grandes novidades, que estão guardadas para a 2.5, mas merece destaque porque a lista de correções é impressionante.

Bugs

Entre as várias correções, algumas merecem destaque:

• Erro no processamento de nulos em Check Constraints.
• Falsa detecção de deadlocks sob carga.
• Possível erro ao atualizar o mesmo registro várias vezes.
• Lentidão das tabelas de monitoramento no ClassicServer sob carga.
• Estatísticas de Stored Procedures não estavam sendo contabilizadas nas tabelas de monitoramento.

Esta duas últimas afetam diretamente os usuários do Sinática Monitor. Por isto recomendo a atualização.

Melhorias

Além dos bugs, algumas melhorias foram incluídas.

• Restrição de usuário para o DPB. Se você conecta-se com um usuário não-sysdba e está usando algum parâmetro especial de conexão, verifique se ele não está na lista de parâmetros bloqueados. Também é possível que os componentes de conectividade estejam fazendo isto. Nestes casos a conexão será rejeitada pelo Firebird.
• Possibilidade de usar o Runtime MS C em diretório privado. Antigamente (2.0 e anteriores), bastava copiar a fbclient.dll para os clientes e pronto. A partir da 2.1 começou a ser necessária a instalação dos Runtimes. Isto levou a problemas com a distribuição de clientes que ficou mais complexa. No 2.1.2 volta a ser possível copiar apenas a fbclient.dll e os arquivos da runtime para o cliente.

Para saber mais, consulte o release notes.

Baixe o Firebird 2.1.2 agora!

Se você está curioso para saber o que é o Produto que eu estava cozinhando nos últimos meses, sua espera acabou.

Ele se chama Sinática Monitor for Firebird. E foi criado especialmente para monitorar seu banco de dados e descobrir aqueles problemas difíceis de encontrar.

E isto é apenas o começo.

Visite nosso site novo e veja telas do Sinática Monitor em ação.

O Sinática Monitor é inteiramente gratuito durante o período de Beta.

Baixe agora e descubra o que ele pode fazer pelo seu banco de dados.

E não seja tímido! Eu quero ouvir de você. Mande suas idéias e sugestões!

Um post do Jeff Atwood me chamou a atenção semana passada. Ele relata como teve dificuldades para encontrar um problema no StackOverflow beta. Eles encontravam logs de deadlocks durante o dia e no fim descobriram que o problema estava relacionado ao travamento de leitores feito pelo MS SQL Server (tradução livre):

Você pode anexar o profiler para pegar o evento de deadlock e ver qual o exato comando que o está causando. Eu fiz isso e achei sempre um mesmo comando SQL:

UPDATE [Posts]
SET [AnswerCount] = @p1, [LastActivityDate] = @p2, [LastActivityUserId] = @p3
WHERE [Id] = @p0

Se detectar um deadlock o SQL Server força um dos comandos envolvidos a dar erro – especificamente aquele que usa menos recursos. Os comandos envolvidos variavam, mas no nosso caso o comando que dava erro era sempre uma leitura inócua, assim:

SELECT *
FROM [Posts]
WHERE [ParentId] = @p0

Para resolver o problema foi preciso instruir o SQL Server a usar leituras sujas em cada uma das leituras onde havia perigo de travamento.

O que ficou me martelando a cabeça todos esses dias não é como pode um banco de dados moderno ainda ter travamento de leitores. E sim a lição que podemos tirar deste episódio. Independente do servidor e de suas limitações de arquitetura, o importante é você conhecê-lo bem e conhecer bem o ambiente da sua aplicação.

No caso do StackOverflow o Jeff descobriu que uma possível solução era a leitura suja. Se a sua aplicação tivesse transações longas as leituras sujas não seriam uma opção. Mas conhecendo bem sua aplicação ele sabia que não era esse o caso e que não teria maiores conseqüências se as usasse. Independente do que diriam os puristas de ACID. E confesso que eu mesmo torci o nariz assim que li “leitura suja”.

Graças a sua arquitetura multi-geração o Firebird não tem travamento de leitores. Então é natural que este problema pareça estranho para nós. Mas cada arquitetura tem seus prós e contras. Esta mesma arquitetura multi-geração se não for bem utilizada pode ser um problema. É o caso de transações que ficam abertas por muito tempo.

Tais transações levam a um acúmulo de versões de registros dentro do banco de dados. (Estas versões também podem ser chamadas de gerações. A arquitetura é multi-geração, lembra?) Quanto mais versões acumuladas, mais trabalho o Firebird tem que realizar para encontrar a versão correta de cada registro. Dado tempo suficiente o acúmulo de versões é tão grande que o servidor Firebird fica lento o suficiente para parecer travado. Esse tempo depende muito da carga do banco de dados e do hardware do servidor. Pode ser um mês, pode ser uma hora.

Eu vi isso acontecer em um bom número de ocasiões. Em algumas delas vi gerentes argumentarem durante horas que o MS SQL Server e o Oracle não têm esse problema. O fato é que eles têm outros detalhes de arquitetura que você deverá levar em conta na sua aplicação. Por exemplo, travamento de leitores. Simplesmente trocar de banco de dados, como alguns desses gerentes chegaram a sugerir, não é uma solução.

Se bem que o StackOverflow rodando em Firebird não seria má idéia. ;)

Se existisse uma estatística sobre bases de dados Firebird corrompidas, acredito que mais de 80% delas teriam algo em comum: estavam com o forced-writes desligado.

Aproveitando que a partir do Firebird 2.1 a opção de forced-writes funciona também em linux, montei um comparativo entre os dois modos.

O que é Forced-Writes e quando usar?

Espero que os DBAs que gostam de viver perigosamente achem útil.

Dois dias fantásticos falando sobre Firebird com pessoas ótimas. Foi assim meu primeiro Firebird Developers Day.

Chegando no teatro da Unimep

Aprendi algumas novidades e saí com uma ótima perspectiva sobre o futuro do projeto. Perspectiva que compartilho agora com você.

Firebird 3.0

Podemos esperar um híbrido baseado no ClassicServer mas com boas doses de código do SuperServer e do Vulcan. E isto é bom. Nada de mudanças bruscas que levariam decadas para estabilizar. A proposta da equipe Firebird, segundo Dmitry Yemanov, é evolucionária e não revolucionária.

Logo cedo já estava movimentado

O Dmitry Yemanov também foi bastante enfático quanto a compartilhar os caches de dados e metadados. Pelo jeito o cache dedicado do ClassicServer está mesmo com os dias contatos. Amén.

A instalação e configuração devem ficar mais fáceis, com apenas um executável para todas as arquiteturas.

Na MasterClass tive a oportunidade de expressar o quanto eu gosto das tabelas de monitoramento e como elas facilitam a vida de um administrador de bancos de dados. E a boa notícia é que parece que a equipe Firebird também está interessada em extendê-las.

Eu fui o último a sair! :)

Firebird 4?

Quando perguntei sobre um interpretador nativo de SQL o Dmitry Yemanov disse que é muito interessante para o Firebird e está nos planos, mas não existe agenda então ele não pode prometer nada.

O Firebird internamente traduz SQL para uma linguagem recursiva proprietária chamada BLR para então executar os comandos em BLR. Em teoria ter um interpretador SQL nativo traria um leve aumento de performance na preparação do comando. Mas mais importante, tornaria mais simples extender a sintaxe SQL do Firebird.

O mesmo vale para para a inclusão de histogramas de distribuição de valores em índices. Não há previsão.

Encontros

Outra parte fantástica do FDD foi encontrar e conhecer nossos colegas russos Dmitry Kuzmenko (IBSurgeon), Dmitry Yemanov (Firebird SQL) e Michael Phlippenko (Fast Report). E também alguns dos palestrantes como o Alexandre Benson Smith (Thor Software), o Professor Beto (Unimep) e o Luis Paulo (Chamando.com.br).

Nada disso seria possível, é claro, sem o pessoal da Firebase.com.br. Obrigadão a eles e em especial ao Carlos Cantu pela organização do evento.

Este terminal da Unimep fala por mim.

Até o ano que vem!

O recente lançamento da versão 2.1.1 do Firebird é muito bem-vindo.

Aqui algumas das correções que considero importantes para servidores 2.1 já em produção e por isto recomendo a atualização:

• Correções de estabilidade nas tabelas de monitoramento
• Correção da possibilidade de corrupção da base de dados de usuários, security2.fdb.
• Correção do nBackup, que não funcionava na versão 2.1.
• Correção de vazamento de memória em comandos DDL.

A lista completa de bugs corrigidos e downloads estão no site do Firebird SQL.

O Firebird 2.5 acabou de entrar em Alpha. Entre a lista de novidades está uma nova arquitetura de servidor.

Chamada de SuperClassic, ela será o alicerce para o suporte a multi-processadores que virá no Firebird 3.0.

Então não perca a conta. A partir do 2.5, você poderá escolher entre SuperServer, ClassicServer e SuperClassic.

Basicamente o SuperClassic é como ClassicServer. Só que ao invés de um processo para cada conexão, ele usa um único processo com um thread para cada conexão. A vantagem é que ele deve usar menos recursos do kernel e deve ser um pouco mais rápido.

Leia uma comparação mais profunda entre as três arquiteturas.