Oracle常见故障——Listener类HangCrash及连接风暴的判断

Oracle常见故障——Listener类：Hang、Crash及连接风暴的判断

目录

监听状态正常，应用反馈时断时连

Listener进程crash

ORA-12514 TNS 监听程序当前无法识别连接描述符中请求服务

11G SCAN LISTENER无法注册服务故障

Listener hang

TNS-12535 TNS-00505处理

应用测试连接不上数据库，连接直接报TNS-12547: TNS:lost contact处理

由Oracle的Listener引起的报错很多，很大一部分是由于配置不当导致的。通常，我们要么从tnsnames.ora找原因，要么从lisntener.ora找原因。基本上，我们从Oracle连接的时候报出的错误代码可以快速查到原因。

下面介绍的几类故障及处理方法，难度稍微要大一些

1监听状态正常，应用反馈时断时连

故障现象:

客户端新发起的短连接时断时连，如下所示:

故障原因:

因短连接持续性发起连接耗尽监听ip 1521端口资源，导致监听无法正常处理连接请求。

超过每秒50次连接则需要关注，可通过tail -20f listener.log 观察，如持续性快速刷屏则可能已经出现连接风暴.

故障解决/日志分析:

2Listener进程crash

故障环境：

操作系统为：SunOS 5.10

数据库版本：Oracle 10.2.0.4

故障现象：

Listener进程已经crash， 查看主机数据库监听日志listener_ngsetdb3/4.log如下：

系统日志：

故障分析：

Listener进程crash是由于IPMP出现故障所致，Listener随后在探测不到服务节点时，直接crash。Oracle MOS文章Solaris Cluster 3.x: IPMP group failure impact [ID 1006916.1]对此有详细描述：在Sun Cluster中，短暂的网络故障会导致IPMP组失败，并触发资源组切换。并且，它会在38秒后回切！

处理方法：

查看监听日志listener.log跟系统日志(/var/adm/ messages)。

手动重启两个节点的Listener，Oracle提供了一个解决方案：修改/etc/default/mpathd文件下的IPMP FAILURE_DETECTION_TIME变量值，即将失败检测时间从默认的10秒(10000)增加到20秒(20000)以上

注：修改该参数需要重启mpathd服务。

3ORA-12514 TNS 监听程序当前无法识别连接描述符中请求服务

故障现象：

客户端无法通过监听连接数据库

故障原因：

1.实例未注册到listener中,可通过lsnrctl status 查看

2.oracle process达到上限无法建立新的连接。

故障解决：

手工注册数据库,alter system register;

检查数据库用户连接分布情况,并show process 查看连接限制

Select username,count(1) from v$session group by username order by 2 asc;

Ps :大部分情况由开发商程序bug引起。

411G SCAN LISTENER无法注册服务故障

故障现象：

scan listener 无法注册service服务

故障原因：

bug 13066936

故障解决:

5Listener hang

故障环境:

任意环境

故障现象:

从其他应用主机tnsping发现延迟很大

查看监听状态报如下错：

listener.log有如下报错：

故障分析:

Too many open files意味着Maximum Number Of Open Files Per Process 达到了上限。因此listener hang住的原因是该limit设置过小。

处理方法：

将oracle用户的soft limit提升为至少1024，然后重新oracle用户登录，检验ulimit合格后，重新启动数据库和监听。

具体解决办法如下：

在/etc/system增加以下行

set rlim_fd_max=65536

set rlim_fd_cur=4096

重新登录ORACLE并检验oracle用户的限制

su – oracle

ulimit -Ha

ulimit –Sa

重新启动数据库和监听

6TNS-12535 TNS-00505处理

故障环境：

任意环境

故障现象：

Db alert日志报如下错误：

故障分析：

一个客户端连接整个步骤：

客户端发起一个connection连接监听

监听启动一个专属进程(服务器进程，也就是我们通常说的LOCA=NO进程)用于接收这个connection

在专属进程启动之后，监听会将这个connection传递给这个专属进程

专属进程通过这个connection来跟客户端握手

专属进程跟客户端信息交换需要建立一个session

session打开

当在以上的第3步到第4步时客户端关闭，所以当专属进程尝试跟客户端联系时发现连接已关闭时，就会报出我们看到的错误！！

错误一般是由于程序异常断开导致超时，11g R1如果出现如上的错误信息会写入到sqlnet.log,11g R2会写入到alert.log，

