Oracle监听服务启动失败案例

简介:

在ORACLE测试服务器上还原恢复了一个数据库后,启动监听服务时出现了TNS-12541, TNS-12560,TNS-00511之类的错误,具体情况如下所示:

[oracle@getlnx01 admin]$ lsnrctl status

LSNRCTL for Linux: Version 10.2.0.4.0 - Production on 09-MAR-2015 09:13:29

Copyright (c) 1991, 2007, Oracle. All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1)))

TNS-12541: TNS:no listener

TNS-12560: TNS:protocol adapter error

TNS-00511: No listener

Linux Error: 111: Connection refused

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=getlnx01.esqule.com)(PORT=1521)))

TNS-12541: TNS:no listener

TNS-12560: TNS:protocol adapter error

TNS-00511: No listener

Linux Error: 111: Connection refused

 

[oracle@getlnx01 dbs]$ lsnrctl start

LSNRCTL for Linux: Version 10.2.0.4.0 - Production on 09-MAR-2015 09:20:46

Copyright (c) 1991, 2007, Oracle. All rights reserved.

Starting /u01/app/oracle/product/10.2.0/db_1/bin/tnslsnr: please wait...

TNSLSNR for Linux: Version 10.2.0.4.0 - Production

System parameter file is /u01/app/oracle/product/10.2.0/db_1/network/admin/listener.ora

Log messages written to /u01/app/oracle/product/10.2.0/db_1/network/log/listener.log

Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1)))

Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=getlnx01.esqule.com)(PORT=1521)))

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1)))

TNS-12547: TNS:lost contact

TNS-12560: TNS:protocol adapter error

TNS-00517: Lost contact

Linux Error: 104: Connection reset by peer

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=getlnx01.esqule.com)(PORT=1521)))

TNS-12541: TNS:no listener

TNS-12560: TNS:protocol adapter error

TNS-00511: No listener

Linux Error: 111: Connection refused

 

因为曾经遇到并解决过TNS-12541这类错误,立即检查/etc/hosts文件,结果发现IP地址写错了,正确的IP地址应该为192.168.7.221,而不是粗心手误写错的192.168.7.211

[root@getlnx01 ~]# more /etc/hosts
 
# Do not remove the following line, or various programs
 
# that require network functionality will fail.
 
127.0.0.1      getlnx01.esqule.com getlnx01
 
192.168.7.211  getlnx01.esqule.com getlnx01 
 

修改为正确的IP地址后,依然出现这个错误,后面查看了官方文档Starting TNS Listener or LSNRCTL Start Yields TNS-12541, Linux Error: 111: Connection Refused (文档 ID 343295.1)后,才发现是因为本地主机环回名称和地址不正确所致,修改/etc/hosts后,重启监听服务,问题解决。

[oracle@getlnx01 ~]$ more /etc/hosts
 
# Do not remove the following line, or various programs
 
# that require network functionality will fail.
 
127.0.0.1      localhost.localdomain localhost
 
192.168.7.221  getlnx01.esqule.com getlnx01 
 

 

CAUSE

 

1. There is possibly an incorrect IP Address specified for the host in the /etc/hosts file.

For example:

192.168.101.101 prod1.us.oracle.com prod1

Whereas the actual ip address for the host "prod1.us.oracle.com" is 192.168.101.110

2. Also, the localhost reference may be incorrect or missing from the /etc/hosts file.

3. Oracle may not have read access to /etc/nsswitch.conf file.

 

SOLUTION

To implement the solution, please execute the following steps:

1. Correct the mapping in the /etc/hosts file by adding/correcting the IP address and/or hostname reference for the Unix/Linux Server (both long and short host names).

For example:

# Add or edit the /etc/hosts file to include a valid entry for the Server:

192.168.101.110 prod1.us.oracle.com prod1

2. Check that the localhost loopback name and address are correct (both long and short host names).

An example of a correct localhost entry would be as follows:

127.0.0.1 localhost.localdomain localhost

3. Remember to save the /etc/hosts file and then start the listener.

4. Check permissions on /etc/nsswitch.conf file to ensure group and other have read access.

- If necessary change permisions on /etc/nsswitch.conf as follows:

chmod 644 /etc/nsswitch.conf

