cesardbaLeave a Comment on Connectivity Testing for Oracle RAC SCAN.

Connectivity Testing for Oracle RAC SCAN.

Introdução

A intermitência em conexões com Oracle RAC utilizando o SCAN (Single Client Access Name) é um dos problemas mais comuns enfrentados por DBAs. Erros como ORA-12170: TNS: Connection timeout occurred e ORA-12560 nem sempre indicam indisponibilidade ou erros do database, mas podem estar relacionados a falhas de rede, DNS, firewall ou comunicação entre os nós do cluster.

Neste post, compartilho uma investigação realizada em um ambiente Oracle Exadata, apresentando os testes e validações que permitiram identificar a causa raiz do problema e restabelecer a estabilidade das conexões.

Os erros ocorriam ao tentar estabelecer a conexão utilizando o nome da SCAN. Em alguns momentos a conexão era realizada com sucesso, enquanto em outros eram apresentados erros de conectividade.

Testes que retornaram o ORA-12170 ao tentar conectar via SQLPLUS:

SQL*Plus: Release 19.0.0.0.0 - Production on Fri Jul 31 10:26:19 2026
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle. All rights reserved.

ERROR:
ORA-12170: TNS:Connection timeout occurred


Enter the username:
ERROR:
ORA-12560: TNS:protocol adapter error


Enter the username:
ERROR:
ORA-12560: TNS:protocol adapter error

Como primeiro passo, realizei consultas ao DNS para validar se os três endereços IP associados ao SCAN estavam sendo resolvidos corretamente. A verificação confirmou que todos os IPs estavam corretos e sendo retornados conforme esperado, descartando qualquer problema relacionado à resolução de nomes no DNS.

nslookup vm01-scan1
Servidor: srv01-vip.lab
Address:  192.168.0.10

Nome:    vm01-scan1
Addresses:  192.168.0.4
            192.168.0.5
            192.168.0.6

Verifiquei o status da SCAN e VIP no exadata, não encontrei nenhum problema:

[grid@exa01 ~]$ srvctl status scan_listener
SCAN Listener LISTENER_SCAN1 is enabled
SCAN listener LISTENER_SCAN1 is running on node exa01
SCAN Listener LISTENER_SCAN2 is enabled
SCAN listener LISTENER_SCAN2 is running on node exa02
SCAN Listener LISTENER_SCAN3 is enabled
SCAN listener LISTENER_SCAN3 is running on node exa02


[grid@exa01 ~]$ srvctl config scan
SCAN name: vm01-scan1, Network: 1
Subnet IPv4: 192.168.0.0/255.255.255.0/bondeth0, static
Subnet IPv6:
SCAN 1 IPv4 VIP: 192.168.0.4
SCAN VIP is enabled.
SCAN 2 IPv4 VIP: 192.168.0.5
SCAN VIP is enabled.
SCAN 3 IPv4 VIP: 192.168.0.6
SCAN VIP is enabled.


[grid@exa01 ~]$ srvctl config nodeapps -a
Network 1 exists
Subnet IPv4: 192.168.0.0/255.255.255.0/bondeth0, static
Subnet IPv6:
Ping Targets: 192.168.0.1
Network is enabled
Network is individually enabled on nodes:
Network is individually disabled on nodes:
VIP exists: network number 1, hosting node exa01
VIP Name: srv01-vip.lab
VIP IPv4 Address: 192.168.0.10
VIP IPv6 Address:
VIP is enabled.
VIP is individually enabled on nodes:
VIP is individually disabled on nodes:
VIP exists: network number 1, hosting node exa02
VIP Name: srv02-vip.lab
VIP IPv4 Address: 192.168.0.11
VIP IPv6 Address:
VIP is enabled.
VIP is individually enabled on nodes:
VIP is individually disabled on nodes:
[grid@exa01 ~]$

Em seguida, criei um loop executando 50.000 testes de TNSPING contra o endereço SCAN, com o objetivo de reproduzir e identificar a intermitência reportada pelos usuários. Durante toda a execução dos testes, não foram observados erros ou falhas de conectividade, indicando que a resolução e o acesso ao SCAN estavam funcionando normalmente naquele momento.


# tnsping SCAN NAME
tnsping vm01-scan1 50000



TNS Ping Utility for 64-bit Windows: Version 19.0.0.0.0 - Production on Fri Jul 31 10:26:19 2026

Copyright (c) 1997, 2019, Oracle. All rights reserved.

Parameter files used:
C:\app\client\product\19.0.0\client_1\network\admin\sqlnet.ora

Used EZCONNECT adapter to resolve nickname
Attempting to contact (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=vm01-scan1) (PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=HML)))
OK (140ms)
OK (160ms)
OK (150ms)
OK (150ms)
OK (150ms)
OK (160ms)
OK (140ms)
OK (140ms)
OK (140ms)
OK (160ms)
OK (120ms)
OK (140ms)
OK (160ms)
OK (120ms)
OK (140ms)
OK (130ms)
OK (120ms)
OK (140ms)
OK (130ms)
OK (120ms)
OK (130ms)
OK (140ms)
OK (120ms)
OK (150ms)
OK (150ms)
OK (160ms)
OK (140ms)
OK (140ms)
OK (120ms)
OK (160ms)
OK (130ms)
OK (150ms)
OK (130ms)
OK (140ms)
OK (150ms)
OK (130ms)
OK (140ms)
OK (160ms)
OK (120ms)
OK (140ms)
OK (140ms)
OK (130ms)
OK (150ms)
OK (140ms)
OK (160ms)
OK (160ms)
OK (150ms)
OK (130ms)
OK (120ms)
OK (130ms)
OK (150ms)
OK (130ms)
OK (120ms)
OK (160ms)

