Entendendo O 'lixo' No Bd

Entendendo o 'lixo' no BD

1 de 2

http://www.firebase.com.br/fb/artigo.php?id=2047

Usuários: 40549 Artigos: 167 Dicas: 111 Downloads: 264 15.05.09

Entendendo o 'lixo' no BD Não é raro encontrar pessoas que não dão a devida importância a um controle transacional correto no banco de dados. Geralmente, são essas pessoas que costumam sofrer com problemas de performance, e que geralmente preferem culpar o SGBD ao invés de procurar o real motivo do problema. Quedas de performance abruptas, sem razão aparente, podem indicar que um sweep está sendo executado. Podemos dizer, de forma geral, que um sweep é uma limpeza de lixo (garbage collection) generalizada, executada no banco de dados. Mas o que é a garbage collection e porque existe “lixo”? A primeira coisa a saber é que o Firebird utiliza um sistema de controle de concorrência chamado MGA (Multi Generational Architecture). Isso significa que dentro de um banco de dados Firebird, podem existir diversas versões de um mesmo registro, cada uma delas apresentando informações válidas em um determinado momento no tempo. Com isso, é possível ter transações enxergando dados que já foram apagados por uma outra transação. Os dados apagados podem continuar existindo para algumas transações, dependendo do isolamento transacional que elas utilizam e do momento em que foram iniciadas. É por isso também que diferentes transações podem enxergar valores diferentes de um mesmo registro. Para que a MGA funcione, tudo que for feito no Firebird, até mesmo um simples select de leitura, deve estar associado a uma transação. Pode parecer confuso, mas tudo fica claro a partir do momento que você entende como os diferentes isolamentos transacionais influenciam a visão dos dados. O fato é que, para manter as diferentes visões de um mesmo registro, o Firebird mantém versões temporárias dos dados. A partir de um determinado momento, esses registros temporários não são mais necessários. Mas eles existem e ocupam espaço dentro do arquivo do banco de dados. Dependendo do número de acessos e operações concorrentes sendo realizadas no BD, a quantidade de “lixo” gerada pode fazer com que o arquivo do banco de dados cresça rapidamente. O processo de Garbage Collection existe justamente para identificar esses espaços que foram usados e que não são mais necessários, e marcá-los como reaproveitáveis. Sendo assim, da próxima vez que o Firebird precisar gravar alguma informação no banco, ele usará os espaços previamente alocados, ao invés de pedir que o sistema operacional aloque mais espaço, o que aumentaria o tamanho do arquivo e prejudicaria a performance (alocar espaço é sempre mais lento do que reutilizar um espaço já alocado). Registros apagados também são um exemplo de lixo ocupando espaço que pode ser reaproveitado. Dependendo da versão e da arquitetura do Firebird utilizada (CS x SS), a coleta de lixo pode se dar de duas formas: Cooperativa – Presente no servidor Classic. Nesse modelo, a transação que está lendo os registros é responsável por identificar a existência de lixo e fazer a limpeza. Isso significa que se você der um select em uma tabela, e ele encontrar muito lixo pelo caminho, a performance deste select será prejudicada, pois ao mesmo tempo em que está recuperando as informações, está também fazendo a limpeza. Faça um teste: pegue uma tabela que contenha alguns milhões de registros e apague todos eles (delete). Dê um commit, e depois rode um select * nessa mesma tabela. Você verá que o select vai demorar certo tempo para retornar “nada” (a tabela está vazia). Isso porque, encontrando as condições propícias, ele realizou a limpeza do lixo. Se rodar o select novamente, ele será rápido (pois o lixo já foi coletado). Background – Presente no servidor SuperServer. Nesse modelo, a transação que está lendo os registros, identifica a existência de lixo e notifica a thread de Garbage Collection para que ela realize a limpeza assim que possível. Combined – Esse modo foi introduzido no FB 2.0, e funciona apenas com o SuperServer. Como o próprio nome sugere, ele é um híbrido entre o modo Cooperativo e Background, e passou a ser o modo padrão de GC no SS. Através do firebird.conf, ainda é possível alterar para o modo Background ou Cooperative. Mas e o Sweep? Como dito anteriormente, o sweep pode ser considerado como uma faxina geral no banco. Além de fazer a GC, ele também atualiza a OIT (Oldest Interesting Transaction) sempre que possível. Por padrão, bancos Firebird são configurados para disparar um sweep automático quando a diferença entre a OAT (Oldest Active Transaction) e a OIT atinge 20.000. Acontece que se isso acontecer em um momento em que o servidor esteja com uma grande carga de processamento, com inúmeras requisições, os usuários vão sentir uma queda repentina de performance. Neste caso, é aconselhável desligar o sweep automático (através do gfix), e agendar um sweep manual para que seja executado em um horário onde o servidor não esteja com muita carga (por exemplo, de madrugada). A quantidade de lixo gerado em um banco de dados depende principalmente do controle transacional. Em ambientes de grande concorrência e com muitas alterações de dados, transações que ficam abertas por muito tempo podem gerar uma grande quantidade de lixo, prejudicando também a performance do servidor. É muito importante que todos os usuários do Firebird entendam como a MGA funciona, para que não sejam pegos de surpresa com problemas de performance “misteriosos”. Na FireBase, temos artigos que explicam isso. Para os que desejarem uma informação mais “hardcore” sobre performance, a FireBase lançou recentemente uma vídeo aula de 3h dada por Dmitry Yemanov (chefe da equipe de desenvolvimento do FB), intitulada “Firebird Performance in Detail”. Essa vídeo aula traz informações

15/05/2009 15:31

Entendendo o 'lixo' no BD

2 de 2

http://www.firebase.com.br/fb/artigo.php?id=2047

preciosas, e que não são encontradas facilmente por aí. Mais informações em http://videos.firebirddevelopersday.com.br. Os CDs/DVDs do Firebird Developers Day (disponíveis na loja on-line da FireBase) também contém palestras que tratam deste assunto. Conclusão: se você tomar os devidos cuidados com suas transações e com o sweep, dificilmente terá problemas de performance com o Firebird. Autor: Carlos H. Cantu Artigo originalmente publicado na revista ActiveDelphi.

Avalie esse artigo/dica:

Comentários Não há comentários para esse item... Atenção! Não poste dúvidas nos comentários. Para obter suporte, use a lista de discussão da FireBase.

Copyright (C) Carlos H. Cantu - É proibida a reprodução de qualquer material desse site sem autorização prévia

15/05/2009 15:31