So my memory wasn't good :) As you remark it's mmon which is performing the snap. Your trace file matches case 1 in the note you reference and a number of bugs in different versions. This looks like a "talk to support" problem to me. On Mon, Jan 6, 2014 at 9:02 AM, LuoLee.me <luolee.me@xxxxxxxxx> wrote: > Dear Niall, > Thanks for your quick reply. > When the awr did not generate, there was some errors in the mmon trace > file: > *** KEWRAFC: Flush slave failed, AWR Enqueue Timeout > *** 2014-01-04 17:48:56.411 > *** KEWRAFC: Flush slave failed, AWR Enqueue Timeout > *** 2014-01-04 17:49:56.455 > *** KEWRAFC: Flush slave failed, AWR Enqueue Timeout > > I didn't seen some messages in the dba_scheduler_job_run_details.There > is some log in the dba_scheduler_job_run_details. > > JOB_NAME STATUS STAT_TIME RUN_DURATION ERROR# > RLM$SCHDNEGACTION SUCCEEDED 2014-01-05 00:17:46 +000 00:00:00 0 > RLM$EVTCLEANUP SUCCEEDED 2014-01-04 23:43:25 +000 00:00:00 0 > RLM$SCHDNEGACTION SUCCEEDED 2014-01-04 23:20:10 +000 00:00:00 0 > RLM$EVTCLEANUP SUCCEEDED 2014-01-04 22:43:25 +000 00:00:00 0 > RLM$SCHDNEGACTION SUCCEEDED 2014-01-04 22:22:34 +000 00:00:01 0 > RLM$EVTCLEANUP SUCCEEDED 2014-01-04 21:43:25 +000 00:00:00 0 > RLM$SCHDNEGACTION SUCCEEDED 2014-01-04 21:24:58 +000 00:00:00 0 > RLM$EVTCLEANUP SUCCEEDED 2014-01-04 20:43:25 +000 00:00:00 0 > RLM$SCHDNEGACTION SUCCEEDED 2014-01-04 20:27:22 +000 00:00:00 0 > > Please pay attention that I repair the awr problem after 2014-01-04 > 22:30:00 followed the MOS ID: 787409.1 > > All the best, > Mobile: +8615651803071 > Blog: http://luolee.me > > On 2014/1/6 14:41:07, Niall Litchfield <niall.litchfield@xxxxxxxxx> wrote: > > We'll need the error encountered by the AWR snapshot job to determine a > suitable answer. (which may of course be that it was a coincidence). You > can find this (if my memory is good) in dba_scheduler_job_run_details. > On Jan 6, 2014 1:59 AM, "LuoLee.me" <luolee.me@xxxxxxxxx> wrote: > >> Dear list, >> I meet a problem that awr snapshot didn't generate correctly last >> week. I attempt to truncate the table sys.WRI$_OPTSTAT_HISTHEAD_HISTORY, >> but it didn't take effect. >> The other way, I use the "alter table >> sys.WRI$_OPTSTAT_HISTHEAD_HISTORY move" in restricted mode, it >> became effect. I know the way that truncate the table could do it >> sometimes, but this time, it fails. >> >> We all know that "alter table move" could lower the highest >> watermark, but why it can repair the awr not generated problem, and why >> truncate could not here. >> Anyone know the truth ? >> Thanks in advance. >> > -- Niall Litchfield Oracle DBA http://www.orawin.info