Coletor de lixo do Firebird 2.0

O mecanismo conhece cada versão de registro produzida por instruções update/delete e pode removê-las assim que a transação de snapshot mais antiga (OST) permitir. Isso elimina a necessidade de ler novamente essas páginas com essas versões por solicitação do usuário (ou seja, SELECT COUNT(*) FROM table) e evita situações em que essas versões nunca são lidas (é claro, o sweep sempre removeu todas as versões de registro não utilizadas). Além disso, há uma alta probabilidade de que as páginas necessárias ainda estejam no cache de buffer, portanto, há menos E/S de disco adicional necessária.

Entre a notificação ao coletor de lixo sobre uma página com versões não utilizadas e o momento em que o coletor de lixo lerá essa página, uma nova transação pode atualizar o registro e o coletor de lixo não poderá limpar esse registro se o número dessa nova transação estiver acima do OST ou ainda estiver ativa. Nesse caso, o mecanismo notifica novamente o coletor de lixo com esse número de página e ele limpará o lixo em algum momento posterior (o coletor de lixo antigo “esquecerá” essa página até que o usuário a leia novamente).

Tanto a coleta de lixo cooperativa quanto a em segundo plano agora são possíveis. Para gerenciá-la, foi introduzido o novo parâmetro de configuração “GCPolicy”. Ele pode ser definido como:

• a) cooperative - a coleta de lixo é realizada apenas no modo cooperativo, como antes do IB6. Cada solicitação do usuário é responsável por remover versões de registro não utilizadas. É assim que o mecanismo funcionava antes do IB6. Esta é a única opção para o modo Classic Server. O mecanismo não rastreia versões produzidas como resultado de instruções update e delete

• b) background - a coleta de lixo é realizada apenas pela thread em segundo plano, como no IB6 e versões posteriores. Nenhuma solicitação do usuário remove versões de registro não utilizadas. Em vez disso, a solicitação do usuário notifica a thread dedicada do coletor de lixo com o número da página onde uma versão de registro não utilizada foi detectada. O mecanismo também lembra os números de página onde a instrução update/delete criou backversions.

• c) combined - tanto a coleta de lixo em segundo plano quanto a cooperativa são realizadas.

O padrão é “combined” para SuperServer. O ClassicServer ignora esse parâmetro e sempre funciona no modo “cooperative”.