Na sequência, realizei o mesmo procedimento executando 50.000 testes de TNSPING individualmente em cada um dos três endereços IP associados ao SCAN, com o objetivo de isolar a origem da intermitência. Foi durante essa etapa que consegui identificar o problema, que ocorria exclusivamente em um dos IPs da SCAN, enquanto os demais respondiam normalmente durante toda a execução dos testes.

# IP 1 = 192.168.0.4
sqlplus sys/oracle12345678@"(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.0.4)(PORT=1521) ))(CONNECT_DATA=(SERVICE_NAME=HML)))" as sysdba

# IP 2 = 192.168.0.5
sqlplus sys/oracle12345678@"(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.0.5)(PORT=1521) ))(CONNECT_DATA=(SERVICE_NAME=HML)))" as sysdba

# IP 3 = 192.168.0.6
sqlplus sys/oracle12345678@"(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.0.6)(PORT=1521) ))(CONNECT_DATA=(SERVICE_NAME=HML)))" as sysdba
tnsping 192.168.0.4 50000
tnsping 192.168.0.5 50000
tnsping 192.168.0.6 50000

Durante a execução dos testes, foi identificado o seguinte erro de forma recorrente em um dos endereços IP da SCAN:ORA-12560: TNS:protocol adapter error

Esse comportamento não foi observado nos demais IPs associados ao SCAN, o que permitiu isolar o problema e direcionar a investigação para o endereço IP específico que apresentava falhas intermitentes de conectividade.

SQL*Plus: Release 19.0.0.0.0 - Production on Fri Jul 31 10:26:19 2026
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle. All rights reserved.

ERROR:
ORA-12170: TNS:Connection timeout occurred


Enter the username:
ERROR:
ORA-12560: TNS:protocol adapter error


Enter the username:
ERROR:
ORA-12560: TNS:protocol adapter error

Realizei os testes a partir de diversas estações de trabalho e o comportamento se manteve, com a ocorrência intermitente do erro. Para descartar a possibilidade de o problema estar relacionado à rede de origem, considerando que os ambientes são segmentados por questões de segurança, executei os mesmos testes a partir do Exadata de Produção, que se encontra no mesmo segmento de rede do Exadata de Homologação.

Nessa condição, não foram observados erros de conectividade. Para simular o acesso realizado pelos usuários, executei um loop com 50 conexões consecutivas ao database HML, realizando consultas (SELECT) por meio do endereço que apresentava falhas. Todos os testes foram concluídos com sucesso, sem a ocorrência do erro ORA-12560: TNS:protocol adapter error.

[oracle@exa01prd ~]$for i in {1..50} ; do sqlplus -L -s sys/oracle12345678@"(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=vm01-scan1) (PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=HML)))" as sysdba <<< 'select INSTANCE_NAME from GV$INSTANCE;'; done
INSTANCE_NAME
----------------
exahml1
exahml2


INSTANCE_NAME
----------------
exahml2
exahml1


INSTANCE_NAME
----------------
exahml1
exahml2


INSTANCE_NAME
----------------
exahml2
exahml1


INSTANCE_NAME
----------------
exahml1
exahml2


INSTANCE_NAME
----------------
exahml1
exahml2


INSTANCE_NAME
----------------
exahml1
exahml2


INSTANCE_NAME
----------------
exahml2
exahml1

Como pode ser observado, executei o loop três vezes, totalizando 150 conexões com consultas à view GV$INSTANCE. Em nenhum momento foi registrado o erro ORA-12560: TNS:protocol adapter error nas conexões realizadas a partir do Exadata de Produção para o Exadata de Homologação.

Diante desse resultado, passei a suspeitar de alguma restrição de conectividade em nível de rede ou firewall. Em conjunto com a equipe de Segurança, foi realizada uma análise das regras de acesso, que identificou que um dos endereços IP associados ao SCAN e ao respectivo VIP não estava devidamente liberado no firewall.

Como a SCAN distribui as conexões entre seus endereços IP, sempre que a resolução apontava para o IP que não possuia liberação, a conexão falhava e retornava o erro ORA-12560. Quando a conexão era direcionada para os demais IPs, que estavam corretamente liberados, o acesso ocorria normalmente.

Essa condição explica o comportamento intermitente reportado pelos usuários, uma vez que o sucesso ou falha da conexão dependia do endereço IP retornado pelo SCAN no momento da tentativa de acesso.

Em resumo as conexões da scan quando respondiam por um IP especifico, recebiam um drop pelo firewall, foi ajustado a regra, o acesso foi normalizado sem problemas.

Espero que esses testes possam te ajudar com os problemas de conexão em RAC.

Leave a Reply

Your email address will not be published. Required fields are marked *

search previous next tag category expand menu location phone mail time cart zoom edit close