4月6日周五同步了一次服务器时间,谁知一时疏忽把4月6日写成了6月6日,等所有的机器时间同步后才发现改错了,赶紧进行了修改,登陆数据库检查发现有大量的日志切换,回滚表空间急剧增长,时间改正后这两个现象消失,观察发现进程、内存、CPU基本正常,就没有太多关注(周末休息)。
部分Oracle告警日志见下:
Wed Jun 06 18:24:24 2012
Thread 1 cannot allocate new log, sequence 1505
Checkpoint not complete
Current log# 4 seq# 1504 mem# 0: /u01/app/oracle/oradata/ytkdb/redo07.log
Current log# 4 seq# 1504 mem# 1: /home/oracle/oralog/REDO08.LOG
Thread 1 advanced to log sequence 1505 (LGWR switch)
Current log# 3 seq# 1505 mem# 0: /u01/app/oracle/oradata/ytkdb/redo03.log
Current log# 3 seq# 1505 mem# 1: /home/oracle/oralog/REDO06.LOG
周一9日早上来检查备份情况,发现备份文件只有日常的20到30分之一,大吃一惊应该有遗漏的错误地方没有被发现,检查日志发现下面的日志部分到4月5日后就没有了,应该是oracle的自动维护任务被停用了。
Thu Apr 05 22:00:00 2012
Setting Resource Manager plan SCHEDULER[0x310A]:DEFAULT_MAINTENANCE_PLAN via scheduler window
Setting Resource Manager plan DEFAULT_MAINTENANCE_PLAN via parameter
Thu Apr 05 22:00:00 2012
Starting background process VKRM
Thu Apr 05 22:00:00 2012
VKRM started with pid=19, OS id=9365
Thu Apr 05 22:00:02 2012
Begin automatic SQL Tuning Advisor run for special tuning task "SYS_AUTO_SQL_TUNING_TASK"
赶紧检查 sys.dba_jobs 试图发现有 APEX_030200、SYSMAN 用户的3个试图 NEXT_DATE 下次运行时间等于'2012-06-07 19:57:30',分别登陆到 APEX_030200、SYSMAN 下进行了时间修改,修改完后观察运行正常,也就未进行深入分析。
第二天10日早上来检查备份情况 ,发现备份文件还是很少,日志中也没有oracle的自动维护运行记录,看来还是有问题,检查维护窗口的试图 DBA_SCHEDULER_WINDOWS 、 DBA_SCHEDULER_WINDOW_GROUPS 发现
next_start_date 下次开始时间等于‘ 07-6月 -12 10.00.00.000000 下午 PRC’,还是时间不对,对这个时间做如下修改,用 DBMS_SCHEDULER 包中的 set_attribute 存储过程来修改:
--重新设置窗口的运行属性:
BEGIN
DBMS_SCHEDULER.set_attribute(name => 'MONDAY_WINDOW',
attribute => 'start_date',
value => '12-4月 -12 10.00.00.000000 下午 PRC'
);
DBMS_SCHEDULER.set_attribute(name => 'TUESDAY_WINDOW',
attribute => 'start_date',
value => '12-4月 -12 10.00.00.000000 下午 PRC'
);
DBMS_SCHEDULER.set_attribute(name => 'WEDNESDAY_WINDOW',
attribute => 'start_date',
value => '12-4月 -12 10.00.00.000000 下午 PRC'
);
DBMS_SCHEDULER.set_attribute(name => 'THURSDAY_WINDOW',
attribute => 'start_date',
value => '12-4月 -12 10.00.00.000000 下午 PRC'
);
DBMS_SCHEDULER.set_attribute(name => 'FRIDAY_WINDOW',
attribute => 'start_date',
value => '12-4月 -12 10.00.00.000000 下午 PRC'
);
DBMS_SCHEDULER.set_attribute(name => 'SATURDAY_WINDOW',
attribute => 'start_date',
value => '12-4月 -12 10.00.00.000000 下午 PRC'
);
DBMS_SCHEDULER.set_attribute(name => 'SUNDAY_WINDOW',
attribute => 'start_date',
value => '12-4月 -12 10.00.00.000000 下午 PRC'
);
END;
/
--注:name 的值,来源于 SELECT * FROM DBA_SCHEDULER_WINDOWS; 的 window_name的值。存储过程的详细说明见包中的注释。
修改后检查试图发现时间已经改正,晚上22点运行,结果只能等第二天看了,试图见下:
SELECT * FROM DBA_SCHEDULER_WINDOWS t ;
SELECT * FROM DBA_SCHEDULER_WINDOW_GROUPS ;
第二天再次检查备份,发现文件基本合理,日志中出现了下面的内容:
Thu Apr 12 22:00:00 2012
Starting background process VKRM
Thu Apr 12 22:00:00 2012
VKRM started with pid=42, OS id=18062
Thu Apr 12 22:00:02 2012
Begin automatic SQL Tuning Advisor run for special tuning task "SYS_AUTO_SQL_TUNING_TASK"
--注:VKRM进程 : Virtual sKeduler for Resource Manager
检查 select * from dba_tables t 发现 last_analyzed 最后分析时间为‘2012-04-12 22:00:28’,问题到此基本结束,下来再观察一段时间看是否有异常。
--补充几个相关的试图见下:
SELECT * FROM DBA_SCHEDULER_WINDOWS t ;
SELECT * FROM DBA_SCHEDULER_WINDOW_GROUPS;
SELECT * FROM DBA_SCHEDULER_WINGROUP_MEMBERS;
SELECT * FROM V$RSRC_PLAN;
SELECT JOB_NAME, STATE FROM DBA_SCHEDULER_JOBS;
SELECT * FROM ALL_SCHEDULER_RUNNING_JOBS;
SELECT * FROM ALL_SCHEDULER_RUNNING_CHAINS ;
--运行日志:
SELECT to_char(log_date, 'DD-MON-YY HH24:MM:SS') TIMESTAMP,
job_name, job_class, operation, status
FROM USER_SCHEDULER_JOB_LOG t
where t.log_date >='04-4月 -12 10.00.00.000000 下午 PRC';
select to_char(log_date, 'DD-MON-YY HH24:MM:SS') TIMESTAMP ,
t.owner,t.job_name,t.job_subname,t.status,t.error#
from dba_scheduler_job_run_details t
where log_date >= '11-4月-12 10.01.42.998766 下午 +08:00';
--数据库自动维护任务的试图:
select * from sys.dba_autotask_client t;
select * from sys.dba_autotask_client_job t;
select * from sys.dba_autotask_client_history t;
select * from sys.dba_autotask_job_history t;
select * from sys.dba_autotask_window_clients t;
select * from sys.dba_autotask_window_history t;
对这个问题的分析,还是粗心大意所导致,在修改时间前多检查几遍是完全可以避免的。不过话有说回来,这个问题不出现上面的知识点也不会熟悉的,不过还是要小心为妙,避免这种低级错误的再次发生。
希望遇到此类问题的朋友探讨指点,谢谢!