Shell: extract more from listener.log(分析监听日志)

最近遇到了两起数据库连接数不足的问题, 通常都会预留一些会话增加的情况, 但在一些特殊情况下如连接风暴(logon storm), 如果在监听中没有做rate限流,对数据库来说巨大的冲击可能会导致数据库Hang 或 ora-20 或ora-18 错误。 对于Hang并伴有进程数不足的情况,AWR、ASH 都可能无法升成,甚至数据库都无法登录或做SSD 都不成功, 这时候LISTENER.LOG 就成了“破案”时关键的线索。 下面记录分享一些分析listener.log的一些脚本.(Note:在不同UNIX下可能稍有变化)

统计一天内每小时的session请求数

# fgrep "13-JAN-2015 " anbob_listener.log  |fgrep "establish" |awk ‘{print $1 " " $2}‘ |awk -F: ‘{print $1 }‘ |sort |uniq -c
2978 13-JAN-2015 00
2883 13-JAN-2015 01
3025 13-JAN-2015 02
2181 13-JAN-2015 03
2131 13-JAN-2015 04
2269 13-JAN-2015 05
1843 13-JAN-2015 06
2133 13-JAN-2015 07
3195 13-JAN-2015 08
4446 13-JAN-2015 09
4849 13-JAN-2015 10
4527 13-JAN-2015 11
3527 13-JAN-2015 12
3507 13-JAN-2015 13
4005 13-JAN-2015 14
4256 13-JAN-2015 15
4523 13-JAN-2015 16
4566 13-JAN-2015 17
5288 13-JAN-2015 18
4921 13-JAN-2015 19
4020 13-JAN-2015 20
3315 13-JAN-2015 21
2418 13-JAN-2015 22
2227 13-JAN-2015 23

指定的一小时每分钟session请求数

# fgrep "13-JAN-2015 11:" anbob_listener.log  |fgrep "establish" |awk ‘{print $1 " " $2}‘ |awk -F: ‘{print $1 ":" $2 }‘ |sort |uniq -c
  94 13-JAN-2015 11:00
  44 13-JAN-2015 11:01
  80 13-JAN-2015 11:02
 119 13-JAN-2015 11:03
  56 13-JAN-2015 11:04
 127 13-JAN-2015 11:05
  68 13-JAN-2015 11:06
  66 13-JAN-2015 11:07
  58 13-JAN-2015 11:08
  67 13-JAN-2015 11:09
 103 13-JAN-2015 11:10
  53 13-JAN-2015 11:11
  88 13-JAN-2015 11:12
...

指定的一小时每秒session请求数

# fgrep "13-JAN-2015 11:30" anbob_listener.log  |fgrep "establish" |awk ‘{print $1 " " $2}‘ |awk -F: ‘{print $1 ":" $2 ":" $3 }‘ |sort |uniq -c
  7 13-JAN-2015 11:30:00
  3 13-JAN-2015 11:30:01
  4 13-JAN-2015 11:30:02
  4 13-JAN-2015 11:30:03
  7 13-JAN-2015 11:30:04
  2 13-JAN-2015 11:30:05
  1 13-JAN-2015 11:30:06
  8 13-JAN-2015 11:30:08
  2 13-JAN-2015 11:30:09
  3 13-JAN-2015 11:30:10
  1 13-JAN-2015 11:30:11
...

指定的一小时内每分钟连接创建失败数

#fgrep "11-JAN-2015 11:" anbob_listener.log |awk  ‘{ if ( $NF != 0 ) print $0 }‘|awk ‘{print $1 " " $2}‘ |awk -F: ‘{print $1 ":" $2 }‘ |sort |uniq -c
 474 11-JAN-2015 11:38
  10 11-JAN-2015 11:39

指定的一小时内每IP请求数

#fgrep "11-JAN-2015 11:" anbob_listener.log|fgrep "establish"|awk -F* ‘{print $3}‘|awk -F= ‘{ print $4}‘|sed -e ‘s/......$//g‘|sort |uniq -c|sort
  1 136.142.26.139
  2 136.142.10.212
  2 136.142.21.171
  8 136.142.21.172
  13 136.142.26.133
  13 136.142.29.17
  14 136.142.29.20
  18 136.142.26.35
  23 136.142.29.29
...

指定的分钟内每IP请求数

