Database in quiesce mode

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

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

Hallo Shakespeare,

We have the same problem, last week we have upgraded to 10.2.0.4 on
AIX 5.2 64 bit.
And at the moment we have already 2 times a quiesce mode.
In the alert log is written:
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

LouisDBA.

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

schreef in bericht
news:0bfd342d-7ba1-4f18-8ba3-6b002343c840-at-79g2000hsk.googlegroups.com...
> Hallo Shakespeare,
>
> We have the same problem, last week we have upgraded to 10.2.0.4 on
> AIX 5.2 64 bit.
> And at the moment we have already 2 times a quiesce mode.
> In the alert log is written:
> 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
>
> LouisDBA.
>
> 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
>

Hello Louis,

this looks EXACTLY like our problem! We'll investigate this, and will report
here!

Shakespeare

"Mladen Gogala" schreef in bericht
news:48b16e63$0$15596$834e42db-at-reader.greatnowhere .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,
Shakespeare

louis.szarzec-at-ggzdrenthe.nl wrote:

> 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
>

Have the other occurrences happened at the roughly same time? If so, there
might be a batch job doing that. Quiesce mode is useful when doing BCV
split. Do you have anything like that?

--
http://mgogala.freehostia.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,
> Shakespeare

Wondering if Note:559298.1 is a clue - perhaps something is obscurely
associated with quiescing. The timing looks very suspicious to me.

jg
--
@home.com is bogus.
"There are few things as obsolete as an obsolete race car." Ken
Miles, 1958

joel garry wrote:
> The timing looks very suspicious to me.
Indeed. Clearly it is the same alert log.

Palooka

"Palooka" schreef in bericht
news:eGDsk.87911$6s4.87430-at-newsfe14.ams2...
> joel garry wrote:
>> The timing looks very suspicious to me.
> Indeed. Clearly it is the same alert log.
>
> Palooka

It IS the same. Both me and my client DBA posted on this group...;-) without
noticing we were both posting the same issue.....

Shakespeare

"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,
> Shakespeare

Wondering if Note:559298.1 is a clue - perhaps something is obscurely
associated with quiescing. The timing looks very suspicious to me.

jg
--
@home.com is bogus.
"There are few things as obsolete as an obsolete race car." Ken
Miles, 1958


============================================
I'll check the note!

Shakespeare