oracle的自动维护任务带来了自动化性能维护的好处,也同时带来了资源开销,合理正确的使用才能发挥作用,同时应注意它的启动时间,错峰进行。
1、oracle有三种预定义的自动维护任务,在创建数据库的时候,有一个选项,默认是开启的。
■ Automatic Optimizer Statistics Collection
■ Automatic Segment Advisor
■ Automatic SQL Tuning Advisor(oracle 11g)
属于维护窗口组:MAINTENANCE_WINDOW_GROUP
跟踪job运行情况:
视图:DBA_AUTOTASK_HISTORY
select client_name,job_name,job_start_time from dba_autotask_job_history;
维护窗口调度一般是在周一到周五的晚上22:00启动,运行4个小时,周六、日06:00启动,执行20个小时,表的统计信息、优化建议等都会收集。该维护任务是比较耗资源的,根据业务高峰时段,需要作出调整,甚至停用,而改为自定义执行统计信息等。
维护窗口是以scheduler job启动的,它依赖scheduler的时间策略配置,这次在客户环境上就遇到由于scheduler的时区问题,导致窗口在白天运行了,占用了大量IO资源,白天也是客户的业务高峰时段。
2、客户案例
awr报告:
![c3c6577535812d373f173c9a01e2ac957f251281](https://yqfile.alicdn.com/c3c6577535812d373f173c9a01e2ac957f251281.png?x-oss-process=image/resize,w_1400/format,webp)
resmgr:cpu quantum等待事件出现,是
resource manager有关的等待事件,resource manager运行时,会控制cpu的资源使用,其他session会进入申请资源等待中。查看alert日志,该时段确实运行了该窗口
Sat Aug 19 13:00:00 2017
Setting Resource Manager plan SCHEDULER[0x32DD]:DEFAULT_MAINTENANCE_PLAN via scheduler window
Setting Resource Manager plan DEFAULT_MAINTENANCE_PLAN via parameter
Sat Aug 19 13:00:00 2017
Starting background process VKRM
Sat Aug 19 13:00:00 2017
VKRM started with pid=191, OS id=2988
Sat Aug 19 13:00:02 2017
Begin automatic SQL Tuning Advisor run for special tuning task "SYS_AUTO_SQL_TUNING_TASK"
Sat Aug 19 13:04:13 2017
Thread 1 advanced to log sequence 1136629 (LGWR switch)
客户反馈说数据库使用统一的模板创建,其他库正常,有2个库该资源运行不正常,时间配置是一样的,于是进行检查。
select WINDOW_NAME,RESOURCE_PLAN,START_DATE,END_DATE,NEXT_START_DATE ,ACTIVE from DBA_SCHEDULER_WINDOWS;
客户问题环境:
![d2a7f6b8ebda1ec2b6859e17d7c18016f41dc47f](https://yqfile.alicdn.com/d2a7f6b8ebda1ec2b6859e17d7c18016f41dc47f.png?x-oss-process=image/resize,w_1400/format,webp)
我的正常环境:
![43a0181030d68d6f76046ac573c63dc4f76785a7](https://yqfile.alicdn.com/43a0181030d68d6f76046ac573c63dc4f76785a7.png?x-oss-process=image/resize,w_1400/format,webp)
发现调度窗口的时间虽然正确,但是后面的时区不正确,问题环境的窗口使用的是PST8PDT(
美国的太平洋标准时间,西8区),而我的正常环境是RPC(
中国时区)。
查看数据库的时区
问题库:
![153d0244748098cd4e790ddefc91b729f2f2c197](https://yqfile.alicdn.com/153d0244748098cd4e790ddefc91b729f2f2c197.png?x-oss-process=image/resize,w_1400/format,webp)
正常的测试库:
![6aa7b73572029a351e7c3c13f7ea0a91c1aeca2f](https://yqfile.alicdn.com/6aa7b73572029a351e7c3c13f7ea0a91c1aeca2f.png?x-oss-process=image/resize,w_1400/format,webp)
我的测试库:
![762611fce72d47e710032974706765487bdf8206](https://yqfile.alicdn.com/762611fce72d47e710032974706765487bdf8206.png?x-oss-process=image/resize,w_1400/format,webp)
和问题库一样的,但是我的scheduler运行就没有问题,应该问题还是出在scheduler调度时间使用了不正确的时区。
检查scheduler的时区配置:
问题库:
![570d5883cfa2b4fee056d86dba1aff07e174fd1b](https://yqfile.alicdn.com/570d5883cfa2b4fee056d86dba1aff07e174fd1b.png?x-oss-process=image/resize,w_1400/format,webp)
我的测试库:
![2882ab2ca24d20e22339035d8942edccef25c0c6](https://yqfile.alicdn.com/2882ab2ca24d20e22339035d8942edccef25c0c6.png?x-oss-process=image/resize,w_1400/format,webp)
问题就出在这里,修改scheduler配置的时区:
begin
DBMS_SCHEDULER.SET_SCHEDULER_ATTRIBUTE ('default_timezone','PRC');
end;
/
调整window的调度
BEGIN
dbms_scheduler.disable(
--这里要先disable,再修改启用才会生效
name => 'MONDAY_WINDOW');
dbms_scheduler.set_attribute(
name => 'MONDAY_WINDOW',
attribute => 'REPEAT_INTERVAL',
value => 'freq=daily;byday=MON;byhour=22;byminute=0; bysecond=0');
dbms_scheduler.enable(
name => 'MONDAY_WINDOW');
END;
/
第二天确认任务已经在正确的时间调度了,等待事件也消失了。