#fgrep "11-JAN-2015 11:30" anbob_listener.log|fgrep "establish"|awk -F* ‘{print $3}‘|awk -F= ‘{ print $4}‘|sed -e ‘s/......$//g‘|sort |uniq -c|sort
  1 136.142.26.35
  1 136.142.29.149
  1 136.142.29.156
  1 136.142.29.17
  2 136.142.30.189
  3 136.142.26.133
  4 136.142.26.136
  4 136.142.29.157
  7 136.142.29.20
  9 136.142.29.22
  10 136.142.26.34
...

全天每小时每个IP请求数

fgrep "09-JAN-2015 " anbob_listener.log|fgrep "establish"|awk -F* ‘{print $1 " " $3}‘|awk -F= ‘{ print $1 " "  $4}‘|sed -e ‘s/......$//g‘| awk ‘{print $1 " " $2 " " $4}‘|cut -b-14,21- |sort |uniq -c 

   1 09-JAN-2015 01 136.142.21.172
  66 09-JAN-2015 01 136.142.21.85
  11 09-JAN-2015 01 136.142.26.131
   5 09-JAN-2015 01 136.142.26.133
  21 09-JAN-2015 01 136.142.26.136
5113 09-JAN-2015 01 136.142.26.24
  49 09-JAN-2015 01 136.142.26.34
   6 09-JAN-2015 01 136.142.29.141
  28 09-JAN-2015 01 136.142.29.148
  49 09-JAN-2015 01 136.142.29.149
  85 09-JAN-2015 01 136.142.29.150
   2 09-JAN-2015 01 136.142.29.151
   6 09-JAN-2015 01 136.142.29.156
   6 09-JAN-2015 01 136.142.29.157
   2 09-JAN-2015 01 136.142.29.162
  58 09-JAN-2015 01 136.142.29.164
   4 09-JAN-2015 01 136.142.29.17
   4 09-JAN-2015 01 136.142.29.184
 207 09-JAN-2015 01 136.142.29.192
-- file: session_rpt.sql
-- Purpose: list of session information
-- Author:	  weejar
-- Copyright:   (c) ANBOB - http://www.anbob.com.com - All rights reserved.
prom
prom List of sessions (c)anbob.com
prom
select ‘anbob.com‘ author,to_char(sysdate,‘yyyy-mm-dd hh24:mi:ss‘) current_time,instance_name from v$instance
/
col sid form 99999
col serial# form 99999
col spid form a6
col program heading ‘program‘ for a25 trunc
col username form a15
col osuser form a10
col idle form a30 heading "Idle"
col terminal form a12
col logon_time form a18
col machine for a15 trunc
col rn for 9999
col service_name for a30
set lines 150 pages 1000
break  on report
compute sum of cnt on report
select username,status,count(*) cnt from v$session group by username,status
/
select username,machine,count(*) cnt from v$session group by username,machine
/
select status,count(*) cnt from v$session group by status
/
select inst_id,service_name,count(*) cnt from gv$session group by  inst_id,service_name order by 1,2
/
ttitle -
   center  ‘displays the top 50 longest idle times‘  skip 2
select  a.*
from (
  select sid,serial#,username,status, to_char(logon_time,‘dd-mm-yy hh:mi:ss‘) logon_time
  , floor(last_call_et/3600)||‘ hours ‘
    || floor(mod(last_call_et,3600)/60)||‘ mins ‘
    || mod(mod(last_call_et,3600),60)||‘ secs‘ idle
  , machine ,row_number() over(order by last_call_et desc ) rn
  from v$session
  where type=‘USER‘ ) a
where rn<= 50
/
ttitle off
column event heading ‘wait event‘ for a30 trunc
ttitle -
   center  ‘displays active session‘  skip 2
select sid,serial#,username,event,program,MACHINE,sql_id,BLOCKING_SESSION from v$session where status=‘ACTIVE‘ and username is not null;
ttitle off
时间: 2024-10-07 23:51:47

Shell: extract more from listener.log(分析监听日志)的相关文章

Shell: extract more from listener.log (分析oracle监听日志)

