Global Transaction Perdida - Informix

Global Transaction Perdida - Informix

  junho 25, 2014    Claudemar Martins de Sá

---

Este é um estudo de caso bem interessante depois de muito pesquisar (e ser ajudado pelo suporte) foi encontrado o que estava causando, era uma transação da Global Transaction entre a comunicação do SQL Server com o Informix que estava causando o lock em uma tabela importante do sistema, acredito que o SQL Server ocorreu um problema (um failover no banco, no DTC ou um outro problema) a solicitação se perdeu no SQL Server mais continuava ativa no Informix, sem esta resposta travou a tabela no Informix, primeiro pesquisando a tabela usando um select, realmente não consigo acessar;

echo "select count(*) from  nota_eletronica ; " | dbaccess nota_fiscal ;

Database selected.

      (count(*))

  252: Cannot get system information for table.

  113: ISAM error:  the file is locked.
Error in line 1
Near character position 31

Database closed.

Depois foi checado para ver quem estava predendo esta tabela - não tinha nenhuma tabela em lock - Checar tabela presa - Script para checar tabela presa

-------------------------------------------------------------------------------------------------
06/01/2014                      ***** INFORMIX BASIC SERVICES *****                      09:39:07
-------------------------------------------------------------------------------------------------

               +-----------------------------------------------------------------+
               |                                                                 |
               |                   NAO TEM TABELA PRESA NO BANCO                 |
               |                                                                 |
               +-----------------------------------------------------------------+

onstat -k

Como não encontramos quem estava prendendo pelos scripts a solução foi analisar o comando onstat -k, repare o 12f6bdaf0 com userthread=0 vamos focar nele nos próximos passos, os parêntesis que significa que esta perdida.

[c099:dba]$/export/home/informix> onstat -k | grep "("
48dcd028         1335a52a0        (12f6bdaf0)        0                HDR+X    600281   0           0      
48dcd0a8         133580238        (12f6bdaf0)        48dcd028         HDR+X    6001a3   0           0      
48dcd128         14ccfccf0        (12f6bdaf0)        48dcd0a8         HDR+X    60023b   0           0      
48dcd1a8         12f6a5128        (12f6bdaf0)        48dcd128         HDR+X    600110   0           0      
48dcd228         0                (12f6bdaf0)        48dcd1a8         HDR+IX   800021   0           0      
48dcd2a8         0                (12f6bdaf0)        48dcd228         HDR+X    800021   331ec11     0      
48dcd328         140625060        (12f6bdaf0)        48dcd2a8         HDR+IX   6002c0   0           0      
48dcd3a8         0                (12f6bdaf0)        48dcd328         HDR+X    6002c0   40803       0

onstat -all

Gerando um relatório geral para pesquisar tudo relacionado com 12f6bdaf0

onstat -all > onstat_g_all.log

Depois de um tempo analisando o onstat_g_all.log foi observado uma coisa interessante, tem uma Global Transaction (sem Subordinator/Coordinator) e uma Logical Log usando a 12f6bdaf0

[c099:dba]$/export/home/dba> cat onstat_g_all.log | grep "12f6bdaf0"
12f6bdaf0        -LX-G 0                8      logid 10891       10891:0x630e470   COMMIT  0:04     0      
48dcd028         1335a52a0        (12f6bdaf0)        0                HDR+X    600281   0           0      
48dcd0a8         133580238        (12f6bdaf0)        48dcd028         HDR+X    6001a3   0           0      
48dcd128         14ccfccf0        (12f6bdaf0)        48dcd0a8         HDR+X    60023b   0           0      
48dcd1a8         12f6a5128        (12f6bdaf0)        48dcd128         HDR+X    600110   0           0      
48dcd228         0                (12f6bdaf0)        48dcd1a8         HDR+IX   800021   0           0      
48dcd2a8         0                (12f6bdaf0)        48dcd228         HDR+X    800021   331ec11     0      
48dcd328         140625060        (12f6bdaf0)        48dcd2a8         HDR+IX   6002c0   0           0      
48dcd3a8         0                (12f6bdaf0)        48dcd328         HDR+X    6002c0   40803       0      
12f6bdaf0         -LX-G  COMMIT  0        4478019    16   48   52B64B6269E60F449D158D6B714313D280D5FF84A271

Checando a Transação Distribuída

O flags L indica uma Loosely Coupled TX:

[c099:informix]$/export/home/informix> onstat -G

IBM Informix Dynamic Server Version 11.10.FC1 -- On-Line -- Up 00:42:24 -- 8760064 Kbytes

Global Transaction Identifiers
address           flags  isol    timeout  fID        gtl  bql  data
12f6bdaf0         -LX-G  COMMIT  0        4478019    16   48   52B64B6269E60F449D158D6B714313D280D5FF84A271
1 active, 512 total

[c099:informix]$/export/home/informix>

Situação

Algumas observações nesta situação; Tirar e voltar o banco do ar não resolve pois a transação esta parada na logical log número 10891, apenas cancelando a GTX (Global Transaction) resolve o lock dessa tabela, para fazer isso temos dois comandos disponíveis;

onmode -Z 0x12f6bdaf0
ou
onmode -H 0x12f6bdaf0

Ambos só funcionam em transações perdidas em rollback. Como não estamos em rollback, pode não funcionar. Se não funcionar só um suporte Informix conseguira matar esta transação.

Matando a Global Transaction

Tentando matar usando o (onmode -Z) não deu certo;

[c099:informix]$/export/home/informix> onmode -Z 0x12f6bdaf0
onmode: Cannot kill transaction 0x12f6bdaf0.
Only I-STAR subordinates that are PREPARE'd or HEURISTICally ABORT'd
may be heuristically completed.

Tentando matar usando o (onmode -H) também não deu certo

[c099:dba]$/export/home/dba> onmode -H 0x12f6bdaf0
onmode -H may only be used to kill heuristically completed transactions.

O suporte teve que assumir e matar esta transação presa, pelo que reparei eles recompilaram um script que mata esta Global Transaction que esta presa, depois de matar resolveu tudo;