Oracle faults caused by Time Synchronization

On Friday, April 6, a server time was synchronized. Who could have neglected to write April 6 as June 6? After all the machine time synchronization, I found that I had corrected the mistake and made changes quickly, log on to the database and check that there are a large number of log switches, and the rollback tablespace increases dramatically. After the time correction, the two phenomena disappear. We can see that the process, memory, and CPU are basically normal, there is not much attention (weekend break ).
For some Oracle alarm logs, see:
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
On Monday 9, I checked the backup information and found that the backup file was only 20 to 30 minutes in a routine manner. I was surprised that the missing errors were not found, check the log and find that the following logs will not be available after January 1, April 5. It should be because the oracle automatic maintenance task has been disabled.
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"
Check sys. dba_jobs tries to find that the next run time of three attempted NEXT_DATE users (APEX_030200 and SYSMAN users) is '2017-06-07 19:57:30 ', respectively, and logs on to APEX_030200 and SYSMAN for time modification, after modification, observe that the operation is normal, and no in-depth analysis is performed.
Check the backup information on the morning of the next day and find that there are still few backup files, and there is no oracle automatic maintenance operation record in the log. It seems that there is still a problem. Check the maintenance window's attempt to DBA_SCHEDULER_WINDOWS
Next_start_date the next start time is equal to '07-6-12 10.00.00.000000 afternoon prc'. The time is still incorrect. Modify the time as follows and use the set_attribute stored procedure in the DBMS_SCHEDULER package to modify it:
-- Reset the running properties of the window:
BEGIN
DBMS_SCHEDULER.set_attribute (name => 'Monday _ Window ',
Attribute => 'start _ date ',
Value => '12-April-12 10.00.00.000000 PM prc'
);
DBMS_SCHEDULER.set_attribute (name => 'tuesday _ Window ',
Attribute => 'start _ date ',
Value => '12-April-12 10.00.00.000000 PM prc'
);
DBMS_SCHEDULER.set_attribute (name => 'wednesday _ Window ',
Attribute => 'start _ date ',
Value => '12-April-12 10.00.00.000000 PM prc'
);
DBMS_SCHEDULER.set_attribute (name => 'Thursday _ Window ',
Attribute => 'start _ date ',
Value => '12-April-12 10.00.00.000000 PM prc'
);
DBMS_SCHEDULER.set_attribute (name => 'Friday _ Window ',
Attribute => 'start _ date ',
Value => '12-April-12 10.00.00.000000 PM prc'
);
DBMS_SCHEDULER.set_attribute (name => 'Saturday _ Window ',
Attribute => 'start _ date ',
Value => '12-April-12 10.00.00.000000 PM prc'
);
DBMS_SCHEDULER.set_attribute (name => 'Sunday _ Window ',
Attribute => 'start _ date ',
Value => '12-April-12 10.00.00.000000 PM prc'
);
END;
/
-- Note: the value of name comes FROM the window_name value of SELECT * FROM DBA_SCHEDULER_WINDOWS. For detailed descriptions of stored procedures, see the annotations in the package.
After modification, check to find that the time has been corrected and run at pm. The result can only be viewed the next day. For details, see:
SELECT * FROM DBA_SCHEDULER_WINDOWS t;
SELECT * FROM DBA_SCHEDULER_WINDOW_GROUPS;
Check the backup again the next day and find that the file is basically reasonable. The following content appears in the log:
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"
-- Note: VKRM process: Virtual sked for Resource Manager
Check select * from dba_tables t and find that the last analysis time of last_analyzed is '2017-04-12 22:00:28 '. The problem ends at this point. Then, check whether an exception exists for a while.

-- To add several related attempts, see:
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;

-- Run log:
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-April 10.00.00.000000 PM 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-October 11-12 10.01.42.998766 PM + ';
 
-- Attempts to perform automatic database maintenance tasks:
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;
The analysis of this problem is still caused by carelessness. It is completely avoided to check it several times before the modification time. However, you may not be familiar with the above knowledge points, but you should be careful to avoid the occurrence of such low-level errors.
I hope you will discuss this kind of problem. Thank you!

1 2 Next Page