最近遇到了两起数据库连接数不足的问题, 通常都会预留一些会话增加的情况, 但在一些特殊情况下如连接风暴(logon storm), 如果在监听中没有做rate限流,对数据库来说巨大的冲击可能会导致数据库Hang 或 ora-20 或ora-18 错误. 对于Hang并伴有进程数不足的情况,AWR.ASH 都可能无法升成,甚至数据库都无法登录或做SSD 都不成功, 这时候LISTENER.LOG 就成了"破案"时关键的线索. 下面记录分享一些分析listener.log的一些脚本.(No

『ORACLE』 清理监听日志(11g)

停止监听服务进程(tnslsnr)记录日志.lsnrctl  set log_status off; 将监听日志文件(listener.log)复制一份,以listener.log.yyyymmdd格式命名cp listener.log listener.log.20170521 将监听日志文件(listener.log)清空. cat /dev/null > listener.log 开启监听服务进程(tnslsnr)记录日志lsnrctl set log_status on; 对于这种lis

ORACLE清理、截断监听日志文件(listener.log)

在ORACLE数据库中,如果不对监听日志文件(listener.log)进行截断,那么监听日志文件(listener.log)会变得越来越大,想必不少人听说过关于"LISTENER.LOG日志大小不能超过2GB,超过会导致LISTENER监听器无法处理新的连接",当然这个不是真理,不会绝对出现,只是发生在老旧的32bit Linux或Unix系统下面,真实的原因是一些32bit OS自带的文件系统不支持2GB以上的文件,导致监听服务进程(tnslsnr)append write日志文件

nginx源码分析--监听套接字的创建 套接字的监听 HTTP请求创建连接

作为一个web服务器,那么肯定是有监听套接字的,这个监听套接字是用于接收HTTP请求的,这个监听套接字的创建是根据配置文件的内容来创建的,在nginx.conf文件中有多少个地址就需要创建多少个监听套接字.这里不说各个结构体的构造 只说大体情况! 1).首先在main函数中调用了ngx_init_cycle()函数,在这个函数的最后调用了ngx_open_listening_sockets函数,这个函数负责将创建的监听套接字进行套接字选项的设置(比如非阻塞.接受发送的缓冲区.绑定.监听处理) 2

有关监听日志的清理问题

近日,有开发人员向我反馈:“代码时有连不上数据库的情况发生”.在了解了一些基本信息之后,希望能通过查看监听日志获取问题线索.首先是通过如下方式确定监听日志的存放路径: LSNRCTL for Linux: Version 10.2.0.4.0 - Production on 21-JUN-2016 21:19:56 Copyright (c) 1991, 2007, Oracle. All rights reserved. Connecting to (ADDRESS=(PROTOCOL=tcp

我所不知道的的监听日志问题

今天,有开发人员向我反馈:“代码时有连不上数据库的情况发生”.在了解了一些基本情况之后,希望能通过查看监听日志获取问题线索.首先是通过如下方式确定监听日志的存放路径: LSNRCTL for Linux: Version 10.2.0.4.0 - Production on 21-JUN-2016 21:19:56 Copyright (c) 1991, 2007, Oracle. All rights reserved. Connecting to (ADDRESS=(PROTOCOL=tcp

oracle 登录数据库时报 无监听 的一种解决方式(监听日志文件达到4g默认上限)

问题:登录服务器时 报无监听服务 检查步骤: 1.进入sqlplus查看数据库的状态,显示当前数据库的状态为OPEN 脚本:select status from v$Instance; 2.检查数据库的监听服务,登录的时候发现进入监听程序的速度非常慢 脚本:lsnrctl status 3.查看监听日志的大小,位置如下: $ORACLE_BASE\diag\tnslsnr\<hostname>\listener\trace\ 5.重启启动监听即可: lsnrctl stop  停止 lsnrc

11g生产环境监听日志告警问题处理-Subscription?for

1.系统报错 Command:?failed????????stdout:?yes???????????stderr:?no Before?command?completion,?additional?instructions?may?appear?below. Initializing?mkcd?log:?/var/adm/ras/mkcd.log... Verifying?command?parameters... Creating?image.data?file... Creating?m

Oracle 11g 监听很慢,由于监听日志文件太大引起的问题(Windows 下)

现象:Windows 操作系统的Oracle 数据库,使用sqlplus 连接(不指定实例名)连接很快,程序连接或使用连接工具或在Net Manager 中测试连接都需要花费约三四十秒的时间(程序连接可能失败). 通过tsping localhost 测试,亦花费三四十秒. 查看监听警告日志(所在位置在文章后面介绍),有信息如下: <msg time='2017-05-16T16:57:51.811+08:00' org_id='oracle' comp_id='tnslsnr' type='U