时间同步引起的Oracle故障

时间同步引起的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;
    对这个问题的分析，还是粗心大意所导致，在修改时间前多检查几遍是完全可以避免的。不过话有说回来，这个问题不出现上面的知识点也不会熟悉的，不过还是要小心为妙，避免这种低级错误的再次发生。
    希望遇到此类问题的朋友探讨指点，谢谢！