Resolvendo “enq: TX – allocate ITL entry” com uma abordagem alternativa – Fabio Brandão

Um dos problemas vistos num banco Oracle com muitos DML’s concorrentes é o evento de espera “enq: TX – allocate ITL entry”. O problema com esse evento é que as sessões fazendo os comandos de alteração nos registros demoram para executar, causando mais espera na aplicação.

Existem alguns jeitos de resolver esse evento de espera, entre eles:

Aumentar os parâmetros INITRANS e MAXTRANS da tabela / índice afetado
Mover a tabela para um tablespace com blocksize menor
Fazer um reorg da tabela
Reduzir a concorrência de DML’s na tabela

Sobre essas alternativas: Alterar o INITRANS e MAXTRANS das tabelas e índices é fácil, o problema é que os valores só são utilizados para os novos blocos criados. Além disso, valores maiores que 100 não diminuem essa contenção (conforme uma das referências).

Mover a tabela para um tablespace com blocksize menor pode ser feito de maneira online mas existem algumas condições nas quais o online não funciona. Além disso, em tabelas muito grandes e com alta taxa de DML’s, a aplicação acaba sentindo uma queda grande de performance nos DML’s durante essa movimentação.

Reduzir a concorrência dos DML’s parece ser uma solução boa, mas necessita a troca da lógica da aplicação, que nem sempre é viável / rápida de ser feita pois envolve a alteração para insert’s / update’s em batch.

Como funciona o ITL

O ITL (interested transaction list) é uma lista de transações que estão alterando os registros que estão localizados dentro de um bloco. Essa lista fica no cabeçalho do bloco e pode crescer conforme os parâmetros INITRANS, MAXTRANS e PCTFREE.

Sempre que uma transação quer alterar um registro em um bloco, ela deve se registrar no ITL. Se não existe um slot livre, o banco vai tentar criar um slot novo com base nos parâmetros informados acima. Caso o banco não possa criar mais slots, a transação vai esperar até um dos slots ser desocupado.

Aqui chegamos em um ponto interessante, as abordagens mencionadas acima para resolver esse problema envolvem:

Aumentar a quantidade de slots
Diminuir o número de transações concorrentes no mesmo bloco

Observando o que é o ITL, ele nada mais é do que uma fila. E existem dois jeitos de aumentar a vazão de uma fila:

Aumentar o número de consumidores
Diminuir o tempo de processamento de cada item da fila

O item 1 é coberto pelas abordagens mencionadas, mas em nenhum momento falamos sobre o item 2. A transação entra no ITL quando é enviado ao banco um DML e a transação só sai do ITL quando a mesma efetua o commit / rollback da transação. A abordagem que podemos seguir é diminuir o tempo entre o DML e o commit / rollback.

Uma pergunta que sempre surge é: por que a aplicação manda um DML e demora para efetuar o commit / rollback? Isto deve ser analisado à nível da aplicação, mas vamos citar aqui alguns exemplos do porquê isso acontece se você está utilizando o Hibernate / JPA.

Hibernate / JPA + Flush

Um dos erros que acontecem é criar ou alterar uma entidade e logo em seguida chamar o flush do JPA / Hibernate. Vamos ver o seguinte exemplo:

@Transactional
public void flush() {
	logger.info("Entering flush method");
	Test1Entity e = new Test1Entity();
	logger.info("Entity created");
	entityManager.persist(e);
	logger.info("Entity persisted");
	entityManager.flush();
	logger.info("Entity Manager flushed");
	// Some slow processing
	slowMethod();
	logger.info("Exiting flush method");
}