ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 如何定义statspack作业的工作时间,让作业只在工作时间采集系统的数据

如何定义statspack作业的工作时间,让作业只在工作时间采集系统的数据

原创 Linux操作系统 作者:ZALBB 时间:2019-03-26 08:09:07 0 删除 编辑

这篇总结应该在几个月前写的,但自己一直懒得动笔,拖到现在!

BITI在这篇文章(http://www.itpub.net/268049.html)里提到了,
只在高峰期对数据库作statspack,当时他提到了该JOB的间隔时间,
******************************************************
每天 8/9/10/15/16/17/23 7个整点执行的报告

job interval

trunc(sysdate) + decode(to_char(sysdate,'hh24'),8,9,9,10,10,15,15,16,16,17,17,23,32)/24

因为8---10点 和 15---17 点是高峰期

这是长期统计观察的依据,不是碰巧
********************************************************
对于statspack的工作时间,我也一直很郁闷,因为不知道该如何定制
作业的工作时间,和BITI一样,我也只需要在工作时间采集系统数据库,
下了班,半夜,也想让它歇着,因为我一直担心JOB不断的运行,会把
分配给perfstat用户的空间给撑爆了,导致系统异常。但在看到BITI的
此文章之前,我一直想不到什么好方法。


当我重新思考这个问题时,距离我第1次看到此篇文章时,已经大半年了,
由于最初阅读文章时,只是大概浏览一下,在涉及到statspack的时间定制
方面,印象中,只记得他用了decode,每次间隔一小时,至于其中如何写,
当我重新当时思考时,没有丝毫的印象,这样也好,自己独立思考,避免
受原来思想禁锢。

对BITI的写法,我有两个不满意的地方,
1、间隔1小时,我认为时间太长,我希望是间隔40分钟。
2、他的写法里罗列了8,9,15,17等这些时间,我觉得这些重复的地方应该
可以改进。

我最终找到这个写法时,大概断断续续用了3-4天的思考,也作了些测试,
起初是先满足在指定的时间运行,也就是BITI现在的写法。
其次,改写了间隔时间,由1小时改写成40分钟,这一改动花了比较长的时间。
记得当时是在车站等353路车的时候,想起了,trunc(sysdate,'MI')的用法,
心情很激动,似乎茅塞顿开,急着想测试,但当时在候车,无条件作测试,
按耐着心情回到家里,用家里那破旧的电脑,VPN连接上公司的主机上来的
琢磨。
最后,是去掉重复的时间点。即:8,9,9,10,10,15 等,也憋了一阵,
当时似乎总觉得可以省掉,但又一下找不到答案,憋着憋着,才想到用
decode方法中other 来实现,想来这应该就是功夫不负苦心人吧。

我最终思考到的写法是:
INTERVAL =
------------------------------------------------------------------------------------
TRUNC(SYSDATE,'MI')+DECODE(TO_CHAR(SYSDATE,'HH24:MI'),'11:30',1/8,'18:30',5/8,1/36)

换成实际JOB的运行时间是:9:30,10:10,10:50,11:30--14:30,15:10,,,17:50,18:30
然后第2天的又重复此时间表.

这种写法有一个隐患,即若数据库系统负荷很重,JOB没能在指定的某一个时间点
(分)运行,比如:JOB在早上9:31分运行,则从此,作业不会在此指定的时间范围运行。
也就是,作业变成了每40分钟运行一次,中途不会如原来那样,11:30到14:30,18:30到
第2天9:30 间停歇。但据经验,ORACLE重来不会把作业拖迟一分钟后才执行,因此,这种
写法还是比较可靠的。

至于想要在指定的日期运行,或者说,在周六,周日不运行,我估计使用JOB的INTERVAL
是很难实现的,估计用DBMS_SCHEDULER来实现会简单些。

2006-09-26

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/1112/viewspace-103719/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2018-08-15

  • 博文量
    19
  • 访问量
    12986