Determinación de la ubicación del archivo relevante tnsnames.ora

Instalé los controladores Oracle 11g de 32 y 64 bits. Busco en mi PC buscando archivos con el nombre “tnsnames.ora” y encuentro 3 en las siguientes ubicaciones:

1. C:\Oracle\product\11203_32bit\CLIENT_1\NETWORK\ADMIN 2. C:\Oracle\product\11203_64bit\CLIENT_1\NETWORK\ADMIN 3. C:\Windows\TNS 

La existencia de la tercera ubicación del archivo tnsnames.ora me sorprende.

Tengo los siguientes clientes de Oracle instalados en mi PC:

 "C:\Program Files (x86)\Quest Software\Toad for Oracle 11.6\Toad.exe" "C:\Program Files\Devart\dbForge Studio Express for Oracle\dbforgeoracle.exe" 

Según la ubicación de cada progtwig (Archivos de progtwig (x86) vs. c: \ Archivos de progtwig), esto me sugiere que el Toad, un progtwig de 32 bits, debe usar el controlador de 32 bits y dbForge debe usar el controlador de 64 bits.

dbForge parece usar el archivo tnsnames.ora en cualquiera de las ubicaciones 2 o 3. Sé esto al renombrar sistemáticamente todos menos uno de los archivos tns y luego verificar si los nombres de conexión leídos del archivo están disponibles cuando bash crear una nueva conexión desde la aplicación.

Sin embargo, ¡parece que TOAD solo reconoce el archivo tnsnames.ora en la ubicación n. ° 3 y no reconoció en absoluto el archivo tnsnames.ora en la ubicación 2! (Siendo que era un progtwig de 32 bits, no esperaba que reconociera el archivo tns en la ubicación 2 y ese fue el caso). Para resumir la prueba TOAD por razones de claridad, TOAD solo reconoció el archivo tns en la ubicación 3.

Otros colegas no tienen un archivo tns en la ubicación 3 en sus máquinas. No estoy seguro de por qué lo hago. Cuando ejecuto Toad, muestra el siguiente 2 Inicio, con el Inicio de 32 bits como el activo.

 OraClient11g_home1 (11.2.0.3) ORACLE_HOME:C:\app\C39293\product\11.2.0\client_1 ORACLE_HOME_NAME:OraClient11g_home1 ORACLE_HOME_KEY:HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_OraClient11g_home1 ORACLE_SID: NLS_LANG:AMERICAN_AMERICA.WE8MSWIN1252 SQLPATH: LOCAL: Client DLL:C:\app\C39293\product\11.2.0\client_1\oci.dll TNSNames.ora: SQLNet.ora: LDAP.ora: Login.sql: GLogin.sql: In system PATH:No Home is valid:No OraClient11g_home1_32bit (11.2.0.3) ORACLE_HOME:c:\oracle\product\11203_32bit\CLIENT_1 ORACLE_HOME_NAME:OraClient11g_home1_32bit ORACLE_HOME_KEY:HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_OraClient11g_home1_32bit ORACLE_SID: NLS_LANG:AMERICAN_AMERICA.WE8MSWIN1252 SQLPATH:c:\oracle\product\11203_32bit\CLIENT_1\dbs LOCAL: Client DLL:c:\oracle\product\11203_32bit\CLIENT_1\bin\oci.dll TNSNames.ora: SQLNet.ora: LDAP.ora: Login.sql: GLogin.sql:c:\oracle\product\11203_32bit\CLIENT_1\sqlplus\admin\glogin.sql In system PATH:Yes 

Q1: ¿Es OraClient11g_home1 mi 64 bit en casa o tengo dos clientes de Oracle instalados?

P2: ¿Por qué TOAD de 32 bits no usa solo el tns en la ubicación n. ° 1 en la ubicación n. ° 3?

P3: si dejo el archivo tns en la ubicación 3, tanto dbForge como TOAD funcionan, pero me gustaría saber por qué para poder entender con precisión cómo mover la información de tns de una máquina a otra.

Basándose en sus rutas, tiene dos clientes instalados como sospecha (Toad y dbforge son herramientas, no clientes, por lo que su terminología está un poco desactualizada). Uno de 32 bits, el otro de 64 bits. Parece que Toad está basado en 32 bits en su ruta de instalación, pero ejecútelo y vaya a Ayuda | Support Bundle. Verá que el encabezado superior será “INFORMACIÓN DE LA APLICACIÓN (32 bits)” o “INFORMACIÓN DE LA APLICACIÓN (64 bits)” solo para confirmar. Toad 11.6 fue el primero en introducir una versión de 64 bits.

Toad solo verá el cliente Oracle que sea para la misma plataforma que él. Entonces, su cliente de 64 bits es irrelevante por el bien de Toad. El C: \ Windows \ TNS parece ser una carpeta utilizada para la carpeta TNS_ADMIN dada su ubicación impar y el hecho de que Toad lo ve. En el símbolo del sistema, ejecute SET TNS_ADMIN y vea si informa “TNS_ADMIN = C: \ Windows \ TNS”. Si lo hace, todas las Herramientas deberían usar ese tnsnames.ora. Eso es una anulación global si lo haces apunta a la carpeta que contiene tus archivos de configuración de red. Si no tiene TNS_ADMIN configurado como una variable de entorno, búsquelo en su registro raíz de Oracle: HKEY_LOCAL_MACHINE \ Software \ Oracle.

