We are suddenly getting the error ORA-12514, TNS:listener does not currently know of service requested in connect descriptor in our application.
Googling this seems to suggest a couple of easy solutions (e.g. found here), but they don't work for us.
The perplexing thing is:
We can connect via SSH to the server running our application, and..
we can connect with SQLPlus on that server, ..
using the exact same JDBC connection parameters as the app (we can get them from a log during application startup, so we are sure they are the same).
Why could it be that we can connect to the DB with SQLPlus, but our app cannot?
Here are the two methods to connect (JDBC and SQLPlus), both consistently anonymised:
JDBC
{
jdbcDriver=oracle.jdbc.OracleDriver,
jdbcUser=THE_USER,
jdbcPassword=THE_PASSWORD,
configurationVersion=1.0.14,
jdbcURL=jdbc:oracle:thin:#(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(Host=THE_HOST)(Port=THE_PORT))(CONNECT_DATA=(SERVICE_NAME=THE_SERVICE_NAME)))
}
SQLPlus
sqlplus THE_USER/'THE_PASSWORD#'"(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(Host=THE_HOST)(Port=THE_PORT))(CONNECT_DATA=(SERVICE_NAME=THE_SERVICE_NAME)))"
According to our DB specialist there were "wrong entries in Oracle Internet Directory (OID)".
They cleaned it up and now it ist working again. Sorry that this is not very helpful as an answer, but I don't know more details...
Related
We have an Oracle server set up and are using TCP with SSL as connection. This setup was made with the assistant wizard and we used the default settings pretty much everywhere (which also means that no tnsnames.ora or listener.ora exist). lsnrctl status shows that the correct ports are listening.
We are trying to connect to this database via DBeaver and SQuirrel SQL but cannot get it to work. We have set the vmargs for the programs to contain the certificate of the server (e.g. dbeaver.exe -vmargs -Djavax.net.ssl.trustStore=C:/...keystore.jks -Djavax.net.ssl.trustStorePassword=password -Djavax.net.ssl.trustStoreType=JKS), which works fine.
Connecting to the database with a concrete JDBC URL string (jdbc:oracle:thin:#(DESCRIPTION=(ADDRESS=(PROTOCOL=TCPS)(HOST=IP)(PORT=5500))(CONNECT_DATA=(SERVICE_NAME=testdb)))) does not work and times out after 60 seconds without a proper error (IO Error: Got minus one from a read call). We have tried pretty much everything and cannot get it to work.
The ports are correctly assigned, the database can successfully get accessed with the normal TCP protocol and port 1521.jdbc:oracle:thin:#(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=IP)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=testdb)))
Are we missing steps? There don't seem to be any firewall issues. The certificates seem to be working fine as well, but we cannot connect with any of the programs (or sqlplus via command line).
Anyone know what could be the problem? Thanks!
Can you check out the SSL blog or our OTN page for step-by-step instructions? If you are using TLSv1.2 then the JDK version and JDBC driver versions are very important.
In the end I got it to work. There are various sites online that show you how it's done. I used this one:
https://database.edorex.ch/blog/database-connection-with-a-certificate/
Getting the wallets set up, certificates set up and the user set up in the database were the most important steps. Additionally, I had to separate the server and client machines. The server is now on a VM and it works that way, I couldn't get it to work having both on the same machine.
I installed Oracle11g XE for windows32.
First time when I try to connect via SQL developer it gets connected effortlessly. But once I close the SQL Developer and restart it, then again I am unable to connect to the DB.
Then I tried to connect with SQL plus and guess what it gets connected!
But through SQL devloper I receive an error message as follows:
ORA-12505, TNS:listener does not currently know of SID given in connect descriptor.
I have checked all the credentials thoroughly. Still am unable to find the error. Please Help.
When you are using sql plus you use the tnsnames.ora file to find your connection. You can do the same in sql developer.
Just click the listbox connection type and choose TNS instead of basic
then for network alias you should be able to choose a connection from your tnsnames.ora
I'm new to working with AWS and RDS. What I'm trying to do is setup an Oracle DB instance on RDS, that part is fine but when I try to connect to it via an application I get various errors. Depending on the application I get a couple of different errors.
[Local computer trying to connect to RDS directly]
LinqPad - Connection Error: Server did not respon within the specified timeout interval. (I get this on both the Direct and OCI connection modes)
SQL Developer - IO Error: The network adapter could not establish the connection.
[EC2 instance in same VPC]
LinqPad - Connection Error: NET: Connection was refused with error ORA-12504
(I get this on both the Direct and OCI connection modes also)
I've done some research and it mostly points that the VPC isn't setup correctly, but I'm able to connect to my EC2 instance fine though.
Oddly enough, I did have one fluke incident where from my local computer it did connect, but as soon as I tried the test again I got more errors.
Any help, or new directions to look would be greatly appreciated.
Will provide more information if needed also. Wasn't sure what to post settings wise. Thanks in advance.
I use the command prompt to connect my Oracle database. All functions work, but when I try to use my Navicat to connect to the database, it shows the following error message:
ORA-12514:TNS:listener does not currently know of service requested in
connect descriptor.
My general settings for Navicat are:
host type:basic
ip address:127.0.0.1(also try my ip, but still have same problem)
port:1521
service name:orcl
By "all functions work", I assume you mean you are able to connect to the database and query.
Can you show us the connect that you use.
If you are using sqlplus in this fashion,
sqlplus userid/password#database1
it means your current client is pointing to the correct tnsnames.ora. May be navicat does not point to the correct tnsnames.ora file? The error indicates that you want to connect to, say database1, and Oracle is not able to map "database1" to the correct server, host and port number.
Have you gone through the connectiond details here?
http://www.navicat.com/en/products/navicat_oracle/oracle_detail_win.html
What is your operating system version and oracle version?
I'm having problems accessing an Oracle database via ODBC in Access and hope someone has some advice. I've spent a fair time trying to find a solution, but nothing useful has come up.
I have a connection setup in ODBC that access an Oracle 9 database. I can use the Test option on ODBC administrator and receive a Test Successful message. I can also connect to the DB using SQL*PLUS. However, when I try to create a new linked table in Access 2007 and use the ODBC option, I get the following error when it tries to connect:
ODBC--Call failed.
[Oracle][ODBC][Ora]ORA-12154: TNS:could not resolve service name
(#12154)[Microsoft][ODBC Driver Manager]Driver's SQLSetConnectAttr failed IM006 0 [Microsoft][ODBC Driver Manager]Driver's SQLSetConnectAttr failed (#0)
I know the TNS lookup is working because ODBC Admin tool works as does tnsping. The question is, why does it work outside Access but Access can't do it?
EDIT (2012-02-22 15:05): Just tried on a different PC and the same thing occurs, although another user logged in and the connection worked for them, so it appears to be linked to my WinXP profile. Does this help any?
Any advice would be greatly appreciated.
BBz
I think I've resolved the issue, but it took some digging. Using Process Monitor from Sysinternals, I discovered that Access had found a sqlnet.ora file in the "My Documents" folder of my profile and was using this in preference to the global tnsnames.ora file.
We had previously disabled sqlnet.ora (renamed the file in the Oracle folder) but Access obvisouly checks other locations for it. I've renamed the file and can now access the DB as expected via ODBC.
Interesting what you can learn!
Hope somebody finds this useful one day.
Thanks for reading
BBz