Ошибка ora 12170 tns connect timeout occurred

TROUBLESHOOTING STEPS (Doc ID 730066.1)

Connection Timeout errors ORA-3135 and ORA-3136
A connection timeout error can be issued when an attempt to connect to the database does not complete its connection and authentication phases within the time period allowed by the following:
SQLNET.INBOUND_CONNECT_TIMEOUT and/or INBOUND_CONNECT_TIMEOUT_ server-side parameters.

Starting with Oracle 10.2, the default for these parameters is 60 seconds where in previous releases it was 0, meaning no timeout.

On a timeout, the client program will receive the ORA-3135 (or possibly TNS-3135) error:

ORA-3135 connection lost contact

and the database will log the ORA-3136 error in its alert.log:

… Sat May 10 02:21:38 2008
WARNING: inbound connection timed out (ORA-3136) …

• Authentication SQL

When a database session is in the authentication phase, it will issue a sequence of SQL statements. The authentication is not complete until all these are parsed, executed, fetched completely. Some of the SQL statements in this list e.g. on 10.2 are:

select value$ from props$ where name = 'GLOBAL_DB_NAME'

select privilege#,level from sysauth$ connect by grantee#=prior privilege# 
and privilege#>0 start with grantee#=:1 and privilege#>0

select SYS_CONTEXT('USERENV', 'SERVER_HOST'), SYS_CONTEXT('USERENV', 'DB_UNIQUE_NAME'),
SYS_CONTEXT('USERENV', 'INSTANCE_NAME'), SYS_CONTEXT('USERENV', 'SERVICE_NAME'), 
INSTANCE_NUMBER, STARTUP_TIME, SYS_CONTEXT('USERENV', 'DB_DOMAIN') 
from v$instance where INSTANCE_NAME=SYS_CONTEXT('USERENV', 'INSTANCE_NAME')

select privilege# from sysauth$ where (grantee#=:1 or grantee#=1) and privilege#>0

ALTER SESSION SET NLS_LANGUAGE= 'AMERICAN' NLS_TERRITORY= 'AMERICA' NLS_CURRENCY= '$'
NLS_ISO_CURRENCY= 'AMERICA' NLS_NUMERIC_CHARACTERS= '.,' NLS_CALENDAR= 'GREGORIAN'
NLS_DATE_FORMAT= 'DD-MON-RR' NLS_DATE_LANGUAGE= 'AMERICAN' NLS_SORT= 'BINARY' TIME_ZONE= '+02:00'
NLS_COMP= 'BINARY' NLS_DUAL_CURRENCY= '$' NLS_TIME_FORMAT= 'HH.MI.SSXFF AM' NLS_TIMESTAMP_FORMAT=
'DD-MON-RR HH.MI.SSXFF AM' NLS_TIME_TZ_FORMAT= 'HH.MI.SSXFF AM TZR' NLS_TIMESTAMP_TZ_FORMAT=
'DD-MON-RR HH.MI.SSXFF AM TZR'

NOTE: The list of SQL above is not complete and does not represent the ordering of the authentication SQL . Differences may also exist from release to release.

• Hangs during Authentication

The above SQL statements need to be Parsed, Executed and Fetched as happens for all SQL inside an Oracle Database. It follows that any problem encountered during these phases which appears as a hang or severe slow performance may result in a timeout.

Symptoms of such hangs will be seen by the authenticating session as waits for:
• cursor: pin S wait on X
• latch: row cache objects
• row cache lock
Other types of wait events are possible; this list may not be complete.

The issue here is that the authenticating session is blocked waiting to get a shared resource which is held by another session inside the database. That blocker session is itself occupied in a long-running activity (or its own hang) which prevents it from releasing the shared resource needed by the authenticating session in a timely fashion. This results in the timeout being eventually reported to the authenticating session.

• Troubleshooting of Authentication hangs

In such situations, we need to find out the blocker process holding the shared resource needed by the authenticating session in order to see what is happening to it.

