Windows 7.
I kept getting Ora err can not resolve tns name while I have all the verified good names resides in tnsnames.ora. There are more than one Oracle in my PATH, maybe that's the reason. So I used tnsping to find out.
tnsping myserver
here is the output:
Used parameter files:
C:\oracle64\product\12.1.0.2\client_1\network\admin\sqlnet.ora
TNS-03505: Failed to resolve name
the tnsnames.ora is in the same folder as sqlnet.ora, why tnsping is not using it?
Because, maybe, you haven't set the TNS_ADMIN env. variable, so tnsnames.ora file cannot be found. Not only with TnsPing but with everythin else, setting this variable pointing to the folder is the only way to consistently use the same tnsnames file.
It actually might have used your tnsnames file. tnsping only prints a message like
Used TNSNAMES adapter to resolve the alias
when it finds a match using tnsnames.
You might look at setting some of the diagnostic parameters in sqlnet.ora to trace the issue in more detail.
Related
I facing login issue with sqlplus login. when I m logging in using hostname, port and service name, its working fine.
sqlplus <userid>/<password>#<hostname>:<port>/<servicename>
No issues with above command. Its working as expected.
When I m trying to login with connect string,
sqplus <userid>/<password>#<connectstring>
I m getting
ORA-12154: TNS:could not resolve the connect identifier specified
I know my sqlnet.ora and tnsnames.ora are not correct, but not able to figure out where the issue is.
sqlnet.ora
SQLNET.AUTHENTICATION_SERVICES = (NTS)
NAMES.DEFAULT_DOMAIN = world
Just above two line are there in the file.
tnsnames.ora
MYTNSENTRY=
(DESCRIPTION =
....
hostname, port and service name defined in tnsnames.ora, just one entry is there.
I m executing sqlplus commands on windows platform.
Any pointers regarding this is much appreciated.
You have in your sqlnet.ora this line:
NAMES.DEFAULT_DOMAIN = world
That means '.world' is going to be appended to your connect string before looking it up in tnsnames. Either remove that line from sqlnet.ora, or append '.world' to the entry name in tnsnames.ora
mytnsentry.world =
(description...)
Agree with what #EdStevens said, and also remove the SQLNET.AUTHENTICATION_SERVICES line from sqlnet.ora. That setting is intended to help authenticate users with Windows native security (like OS authentication), but if you're not using that then it can often create problems.
Good Morning. I tell you my connection problem with pl / sql Developer.
First, I will indicate my environment:
-SO Windows10 64 bits.
-PLSQL Developer 13 (64 bit)
-Client Oracle 12-64bits.
Now I put the screenshots of my settings.
But finally the connection error message returns
Cause of this issue would be you tried to connect to Oracle, but the service name is either missing from the TNSNAMES.ORA file or is incorrectly defined.
You can try below options:
Make sure that the TNSNAMES.ORA file exists and is in the correct directory.
Make sure that the service name that you are connecting to is included in the TNSNAMES.ORA file and that it is correctly defined.
Make sure that there are no syntax errors in the TNSNAMES.ORA file. For example, if there are unmatched parentheses in the file (ie: open bracket without the corresponding close bracket), the file will be rendered unusable.
Check if tnsping works. Open command window type tnsping SERVICE_NAME. Here SERVICE_NAME is the oracle database you want to connect to and it must already exist in tnsnames.ora file where your client product is installed.
If tnsping works and still PL/SQL Developer complains about ORA-12154 then check where PL/SQL Developer program is installed. If it is located in an address which contains brackets this is the problem. So uninstall and reinstall it in a location where location address doesn't contain brackets.
set Environment Variables: ORACLE_BASE, ORACLE_HOME, ORACLE_SID
I hope this works with the above options
I get a error while trying to connect using TOAD:
ora 12154 tns could not resolve the connect identifier specified(myDBname)
You might be mis-naming the server...
If you are using local naming (TNSNAMES.ORA file):
Make sure that "TNSNAMES" is listed as one of the values of the NAMES.DIRECTORY_PATH parameter in the Oracle Net profile (SQLNET.ORA)
Verify that a TNSNAMES.ORA file exists and is in the proper directory and is accessible.
Check that the net service name used as the connect identifier exists in the TNSNAMES.ORA file.
Make sure there are no syntax errors anywhere in the TNSNAMES.ORA file. Look for unmatched parentheses or stray characters. Errors in a TNSNAMES.ORA file may make it unusable.
Try using the IP(rather then the name) of the Oracle serverin tnsnames.ora, and check you have permissions. Can you ping the server?
Here are the details:
I installed the oracle instant client 11.2.0.2.0 from the OTN download page on a windows 7 64 bit vm (vmware).
I am trying to to connect to a remote oracle database, and I can successfully connect with one program using TNS, but not with SQL*Plus and other applications.
Trying to connect with SQL*Plus, using schema#servicename, password, etc, gives the above error.
To connect via SQL Developer, normally I would use the basic connection info and not rely on tnsnames, but trying a normal connection gives me: io error: unknown host specified. SQL Developer can successfully connect and query database if i use the TNS protocol.
Trying from other programs gives me the same error I got with SQL*Plus. Same when trying with the service name from tnsnames.
This is obviously quite frustrating for it to work one way and not the other. I followed all the normal instructions for using the instant client, the directory with instantclient has been addded to the PATH, a TNS_ADMIN entry has also been created, with the directory to the tnsnames.ora file
Well, on a whim, I went to changing everything in my setup to match an windows 2003 server that i had setup with instant client before. The main changes were putting the instant client in a folder at the root of the drive (not program files/oracle/etc), but c:/oracle, i know ive seen other posts saying that oracle was particular about characters in the directory path, maybe spaces are a no-no too?
I also add a bunch more environmental variables, anythign that was on the other machine, ORACLE_HOME (to root of instance), SQL_PATH (same), and added the root of the directory to the PATH system variable, not just the folder with the instantclient files. Anyways, I'm happy its working, anyone one of these changes could have been it though-
You may use ProcessMonitor and look at what your sqlplus process is doing. In my case TNS_ADMIN was correctly defined but, by mistake, my tnsnames.ora and sqlnet.ora had a stupid ".txt" extension, added by default by notepad when I created those files. And because "Windows Explorer" has the "Hide extensions for known file types" option set by default, the naming error wasn't obvious at all.
I installed the 12.1 instant client. For me, the problem was solved by creating \network\admin\tnsnames.ora file. Here's the PowerShell I used:
$source = "C:\Users\USER1\Desktop\tnsnames.ora"
$target = "C:\oracle\product\12.1.0\client_1\network\admin"
mkdir $target
copy-item $source $target
I'm trying to use cygwin sqlplus to connect to a remote oracle installation located at myserver.mycompany.com port 1530. When I try
sqlplus username#myserver.mycompany.com:1530/orcl
I get the error:
ORA-12154: TNS:could not resolve the connect identifier specified
When I set ORACLE_HOME to /cygdrive/c/oracle/product/10.2.0/client_1, I get a different error:
Error 6 initializing SQL*Plus
Message file sp1<lang>.msb not found
SP2-0750: You may need to set ORACLE_HOME to your Oracle software directory
I can telnet to the server's port 1530, and the SQL Developer installed locally is also able to connect to the database. What am I doing wrong?
I wasn't aware there was a native cygwin client for Oracle (correct me if I'm wrong here but I can't find any mention of it on Oracle's web site either). If you're using Cygwin with the Windows client you need to use a native windows path. It won't understand your /cygdrive path.
However, I have used Win32 Oracle clients with cygwin and made it work - the same shell scripts would work on Cygwin, Linux and Solaris.
There isn't a cygwin Oracle client. As above answer, use the ORACLE_HOME set to the windows path.
For the first half of your question, try seeing what the TNS_NAMES env variable is set to, and if not set, you may need to try setting it to the correct place. Usually it defaults to %ORACLE_HOME%/network/admin/tnsnames.ora . SQL Developer keeps it's own copy of the tnsnames file, so you can't reply upon that to fix the problem.
Combining the details from the other answers (which took me a little, so I post it as separate answer instead of comments):
The $ORACLE_SID and, if set, $TNS_ADMIN (and probably other path-related Oracle variables) must use Windows-paths. Your Cygwin $PATH variable should of course use the Cygwin notation (/drives/c/…). So I've included into my .bashrc:
export ORACLE_HOME=c:\\Oracle\\product\\12.1.0\\dbhome_1
export TNS_ADMIN=d:\\Oracle\TNSAdmin
export PATH=$PATH:$(cygpath -u $ORACLE_HOME)/BIN
After that, I had no more issues calling e.g. tnsping or sqlplus. As the above is just an example, you must of course adjust the paths to reflect your installation/configuration :)
NXC is right - it wasn't a cygwin client I was using, but the windows sqlplus client.
I set the windows environment variables for ORACLE_HOME and ORACLE_SID and was then able to run sqlplus in a cygwin bash shell using the net_service_name from tnsnames.ora.
The way it worked for me was to remove /cygdrive/d or /cygdrive/c and replace them with with d:/ or c:/ and then your sqlplus call within cygwin session will work. The /cygdrive/DriveLetter is confusing it.
I have same error like you,
you should set not only ORACLE_HOME in windows Variables,
But also PATH include %ORACLE_HOME%\bin
then you can open windows cmd,
try sqlplus username/password#your_define_tnsname
if okay, then remove all ORACLE PATH setting in cygwin, restart cygwin,try it.
if failure, should let sqlplus works well in windows cmd at first
I have TNS_ADMIN variable configured and it works properly in Win Environ
I used cygpath mnodification in .bashrc
If TNS_ADMIN is configured add following row to .bashrc
export TNS_ADMIN=$(cygpath -m $TNS_ADMIN)