Ora 12541 tns no listener что это
In Oracle, a listener is a process that runs on the database server computer. It manages the traffic of incoming connect requests from clients to the database server, and therefore, is very important. Each time a client requests a network session with a server, it is the listener that receives this client request. The listener will check to see that the client information matches the listener information, and thereby grant (or deny) the request. To learn more about listeners, click here.
Generally, the listener.ora file can be found in $ORACLE_HOME/network/admin or ORACLE_BASEORACLE_HOMEnetworkadmin on Unix and Windows platforms respectively.
When there is any problem with the listener, the user will likely run into ORA-12541.
The Problem
The ORA-12541 message reads, “TNS no listener.” This happens if the listener is either down as it attempts to make a connection or if it has not been started or improperly configured. In addition, it may be caused by a connectivity problem with the network.
To figure out what may be causing the problem, follow the solution steps outlined below.
The Solution
First, make sure that the listener is up and running. To do this, go to the Control Panel into Services under NT or listener control program (LSNRCTL).
C:Documents and SettingsME>lsnrctl stat
This should show the current status of the listener. If the listener is currently not running, re-start the listener service by running the “net start” command by filling in “XX” with the version being used:
C:Documents and SettingsME>net start OracleOraDbXXg_home1TNSListener
If the listener is up and running, the problem may lie with the listener not having been associated with the correct instance or protocol. To make sure all instances are correct, you can obtain basic information about the listener and the configuration settings by simple commands, such as the STATUS command. The status command will give basic information about the listener as well as the configured protocol addresses, summary of the services registered, and the service handlers allocated to each service. There are 4 types of status: ready, blocked, ready/secondary, and unknown. Below are descriptions of each status signals.
- Ready: Instance can accept connections
- Blocked: Instance cannot accept connections
- READY/SECONDARY: A secondary instance in an Oracle9i Real Application Clusters primary/secondary configuration that is ready to accept connections
- UNKNOWN: Status unknown because instance registered statically in the listener.ora file rather than dynamically with service registration
Below is a partial example by Oracle of the STATUS command:
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=net))) STATUS of the LISTENER ———————— Alias LISTENER Version
TNSLSNR for Solaris: Version 9.2.0.2.0 – Development Start Date…
Services Summary… Service “sales.us.acme.com” has 1 instance(s). Instance “sales”, status READY, has 3 handler(s) for this service… Service “hr.us.acme.com” has 1 instance(s). Instance “hr”, status READY, has 2 handler(s) for this service… The command completed successfully
If you are still unable to get the listener up and running, you may want to delete the listener and create a new one in the network configuration assistant.
The last possible cause may be a network problem. Check to see that there is a proper network connection if you find that the listener has been configured and is running correctly.
Looking Forward
Following proper configuration steps is key to successfully establishing a connection with the listener. For more information, review the Oracle documentation on “configuring and administering the listener” here.
To avoid future problems with the listener, Oracle users should actively monitor and ensure security. One of the first and easiest ways to protect the listener is to encrypt it with a password to ensure that only authorized users can view and change settings.
In addition to security, it is always a good idea to consistently monitor and review the listener log file for any of the following conditions, which can cause problems with the listener:
- Irregular connection establishment times
- Connectivity problems and refusals
- Unexpected shutdown of listener which can lead to a DOS attack
If you continue to have trouble with ORA-12541 or any other listener problems, contact your system DBA or a licensed Oracle consultant for professional help.
How to Resolve ORA-12541: TNS:no listener
ORA-12541 is the same as TNS-12541, they all indicate that the listener is not running according to your specified destination.
Let’s see how we reproduce ORA-12541 and TNS-12541.
SQL*Plus throws ORA-12541
TNSPING throws TNS-12541
TNS Ping Utility for 64-bit Windows: Version 12.1.0.1.0 — Production on 22-JUL-2014 19:20:06
Copyright (c) 1997, 2013, Oracle. All rights reserved.
Used parameter files:
C:\oracle\app\client\ed\product\12.1.0\client_1\network\admin\sqlnet.ora
Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = primary01)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = compdb)))
TNS-12541: TNS:no listener
Cause
The connection cannot find the listener, it could be:
-
The listener is not started.
This is the most common problem of ORA-12541 we have met. Just start it up and make sure it’s running.
Backup port like 1522 may be used by the listener for connection, you should ask for DBA to handle it.
Please check every parameter in your connect descriptor and make sure they are correct.
It’s rare, but it did happen in a very complex network environment. Part of connections are routed by some network device to an unknown server where no listener on port 1521.
Solution
Check the status and port of LISTENER on server side and start it if necessary.
LSNRCTL for Linux: Version 12.1.0.1.0 — Production on 22-JUL-2014 19:22:34
Copyright (c) 1991, 2013, Oracle. All rights reserved.
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1521)))
TNS-12541: TNS:no listener
TNS-12560: TNS:protocol adapter error
TNS-00511: No listener
Linux Error: 2: No such file or directory
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=primary01)(PORT=1521)))
TNS-12541: TNS:no listener
TNS-12560: TNS:protocol adapter error
TNS-00511: No listener
Linux Error: 111: Connection refused
As you can see, the database port is 1521 without questions. But the listener is not started. So let’s start it up.
LSNRCTL for Linux: Version 12.1.0.1.0 — Production on 22-JUL-2014 19:23:59
Copyright (c) 1991, 2013, Oracle. All rights reserved.
Starting /u01/app/oracle/product/12.1.0/dbhome_1/bin/tnslsnr: please wait.
TNSLSNR for Linux: Version 12.1.0.1.0 — Production
System parameter file is /u01/app/oracle/product/12.1.0/dbhome_1/network/admin/listener.ora
Log messages written to /u01/app/oracle/diag/tnslsnr/primary01/listener/alert/log.xml
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=primary01)(PORT=1521)))
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1521)))
STATUS of the LISTENER
————————
Alias LISTENER
Version TNSLSNR for Linux: Version 12.1.0.1.0 — Production
Start Date 22-JUL-2014 19:23:59
Uptime 0 days 0 hr. 0 min. 2 sec
Trace Level off
Security ON: Local OS Authentication
SNMP OFF
Listener Parameter File /u01/app/oracle/product/12.1.0/dbhome_1/network/admin/listener.ora
Listener Log File /u01/app/oracle/diag/tnslsnr/primary01/listener/alert/log.xml
Listening Endpoints Summary.
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=primary01)(PORT=1521)))
The listener supports no services
The command completed successfully
8 thoughts on “How to Resolve ORA-12541: TNS:no listener”
Used three of your posts related to listener and TNS setup, they did the trick, all of my issues are resolved. I’ve worked with Oracle since the 1980s and this has always been a hit and miss subject for me, but you have provided an excellent web tech information resource. Well done!!
Thanks! It’s my honor to contribute the community.
tnx solved my problem
I have the same issue,I did start the listener but still it doesn’t work.
LSNRCTL for Linux: Version 12.2.0.1.0 – Production on 14-MAY-2020 10:21:14
Copyright (c) 1991, 2016, Oracle. All rights reserved.
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.1.102)(PORT=1539)))
STATUS of the LISTENER
————————
Alias LISTENER
Version TNSLSNR for Linux: Version 12.2.0.1.0 – Production
Start Date 14-MAY-2020 10:12:47
Uptime 0 days 0 hr. 8 min. 27 sec
Trace Level off
Security ON: Local OS Authentication
SNMP OFF
Listener Parameter File /ora01/app/oracle/product/12.2.0/db_1/network/admin/listener.ora
Listener Log File /ora01/app/oracle/diag/tnslsnr/server/listener/alert/log.xml
Listening Endpoints Summary…
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.1.102)(PORT=1539)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcps)(HOST=server)(PORT=5500))(Security=(my_wallet_directory=/ora01/app/oracle/admin/orcl/xdb_wallet))(Presentation=HTTP)(Session=RAW))
Services Summary…
Service “ORA12CXDB” has 1 instance(s).
Instance “ORA12C”, status READY, has 1 handler(s) for this service…
Service “a50ca342f86bccc0e0536801a8c085de” has 1 instance(s).
Instance “ORA12C”, status READY, has 1 handler(s) for this service…
Service “orcl” has 1 instance(s).
Instance “ORA12C”, status READY, has 1 handler(s) for this service…
Service “orclpdb” has 1 instance(s).
Instance “ORA12C”, status READY, has 1 handler(s) for this service…
The command completed successfully
and if I run the below command I get the same error:-
SQL*Plus: Release 12.2.0.1.0 Production on Thu May 14 10:34:59 2020
Copyright (c) 1982, 2016, Oracle. All rights reserved.
ERROR:
ORA-12541: TNS:no listener
this is my listener.ora file:-
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.102)(PORT = 1539))
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
)
)
Could you please help.
Since your listener port is not the default one (1521), you should provide the port number in the connection string.
sqlplus anju/anju@192.168.1.102 :1539 /ORA12C
Thank you Ed ,but it gave me this error:-
[oracle@server bin]$ ./sqlplus anju/anju@192.168.1.102:1539/ORA12C
SQL*Plus: Release 12.2.0.1.0 Production on Thu May 14 11:47:18 2020
Copyright (c) 1982, 2016, Oracle. All rights reserved.
ERROR:
ORA-12514: TNS:listener does not currently know of service requested in connect
descriptor
Please check the service name (NOT instance name) that you used in the connection string. Normally, the service and the instance name are the same, but in your case, it’s not.
Oracle client ORA-12541: TNS:no listener [closed]
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 years ago .
I am new on Oracle database, but I have one issue. On my Database server (server1) listener and database instance run correctly and I can use sqlplus to connect to this DB. When I connect to database by using other server, I check the TNS configuration and it is correct but system says:
Ora 12541 tns no listener что это
Oracle Net Services provides methods for understanding, testing and resolving network problems. Oracle Database includes utilities, and log and trace files for testing and diagnosing network connection and problems. The TNSPING and TRCROUTE utilities test connectivity. The log and trace files keep track of the interaction between network components as errors occur. Evaluating this information helps to diagnose and troubleshoot network problems.
Understand the common testing procedures and network errors, and outline procedures for resolving problems. Also, learn methods for logging and tracing error information to diagnose and troubleshoot more complex network problems.
These are the suggestions for diagnosing network problems and troubleshooting Oracle Connection Manager in Traffic Director Mode.
16.1 Understanding Automatic Diagnostic Repository
The Automatic Diagnostic Repository (ADR) (ADR) is a systemwide tracing and logging central repository. The repository is a file-based hierarchical data store for depositing diagnostic information, including network tracing and logging information.
The ADR home is the unit of the ADR directory that is assigned to an instance of an Oracle product. Each database instance has its own ADR home. Similarly, each listener, Oracle Connection Manager, and client instance has its own ADR home.
In case of a process failure, an incident is generated. The incident dump files are located in the ADR_BASE/ADR_HOME/incident/ directory, By default, ADR_BASE is ORACLE_BASE if the ORACLE_BASE variable is set. If the variable is not set, then ADR_BASE is ORACLE_HOME/log . ADR_BASE can be set to any location.
The incident dump file location can be found inside the process trace file.
The location of an ADR home is given by the following path, which starts at the ADR base directory:
The following table lists the values of the path components for an Oracle Net Listener instance.
Table 16-1 ADR Home Path Components for an Oracle Net Listener Instance
listener alias name
The following figure illustrates the directory hierarchy of the ADR for an Oracle Net Listener instance. Other ADR homes for other Oracle products or components, such as Automatic Storage Management (ASM) or Oracle Database, can exist within this hierarchy, under the same ADR base.
Figure 16-1 Directory Structure for an Oracle Net Listener Instance
The following table lists the values of the path components for an Oracle Connection Manager instance.
Table 16-2 ADR Home Path Components for an Oracle Connection Manager Instance
Oracle Connection Manager instance name
The following figure illustrates the directory hierarchy of the ADR for an Oracle Connection Manager instance. Other ADR homes for other Oracle products or components, such as Oracle ASM or Oracle Database, can exist within this hierarchy, under the same ADR base.
Figure 16-2 Directory Structure for an Oracle Connection Manager Instance
Within the ADR home directory are subdirectories where each instance, such as the database, listener, Oracle Connection Manager, or client, stores diagnostic data. The following table lists all the subdirectories shown in the preceding figure and their contents.
Table 16-3 ADR Home Subdirectories
The XML-formatted log named log.xml .
Multiple subdirectories, in which each subdirectory is named for a particular incident, and each contains dumps pertaining only to that incident.
Background and server process trace files, SQL trace files, and text version of the log.xml file in the alert directory.
Other subdirectories of ADR home, which store incident packages, health monitor reports, and other information.
The ADR_BASE directory is the physical location in which one or more ADR homes are placed. Conceptually, it is the root directory of ADR.
Non-ADR (meaning that the DIAG_ADR_ENABLED parameter is set to OFF ) diagnostic and tracing methods are still current and applicable but the parameters are ignored if ADR is enabled. ADR is enabled by default.
Diagnostic parameters are found in the following configuration files:
sqlnet.ora for clients
listener.ora for listeners
cman.ora for Oracle Connection Managers
The following table compares usage of diagnostic parameters found in the sqlnet.ora file used in both ADR-based and non-ADR-based diagnostics.
Table 16-4 sqlnet.ora File Diagnostic Parameter Comparison
The following table compares usage of diagnostic parameters found in the listener.ora file used in both ADR-based and non-ADR-based diagnostics.
Table 16-5 listener.ora File Diagnostic Parameter Comparison
Table 16-6 compares usage of diagnostic parameters found in the cman.ora file used in both ADR-based and non-ADR-based diagnostics.
Table 16-6 cman.ora File Diagnostic Parameter Comparison
Oracle Call Interface Programmer’s Guide for additional information about the location of the client ADR Home
Oracle Database Net Services Reference for descriptions of the diagnostic parameters
16.1.1 ADRCI: ADR Command Interpreter
ADRCI is a command-line tool that is part of the fault diagnosability infrastructure. ADRCI enables you to do the following:
View diagnostic data within ADR
Package incident and problem information into a zip file for transmission to Oracle Support Services
Diagnostic data includes incident and problem descriptions, trace files, dumps, health monitor reports, alert log entries, and so on.
ADRCI has a rich command set, and can be used in interactive mode or within scripts. In addition, ADRCI can run scripts of ADRCI commands in the same way that SQL*Plus runs scripts with SQL and PL/SQL commands.
To view trace files using ADRCI, enter ADRCI at a command line. The following are common ADRCI commands used to check a client:
In the preceding commands, the SHOW ALERT command shows the log.xml file in a text editor, such as VI. The SHOW BASE -product client command displays the value of the ADR_BASE directory for the client. Use that value for client in the SET BASE command.
The following are common ADRCI commands used to check a server:
Other ADRCI command options are available for a more targeted Oracle Net trace file analysis. Type HELP at the ADRCI prompt for help documentation.
Oracle Database Utilities for additional information about ADRCI
16.2 Diagnosing Oracle Net Services
Any underlying fault, noticeable or not, is reported by Oracle Net Services with an error number or message. The error number and message provide useful information for diagnosing the problem, but may not always identify the actual problem. The tasks in this section help determine which parts of Oracle Net Services do function properly rather than the parts which do not work. They also help to determine in which of the following categories the fault belongs:
- Oracle software
- Operating system layer
- Other network layers
Testing the various network layers progressively should, in most cases, uncover any problem.
Starting with Oracle Database 21c, a connection identifier is available for each network connection. The connection identifier uniquely identifies a connection in trace and logs of different network elements and helps in correlating diagnostic data from these elements.
When a SQL*Net connection has multiple hops, such as from a client to Oracle Connection Manager (CMAN) and then to a server, correlating diagnostic information from the existing logs and traces becomes difficult. However, with the availability of a connection identifier, you can now easily correlate diagnostics, track network data traffic, and resolve connectivity errors.
The connection identifier consists of two components, namely, CONNECTION_ID and CONNECTION_ID_PREFIX . The CONNECTION_ID parameter contains a unique value, which is generated when the connection originates at the client. The CONNECTION_ID_PREFIX is an application specific prefix parameter that is added to the connection identifier.
16.2.1 Diagnosing Server Problems
To start diagnosing server problems, you should answer the following questions:
Is any other system such as a workstation or server able to connect to the server using Oracle Net?
Has the server, database, or listener configuration remained the same for some time?
If you answered yes to either of the preceding questions, then go to «Diagnosing Client Problems» .
If you are unsure, or answered no to any of the preceding questions, then use the tasks in this section to diagnose the problem. Diagnosing Oracle Net Services on the server involves the following tasks:
To check that the database is up, log in to the database and connect with a valid username and password. For example:
A message appears, confirming that you are connected with the database. If you receive the following errors, then ask the database administrator to assist you:
ORA-1017: invalid U/P
ORA-1034: Oracle not available
A loopback test uses Oracle Net to go from the database server back to itself, bypassing the Interprocess Communication (IPC) protocol. Many network protocols provide a means of testing network connections. The PING utility can be used with a TCP/IP network. Performing a successful loopback verifies that Oracle Net is functioning on the database server.
The following procedure describes how to perform a loopback test from the server to the database:
Ensure that the listener.ora , tnsnames.ora , and sqlnet.ora files exist in the correct locations, as described in «Using Localized Management» .
Start Oracle Net Manager.
In the navigator, expand the Directory or Local option.
Expand Service Naming to view the available network service and database names.
Select the network service name or database service.
Choose Command , and then select Test Net Service .
Testing assumes the listener and database are running. If they are not, then see «Starting Oracle Net Listener and the Oracle Database Server» to start components.
During testing, a Connection Test dialog box appears, providing status and test results. A successful test results in the following message:
If the test was successful, then proceed to step 7.
If the test was not successful, then do the following:
Ensure the database and listener are running, and then click Test .
Click Change Login to change the username and password for the connection, and then click Test .
If the loopback test passes, then go to «Diagnosing Client Problems» .
If the loopback test continues to fail, then contact Oracle Support Services.
Click Close to close the Connect Test dialog box.
16.2.2 Diagnosing Client Problems
Verify at least one of the following statements. This will help you decide if it is a client problem.
The database server passed a loopback test, showing the connection worked.
Other computers connect using Oracle Net Services to the same database.
Connections from this workstation worked before making changes on this computer, such as the installation of a new product or modification to the network configuration.
The following procedure describes how to perform diagnostics on the client:
Check that you have installed the same protocol support that was installed on the database server.
On Linux and UNIX platforms you can use the ADAPTERS utility to verify protocol support. On the database server, run the following command from the ORACLE_HOME/bin directory to display the protocol support, naming methods, and security options linked with the oracle executable:
The adapters utility displays output similar to the following:
On the client, run the adapters command from the ORACLE_HOME/bin directory to display the configured Oracle protocol support, naming methods, and security options. The ADAPTERS utility displays output similar to the following:
The DES , DES40 , 3DES 112 , 3DES 168 , RC4 40 , RC4 56 , RC4 128 , RC4 256 , and MD5 algorithms are deprecated in this release.
To transition your Oracle Database environment to use stronger algorithms, download and install the patch described in My Oracle Support note 2118136.2.
RAW is an internal protocol used by Oracle Net.
Oracle Database Administrator’s Reference for additional information about the adapters utility
Check base connectivity for underlying network transport. Oracle Net technology depends on the underlying network for a successful connection.
Table 16-7 Verify Base Connectivity for Network Transport
Use terminal emulation or file transfer utilities, (PING, FTP, TELNET) from the client to the database server.
See other computers or servers on the Microsoft network.
Ensure that you are able to share drives within the network.
Ensure that the Oracle Net foundation layer and the appropriate Oracle protocol support are present by verifying that all Oracle Net Services software has been installed for the client.
Ensure that the client computer has the tnsnames.ora and the sqlnet.ora files in the correct locations.
If any other working client computers are connecting to the selected Oracle Database, then back up your existing files and copy both the working tnsnames.ora and sqlnet.ora files from the working client computer to the non-working clients. This eliminates the possibility of errors in the files.
Test the Oracle Net foundation layer. You can test using the following command to connect to SQL*Plus:
Do not use the TNSPING utility. The TNSPING utility works like the TCP/IP ping utility and does not create and open a socket, nor does it connect with the listener. It only shows that the listener is present on the database server.
If the connection still fails, then do the following:
Check the Oracle Support Services website for a specific diagnostics bulletin on the error received.