Typical diagnostics used in such cases are the following:

1. Three consecutive systemstate dumps at level 266 during the time that one or more authenticating sessions are blocked. It is likely that the blocking session will have caused timeouts to more than one connection attempt. Hence, systemstate dumps can be useful even when the time needed to generate them exceeds the period of a single timeout e.g. 60 sec:

      $ sqlplus -prelim '/ as sysdba' 

       oradebug setmypid 
       oradebug unlimit 
       oradebug dump systemstate 266 
       ...wait 90 seconds 
       oradebug dump systemstate 266 
       ...wait 90 seconds 
       oradebug dump systemstate 266 
       quit

• ASH reports covering e.g. 10-15 minutes of a time period during which several timeout errors were seen.
• If possible, Two consecutive queries on V$LATCHHOLDER view for the case where the shared resource being waited for is a latch.
  select * from v$latchholder;
  The systemstate dumps should help in identifying the blocker session.
  Level 266 will show us in what code it is executing which may help in locating any existing bug as the root cause.

Examples of issues which can result in Authentication hangs

• Unpublished Bug 6879763 shared pool simulator bug fixed by patch
  for unpublished Bug 6966286 see Note 563149.1

• Unpublished Bug 7039896 workaround parameter
  _enable_shared_pool_durations=false see Note 7039896.8

• Other approaches to avoid the problem

In some cases, it may be possible to avoid problems with Authentication SQL by pinning such statements in the Shared Pool soon after the instance is started and they are freshly loaded. You can use the following artcile to advise on this:
Document 726780.1 How to Pin a Cursor in the Shared Pool using DBMS_SHARED_POOL.KEEP

Pinning will prevent them from being flushed out due to inactivity and aging and will therefore prevent them for needing to be reloaded in the future i.e. needing to be reparsed and becoming susceptible to Authentication hang issues.

At some points, the client sides received intermittent ORA-12170 repeatedly:

ORA-12170: TNS:Connect timeout occurred

Meanwhile, the server side did not receive any errors either in listener.log or alert.log.

ORA-12170 mean that the failed connections did not reach the listener due to network problem. Most likely, they’re blocked by security rules.

Sometimes, there’s a time-out, but what would cause the network time out? What factors that blocked the packets of clients in the pathway to database. Here I made a list for the possibilities of ORA-12170:

• Server is Down

Sometimes, the network is unable to send your packets to the destination because the database server is down.

• TNS Names
• Wrong IP address in TNS entry, which cannot be reachable in your local area network. There maybe a duplicate entry in your tnsnames.ora.
• Wrong port in TNS entry, which denies all connections by firewall.
• Hardware or software firewall
• Poor quality of network
• Network card interface (NIC) failure
• Anti-Virus software
• Detected suspicious packets and blocked them.
• Was scanning the whole operating system.
• Intrusion Prevention System (IPS)
• Intrusion Detection System (IDS)
• Proxy Server

Solutions

The first step, you need to make sure everything you provided is correct like I said earlier, which includes checking tnsnames.ora.

The most common mistake is that you didn’t open the port 1521 on firewall. That caused ORA-12170. To open port on firewall of the database server, you may refer to these posts:

• How to Open Port 1521 on Linux Server
• How to Open Port 1521 on Windows Server

If the firewall is on network appliance, you should ask your network administrator for help.

In our case, we found an IPS applied new rules recently that could caused the problem eventually. To revert the configuration, we rolled back the policy of that IPS. No more ORA-12170.

Other Factors

By the way, if the network appliance really needs more considerable time to complete the validation, you can raise the inbound connect time value of the listener, which is also the solution to ORA-03136 Inbound Connection Timed Out.

Such cases of ORA-12170 happened on the client sides. The management usually misunderstood as a database problem, and ask DBA for resolving it. But the database was healthy during incidents, this reminds us that not all ORA errors are thrown by the database.