Si usa un conjunto común de conexiones para todas sus herramientas, eliminaría todos sus archivos tnsnames.ora. También reubicaría esa carpeta C: \ Windows \ TNS a un sitio más apropiado como C: \ Oracle \ Admin y crearía allí sus tnsnames.ora, sqlnet.ora y ldap.ora (si corresponde). Cree una variable de entorno TNS_ADMIN que apunte a esa ubicación.

Según Oracle, estas ubicaciones se buscan tnsnames.ora , resp. sqlnet.ora y ldap.ora :

  1. Archivos de Oracle Net en el directorio de trabajo actual (PWD / CWD)
  2. TNS_ADMIN definido por sesión o por script definido por el usuario
  3. TNS_ADMIN definido como una variable de entorno global
  4. TNS_ADMIN definido en el registro
  5. Archivos de Oracle Net en %ORACLE_HOME/network|net80\admin (ubicación predeterminada de Oracle)

Sin embargo, no estoy seguro de si cada aplicación / controlador sigue esta lista. Obtuve esta lista del documento de Oracle 111942.1 que hace referencia a Oracle 9i, por lo que podría estar desactualizado.

En la Guía del administrador de Servicios de red de base de datos, el orden es

  1. TNS_ADMIN definido por variable de entorno
  2. TNS_ADMIN definido en el registro (si la variable de entorno TNS_ADMIN no está presente)
  3. %ORACLE_HOME%/network/admin directory (si la variable de entorno TNS_ADMIN no está presente)

Yo recomendaría definir una variable de entorno para TNS_ADMIN y usar solo un archivo tnsnames.ora. Para estar seguro, verifique también sus valores de registro.

Si sus archivos no se encuentran en %ORACLE_HOME%\network\admin , recomiendo crear un enlace simbólico para ello, solo para estar en el lado seguro, por ejemplo, mklink /d %ORACLE_HOME%\network\admin c:\Oracle\common\settings\admin

Otra nota, no tienes que “jugar” con tu archivo tnsnames.ora. Con Process Monitor de Microsoft Sysinternals puede controlar cada acceso de archivo, es decir, el filtro sería Path contains tnsnames

Actualizar

Cuando realizo una prueba en mi máquina obtengo el siguiente orden:

  1. Variable de entorno TNS_ADMIN
  2. Clave de registro HKEY_CURRENT_USER\SOFTWARE\ORACLE\KEY_{Oracle_Home_Name}\TNS_ADMIN
  3. Clave de registro HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_{Oracle_Home_Name}\TNS_ADMIN , resp. HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ORACLE\KEY_{Oracle_Home_Name}\TNS_ADMIN

    -> Solo si la variable de entorno TNS_ADMIN no está configurada.

  4. %ORACLE_HOME%\network\admin
  5. Directorio actual (que puede ser diferente al directorio donde se encuentra su aplicación)
  6. Carpeta donde se encuentra su aplicación

Actualización 2

Obviamente no hay una búsqueda de arreglo, varía para diferentes proveedores / controladores. Tal vez también depende de la versión de Oracle.

Por ejemplo, Oracle HTTP Server lee la configuración de TNS_ADMIN desde el opmn.xml configuración opmn.xml .

Otro ejemplo, para la versión beta de ODP.NET Managed Driver (Oracle.ManagedDataAccess), encontré este orden en Oracle Managed y TNS Names :

  1. alias de origen de datos en la sección ‘dataSources’ en la sección en el archivo de configuración .NET (es decir, machine.config , web.config , user.config ).
  2. alias de origen de datos en el archivo tnsnames.ora en la ubicación especificada por TNS_ADMIN en el archivo de configuración .NET.
  3. alias de origen de datos en el archivo tnsnames.ora presente en el mismo directorio que el .exe .
  4. alias del origen de datos en el archivo tnsnames.ora presente en %TNS_ADMIN%
    (donde %TNS_ADMIN% es una configuración de variable de entorno).
  5. alias del origen de datos en el archivo tnsnames.ora presente en %ORACLE_HOME%\network\admin
    (donde %ORACLE_HOME% es una configuración de variable de entorno).

En la documentación oficial (12c Release 4 (12.1.0.2.4)) dice:

  1. alias del origen de datos en la sección dataSources en la sección en el archivo de configuración .NET (es decir, machine.config , web.config , user.config ).
  2. alias de origen de datos en el archivo tnsnames.ora en la ubicación especificada por TNS_ADMIN en el archivo de configuración .NET. Las ubicaciones pueden consistir en rutas de directorio absolutas o relativas.
  3. alias de origen de datos en el archivo tnsnames.ora presente en el mismo directorio que el .exe .

Sin embargo, en función de algunas pruebas que realicé con el Controlador administrado ODP.NET (4.121.2.0), toma %ORACLE_HOME%\network\admin y la variable de entorno TNS_ADMIN en cuenta. Bloqueos como la documentación no es 100% correcto.