Antes do FixPak 4, o DB2 verificava a conclusão de archive apenas quando um novo arquivo de log era necessário. Agora, o DB2 verifica a conclusão de archive sempre que o primeiro log ativo é alterado. Conseqüentemente, as informações são registradas em disco com maior antecedência e mais freqüentemente.
O benefício dessa alteração é que, se o sistema travar, as informações armazenadas em disco (relacionadas a quais arquivos de log foram arquivados corretamente) são mais exatas e o DB2 não precisa emitir o pedido de archive novamente para arquivos de log que já estão arquivados.
Não há alterações no que o DB2 faz depois de detectar o archive correto de um arquivo de log específico.
O DB2 agora detecta a conclusão de archives de log com mais antecedência e os renomeia com mais antecedência. Arquivos de log inativos truncados são excluídos. Como conseqüência, o número de arquivos de log que permanecem no caminho de log ativo pode ser menor que o valor de configuração no banco de dados LOGPRIMARY. Nesse caso, o DB2 criará novos arquivos de log quando necessário.
Antes dessa alteração, a reinicialização do banco de dados reduzia o número de logs para corresponderem ao valor de LOGPRIMARY. Agora, quando o banco de dados é iniciado, primeiro o DB2 examina o diretório de log do banco de dados. Se o número de logs vazios for menor que o número de logs principais, o DB2 alocará novos logs para compensar a diferença. Se houver mais logs vazios disponíveis do que logs principais no diretório do banco de dados, o DB2 permitirá que o banco de dados seja reiniciado com todos os logs vazios disponíveis no diretório do banco de dados.
Depois do encerramento do banco de dados, todos os arquivos de log secundários existentes permanecerão no caminho do log ativo no momento da reinicialização. Para limpar o caminho do log ativo, pode-se utilizar o comando DB2 ARCHIVE LOG.