其实出现此错误是正常的现象。

处理方法：

如果不想这样的信息打印在alert日志中，

在sqlnet.ora设置

DIAG_ADR_ENABLED = OFF

在listener.ora设置

DIAG_ADR_ENABLED_ = OFF

重启监听

7应用测试连接不上数据库，连接直接报TNS-12547: TNS:lost contact处理

故障环境：

环境：HP-UX 11.31 ia64

数据库版本：11.2.0.4

故障现象：

应用测试连接不上数据库，连接直接报TNS-12547: TNS:lost contact。

但查看监听状态，CRS状态，数据库状态均正常。CRS日志、CSS日志及AGENT日志均无报错。

故障分析：

应用连接数据库直接报TNS-12547: TNS:lost contact

监听日志发现一直在报连接失败:

问题导致的原因有在32位平台中当listener.log超过2G会报这个错。

ORACLE_HOME下的一些执行文件权限不对也会导致相同的错误，但我们这个是64位的，排除第一种，

所以去查询执行文件的权限是否正常。

处理方法：

1、 通过对比发现部分执行文件少了S权限，做了relink all,重新同步执行文件

2、 由于数据库使用的是ASM，磁盘属组为asmadmin，故对比问题节点及正常节点DB ORACLE_HOME下属组为asmadmin的文件，将问题节点文件权限修正即可解决问题。

本文来自云栖社区合作伙伴"DBAplus"，原文发布时间：2015-12-23

Oracle常见故障——Listener类HangCrash及连接风暴的判断相关教程

Oracle日常运维注意点

关于数据库空间管理

•添加数据文件时，注意存储I/O资源空闲率

•自动扩展模式下的数据文件大小存在限制，即：Block数量2的22次方。如block size大小为8k，则数据文件最大为32G。

•建议统一规划数据文件大小，8/16G。

关于用户登录

•连续10次密码错误登录将会导致用户被锁

•Oracle 11g以上，用户密码有大小写之分

关于主机登录

•RAC情况下，建议不要使用VIP地址登录到主机。VIP会漂移！

•重大操作前，再次确认当前主机名句酷和当前。建议配置如下环境变量：

exportPS1='\e[31;1m${LOGNAME}@${HOSTNAME}:${PWD}>\e[0m'

关于表格创建

•列的总长度超过8000，引起行连接，从而引起性能下降

•11g创建空表时默认不占物理空间。11.2.0.1时，exp导出时不导空表，bug如下：

创建、删除、修改sequence

•Sequence的cache属性设置过小，从而引起数据库出现latch：row cache objects等待事件。

关于truncate table

•如果表比较大，建议步骤如下：

表增加字段

•高并发环境下，极易导致library cache lock等待事件，从而出现hang

•导致表相关的依赖对象失效，相关会话自动重编译。进而导致出现大规模的library cache lock等待事件

•导致相关cursor失效，引起硬解析风暴

•新增字段如果是NOT NULL的，则一定要有默认值，否则老应用的insert代码可能报错。

•表如果存在老数据，带上默认值的时候会导致oracle去订正老的数据行的新增列。如果老数据非常多，表的并发访问高，很有可能导致大面积的阻塞等待以及产生大事务，甚至有可能导致undo耗尽。

•建议：先不带not null不带默认值加上列，再更改列默认值，再批量订正老数据，然后再加上not null属性。

修改字段长度

•建议只加大长度，而不是缩小

•会引起cursor和相关依赖对象失效，高并发时会出现library cache lock/pin、mutex等待事件

•存储过程报错，建议存储过程声明变量时采用col%type

关于修订(DML)数据

•严禁仅用一个事务来处理大规模订正(影响的记录数超过1万笔)。大事务修订极易引起undo空间不足报错，从而导致事务回滚。

•条件允许的话，做好原表的备份工作

关于索引创建、重建

•单个索引条目的大小(索引键值的定义长度总和)不能超过6398字节(db_block_size为8k)。

•如何加快索引创建速度：

Ø开启并行：create index idx1 on t1(col1) degree 2;

Ø加大排序区：pga_aggregate_target/sort_area_size

•注意：

Ø索引创建完毕，重新设置degree为1

Ø索引创建时同时会收集统计信息(Oracle 10g及之后)，如果表没有或者存在过旧统计信息，则可能会导致执行计划混乱，进而导致SQL性能急剧下降。

关于删除索引

•删除之前建议观察一段时间(一个业务周期)：

alterindex idx1 monitoring index usage

•11g之后可以将索引设置为不可见，但后台仍需维护

•删除之前保留索引脚本

关于分区操作

•谨慎评估增加Hash分区，会导致分区建变更

•严禁使用Spilt方式增加分区

Ø若spilt的分区有数据，会导致local index为unusable；一般分区都是大表，后果不堪设想

Ø若spilt的分区有数据，会占用大量的临时段

•list分区严禁给予default分区，否则无法添加其他值的分区

•任何分区删除操作必须加上update global Indexes，防止全局索引失效

关于MOVE表

•Move表的主要目的是更换表空间或者回收空间

•相关索引会失效

•堵塞其他DML会话

•表中不能包含LONG字段

关于exp备份

•模板如下：

cat exp.par

userid=user/password@orcl

direct=y--直接路径导出，加快导出速度

compress=n--避免数据全部压缩在一个数据块上

file=exp.dmp

log=exp.log

recordlength=65535--写dmp文件时一次IO的大小，上限是65535，可以加快导出速度

tables=t1

关于imp

•模板如下：

cat imp_ws0208.par

userid=user/password

commit=y--开启批量提交，避免长事务

ignore=y--如果目标表已经存在，只导入数据

fromuser=yyc

touser=zzzzzz

tables=yz_ongimt_jingtzt

file=exp0208.dmp

log=imp0208.log

buffer=100000

连接池设置不合理可能导致的后果

连接池的MIN数和MAX数，看似很简单的两个参数，其实对于应用和数据库的影响，并不是那么的简单。我们先来看看连接数设置不合理可能产生的后果：

连接池MIN设置过小，应用业务量突增，或者启动时可能产生连接风暴。

连接池MIN值设置过大,会造成资源的浪费，主要包括数据库和应用内存，连接数的浪费，同时连接池MIN值设置过大，也会导致连接被频繁的创建和销毁。这是由连接池的工作机制决定的。

连接池MAX值设置过大。在极端情况下，当应用发生异常时，会导致连接数被撑到MAX值，有可能导致数据库连接数被耗尽，从而导致正常的业务受到影响。当连接数被撑到MAX值，在获取连接超时的时候，应用的线程池也有可能受到影响，这是一系列的连锁反应。

以上是连接池MIN值和MAX值设置最主要的3点影响。其中，影响最大的并且最难配置的是第2点，即连接数的MIN值设置。

设置连接池的min-pool-size

一般来说，我们可以按照业务高峰时期的压力来估算连接数。比如，在高峰时期，每秒有5000个并发请求，每个请求的处理时间为2ms，则每秒总共需要5000*2ms=10s的连接处理时间。因此，连接数的MIN值我们可以设置为10个(适当上浮1-2个)，这样就能基本上解决连接风暴的问题了。当然在业务低峰时期，10个连接数的设置可能偏大了点，所以这里对于连接数的MIN值设置也做了一个权衡，保守起见，我们需要以高峰时需要的正常连接数来设置MIN值，以避免连接风暴的发生。因为这样做是最保险的，当然，这带了一些额外的代价，会牺牲掉部分的数据库和应用的资源。

有时候，我们对于业务的估计可能并不准备，如业务刚上线，对于连接数不能很好的评估，这个时候我们可以对连接池的MIN值进行调优，共有两种方式，如下：

通过ORACLE监听日志对min-pool-size调优

对于ORACLE数据库，我们可以使用数据库的监听日志来进行调优，即通过listener.log(数据库监听日志)进行调优。收集以下几个信息：

1. 根据监听日志，我们可以得到某个应用集群A在2小时内创建的连接总数，假设统计一共为N个。

2. 假设A集群在2小时内的连接数维持在一个值：M。(后面会对这个M进行说明)

3. A集群有S台应用服务器，假设应用服务器负载均衡。

我们知道，连接池IDLE清理是15分钟执行一次的，每次清理空闲时间超过30分钟的连接。所以，2小时内，每台应用平均创建的连接数为:N/4S个。

假设:

1. M=min连接数，则我们的应用可以下调的MIN连接数为N/4S个，即设置为M-N/4S。(由连接池的原理可以知道，这些新创建的连接完全都是空闲的连接，只是由于配置了MIN值较大而产生的，实际上这些连接一直处于空闲状态)

2.假设M值>min连接数，则需要将min值设置为M。

3.假设M

之前对于某核心系统做的一次调优，上线后效果很不错,参考一个生产库的JBOSS连接池调整优化及分析

通过监控JBOSS连接池对min-pool-size的调优

连接池默认参数及获取连接池中相关的统计信息一节中，我们提到了连接池中有一些方法可以获取连接数的信息，其中有三个方法:

//获取连接数，内部执行：return created - destroyed;即所有创建的连接数-所有销毁的连接数

public int getConnectionCount()

{

return connectionCounter.getCount();

}

//创建连接的总数

public int getConnectionCreatedCount()

{

return connectionCounter.getCreatedCount();

}

//连接销毁总数

public int getConnectionDestroyedCount()

{

return connectionCounter.getDestroyedCount();

}

通过监控这三个参数我们即可进行连接数的调优，具体的调优方式和方法1一致，只是我们获取创建的连接数，通过监控连接池中的状态获取。如下图所示,我们监控了10:00-12:00数据库的连接数：

通过上面的图可以知道，我们的连接数MIN值设置过大了(上图是对于单台应用的连接池监控)。因为连接池始终保持在MIN值10个，说明连接数过剩，而我们的连接池不停的创建，销毁。由于定时任务是15分钟启动1次的，所以我们在图上可以看到每隔15分钟说有1个连接被销毁。在30分钟平均有2个连接被销毁。根据同样的ORACLE监听日志的调优算法：

我们的连接数可以被设置为M-N/4S,即10-8/4=8个。

这是二种连接池MIN调整的方案。其实原理是完全一样的，只是获取数据的两种方式不同，对于有条件的应用，建议监控JBOSS的连接池进行调优。这样，连接池的一切状态，都会尽在掌握之中，调优也会变的更加简单高效。

设置连接的max-pool-size

其实我们在调整连接池MIN值的时候，已经是按业务的高峰时期进行调整。所以MAX值调整的意义其实并不大，我们只要将MAX值设置在一个安全的阀值即可。保证不超过数据库的连接数，同时又保证在业务偶尔分布不均匀时，应用也能够获取连接，防止连接池取不到的情况。

我们经常会看到应用程序报错：“No ManagedConnections available within configured blocking timeout xx [ms]”，这其实是由于连接池达到最大值了，没有可用的连接的时候产生的。(参考：JBOSS连接池4-从连接池中获取连接及返还连接)。产生这个问题，最根本的原因往往并不是连接数不够用，我们应该首先看看数据库的响应和应用DAO的响应时间。有时候因为SQL走不上索引，或者数据库响应较慢，会增加业务占用连接的时间(即处理时间)，这种情况下，加大MAX连接数可以从一定程序上缓解问题，但是不能解决根本的问题。

blocking-timeout-millis的设置

另外一点建议是，将blocking-timeout-millis参数设置的尽量小一点，这个参数是应用getconnection时的超时时间，只在连接数达到MAX值时才会起作用，因为连接数没到达MAX值，这个获取连接是一个很快的操作，内部仅仅是执行一个获取信号量的操作。为了尽量的减小在获取不到连接而等待超时对应用线程池的阻塞，我们需要将blocking-timeout-millis参数设置为一个较小的值即可，这样，当连接池中无可用的连接时，由于超时时间减小了，可以避免由于线程池共享造成对其它正常业务的影响，特别是一个应用连接多个数据源时，这个值的设置尤其重要。

总结

实际我们对于连接池的调优，需要从连接池的原理入手，只有理解了原理，才能够更好的将连接池控制在我们所想要的一个状态。因为连接池的不合理设置所产生的问题，我们在上面吃的亏很多。就因为一个小小的连接池出了问题，现在看来实在有点得不偿失。

真实的场景中，特别是基于数据库的水平拆分，或者读写分离的场景中，当一个应用集群需要连接多个数据源时，我们尤其需要考虑连接池的这几个参数：prepared-statement-cache-size，min-pool-size, max-pool-size, blocking-timeout-millis。这几参数设置的利害关系，需要仔细的考虑。另外，我们还需要重点考虑2个点：

对于物理库-逻辑库中，数据源共享和不共享的取舍。

prepared-statement-cache-size，min-pool-size值的设置，数据源个数，fetchsize的设置 直接影响到JVM内存的使用。