ORA-12170: TNS: le délai de connexion s'est produit

c'est à cause du conflit SID. Par exemple, dans votre Oracle12cBase\app\product\12.1.0\dbhome_1\NETWORK\ADMIN\tnsnames.ora fichier, description de la connexion pour ORCL) est ceci:

ORCL =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl)
    )
  )

et, vous essayez de vous connecter en utilisant la chaîne de connexion en utilisant le même SID mais une IP différente, nom d'utilisateur / mot de passe, comme ceci:

sqlplus username/password@192.168.130.52:1521/orcl

pour résoudre ceci, faites des changements dans les noms de domaine.ora fichier:

ORCL =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.130.52)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl)
    )
  )

vérifiez le pare-feu, pour autoriser la connexion au serveur à partir de votre client. En permettant le réseau de domaine ou créer la règle.

problème parce que l'établissement de la connexion ou la communication avec un client ne s'est pas terminée dans le délai prévu. Cela peut être dû à des retards dans le réseau ou le système.

j'ai eu la même erreur en connectant mon utilisateur "hr" D'ORCLPDB qui est une base de données connectable.

tout d'abord, obtenir le nom d'hôte et le numéro de port en tapant une commande lsnrctl status sur l'invite de commande windows. Dans mon cas, c'était 127.0.0.1 avec numéro de port 1521

Deuxièmement, entrez la commande ci-dessous avec votre nom d'hôte et votre numéro de port:

sqlplus username/password@HostName:Port Number/PluggableDatabaseName.

Par exemple:

sqlplus hr/hr@127.0.0.1:1521/ORCLPDB.

ÉTAPES DE DÉPANNAGE (DOC ID 730066.1)

erreurs de délai de connexion ORA-3135 et ORA-3136 Une erreur de délai de connexion peut être émise lorsqu'une tentative de connexion à la base de données ne termine pas ses phases de connexion et d'authentification dans le délai autorisé par les éléments suivants:: SQLNET.INBOUND_CONNECT_TIMEOUT et/ou INBOUND_CONNECT_TIMEOUT_ paramètres côté serveur.

à partir D'Oracle 10.2, la valeur par défaut pour ces paramètres est de 60 secondes où dans les versions précédentes il était 0, ce qui signifie pas de délai.

sur un timeout, le programme client recevra L'erreur ORA-3135 (ou éventuellement TNS-3135):

Ora-3135 perte de contact

et la base de données enregistrera L'erreur ORA-3136 dans son alerte.log:

... Sam. Mai 10 02:21: 38 2008 Attention: connexion entrante chronométrée (ORA-3136)) ...

• authentification SQL

Lorsqu'une session de base de données est en phase d'authentification, elle émettra une séquence D'instructions SQL. L'authentification n'est pas complète tant que tous ceux-ci ne sont pas analysés, exécutés, récupérés complètement. Certains des instructions SQL dans cette liste, par exemple sur 10.2:

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: la liste de SQL ci-dessus n'est pas complète et ne représente pas l'ordre du SQL d'authentification . Des différences peuvent également exister à partir d'une version à une autre.

• se Bloque lors de l'Authentification

les instructions SQL ci-dessus doivent être analysées, exécutées et récupérées comme c'est le cas pour tous les SQL à l'intérieur d'une base de données Oracle. Il s'ensuit que tout problème rencontré au cours de ces phases, qui apparaît comme une performance lente ou sévère, peut entraîner un temps d'arrêt.

le problème ici est que la session d'authentification est bloquée en attente d'obtenir une ressource partagée qui est détenue par une autre session à l'intérieur de la base de données. Cette session de bloqueur est elle-même occupée dans une activité de longue durée (ou sa propre suspension) qui l'empêche de libérer la ressource partagée nécessaire par la session d'authentification dans un temps opportun mode. Il en résulte que le timeout est finalement rapporté à la session d'authentification.

• dépannage d'authentification hangs

dans de telles situations, nous avons besoin de découvrir le processus de bloqueur qui détient la ressource partagée nécessaire à la session d'authentification afin de voir ce qui lui arrive.

1. trois consécutifs systemstate bascule au niveau 266 pendant qu'une ou plusieurs sessions d'authentification sont bloquées. Il est probable que la session de blocage aura causé plus d'une tentative de connexion. Par conséquent, les dumps de systemstate peuvent être utiles même lorsque le temps nécessaire pour les générer dépasse la période d'un seul délai, par exemple 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

• rapports ASH couvrant par exemple 10-15 minutes d'une période de temps au cours de laquelle plusieurs erreurs de temporisation ont été observés.
• si possible, deux requêtes consécutives sur la vue V$LATCHHOLDER pour le cas où la ressource partagée attendue est un verrou. select * from v$latchholder; Les dumps de systemstate devraient aider à identifier la session de bloqueur. Le niveau 266 nous montrera dans quel code il exécute ce qui peut aider à localiser n'importe quel bogue existant comme la cause racine.

Exemples de questions qui peuvent entraîner l'Authentification se bloque

• non publié Bug 6879763 simulateur de piscine partagée bug corrigé par le correctif pour le bogue 6966286 non publié, voir la Note 563149.1

• paramètre de contournement du bogue 7039896 non publié _enable_shared_pool_durations=false voir Note 7039896.8

• d'Autres approches pour éviter le problème

dans certains cas, il peut être possible d'éviter des problèmes avec L'authentification SQL en épinglant de telles déclarations dans le Pool partagé peu de temps après l'instance est commencé et ils sont fraîchement chargés. Vous pouvez utiliser l'artcile à conseiller: Document 726780.1 comment épingler un curseur dans le Pool partagé en utilisant DBMS_SHARED_POOL.KEEP

L'épinglage les empêchera d'être évacués en raison de l'inactivité et du vieillissement et les empêchera donc d'avoir besoin d'être rechargés à l'avenir, c'est-à-dire d'avoir besoin d'être réparés et de devenir vulnérables aux problèmes de suspension de L'authentification.

open sqlnet.ora  

NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)
SQLNET.INBOUND_CONNECT_TIMEOUT=360
SQLNET.RECV_TIMEOUT=10
SQLNET.SEND_TIMEOUT=10

http://docs.oracle.com/cd/B19306_01/network.102/b14213/sqlnet.htm