时间同步引起的oracle故障

    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;

    对这个问题的分析，还是粗心大意所导致，在修改时间前多检查几遍是完全可以避免的。不过话有说回来，这个问题不出现上面的知识点也不会熟悉的，不过还是要小心为妙，避免这种低级错误的再次发生。

    希望遇到此类问题的朋友探讨指点，谢谢！

©著作权归作者所有：来自51CTO博客作者srsunbing的原创作品，如需转载，请注明出处，否则将追究法律责任

oracle自动维护任务oracle维护