Database in quiesce mode
in [Oracle]
|
Prev: Installation of Oracle patch p5337014_10203_LINUX.zip on linux.
Next: Slow connection to Oracle 10
From: Mladen Gogala on 27 Aug 2008 07:07 On Tue, 26 Aug 2008 07:50:42 +0200, Shakespeare wrote: > "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, >> 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
From: Shakespeare on 27 Aug 2008 13:52 "Mladen Gogala" <gogala.mladen(a)gmail.com> schreef in bericht news:48b5356c$0$15592$834e42db(a)reader.greatnowhere.com... > On Tue, 26 Aug 2008 07:50:42 +0200, Shakespeare wrote: > >> "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, >>> 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
From: Shakespeare on 3 Sep 2008 10:39 On 23 aug, 21:19, "Shakespeare" <what...(a)xs4all.nl> 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 It appears one of the DBA's was installing Enterprise Manager using EMCA. This puts the database in quiesce mode.... Shakespeare
From: Mladen Gogala on 3 Sep 2008 11:24 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
From: Shakespeare on 3 Sep 2008 14:54 "Mladen Gogala" <mgogala(a)yahoo.com> schreef in bericht news:g9ma6u$9me$3(a)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
First
|
Prev
|
Pages: 1 2 3 Prev: Installation of Oracle patch p5337014_10203_LINUX.zip on linux. Next: Slow connection to Oracle 10 |