在之前写了一个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
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报告来详细的分析一下。