Passo a Passo 

VERIFICAR QUEM ESTÁ BLOQUEANDO O SISTEMA

Um Banco de Dados Relacional provê dispositivos de segurança para evitar a sobreposição de alterações num mesmo registro.

Assim, se um usuário, num momento crítico da atualização de uma tabela, abandonar posto de trabalho com uma seção "aberta" é possível que "bloqueie" o acesso dos demais usuários a uma determinada tabela. Desta forma, as seções destes outros usuários ficarão "paradas", aguardando a liberação do primeiro.

Para verificar quais tabelas está bloqueado por quais usuários, o administrador do sistema deve entrar no "dbaccess" e executar os seguintes comandos SQL:

set isolation to dirty read;

select username, waiter, dbsname[1,10], tabname[1,10], type

from sysmaster:syslocks, sysmaster:syssessions where

sysmaster:syssessions.sid = sysmaster:syslocks.owner and dbsname="sisdia";

Será exibida uma lista de seções, conforme exemplo abaixo: 

Será exibida uma lista de seções, conforme exemplo abaixo:
Nesta lista temos:
username nome do usuário desta seção;
waiterse estiver em "branco" é um usuário que está bloqueado;
se tiver um valor é o usuário que está bloqueando a tabela e impedindo
outros acessos;
dbsname nome do banco (no caso, sempre "sisdia");
tabname tabela que está bloqueada;
type tipo de bloqueio : o usuário que está bloqueando a tabela tem tipo "U" e
contém um valor no campo "waiter".
No exemplo acima, a tabela (cofilial) está bloqueada pelo usuário "sisdia", enquanto que o usuário "informix" está aguardando a liberação da tabela.
Então, para resolver o "travamento" devo fazer com que o usuário "sisdia" complete sua transação, liberando assim o usuário "informix".
<span style="color: #ff0000"><strong>IMPORTANTE</strong></span>
Não "matar" a seção que está bloqueando, nem qualquer outra seção.
Toda vez que uma seção é "abortada" o banco de dados entra em "roll back" (desfazer a parte da transação que já havia sido feita). Cada "roll back" causa um impacto 6 a 7 vezes maior em termos de demora e performance do que a transação causaria.
Então, se "matarmos" diversas seções teremos diversos "roll back's" e isso terá um impacto em cascata sobre a performance e a demora em retornar ao normal.