Ao iniciar o debug de uma rotina no PL/SQL Developer e ver a janela travada com o status Executing…, sem nunca habilitar os botões de controle do debug, já dá para sentir que tem algo esquisito. Mas se ao consultar a GV$SESSION você encontra o evento de espera pipe get, o problema está na forma como as sessões foram abertas.

Esse comportamento acontece quando o banco está em um ambiente Oracle RAC e as sessões da compilação do objeto e da execução do debug são abertas separadamente, cada uma podendo cair em um node diferente do cluster.

Por que isso acontece?

O debug no Oracle depende da comunicação entre duas sessões, a que compila a procedure antes de iniciar o debug e a que executa o código usando a opção Test, onde o debug de fato começa.

Cada uma dessas ações abre uma nova sessão no banco. Em ambientes Oracle RAC (com múltiplos nodes), essas sessões podem cair em nodes diferentes. Como o mecanismo de debug usa pipes internos para se comunicar, quando as sessões estão em nodes distintos, essa troca simplesmente não acontece.

O resultado: a sessão fica aguardando indefinidamente no evento pipe get.

Como Resolver

Alterar a string de conexão no PL/SQL Developer para apontar diretamente para o VIP ou IP público do node desejado

Se você é desenvolvedor e não tem acesso direto ou facilidade para identificar essas informações, fale com o DBA.
Explique o cenário do debug travando no pipe get e peça os dados de conexão que forcem a entrada por um único node. Isso pode ser feito via IP VIP, IP público ou, dependendo da configuração, até por um service name específico que esteja amarrado a um único node.

Alterando a entrada no TNSNAMES.ORA

Para que o PL/SQL Developer se conecte sempre ao mesmo node do cluster durante o debug, é necessário ajustar a entrada usada no tnsnames.ora. Esse arquivo normalmente fica em:

C:\Oracle\product\<versão>\network\admin\tnsnames.ora

C:\Oracle\product\<versão>\network\admin\tnsnames.ora

Identifique qual entrada o PL/SQL Developer está usando e substitua (ou crie uma nova) apontando diretamente para o VIP, IP público ou serviço fixo em um único node.

Antes (com SCAN)

PROD_SCAN =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = scan.prod.corp.local)(PORT = 1521))
    (CONNECT_DATA =
      (SERVICE_NAME = prodservicelb.corp.local)
    )
  )

PROD_SCAN =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = scan.prod.corp.local)(PORT = 1521))
    (CONNECT_DATA =
      (SERVICE_NAME = prodservicelb.corp.local)
    )
  )

Depois (com VIP fixo em um node):

PROD_NODE1 =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 10.10.10.101)(PORT = 1521)) 
    (CONNECT_DATA =
      (SERVICE_NAME = prodservicelb.corp.local)
    )
  )

PROD_NODE1 =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 10.10.10.101)(PORT = 1521)) 
    (CONNECT_DATA =
      (SERVICE_NAME = prodservicelb.corp.local)
    )
  )

Após salvar o arquivo, reabra o PL/SQL Developer e selecione a nova entrada (ex: PROD_NODE1) ao se conectar. Isso garante que as sessões de compilação e execução fiquem no mesmo node, evitando o travamento no evento pipe get.

Conclusão

Essa configuração resolve o problema do debug travando no pipe get. Não estou dizendo que você deve ou não usar o SCAN isso é uma decisão da sua empresa, alinhada com arquitetura, segurança e disponibilidade. Não tenho nada a ver com isso.

O ponto aqui é simples: essa solução faz o debug funcionar no PL/SQL Developer. E é isso que importa se você está tentando depurar seu código e travou sem explicação.

Se quiser usar SCAN depois, ótimo. Mas na hora do debug, conecte direto e siga em frente.

e zas

#20250819 #DBASobrinho #GuinaNãoTinhaDó #BóBó #CaceteDeAgulha #OracleACE #SimbaSafari #DedoMole #DRQuebro