web-dev-qa-db-fra.com

ORA-12170: TNS: délai de connexion écoulé

J'essayais de me connecter à la base de données ici sur mon ordinateur portable en utilisant Oracle Toad mais je continuais à avoir cette erreur:

ORA-12170: TNS: délai de connexion écoulé

Quelles sont les raisons possibles pour lesquelles j'ai continué à avoir cette erreur? 

J'ai accédé à la même base de données hier et j'ai pu y accéder.

oracletoadora-12170
14
Pseudonymous

[Rassembler les réponses dans les commentaires]

Le problème est que le service Oracle s'exécute sur une adresse IP et que l'hôte est configuré avec une autre adresse IP.

Pour voir l'adresse IP du service Oracle, lancez une commande lsnrctl status et vérifiez l'adresse indiquée (dans ce cas, 127.0.0.1, l'hôte local):

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(Host=127.0.0.1)(PORT=1521)))

Pour voir l'adresse IP de l'hôte, exécutez la commande ipconfig (sous Windows) ou ifconfig (sous linux).

Cependant, dans mon installation, le service ne fonctionne pas s'il est défini sur l'adresse localhost, je dois définir la véritable adresse IP de l'hôte (par exemple 192.168.10.X).

Pour éviter ce problème à l'avenir, n'utilisez pas DHCP pour attribuer une adresse IP à l'hôte, mais utilisez une adresse statique.

6
Zac

C'est à cause d'un SID en conflit. Par exemple, dans votre fichier Oracle12cBase\app\product\12.1.0\dbhome_1\NETWORK\ADMIN\tnsnames.ora, la description de la connexion pour ORCL est la suivante:

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 adresse IP, nom d'utilisateur/mot de passe différente, comme ceci:

nom d'utilisateur sqlplus/[email protected]: 1521/orcl

Pour résoudre ce problème, apportez des modifications au fichier tnsnames.ora:

ORCL =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(Host = 192.168.130.52)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl)
    )
  )
2
Ashish Jain

Problème car l'établissement de la connexion ou la communication avec un client a échoué dans le délai imparti. Cela peut être dû à des retards de réseau ou du système.

1
Vishal Tathe

Cochez la case FIREWALL pour autoriser la connexion au serveur à partir de votre client . En autorisant le réseau de domaine ou en créant une règle.

1
Fajar

J'obtenais la même erreur en connectant mon utilisateur "hr" de ORCLPDB qui est une base de données enfichable.

Commencez par 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, il s’agissait de 127.0.0.1 avec le 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/[email protected]:1521/ORCLPDB.
0
Avatar Girase

ÉTAPES DE DÉPANNAGE (ID de document 730066.1)

Erreurs de délai de connexion ORA-3135 et ORA-3136 Une erreur de délai de connexion peut être générée lorsqu'une tentative de connexion à la base de données n'achève pas ses phases de connexion et d'authentification dans les délais autorisés 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; dans les versions précédentes, la valeur était 0, ce qui signifie aucun délai d'expiration.

Lors d'un délai d'attente, le programme client recevra l'erreur ORA-3135 (ou éventuellement TNS-3135):

ORA-3135 connexion perdue contact

et la base de données consignera l'erreur ORA-3136 dans son fichier alert.log:

... samedi 10 mai 02:21:38 2008 AVERTISSEMENT: la connexion entrante a expiré (ORA-3136) ...

  • Authentification SQL

Lorsqu'une session de base de données est en phase d'authentification, elle émet une séquence d'instructions SQL. L'authentification n'est pas complète jusqu'à ce que tous ceux-ci soient analysés, exécutés, complètement récupérés. Certaines des instructions SQL de cette liste, par exemple. sur 10.2 sont:

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'

Remarque: la liste de SQL ci-dessus n'est pas complète et ne représente pas l'ordre de l'authentification SQL. Des différences peuvent également exister d'une publication à l'autre.

  • se bloque pendant l'authentification

Les instructions SQL ci-dessus doivent être analysées, exécutées et extraites comme pour tous les SQL au sein d'une base de données Oracle. Il s'ensuit que tout problème rencontré au cours de ces phases, qui apparaît comme un blocage ou une performance extrêmement lente, peut entraîner un dépassement du délai d'attente.

La session d'authentification voit les symptômes de tels blocages comme des attentes: • curseur: broche S attendre sur X • latch: objets de cache de lignes • verrouillage de cache de lignes Autres types d'événements d'attente sont possibles cette liste peut ne pas être complète.

Le problème ici est que la session d'authentification est bloquée dans l'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 par une activité de longue durée (ou par son propre blocage) qui l’empêche de libérer à temps la ressource partagée nécessaire à la session d’authentification. Il en résulte que le délai d'attente est finalement signalé à la session d'authentification.

  • Dépannage de l'authentification se bloque

Dans de telles situations, nous devons connaître le processus de blocage contenant la ressource partagée nécessaire à la session d'authentification afin de voir ce qui lui arrive.

Les diagnostics typiques utilisés dans de tels cas sont les suivants:

  1. Trois vidages système consécutifs au niveau 266 pendant le blocage d’une ou de plusieurs sessions d’authentification. Il est probable que la session de blocage ait provoqué des délais d'attente pour plusieurs tentatives de connexion. Par conséquent, les vidages d'état système 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 d'attente, par ex. 60 secondes:
      $ 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 au cours de laquelle plusieurs erreurs de timeout ont été constatées.
  • Si possible, deux requêtes consécutives sur la vue V $ LATCHHOLDER pour le cas où la ressource partagée attendue est un verrou . Sélectionnez * à partir de v $ latchholder; Les vidages de système doivent aider à identifier la session de blocage. Le niveau 266 nous montrera dans quel code il s’exécute, ce qui peut aider à localiser tout bogue existant comme cause fondamentale.

Exemples de problèmes pouvant entraîner un blocage de l'authentification

  • Bogue non publié 6879763; bogue du simulateur de pool partagé résolu par le correctif Pour le bogue non publié 6966286, voir la note 563149.1. 

  • Paramètre de contournement du bogue 7039896 non publié _ enable_shared_pool_durations = false, voir la note 7039896.8

  • Autres approches pour éviter le problème

Dans certains cas, il peut être possible d'éviter les problèmes liés à Authentication SQL en épinglant de telles instructions dans le pool partagé peu après le démarrage de l'instance et leur chargement récent. Vous pouvez utiliser l’artcile suivant pour vous aider: Document 726780.1 Comment épingler un curseur dans le pool partagé à l’aide de DBMS_SHARED_POOL.KEEP

L’épinglage les empêchera d’être vidés du fait de leur inactivité et de leur vieillissement et leur évitera donc de devoir être rechargés à l’avenir, c’est-à-dire qu’ils doivent être reparsés et susceptibles de poser des problèmes de blocage d’authentification.

0
Tagar
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

0
Mohammad AL-Omari