Home > Oracle, RDBMS > Resolving Oracle networking problems – ORA-12514.

Resolving Oracle networking problems – ORA-12514.

The original version of the below article was created by Ed Stevens and could be find here.
In previous posts I have explored various reasons why a client process might not be able to connect to an Oracle database. In “Resolving Oracle networking problems – general introduction” I presented an overview of the process used by sqlnet to convert a connection request to a network connection descriptor and deliver that request to a listener capable of servicing the request. I followed that with two posts going into more depth on the types of problems that can prevent the request from reaching the host server. Now I would like to look at the next possible problem in the sequence, in particular the “ORA-12514: TNS:listener does not currently know of service requested in connect descriptor”.
For this demonstration I will generate the error then go through the standard analysis and solution. After that, I will explore some of the interesting factors that flow from this.

The ORA-12514 error.
The vast majority of the time, this error results from an incorrectly specified connect descriptor in the tnsnames.ora file. Let’s look at a very typical example then diagnose and fix it. After that we will dig in to how the listener comes to know of a service name.

Of course the very first thing anyone should do when confronted with an Oracle error is to check the official description. There are many sources on the web, but I like to start with ‘oerr’ utility on the server:

[oracle@orclsvr ~]$ oerr ora 12514
12514, 00000, "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.

The error is pretty self-explanatory: “listener does not currently know of service requested in connect descriptor”. So how do we know exactly what service was “requested in connect descriptor”? First, do a sanity check by looking at the tnsnames.ora file.

# tnsnames.ora Network Configuration File: c:\oracle\11.2.0\CLIENT\network\admin\tnsnames.ora
# Generated by Oracle configuration tools.
myorcl =
(ADDRESS = (PROTOCOL = TCP)(HOST = orclsvr)(PORT = 1521))

In line 8 we see that we should be requesting SERVICE_NAME = orcl. In our discussion of ORA-12154 I described how we might not be using the tnsnames.ora we thought we were. At this point we know what SERVICE_NAME we should be using. We can use tnsping to confirm this.

In the above screen we can see that we are requesting a connection to service ‘orcl’. Don’t be fooled by the good return code. As we saw in “Resolving Oracle networking problems – TNSPING: what it is, what it isn’t“, tnsping only goes as far as confirming there is a listener at the specified IP address and port. It says nothing about any services the listener knows about. The presence of SERVCICE_NAME in the feedback is simply the result of showing the entire connect descriptor.
Now that we know what service name was actually requested, we need to check what the listener knows about. Examining the listener configuration file, listener.ora, could give some clues but it is not the whole story. In fact, the listener can be started without any listener.ora file at all. The only sure way to tell what the listener knows about is to ask it directly, with the lsnrctl command:

This listener knows about two service names (orclnew, orclnewXDB), all associated with the instance ‘orclnew’. The XDB service is for special use – we can ignore it for general connection problems. The vast majority of the time, that’s all the debugging we need to do. We know that we should be requesting a connection to service ‘orclnew’ instead of ‘orcl’. Since that request comes from the client, we have to fix tnsnames.ora:

# tnsnames.ora Network Configuration File: c:\oracle\11.2.0\CLIENT\network\admin\tnsnames.ora
# Generated by Oracle configuration tools.
myorcl =
(ADDRESS = (PROTOCOL = TCP)(HOST = orclsvr)(PORT = 1521))
(SERVICE_NAME = orclnew)

and make another test:

We have made the necessary correction in tnsnames.ora. The subsequent connection request is successful, thus validating our analysis and corrective action.

Registering the service with the listener.
So how did the listener come to know about service ‘orclnew’ in the first place? There are two methods by which a service is registered with the listener – ‘static’ and ‘dynamic’. We’ll discuss each in turn:
Static registration.
Static registration is accomplished by configuring the SID_LIST section of the listener.ora file (on the server side).

# listener.ora Network Configuration File: c:\oracle\11.2.0\DATABASE\network\admin\listener.ora
    (SID_DESC =
      (SID_NAME = PLSExtProc)
      (ORACLE_HOME = c:\oracle\11.2.0\DATABASE)
      (PROGRAM = extproc)
    (SID_DESC =
      (GLOBAL_DBNAME = test)
      (ORACLE_HOME = c:\oracle\11.2.0\DATABASE)
      (SID_NAME = test)
    (SID_DESC =
      (ORACLE_HOME = c:\oracle\11.2.0\DATABASE)
      (SID_NAME = orclnew)

      (ADDRESS = (PROTOCOL = TCP)(HOST = orclsvr)(PORT = 1521))

We can see three SIDs listed: PLSExtProc, test and orclnew – checking the status of the listener, we get:

Notice the entry for service “test” maps back to “(GLOBAL_DBNAME=test)” and is related to instance “test”. Further, notice that its status is UNKNOWN. This status of UNKNOWN is the indication that this registration came from the SID_LIST section of listener.ora. It is unknown because the listener doesn’t make a check to see if there is an instance named “test” broadcasting a service name of “test”. The listener is just saying “if you ask for a connection to ‘test’, I’ll see what I can do to service it”. In fact, I have no database named “test”.
Notice also that service “orclnew” has two instances, one unknown, and one READY. Like “test”, the UNKNOWN “orclnew” comes from listener.ora, the READY instance comes from the database having registered with the listener (dynamic registration).
Again, for our current discussion, we can ignore the service orclnewXDB – it has special internal uses for Oracle.
For the remainder of the discussion, I am going to completely remove listener.ora, then restart the listener so that it has no static registrations and is running with all default values:

With no static registration the listener will start with all default values and support no services until a PMON process registers itself.

Dynamic registration.
Dynamic registration is accomplished when the PMON process of the database instance contacts the listener and requests registration. This occurs at instance startup, and every few minutes during the life of the instance.

There are three initialization parameters that affect what service name(s) PMON will register with the listener:

You should look up each one in the Reference Manual and read the descriptions, notice particularly in the description of SERVICE_NAMES the following:
If you do not qualify the names in this parameter with a domain, Oracle qualifies them with the value of the DB_DOMAIN parameter. If DB_DOMAIN is not specified, then no domain will be applied to the non-qualified SERVICE_NAMES values.
There is another interaction that is not spelled out in the Reference Manual, but mentioned in the Net Services Administrator’s Guide:
The service name defaults to the global database name, a name comprising the database name (DB_NAME parameter) and domain name (DB_DOMAIN parameter).
The normal practice might be to make the SERVICE_NAMES parameter the same as the DB_NAME.
All service names – those derived from DB_NAME as well as the one derived from SERVICE_NAMES – will have the value of DB_DOMAIN appended to them (if we have the fully qualified service name in the SERVICE_NAMES initialization parameter, the value of DB_DOMAIN will not apply).

We have explored the relationship between the connect descriptor issued by the client and the services supported by the listener, as well as the factors that control what services the listener supports. In the concluding post in this series, I will discuss how the database locates the listener in order to register its services – the LOCAL_LISTENER initialization parameter.

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: