客户的一套库,早上突然连不进数据库,报TNS-12514
客户自己重启监听后,过了一段时间还是连不上,尝试register,还是报TNS-12505。
电话支持,受客户误导,让其测试在服务器上用非SYS用户能否连接数据库,不用使用TNS。告知不行。
让其检查监听状态,告知一切正常。
于是猜想归档满了,检查没有。由于时间紧迫,直接重启的库,重启后恢复
最后了解到,其在服务器上仍然使用了TNS连接数据库......估计也没仔细看监听的信息,只看了监听起来在......
事后从日志分析:
1.当时系统负载不高
2.数据库日志没有异常信息
3.监听日志只记录了报错信息已经执行lsnrctl的信息,竟然没有连接与监听注册的信息,没有设置任何控制参数
猜测是PMON出了什么问题,导致没有监听中的服务状态出现问题。
仔细检查监听日志,发现该故障在4月28日出现过一次,大概4分钟后恢复正常。这里的日志信息比较全
28-APR-2012 18:12:17 * service_died * ctais * 12537
28-APR-2012 18:13:08 * (CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=ctais)(INSTANCE_NAME=ctais)(CID=(PROGRAM=fgaOraAgent102_32)(HOST=scctais)(USER=root))) * (ADDRESS=(PROTOCOL=tcp)(HOST=91.16.16.33)(PORT=57886)) * establish * ctais * 12514
TNS-12514: TNS:listener could not resolve SERVICE_NAME given in connect descriptor
28-APR-2012 18:13:18 * (CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=ctais)(INSTANCE_NAME=ctais)(CID=(PROGRAM=fgaOraAgent102_32)(HOST=scctais)(USER=root))) * (ADDRESS=(PROTOCOL=tcp)(HOST=91.16.16.33)(PORT=57887)) * establish * ctais * 12514
TNS-12514: TNS:listener could not resolve SERVICE_NAME given in connect descriptor
28-APR-2012 18:13:23 * (CONNECT_DATA=(SID=ctais)(CID=(PROGRAM=)(HOST=__jdbc__)(USER=))) * (ADDRESS=(PROTOCOL=tcp)(HOST=91.16.16.159)(PORT=4397)) * establish * ctais * 12505
TNS-12505: TNS:listener could not resolve SID given in connect descriptor
28-APR-2012 18:13:28 * (CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=ctais)(INSTANCE_NAME=ctais)(CID=(PROGRAM=fgaOraAgent102_32)(HOST=scctais)(USER=root))) * (ADDRESS=(PROTOCOL=tcp)(HOST=91.16.16.33)(PORT=57888)) * establish * ctais * 12514
TNS-12514: TNS:listener could not resolve SERVICE_NAME given in connect descriptor
......
28-APR-2012 18:16:38 * (CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=ctais)(INSTANCE_NAME=ctais)(CID=(PROGRAM=fgaOraAgent102_32)(HOST=scctais)(USER=root))) * (ADDRESS=(PROTOCOL=tcp)(HOST=91.16.16.33)(PORT=57913)) * establish * ctais * 12514
TNS-12514: TNS:listener could not resolve SERVICE_NAME given in connect descriptor
28-APR-2012 18:16:48 * (CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=ctais)(INSTANCE_NAME=ctais)(CID=(PROGRAM=fgaOraAgent102_32)(HOST=scctais)(USER=root))) * (ADDRESS=(PROTOCOL=tcp)(HOST=91.16.16.33)(PORT=57914)) * establish * ctais * 12514
TNS-12514: TNS:listener could not resolve SERVICE_NAME given in connect descriptor
参考TNS-12521 / TNS-12502 and service_died Reported in the Listener Log [ID 1307275.1]
service_died 12537表示PMON到监听的服务注册服务被outbound connect timeout,也就是超时。相关BUG造成该故障在9i中未被报告过。
也就是说,PMON这个时候可能在忙于其他事情
一般PMON在1分钟会向监听注册,这次重启监听后,过了4分钟数据库仍然未向监听注册数据库信息。这也说明PMON可能在忙于其他事情,无法注册监听
而数据库重启,使得PMON释放了持有的资源,从而可以注册监听成功
客户这套库本来配置了静态注册,但是不是用了listener这个默认名称,而客户启动的是listener这个监听,也就是没有静态注册服务
如果启动原先配置好的监听,这种故障原本是不会影响业务的
其根本的原因是PMON卡在某个资源上。由于缺少数据分析,先不讨论
客户自己重启监听后,过了一段时间还是连不上,尝试register,还是报TNS-12505。
电话支持,受客户误导,让其测试在服务器上用非SYS用户能否连接数据库,不用使用TNS。告知不行。
让其检查监听状态,告知一切正常。
于是猜想归档满了,检查没有。由于时间紧迫,直接重启的库,重启后恢复
最后了解到,其在服务器上仍然使用了TNS连接数据库......估计也没仔细看监听的信息,只看了监听起来在......
事后从日志分析:
1.当时系统负载不高
2.数据库日志没有异常信息
3.监听日志只记录了报错信息已经执行lsnrctl的信息,竟然没有连接与监听注册的信息,没有设置任何控制参数
猜测是PMON出了什么问题,导致没有监听中的服务状态出现问题。
仔细检查监听日志,发现该故障在4月28日出现过一次,大概4分钟后恢复正常。这里的日志信息比较全
28-APR-2012 18:12:17 * service_died * ctais * 12537
28-APR-2012 18:13:08 * (CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=ctais)(INSTANCE_NAME=ctais)(CID=(PROGRAM=fgaOraAgent102_32)(HOST=scctais)(USER=root))) * (ADDRESS=(PROTOCOL=tcp)(HOST=91.16.16.33)(PORT=57886)) * establish * ctais * 12514
TNS-12514: TNS:listener could not resolve SERVICE_NAME given in connect descriptor
28-APR-2012 18:13:18 * (CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=ctais)(INSTANCE_NAME=ctais)(CID=(PROGRAM=fgaOraAgent102_32)(HOST=scctais)(USER=root))) * (ADDRESS=(PROTOCOL=tcp)(HOST=91.16.16.33)(PORT=57887)) * establish * ctais * 12514
TNS-12514: TNS:listener could not resolve SERVICE_NAME given in connect descriptor
28-APR-2012 18:13:23 * (CONNECT_DATA=(SID=ctais)(CID=(PROGRAM=)(HOST=__jdbc__)(USER=))) * (ADDRESS=(PROTOCOL=tcp)(HOST=91.16.16.159)(PORT=4397)) * establish * ctais * 12505
TNS-12505: TNS:listener could not resolve SID given in connect descriptor
28-APR-2012 18:13:28 * (CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=ctais)(INSTANCE_NAME=ctais)(CID=(PROGRAM=fgaOraAgent102_32)(HOST=scctais)(USER=root))) * (ADDRESS=(PROTOCOL=tcp)(HOST=91.16.16.33)(PORT=57888)) * establish * ctais * 12514
TNS-12514: TNS:listener could not resolve SERVICE_NAME given in connect descriptor
......
28-APR-2012 18:16:38 * (CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=ctais)(INSTANCE_NAME=ctais)(CID=(PROGRAM=fgaOraAgent102_32)(HOST=scctais)(USER=root))) * (ADDRESS=(PROTOCOL=tcp)(HOST=91.16.16.33)(PORT=57913)) * establish * ctais * 12514
TNS-12514: TNS:listener could not resolve SERVICE_NAME given in connect descriptor
28-APR-2012 18:16:48 * (CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=ctais)(INSTANCE_NAME=ctais)(CID=(PROGRAM=fgaOraAgent102_32)(HOST=scctais)(USER=root))) * (ADDRESS=(PROTOCOL=tcp)(HOST=91.16.16.33)(PORT=57914)) * establish * ctais * 12514
TNS-12514: TNS:listener could not resolve SERVICE_NAME given in connect descriptor
参考TNS-12521 / TNS-12502 and service_died Reported in the Listener Log [ID 1307275.1]
service_died 12537表示PMON到监听的服务注册服务被outbound connect timeout,也就是超时。相关BUG造成该故障在9i中未被报告过。
也就是说,PMON这个时候可能在忙于其他事情
一般PMON在1分钟会向监听注册,这次重启监听后,过了4分钟数据库仍然未向监听注册数据库信息。这也说明PMON可能在忙于其他事情,无法注册监听
而数据库重启,使得PMON释放了持有的资源,从而可以注册监听成功
客户这套库本来配置了静态注册,但是不是用了listener这个默认名称,而客户启动的是listener这个监听,也就是没有静态注册服务
如果启动原先配置好的监听,这种故障原本是不会影响业务的
其根本的原因是PMON卡在某个资源上。由于缺少数据分析,先不讨论
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/8242091/viewspace-749738/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/8242091/viewspace-749738/