Prev: Installation of Oracle patch p5337014_10203_LINUX.zip on linux.
Next: Slow connection to Oracle 10
From: Mladen Gogala on 25 Aug 2008 06:29 louis.szarzec(a)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
From: joel garry on 25 Aug 2008 13:58 On Aug 25, 3:25 am, "Shakespeare" <what...(a)xs4all.nl> wrote: > "Mladen Gogala" <mgog...(a)yahoo.com> schreef in berichtnews:48b16e63$0$15596$834e42db(a)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 db went unquiesce again. I searched docs, metalink, > >> Google but did not find a clue why a DB 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
From: Palooka on 25 Aug 2008 15:24 joel garry wrote: > The timing looks very suspicious to me. Indeed. Clearly it is the same alert log. Palooka
From: Shakespeare on 26 Aug 2008 01:40 "Palooka" <nobody(a)nowhere.com> schreef in bericht news:eGDsk.87911$6s4.87430(a)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
From: Shakespeare on 26 Aug 2008 01:50 "joel garry" <joel-garry(a)home.com> schreef in bericht news:15ab9b7b-d291-4120-a15c-fc3ff59049c5(a)w39g2000prb.googlegroups.com... On Aug 25, 3:25 am, "Shakespeare" <what...(a)xs4all.nl> wrote: > "Mladen Gogala" <mgog...(a)yahoo.com> schreef in > berichtnews:48b16e63$0$15596$834e42db(a)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 db went unquiesce again. I searched docs, metalink, > >> Google but did not find a clue why a DB 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
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: Installation of Oracle patch p5337014_10203_LINUX.zip on linux. Next: Slow connection to Oracle 10 |