Re: Why alter table move can repair the problem awr not generated ?

From: Niall Litchfield <niall.litchfield_at_gmail.com>
Date: Mon, 6 Jan 2014 11:31:09 +0000
Message-ID: <CABe10sYOpacSN9F+3aZs0SgvTo+2MVj-t9Ui+GrTeH95g0x+oA_at_mail.gmail.com>

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_at_gmail.com> 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_at_gmail.com> 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_at_gmail.com> 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

--
http://www.freelists.org/webpage/oracle-l

Received on Mon Jan 06 2014 - 12:31:09 CET