Blz ?? Fico contente de poder ter ajudado - na verdade, esse comportamento de demora do Listener receber da camada de rede (do ONS mais especificamente) a info que não há outros nós causar timeouts e crashes eu já tinha visto outras vezes no passado : por exemplo, bem no começo do 10g tinhamos num cliente uma situação que essa msg WARNING: Subscription for node down event still pending. se repetia tanto que acabava deixando o listener.log tão grande que causava lentidão geral na conexão, então desde essa época tive por norma sempre necessariamente desativar em toda e qualquer instalação single....
Essa recomendação geral da Oracle tá registrada entre outras na nota metalink "Lsnrctl Stop Command Hangs in non-RAC or Standalone Installation" (Doc ID 2169232.1) onde a Oracle indica : "ONS notification should be turned OFF in standalone installations. This subscription is strictly for RAC." è claro, nessa nota em especial o crash acontecia quando tentava dar um lsnrctl stop, mas podem haver casos onde um simples lsnrctl status, ou mesmo uma tentativa de conexão levava ao crash, ou se não crashava ficava queimando uma CPU lascada... è evitar, simplesmente... Igualmente, eu tenho como prática default pra ambientes produtivos e/ou exigentes rigorosamente ** NUNCA ** deixar um setting que eu sei que não será usado : o exemplo típico é vc pegar SQLNET.ORA especificando um DOMAIN quando vc Sabe que não será usado, ou especificando DIRECTORY_PATH diferente de TNSNAMES.ORA quando vc sabe que é só ele que vai ser usado : parece ser bobo, mas já peguei no passado uns casos onde estava : NAMES.DIRECTORY_PATH= (LDAP, EZCONNECT, TNSNAMES, ONAMES, HOSTNAME) aí o ** tempo ** que a camada de rede levava pra pesquisar e descobrir que não havia LDAP levava a timeouts e probs de lentidão... De modo geral a recomendação quando se fala de rede é clara : ** TUDO ** que vc puder indicar pro Oracle como / onde está configurado, melhor... []s Chiappa
