Database in quiesce mode

On Tue, 26 Aug 2008 07:50:42 +0200, Shakespeare wrote:

> "joel garry" schreef in bericht
> news:15ab9b7b-d291-4120-a15c-
fc3ff59049c5-at-w39g2000prb.googlegroups.com...
> On Aug 25, 3:25 am, "Shakespeare" wrote:
>> "Mladen Gogala" schreef in
>> berichtnews:48b16e63$0$15596$834e42db-at-reader.great nowhere.com...
>>
>>
>>
>>
>>
>> > On Sat, 23 Aug 2008 21:19:36 +0200, Shakespeare wrote:
>>
>> >> I have a client using 10.2.0.4 64 bit on AIX. After an upgrade from
>> >> 9 to
>> >> 10, his database went (after running for about 15 hours) into
>> >> quiesce mode without anyone specifically performing such an action.
>> >> (Unfortunately, no more specific data available right now; only
>> >> thing he
>> >> noticed in the alert log was a log writer switch on redo01.log when
>> >> this
>> >> happened).
>> >> After a while, his Database went unquiesce again. I searched docs,
>> >> metalink, Google but did not find a clue why a Database would do this all
>> >> by itself. A) Is this possible anyway?
>> >> B) What could cause this?
>>
>> >> Thanks,
>>
>> >> Shakespeare
>>
>> > Something like that should be recorded in the alert log. Posting the
>> > relevant information from the alert log would certainly help people
>> > on this group during the diagnostic process.
>>
>> > --
>> >http://mgogala.freehostia.com
>>
>> This is the part of the alert log:
>>
>> > Mon Aug 25 11:21:09 2008
>> > Thread 1 advanced to log sequence 3080 (LGWR switch) Current log# 3
>> > seq# 3080 mem# 0: /oradata/xmcp/redo03.log Current log# 3 seq# 3080
>> > mem# 1: /oradata/xmcp/redo03b.log Current log# 3 seq# 3080 mem# 2:
>> > /oradata/xmcp/redo03c.log Mon Aug 25 11:44:11 2008
>> > Database in quiesce mode
>> > Mon Aug 25 11:48:39 2008
>> > Thread 1 advanced to log sequence 3081 (LGWR switch) Current log# 2
>> > seq# 3081 mem# 0: /oradata/xmcp/redo02.log Current log# 2 seq# 3081
>> > mem# 1: /oradata/xmcp/redo02b.log Current log# 2 seq# 3081 mem# 2:
>> > /oradata/xmcp/redo02c.log Mon Aug 25 11:50:29 2008
>> > Database out of quiesce mode
>>
>> Thanks,
>> Shakeespeare
>
> Wondering if Note:559298.1 is a clue - perhaps something is obscurely
> associated with quiescing. The timing looks very suspicious to me.


However, you should audit the "alter database" privilege to see what
executes it and when.
--
Mladen Gogala
http://mgogala.freehostia.com

"Mladen Gogala" schreef in bericht
news:48b5356c$0$15592$834e42db-at-reader.greatnowhere .com...
> On Tue, 26 Aug 2008 07:50:42 +0200, Shakespeare wrote:
>
>> "joel garry" schreef in bericht
>> news:15ab9b7b-d291-4120-a15c-
> fc3ff59049c5-at-w39g2000prb.googlegroups.com...
>> On Aug 25, 3:25 am, "Shakespeare" wrote:
>>> "Mladen Gogala" schreef in
>>> berichtnews:48b16e63$0$15596$834e42db-at-reader.great nowhere.com...
>>>
>>>
>>>
>>>
>>>
>>> > On Sat, 23 Aug 2008 21:19:36 +0200, Shakespeare wrote:
>>>
>>> >> I have a client using 10.2.0.4 64 bit on AIX. After an upgrade from
>>> >> 9 to
>>> >> 10, his database went (after running for about 15 hours) into
>>> >> quiesce mode without anyone specifically performing such an action.
>>> >> (Unfortunately, no more specific data available right now; only
>>> >> thing he
>>> >> noticed in the alert log was a log writer switch on redo01.log when
>>> >> this
>>> >> happened).
>>> >> After a while, his Database went unquiesce again. I searched docs,
>>> >> metalink, Google but did not find a clue why a Database would do this all
>>> >> by itself. A) Is this possible anyway?
>>> >> B) What could cause this?
>>>
>>> >> Thanks,
>>>
>>> >> Shakespeare
>>>
>>> > Something like that should be recorded in the alert log. Posting the
>>> > relevant information from the alert log would certainly help people
>>> > on this group during the diagnostic process.
>>>
>>> > --
>>> >http://mgogala.freehostia.com
>>>
>>> This is the part of the alert log:
>>>
>>> > Mon Aug 25 11:21:09 2008
>>> > Thread 1 advanced to log sequence 3080 (LGWR switch) Current log# 3
>>> > seq# 3080 mem# 0: /oradata/xmcp/redo03.log Current log# 3 seq# 3080
>>> > mem# 1: /oradata/xmcp/redo03b.log Current log# 3 seq# 3080 mem# 2:
>>> > /oradata/xmcp/redo03c.log Mon Aug 25 11:44:11 2008
>>> > Database in quiesce mode
>>> > Mon Aug 25 11:48:39 2008
>>> > Thread 1 advanced to log sequence 3081 (LGWR switch) Current log# 2
>>> > seq# 3081 mem# 0: /oradata/xmcp/redo02.log Current log# 2 seq# 3081
>>> > mem# 1: /oradata/xmcp/redo02b.log Current log# 2 seq# 3081 mem# 2:
>>> > /oradata/xmcp/redo02c.log Mon Aug 25 11:50:29 2008
>>> > Database out of quiesce mode
>>>
>>> Thanks,
>>> Shakeespeare
>>
>> Wondering if Note:559298.1 is a clue - perhaps something is obscurely
>> associated with quiescing. The timing looks very suspicious to me.
>
>
> However, you should audit the "alter database" privilege to see what
> executes it and when.
> --
> Mladen Gogala
> http://mgogala.freehostia.com

Good tip! It has not occured since last Monday, but it won't hurt to audit !

Shakespeare

On 23 aug, 21:19, "Shakespeare" wrote:
> I have a client using 10.2.0.4 64 bit on AIX.
> After an upgrade from 9 to 10, his database went (after running for about 15
> hours) into quiesce mode without anyone specifically performing such an
> action. (Unfortunately, no more specific data available right now; only
> thing he noticed in the alert log was a log writer switch on redo01.log when
> this happened).
> After a while, his Database went unquiesce again. I searched docs, metalink,
> Google but did not find a clue why a Database would do this all by itself.
> A) Is this possible anyway?
> B) What could cause this?
>
> Thanks,
>
> Shakespeare

It appears one of the DBA's was installing Enterprise Manager using
EMCA. This puts the database in quiesce mode....

Shakespeare

On Wed, 03 Sep 2008 07:39:33 -0700, Shakespeare wrote:

> It appears one of the DBA's was installing Enterprise Manager using
> EMCA. This puts the database in quiesce mode....

That is what the capital punishment was invented for.



--
http://mgogala.freehostia.com

"Mladen Gogala" schreef in bericht
news:g9ma6u$9me$3-at-registered.motzarella.org...
> On Wed, 03 Sep 2008 07:39:33 -0700, Shakespeare wrote:
>
>> It appears one of the DBA's was installing Enterprise Manager using
>> EMCA. This puts the database in quiesce mode....
>
> That is what the capital punishment was invented for.
>
>
>
> --
> http://mgogala.freehostia.com

Yes... another case of "We did nothing and still something changed...."

Shakespeare