時間同步引起的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;
    對這個問題的分析，還是粗心大意所導致，在修改時間前多檢查幾遍是完全可以避免的。不過話有說回來，這個問題不出現上面的知識點也不會熟悉的，不過還是要小心為妙，避免這種低級錯誤的再次發生。
    希望遇到此類問題的朋友探討指點，謝謝！

1 2 下一頁