TNS-12514 on Windows

Expert Oracle Tips by Burleson Consulting

March 30, 2011

Question: My database was running fine and all of a sudden I am getting the TNS12514 error:
TNS-12514: TNS:listener does not currently know of service requested in connect
descriptor
I am running on Windows.
I now get the TNS-12514 constantly, and I did not change my listener.ora or
tnsnames.ora files.
Is this TNS-12514 error a Windows problem?
Answer: Your ROOT CAUSE is that you are running on Windows!
BEWARE: Windows IS NOT robust enough for any mission critical system, especially
with the Windows virus issues and weekly patches.
My Windows systems crash at a rate at LEAST 4 times more often than Linux/UNIX.
To diagnose the TNS-12514 error, see these diagnostics for the TNS-12514 error.
Diagnosing the TNS-12514 in Windows
In Windows when, for unknown reasons, Oracle is refusing connections, I have seen
Windows TNS-12514 problems with any of these issues:

A Windows screen saver causes CPU hogging that makes connections get
refused
Somebody installed a Windows virus scanner
A weekly Windows patch application has caused a problem
Never apply a Windows patch unless it is to address a known Oracle problem
You have a Windows virus. For example, the Nimbda virus can cause a TNS12514.

FIRST THING, I would bounce ALL of your Windows services (or just bounce the
whole PC Windows server):
Then, verify that all of your Windows services are running properly.
If you continue to get the TNS-12514 error, follow these Oracle TNS networking

diagnostic steps
The oerr utility shows this for the ORA-12514 and TNS-12514 error:
ORA-12514: TNS:listener does not currently know of service requested in connect
descriptor
Cause: The listener received a request to establish a connection to a database or other
service. The connect descriptor received by the listener specified a service name for a
service (usually a database service) that either has not yet dynamically registered with
the listener or has not been statically configured for the listener. This may be a
temporary condition such as after the listener has started, but before the database
instance has registered with the listener.
Action:

Wait a moment and try to connect a second time.

Check which services are currently known by the listener by executing: lsnrctl
services
Check that the SERVICE_NAME parameter in the connect descriptor of the net
service name used specifies a service known by the listener.
If an easy connect naming connect identifier was used, check that the service
name specified is a service known by the listener.
Check for an event in the listener.log file.

Burleson Forum user and Oracle expert, Dave, notes:

It appears in a TNS-12514 error that your database isn't registering itself with the
listener.
Issue an alter system register xxx and lsnrctl status from SQL*Plus and see if the
listener knows about your database
Then issue a show parameter local_listener to show what the database thinks about the
listener status.
Failing that, place a static entry in the listener.ora for the database service name and the
TNS-12514 may be fixed.

Check & verify Oracle windows services

Oracle Tips by Burleson Consulting

Question: How do I verify that my Oracle Windows services are running? I want to
monitor and verify that the Windows services are always available?
Answer: In Oracle Windows you can check for the Oracle services with these
commands, and you can encapsulate the services monitoring with a "check script".

The Windows Oracle database must attach itself to a running Windows process, and it is
the Windows Service that provides this process. Most DBAs think that the Windows
service is the Oracle database but that is not true. The Windows service can start/stop
the Oracle database, but it can also be started without starting the database.
Most Problem with the Windows Service for the Oracle database involve the
service starting but the database not starting.
If the Windows service is set to automatically start when the server boots but the Oracle
database does not start, you may have a improper registry setting or you may have a bad
service.
1. Check Task Manager for the ORACLE.EXE process. If it is present, then the
service started.
2. Check the Alert Log for the database. If the problem is not with the database, there
will be no indication in the log that the database even tried to start.
3. Check the oradim.log in the $ORACLE_HOME/database directory for errors.
Check the date on the log file as versions before 9i did not date/time stamp the entries.
If there are no errors in the logs then try and start the Oracle database.
C:> sqlplus "/ as sysdba"
connected to an idle instance
SQL> starup

If the Oracle database starts great, the problem is in the service.

To check the Windows service:
Open the registry with regedit. Always back up the registry before making changes.
Navigate to the key entry in the Windows registry:
HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\oracle_home_name.

There will be a key called:

ORA_SID_AUTOSTART. SID is your database SID.
This key should be set to TRUE. If not the server starts but does not start the database.
There is also an ORA_SID_SHUTDOWN which you want to be TRUE so that if the
server is shut down the service will shutdown the database.
If you want to manually start the database set ORA_SID_AUTOSTART to FALSE. The
Windows service will start but not the Oracle database.
Test the Windows Oracle service.
If the ORA_SID_AUTOSTART setting was the problem, change it to TRUE and then
test the service by stopping and then restarting the service to see it the database
automatically starts. If it does, then that fixed your problem......or maybe it didn't.
Reboot the Windows server to verify that the database will start automatically.
Sometimes the service will work, only to fail again after a reboot. If the Windows
service fails after rebooting you will need to recreate it. This is where the oradim utility
is useful.

roubleshooting & diagnosing TNS SQL*Net connectivity errors

Oracle Tips by Burleson Consulting

There are a variety of common network connectivity error messages, and most DBA's
have seen TNS error messages these at sometime in their careers. Here is just a small
sample of possible TNS network connectivity-related errors:

TNS-12545: Connect failed because target host or object does not exist
ORA-12154: TNS: Could not resolve service name
ORA-12157: TNS Internal network communication error

In the simplest of terms, the Oracle*Net architecture is like peeling on onion, with one
transport layers nested inside the inner payer. The lowest level of Oracle transport is
TCP/IP (or rarely other protocols), where the packets are shipped between the servers.

Steps to troubleshoot Oracle

connectivity:
Also see my notes on Oracle network tuning.
To troubleshoot & diagnose Oracle connectivity problems, I like to start at the simplest,
outermost level, and follow this checklist:
1.
2.
3.
4.
5.

Check with "ping" using the IP address ("ping 198.11.34.43")

Check with "ping" using DNS name (e.g. "tnsping uranus")
Try telnet to the IP on port 1521 (telnet 1.2.3.4 1521)
Check with "tnsping" using TNS service name
Invoke SQL*Plus from the OS command line "sqlplus fred@flintstone". If this
fails, check to ensure that your listener has the flintstone service defined.
6. Sign-on to SQL*Plus and connect with the TNS name ("connect
fred/flintstome@service_name")
7. Within SQL*Plus, try a select from table@remote_db_link
Let's look closer as we peel away the layers of our onion.
Server-level connectivity layer in TNS
When the Oracle DBA creates their tnsnames.ora file to define remote databases they
often specify the host name of the foreign server that contains the remote Oracle
database. For example, a entry in the tnsnames.ora file for a remote database might
look like this:
berlin =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS =
(COMMUNITY = TCP)
(PROTOCOL = TCP)
(HOST = hum)
(PORT = 1521)
)
)
(CONNECT_DATA = (SID = kraus))
)

Here we see a TNS service name of berlin, which defines a connection to a remote
server named hum that contains an Oracle database named kraus. When a remote
connection request is made from the UNIX server, the /etc/host file is accessed to get
the IP address for the hum server.
From the listing below, we see that the hum server is located at 192.133.13.12. In sum,
the /etc/host file is used to isolate the IP address from the tnsnames.ora file. If the IP
address should ever change, the UNIX systems administrator only needs to change the
IP address in one place.

root> cat /etc/hosts

192.133.13.22 hum
192.144.13.22 dopey

hum.com
dopey.com