使用shell脚本查看数据库负载情况(第二篇)(r3笔记第92天)
在之前写了一个shell脚本,能够得到一个基于时间点的数据库负载报告。 使用shell脚本查看数据库负载情况 http://blog.itpub.net/23718752/viewspace-1168027/ 在生产环境中快照的生成频率可能10分钟或者半个小时就会生成,频率要快些,使用原先的脚本执行起来会有一定的延时。 想查看在快照的时间间隔内数据库的负载情况。这样能够更高效的定位某个问题。比如10点到11点,每10分钟生成一次快照。可能问题发生在10:40~10:50,如果通过一个小时的快照就不一定能够准确的定位问题。 我尝试了如下的脚本,能够很清晰地 列出快照信息和数据库的负载情况。
sqlplus -s $DB_CONN_STR@$SH_DB_SID <<EOF break on db_name set pages 50 set linesize 100 prompt prompt Current Instance prompt ~~~~~~~~~~~~~~~~ select d.dbid dbid , d.name db_name , i.instance_number inst_num , i.instance_name inst_name from v$database d, v$instance i; select db_name ,begin_snap ,end_snap ,snapdate ,lvl ,round(((END_INTERVAL_TIME+0)-(BEGIN_INTERVAL_TIME+0 ))*24*60) duration_mins ,round((select round((sum(e.value) - sum(b.value)) / 1000000 /60,2) dbtime FROM DBA_HIST_SYS_TIME_MODEL e, DBA_HIST_SYS_TIME_MODEL b WHERE e.STAT_NAME = 'DB time' and b.snap_id=begin_snap and e.snap_id =end_snap AND b.STAT_NAME = 'DB time' group by e.snap_id,b.snap_id)) dbtime from ( select di.db_name db_name , s.snap_id begin_snap ,lead(s.snap_id ,1,s.snap_id ) over(order by s.end_interval_time ) end_snap , to_char(s.end_interval_time,'dd Mon YYYY HH24:mi') snapdate , s.snap_level lvl ,s.end_interval_time ,s.begin_interval_time from dba_hist_snapshot s , dba_hist_database_instance di where ( di.dbid,di.instance_number) in (select d.dbid dbid , i.instance_number inst_num from v$database d, v$instance i) and di.dbid = s.dbid and di.instance_number = s.instance_number and di.startup_time = s.startup_time and to_char(END_INTERVAL_TIME,'yyyymmdd')='$1' and EXTRACT(HOUR FROM END_INTERVAL_TIME) between $2-1 and $3+1 order by db_name, instance_name, snap_id ); EOF
脚本的执行情况如下,生成的快照信息会前后顺延一个小时,比如查看10点到11点的信息,会列出9点到12点的信息。
> ksh showsnap2.sh 20141222 10 11 Current Instance ~~~~~~~~~~~~~~~~ DBID DB_NAME INST_NUM INST_NAME ---------- --------- ---------- ---------------- 3100077577 XXXXXX 1 XXXXXX DB_NAME BEGIN_SNAP END_SNAP SNAPDATE LVL DURATION_MINS DBTIME --------- ---------- ---------- ----------------- ---------- ------------- ---------- XXXXXX 24597 24598 22 Dec 2014 09:00 1 10 374 24598 24599 22 Dec 2014 09:10 1 10 180 24599 24600 22 Dec 2014 09:20 1 10 193 24600 24601 22 Dec 2014 09:30 1 10 114 24601 24602 22 Dec 2014 09:40 1 9 156 24602 24603 22 Dec 2014 09:50 1 10 171 24603 24604 22 Dec 2014 10:00 1 10 220 24604 24605 22 Dec 2014 10:10 1 10 214 24605 24606 22 Dec 2014 10:20 1 10 256 24606 24607 22 Dec 2014 10:30 1 10 270 24607 24608 22 Dec 2014 10:40 1 10 1288 24608 24609 22 Dec 2014 10:50 1 10 346 24609 24610 22 Dec 2014 11:00 1 10 350 24610 24611 22 Dec 2014 11:10 1 10 398 24611 24612 22 Dec 2014 11:20 1 10 355 24612 24613 22 Dec 2014 11:30 1 10 295 24613 24614 22 Dec 2014 11:40 1 10 318 24614 24615 22 Dec 2014 11:50 1 10 338 24615 24616 22 Dec 2014 12:00 1 10 355 24616 24617 22 Dec 2014 12:10 1 10 288 24617 24618 22 Dec 2014 12:20 1 10 257 24618 24619 22 Dec 2014 12:30 1 10 255 24619 24620 22 Dec 2014 12:40 1 10 255 24620 24620 22 Dec 2014 12:50 1 10 0
可以很清晰的看到在10:40~10:550的时候,负载异常的高,可以针对这种情况抓取一个awr报告来详细的分析一下。
优质内容筛选与推荐>>