Rogue TNSNAMES.ORA files Revisited
A few days (or was that weeks??) ago, someone posted some problems they were having connecting to a database defined in their tnsnames.ora file. The problem was resolved when they found out that there was a rogue tnsnames.ora file residing in the same directory as the binary. The binary file was resolving a databases address by using the local tnsnames.ora first. I recently had a similar issue (a long story, available on http://www.clanmcgraw.com/oracle.html for those interested) where sqlplus was resolving a database address by using a tnsnames.ora file stored in /var/opt/oracle (on Solaris 8). I thought that was because I did not have the TNS_ADMIN environment variable set properly by the oraenv file. I did some research on Metalink, and under Note 114085.1, found the following information that others might find useful: Windows NT/2000 running Oracle 9i First: The directory where the application is launched. For example, if sqlplus resides in ORACLE_HOME\bin\sqlplus but was launched from the c:\temp directory, then c:\temp is searched for a tnsnames.ora file. Second: The value of the TNS_ADMIN environment variable. Third: ORACLE_HOME\network\admin Sun Solaris running Oracle 8i or 9i First: The oracle user's home directory is searched for a hidden '.tnsnames.ora' Second: The value of the TNS_ADMIN environment variable. Third: /var/opt/oracle Fourth: $ORACLE_HOME/network/admin Some were talking about an April Fools joke with local tnsnames.ora files. I think youd have a lot more fun with the .tnsnames.ora file, if youre on Solaris. J Hope that information is useful to someone out there Brian -- | Brian McGraw /* DBA */ Infinity Insurance | | mailto:[EMAIL PROTECTED] | --
RE: Rogue TNSNAMES.ORA files Revisited
Title: RE: Rogue TNSNAMES.ORA files Revisited Yup ... learned it the hard way !! At-least AIX is *normal* (fingers crossed). Raj __ Rajendra Jamadagni MIS, ESPN Inc. Rajendra dot Jamadagni at ESPN dot com Any opinion expressed here is personal and doesn't reflect that of ESPN Inc. QOTD: Any clod can have facts, but having an opinion is an art! -Original Message- From: Brian McGraw [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 29, 2003 1:14 PM To: Multiple recipients of list ORACLE-L Subject: Rogue TNSNAMES.ORA files Revisited A few days (or was that weeks??) ago, someone posted some problems they were having connecting to a database defined in their tnsnames.ora file. The problem was resolved when they found out that there was a 'rogue' tnsnames.ora file residing in the same directory as the binary. The binary file was resolving a database's address by using the local tnsnames.ora first. I recently had a similar issue (a long story, available on http://www.clanmcgraw.com/oracle.html for those interested) where sqlplus was resolving a database address by using a tnsnames.ora file stored in /var/opt/oracle (on Solaris 8). I thought that was because I did not have the TNS_ADMIN environment variable set properly by the oraenv file. I did some research on Metalink, and under Note 114085.1, found the following information that others might find useful: Windows NT/2000 running Oracle 9i First: The directory where the application is launched. For example, if sqlplus resides in ORACLE_HOME\bin\sqlplus but was launched from the c:\temp directory, then c:\temp is searched for a tnsnames.ora file. Second: The value of the TNS_ADMIN environment variable. Third: ORACLE_HOME\network\admin Sun Solaris running Oracle 8i or 9i First: The oracle user's home directory is searched for a hidden '.tnsnames.ora' Second: The value of the TNS_ADMIN environment variable. Third: /var/opt/oracle Fourth: $ORACLE_HOME/network/admin Some were talking about an April Fool's joke with local tnsnames.ora files. I think you'd have a lot more fun with the .tnsnames.ora file, if you're on Solaris. J Hope that information is useful to someone out there... Brian -- | Brian McGraw /* DBA */ Infinity Insurance | | mailto:[EMAIL PROTECTED] | -- This e-mail message is confidential, intended only for the named recipient(s) above and may contain information that is privileged, attorney work product or exempt from disclosure under applicable law. If you have received this message in error, or are not the named recipient(s), please immediately notify corporate MIS at (860) 766-2000 and delete this e-mail message from your computer, Thank you.*2
RE: Rogue TNSNAMES.ORA files Revisited
Brian, The order in which the TNS connection searches are performed can also easily be determined by using the 'truss' command on Solaris. I used this to prove my case to a PHB of a smart-aleck Developer who was side-stepping our move to an Oracle Name Service in a prior assignment. I see what you mean - been there done that! Take care bro! John Kanagaraj Oracle Applications DBA DBSoft Inc (W): 408-970-7002 I don't know what the future holds for me, but I do know who holds my future! ** The opinions and statements above are entirely my own and not those of my employer or clients ** -Original Message- Sent: Wednesday, January 29, 2003 10:14 AM To: Multiple recipients of list ORACLE-L A few days (or was that weeks??) ago, someone posted some problems they were having connecting to a database defined in their tnsnames.ora file. The problem was resolved when they found out that there was a 'rogue' tnsnames.ora file residing in the same directory as the binary. The binary file was resolving a database's address by using the local tnsnames.ora first. I recently had a similar issue (a long story, available on http://www.clanmcgraw.com/oracle.html for those interested) where sqlplus was resolving a database address by using a tnsnames.ora file stored in /var/opt/oracle (on Solaris 8). I thought that was because I did not have the TNS_ADMIN environment variable set properly by the oraenv file. I did some research on Metalink, and under Note 114085.1, found the following information that others might find useful: Windows NT/2000 running Oracle 9i First: The directory where the application is launched. For example, if sqlplus resides in ORACLE_HOME\bin\sqlplus but was launched from the c:\temp directory, then c:\temp is searched for a tnsnames.ora file. Second: The value of the TNS_ADMIN environment variable. Third: ORACLE_HOME\network\admin Sun Solaris running Oracle 8i or 9i First: The oracle user's home directory is searched for a hidden '.tnsnames.ora' Second: The value of the TNS_ADMIN environment variable. Third: /var/opt/oracle Fourth: $ORACLE_HOME/network/admin Some were talking about an April Fool's joke with local tnsnames.ora files. I think you'd have a lot more fun with the .tnsnames.ora file, if you're on Solaris. J Hope that information is useful to someone out there... Brian -- | Brian McGraw /* DBA */ Infinity Insurance | | mailto:[EMAIL PROTECTED] | -- -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: John Kanagaraj INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Rogue TNSNAMES.ORA files Revisited
Thanks, John. Just out of curiousity - for those of us who aren't Unix experts - what options did you use for truss to obtain that info.?? Brian -Original Message- Kanagaraj Sent: Wednesday, January 29, 2003 2:14 PM To: Multiple recipients of list ORACLE-L Brian, The order in which the TNS connection searches are performed can also easily be determined by using the 'truss' command on Solaris. I used this to prove my case to a PHB of a smart-aleck Developer who was side-stepping our move to an Oracle Name Service in a prior assignment. I see what you mean - been there done that! Take care bro! John Kanagaraj Oracle Applications DBA DBSoft Inc (W): 408-970-7002 I don't know what the future holds for me, but I do know who holds my future! ** The opinions and statements above are entirely my own and not those of my employer or clients ** -Original Message- Sent: Wednesday, January 29, 2003 10:14 AM To: Multiple recipients of list ORACLE-L A few days (or was that weeks??) ago, someone posted some problems they were having connecting to a database defined in their tnsnames.ora file. The problem was resolved when they found out that there was a 'rogue' tnsnames.ora file residing in the same directory as the binary. The binary file was resolving a database's address by using the local tnsnames.ora first. I recently had a similar issue (a long story, available on http://www.clanmcgraw.com/oracle.html for those interested) where sqlplus was resolving a database address by using a tnsnames.ora file stored in /var/opt/oracle (on Solaris 8). I thought that was because I did not have the TNS_ADMIN environment variable set properly by the oraenv file. I did some research on Metalink, and under Note 114085.1, found the following information that others might find useful: Windows NT/2000 running Oracle 9i First: The directory where the application is launched. For example, if sqlplus resides in ORACLE_HOME\bin\sqlplus but was launched from the c:\temp directory, then c:\temp is searched for a tnsnames.ora file. Second: The value of the TNS_ADMIN environment variable. Third: ORACLE_HOME\network\admin Sun Solaris running Oracle 8i or 9i First: The oracle user's home directory is searched for a hidden '.tnsnames.ora' Second: The value of the TNS_ADMIN environment variable. Third: /var/opt/oracle Fourth: $ORACLE_HOME/network/admin Some were talking about an April Fool's joke with local tnsnames.ora files. I think you'd have a lot more fun with the .tnsnames.ora file, if you're on Solaris. J Hope that information is useful to someone out there... Brian -- | Brian McGraw /* DBA */ Infinity Insurance | | mailto:[EMAIL PROTECTED] | -- -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: John Kanagaraj INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Brian McGraw INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Rogue TNSNAMES.ORA files Revisited
Brian, I used the following command - a grep of 'access' is pasted below: (I should mention that we use Oracle Name Service, so after getting to the proper sqlnet.ora, you will not see access of the tnsnames.ora. John truss -f sqlplus '/ as sysdba' truss.out 21 EOF exit EOF 5484: access(/u01/c4prdb/8.1.7/network/admin/ldap.ora, 0) Err#2 ENOENT 5484: access(/u01/c4prdb/8.1.7/network/admin/ldap.ora, 0) Err#2 ENOENT 5484: access(/u01/c4prdb/8.1.7/network/admin/C4PR/sqlnet.ora, 0) = 0 5484: access(/export/home/oracle/.sqlnet.ora, 0)Err#2 ENOENT 5484: access(/u01/c4prdb/8.1.7/network/admin/C4PR/intchg.ora, 0) Err#2 ENOEN T 5484: access(/var/opt/oracle/intchg.ora, 0) Err#2 ENOENT 5484: access(/u01/c4prdb/8.1.7/network/admin/intchg.ora, 0) Err#2 ENOENT 5484: access(/u01/c4prdb/8.1.7/network/admin/C4PR/tnsnav.ora, 0) Err#2 ENOEN T 5484: access(/var/opt/oracle/tnsnav.ora, 0) Err#2 ENOENT 5484: access(/u01/c4prdb/8.1.7/network/admin/tnsnav.ora, 0) Err#2 ENOENT 5485: access(/u01/c4prdb/8.1.7/network/admin/ldap.ora, 0) Err#2 ENOENT 5485: access(/u01/c4prdb/8.1.7/network/admin/C4PR/sqlnet.ora, 0) = 0 5485: access(/u01/c4prdb/8.1.7/network/trace/svr_5485.trc, 0) Err#2 ENOENT 5485: access(/u01/c4prdb/8.1.7/network/admin/C4PR/intchg.ora, 0) Err#2 ENOEN T 5485: access(/var/opt/oracle/intchg.ora, 0) Err#2 ENOENT 5485: access(/u01/c4prdb/8.1.7/network/admin/intchg.ora, 0) Err#2 ENOENT 5485: access(/u01/c4prdb/8.1.7/network/admin/C4PR/tnsnav.ora, 0) Err#2 ENOEN T 5485: access(/var/opt/oracle/tnsnav.ora, 0) Err#2 ENOENT 5485: access(/u01/c4prdb/8.1.7/network/admin/tnsnav.ora, 0) Err#2 ENOENT 5485: access(/etc/ORACLE/WALLETS/oracle, 0) Err#2 ENOENT -Original Message- From: Brian McGraw [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 29, 2003 1:24 PM To: Multiple recipients of list ORACLE-L Subject: RE: Rogue TNSNAMES.ORA files Revisited Thanks, John. Just out of curiousity - for those of us who aren't Unix experts - what options did you use for truss to obtain that info.?? Brian -Original Message- Kanagaraj Sent: Wednesday, January 29, 2003 2:14 PM To: Multiple recipients of list ORACLE-L Brian, The order in which the TNS connection searches are performed can also easily be determined by using the 'truss' command on Solaris. I used this to prove my case to a PHB of a smart-aleck Developer who was side-stepping our move to an Oracle Name Service in a prior assignment. I see what you mean - been there done that! Take care bro! John Kanagaraj Oracle Applications DBA DBSoft Inc (W): 408-970-7002 I don't know what the future holds for me, but I do know who holds my future! ** The opinions and statements above are entirely my own and not those of my employer or clients ** -Original Message- Sent: Wednesday, January 29, 2003 10:14 AM To: Multiple recipients of list ORACLE-L A few days (or was that weeks??) ago, someone posted some problems they were having connecting to a database defined in their tnsnames.ora file. The problem was resolved when they found out that there was a 'rogue' tnsnames.ora file residing in the same directory as the binary. The binary file was resolving a database's address by using the local tnsnames.ora first. I recently had a similar issue (a long story, available on http://www.clanmcgraw.com/oracle.html for those interested) where sqlplus was resolving a database address by using a tnsnames.ora file stored in /var/opt/oracle (on Solaris 8). I thought that was because I did not have the TNS_ADMIN environment variable set properly by the oraenv file. I did some research on Metalink, and under Note 114085.1, found the following information that others might find useful: Windows NT/2000 running Oracle 9i First: The directory where the application is launched. For example, if sqlplus resides in ORACLE_HOME\bin\sqlplus but was launched from the c:\temp directory, then c:\temp is searched for a tnsnames.ora file. Second: The value of the TNS_ADMIN environment variable. Third: ORACLE_HOME\network\admin Sun Solaris running Oracle 8i or 9i First: The oracle user's home directory is searched for a hidden '.tnsnames.ora' Second: The value of the TNS_ADMIN environment variable. Third: /var/opt/oracle Fourth: $ORACLE_HOME/network/admin Some were talking about an April Fool's joke with local tnsnames.ora files. I think you'd have a lot more fun with the .tnsnames.ora file, if you're on Solaris. J Hope that information is useful to someone out there... Brian -- | Brian McGraw /* DBA */ Infinity Insurance | | mailto:[EMAIL PROTECTED] | -- -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author
