"Inativo na transação" significa que uma transação foi iniciada em uma conexão de banco de dados e não foi concluída e não há mais nenhuma consulta em execução.
Na lista de processos do servidor de banco de dados (por exemplo: ps -ef | grep "idle in"
), você encontrará a conexão que está nesse estado. Vai mostrar algo como:
postgres 15268 12917 0 22:36 ? 00:00:03 postgres: user user x.x.x.x(59830) idle in transaction
O (59830)
é a porta na máquina x.x.x.x
.
Na máquina x.x.x.x
, você pode executar o seguinte para descobrir qual processo estabeleceu essa conexão com o banco de dados:
netstat -np | grep 59830
Isso lhe dará algo como:
tcp6 0 0 x.x.x.x:59830 dbserver:5432 ESTABLISHED 25254/java
(ou Apache, ou qualquer que seja o processo). Neste exemplo, 25254
é o PID do processo.
Para que responda à sua pergunta no corpo da sua postagem.
Para lidar, claro, é um assunto mais complicado. Por que esta conexão inicia uma transação e não a completa = codificação incorreta. Resolução: codifique corretamente.
Nota:
O PDI da Pentaho tem o péssimo hábito de também deixar as transações ociosas por um longo tempo. Digamos que você tenha uma etapa no PDI que atualize algumas linhas. Vai:
input step --> filter step --> update step
E digamos que você defina o lote de confirmação como 100 no update step
. Você disse, 75 linhas na etapa de atualização e as linhas input step
ainda estão sendo inseridas e as linhas filter step
de filtragem, mas devido à condição, nada é transferido para update step
por pouco tempo porque nenhuma linha corresponde seus critérios no filter step
. Então o que você tem? Uma conexão de banco de dados que é idle in transaction
(75 linhas atualizadas, mas não confirmadas).
Então está tudo bem, exceto que é chato para o DBA que é alertado sobre essa longa transação.
Mas agora, digamos que você tenha outra etapa que ramifica o filter step
e atualiza a mesma tabela, mas de forma diferente e que, de alguma forma, um registro faz parte das 75 linhas atualizadas (mas não confirmadas) e update step 2
precisa atualizar essa linha. O que acontece? Uma tenda. update step 2
não pode atualizar a linha até update step
confirmar o lote.
Não está dizendo que é o que você está enfrentando, já que parece ter descoberto, mas não confirmado, que sua transação de bloqueio está sendo executada com o Apache, não com o PDI. Mas a descrição acima é uma descrição de um problema que pode ocorrer para ilustrar o que geralmente está acontecendo.