时间同步引起的oracle故障

zpjx

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