相关文章
|
21天前
|
Oracle 关系型数据库 数据库
Oracle数据恢复—Oracle数据库文件有坏快损坏的数据恢复案例
一台Oracle数据库打开报错,报错信息: “system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。管理员联系我们数据恢复中心寻求帮助,并提供了Oracle_Home目录的所有文件。用户方要求恢复zxfg用户下的数据。 由于数据库没有备份,无法通过备份去恢复数据库。
|
27天前
|
存储 Oracle 关系型数据库
oracle数据恢复—Oracle数据库文件大小变为0kb的数据恢复案例
存储掉盘超过上限,lun无法识别。管理员重组存储的位图信息并导出lun,发现linux操作系统上部署的oracle数据库中有上百个数据文件的大小变为0kb。数据库的大小缩水了80%以上。 取出&并分析oracle数据库的控制文件。重组存储位图信息,重新导出控制文件中记录的数据文件,发现这些文件的大小依然为0kb。
|
14天前
|
存储 Oracle 关系型数据库
服务器数据恢复—华为S5300存储Oracle数据库恢复案例
服务器存储数据恢复环境: 华为S5300存储中有12块FC硬盘,其中11块硬盘作为数据盘组建了一组RAID5阵列,剩下的1块硬盘作为热备盘使用。基于RAID的LUN分配给linux操作系统使用,存放的数据主要是Oracle数据库。 服务器存储故障: RAID5阵列中1块硬盘出现故障离线,热备盘自动激活开始同步数据,在同步数据的过程中又一块硬盘离线,RAID5阵列瘫痪,上层LUN无法使用。
|
2月前
|
存储 Oracle 关系型数据库
数据库数据恢复—Oracle ASM磁盘组故障数据恢复案例
Oracle数据库数据恢复环境&故障: Oracle ASM磁盘组由4块磁盘组成。Oracle ASM磁盘组掉线 ,ASM实例不能mount。 Oracle数据库故障分析&恢复方案: 数据库数据恢复工程师对组成ASM磁盘组的磁盘进行分析。对ASM元数据进行分析发现ASM存储元数据损坏,导致磁盘组无法挂载。
|
3月前
|
Oracle 关系型数据库 数据库
数据库数据恢复—Oracle数据库文件出现坏块的数据恢复案例
打开oracle数据库报错“system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。 数据库没有备份,无法通过备份去恢复数据库。用户方联系北亚企安数据恢复中心并提供Oracle_Home目录中的所有文件,急需恢复zxfg用户下的数据。 出现“system01.dbf需要更多的恢复来保持一致性”这个报错的原因可能是控制文件损坏、数据文件损坏,数据文件与控制文件的SCN不一致等。数据库恢复工程师对数据库文件进一步检测、分析后,发现sysaux01.dbf文件损坏,有坏块。 修复并启动数据库后仍然有许多查询报错,export和data pump工具使用报错。从数据库层面无法修复数据库。
数据库数据恢复—Oracle数据库文件出现坏块的数据恢复案例
|
3月前
|
Oracle 关系型数据库 数据库
Oracle数据恢复—异常断电导致Oracle数据库数据丢失的数据恢复案例
Oracle数据库故障: 机房异常断电后,Oracle数据库启库报错:“system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。数据库没有备份,归档日志不连续。用户方提供了Oracle数据库的在线文件,需要恢复zxfg用户的数据。 Oracle数据库恢复方案: 检测数据库故障;尝试挂起并修复数据库;解析数据文件。
|
2月前
|
Oracle 关系型数据库 数据库
oracle数据恢复—Oracle数据库文件损坏导致数据库打不开的数据恢复案例
打开oracle数据库时报错,报错信息:“system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。急需恢复zxfg用户下的数据。 出现上述报错的原因有:控制文件损坏、数据文件损坏、数据文件与控制文件的SCN不一致等。数据恢复工程师对数据库文件做进一步检测分析后发现sysaux01.dbf文件有坏块。修复sysaux01.dbf文件,启动数据库依然有许多查询报错。export和data pump工具无法使用,查询告警日志并分析报错,确认发生上述错误的原因就是sysaux01.dbf文件损坏。由于该文件损坏,从数据库层面无法修复数据库。由于system和用户表空间的数据文件是正常的,
|
5月前
|
SQL Oracle 关系型数据库
|
7月前
|
存储 Oracle 关系型数据库
服务器数据恢复—RAID5上层SAP+oracle数据恢复案例
**服务器存储数据恢复环境:** 某品牌服务器存储中有一组由6块SAS硬盘组建的RAID5阵列,其中有1块硬盘作为热备盘使用。上层划分若干lun,存放Oracle数据库数据。 **服务器存储故障&分析:** 该RAID5阵列中一块硬盘出现故障离线,热备盘自动激活替换故障硬盘,热备盘同步数据的过程中该raid5阵列中又有一块硬盘出现故障,RAID5阵列瘫痪,上层LUN无法正常访问。 因为本案例中存储控制器的磁盘检查策略严格,一旦某些磁盘性能不稳定,该型号存储控制器就将该块磁盘识别为坏盘,并将该块磁盘踢出RAID。一旦RAID中掉线的盘数到超过RAID级别允许掉盘的最大数量,该RAID将不可用,
服务器数据恢复—RAID5上层SAP+oracle数据恢复案例
|
7月前
|
Oracle 关系型数据库
oracle基本笔记整理及案例分析2
oracle基本笔记整理及案例分析2

推荐镜像

更多