Artigo Clube Delphi Edição 42 - Transações no Firebird/InterBase

Transações no Firebird/InterBase

Conceitos, arquitetura e modos de isolamento

As transações em bancos de dados cliente/servidor são de extrema importância e seu uso representa uma das maiores evoluções quando se migra de um banco de dados desktop para um verdadeiro SGBD (Sistema Gerenciador de Banco de Dados). Em se tratando do Firebird/InterBase, as transações têm uma importância ainda maior, devido à arquitetura de versioning utilizada por esses servidores. Esta abordagem obriga que qualquer operação no banco de dados, mesmo um simples select, esteja dentro de uma transação.

Neste artigo serão mostrados conceitos de transações no Firebird/InterBase, detalhes da arquitetura de versioning, e as diferenças entre os vários tipos de isolamentos transacionais, além do relacionamento entre eles.

Arquitetura de versioning

Para entender o mecanismo de transações do FB/IB, é importante termos uma noção básica do que é versioning, o sistema gerenciador de concorrência utilizado no FB/IB, também chamado de Multi-Generational Architecture (MGA). No versioning, quando você altera alguma informação no banco de dados, versões temporárias dos registros alterados são criadas e permanecem “ativas” durante o tempo que for necessário, permitindo que o registro fique acessível – com seu conteúdo original – a outras transações, que enxergam sempre uma visão consistente dos dados.

As versões temporárias dos registros, obviamente, ocupam espaço no banco de dados. Quando os registros temporários não forem mais necessários, o processo de coleta de lixo (garbage collection) se encarrega de marcá-los como “lixo” para futuro reaproveitamento do espaço ocupado. Por essa razão, um banco de dados FB/IB nunca diminui de tamanho (a não ser quando um backup/restore é executado). Essa é uma medida de eficiência, pois a alocação de novo espaço em disco é muito mais onerosa do que o reaproveitamento de um espaço já alocado.

Devido à arquitetura de versioning, o FB/IB não precisa manter logs de transações como é feito em outros bancos relacionais (Oracle, SQL Server etc.). Esses logs são utilizados quando se deseja reverter o banco do seu estado atual para um anterior como, por exemplo, quando ocorre algum tipo de falha invalidando os dados atuais. Em uma situação desse tipo, o log é usado para desfazer as últimas operações, deixando o banco novamente em um estado consistente.

Como o versioning cria versões temporárias dos registros com que se está trabalhando, em uma situação de falha ou erro, o SGBD apenas marca o flag da transação como RolledBack, fazendo com que todos os registros associados a ela sejam descartados, deixando o banco de dados consistente em questão de segundos. Em outros servidores, dependendo do tamanho do log de transações, o processo pode levar muito mais tempo. Conseqüentemente, o BD ficará indisponível por um período maior.

Um efeito colateral gerado pelo versioning é que, como não existe um log de transações, não há possibilidade de realizar backups incrementais, pois não se sabe o que foi alterado desde o último backup. Já existem ferramentas de terceiros que implementam um log de alterações em bancos de dados " [...] continue lendo...