Return-Path: Delivered-To: 2-oracle-l@orafaq.com Received: (qmail 19190 invoked from network); 6 Dec 2007 19:39:59 -0600 Received: from freelists-180.iquest.net (HELO turing.freelists.org) (206.53.239.180) by 69.64.49.119 with SMTP; 6 Dec 2007 19:39:58 -0600 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id DC3047D4ABF; Thu, 6 Dec 2007 20:39:58 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04782-05; Thu, 6 Dec 2007 20:39:58 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 475C47D4A54; Thu, 6 Dec 2007 20:39:58 -0500 (EST) Received: with ECARTIS (v1.0.0; list oracle-l); Thu, 06 Dec 2007 19:53:02 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 1C4BD7D3828 for ; Thu, 6 Dec 2007 19:53:02 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27211-06 for ; Thu, 6 Dec 2007 19:53:01 -0500 (EST) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 031CD7D2E2E for ; Thu, 6 Dec 2007 19:53:00 -0500 (EST) Received: from [192.168.2.5] (d58-109-9-244.dsl.nsw.optusnet.com.au [58.109.9.244]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lB70qaYV002619; Fri, 7 Dec 2007 11:52:42 +1100 Subject: RE: Altering dymanic SGA parameters and ORA-00376 From: Peter McLarty To: "Kerber, Andrew W." Cc: krish.hariharan@quasardb.com, oracle-l In-Reply-To: References: Content-Type: multipart/alternative; boundary="=-HrXN6oSHVG6ZxfJhpXYa" Organization: Pacific DBMS Pty Ltd Date: Fri, 07 Dec 2007 10:52:31 +1000 Message-Id: <1196988751.6449.13.camel@notebook5.pacificdbms.com.au> Mime-Version: 1.0 X-archive-position: 3767 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-to: oracle-l-bounce@freelists.org X-original-sender: peter.mclarty@pacificdbms.com.au Precedence: normal Reply-to: peter.mclarty@pacificdbms.com.au List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: oracle-l X-List-ID: oracle-l List-subscribe: List-owner: List-post: List-archive: X-list: oracle-l X-Virus-Scanned: Debian amavisd-new at localhost.localdomain --=-HrXN6oSHVG6ZxfJhpXYa Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi Thanks for your comments, Andrew IO can find no reference to fork events that might be in error. I have been reviewing trace files in bdump and find no answer. It seems none were written all morning prior to the event. Andrew you and I may have came to a similar conclusion that the sysadmins might not like. FYI SGA_TARGET is not set on this system, Oracle is not dynamically altering the settings. I the q still somewhat stumped as to what the real cause is, I guess closer monitoring of the system may answer question if it decides to turn its toes up again. Put one down for experience on this one until a better answer comes along. Metalink and Google have not shown anything that suggests that a problem may exist with altering shared_pool_size and db_cache_size parameters, except when you try to effectively increase then to the point it exceeds SGA_MAX_SIZE. maybe I didnt find the right query combination Thanks again Cheers Peter On Thu, 2007-12-06 at 14:40 -0600, Kerber, Andrew W. wrote: > Yes, I have seen it. Never did find a cause, and the theory I > developed was one my unix sys admin did not like. Were there errors > in the trace files about forking a process? > > > > -----Original Message----- > From: oracle-l-bounce@freelists.org > [mailto:oracle-l-bounce@freelists.org] On Behalf Of > krish.hariharan@quasardb.com > Sent: Thursday, December 06, 2007 10:14 AM > To: peter.mclarty@pacificdbms.com.au; 'oracle-l' > Subject: RE: Altering dymanic SGA parameters and ORA-00376 > > > > I am unable to locate the bug number associated with a similar error I > saw in the recent past, I will post that when I can locate it. > Basically, if I remember this correct the database instance crashes > (10.2.0.3 I believe) if you resize when the sga_target is a multiple > of 4G. I think the circumstances were > > > > 1. SGA_TARGET 12G > > 2. DB_CACHE_SIZE was increased > > > > Regards > > -Krish > > > > > > ______________________________________________________________________ > > From:oracle-l-bounce@freelists.org > [mailto:oracle-l-bounce@freelists.org] On Behalf Of Peter McLarty > Sent: Thursday, December 06, 2007 7:58 AM > To: oracle-l > Subject: Altering dymanic SGA parameters and ORA-00376 > > > > > > Hi > > I am sure this is a totally dumb question but does anyone know if > changing parameters dynamically for SGA settings like increasing > shared_pool_size can cause a DB to crash and show many problem > datafiles with ORA-00376. > > I am thinking SAN failure of some sort, we relocated the database to > another set of LUNS from a different SAN and did datafile recovery and > all is good, but just trying to isolate the causes, alert log shows a > read error on an index datafile just seconds before it had the alter > for the SGA parameters and then crash. > > Interestingly it had to use 4 archivelogs to conduct the recovery > which cover about 20 minutes prior to the crash. > > Some hypothesis to consider ,based on the above information is what I > am looking for. > It is Solaris 10 and its Sun Storage but i don't have available the > models, the server is a T2200, 16 VCPU's > > Or if someone has had a similar experience and what you found out > We are going to try and do a root cause analysis tomorrow if no issues > are present when the users hit it again > > 1am here and I am off to bed > > All help appreciated > > Cheers > > -- > Peter McLarty > Pacific DBMS Pty Ltd > > > > > > > > ------------------------------------------------------------------------------ > NOTICE: This electronic mail message and any attached files are > confidential. The information is exclusively for the use of the > individual or entity intended as the recipient. If you are not the > intended recipient, any use, copying, printing, reviewing, retention, > disclosure, distribution or forwarding of the message or any attached > file is not authorized and is strictly prohibited. If you have > received this electronic mail message in error, please advise the > sender by reply electronic mail immediately and permanently delete the > original transmission, any attachments and any copies of this message > from your computer system. Thank you. > > ============================================================================== > > --=-HrXN6oSHVG6ZxfJhpXYa Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi

Thanks for your comments, Andrew IO can find no reference to fork events that might be in error.

I have been reviewing trace files in bdump and find no answer. It seems none were written all morning prior to the event. Andrew you and I may have came to a similar conclusion that the sysadmins might not like.

FYI SGA_TARGET is not set on this system, Oracle is not dynamically altering the settings.  I the q still somewhat stumped as to what the real cause is, I guess closer monitoring of the system may answer  question if it decides to turn its toes up again.

Put one down for experience on this one until a better answer comes along.

Metalink and Google have not shown anything that suggests that a problem may exist with altering shared_pool_size and db_cache_size parameters, except when you try to effectively increase then to the point it exceeds SGA_MAX_SIZE. maybe I didnt find the right query combination

Thanks again

Cheers

Peter



On Thu, 2007-12-06 at 14:40 -0600, Kerber, Andrew W. wrote:
Yes, I have seen it.    Never did find a cause, and the theory I developed was one my unix sys admin did not like.  Were there errors in the trace files about forking a process?

 

-----Original Message-----
From: oracle-l-bounce@freelists.org [mailto:oracle-l-bounce@freelists.org] On Behalf Of krish.hariharan@quasardb.com
Sent: Thursday, December 06, 2007 10:14 AM
To: peter.mclarty@pacificdbms.com.au; 'oracle-l'
Subject: RE: Altering dymanic SGA parameters and ORA-00376

 

I am unable to locate the bug number associated with a similar error I saw in the recent past, I will post that when I can locate it. Basically, if I remember this correct the database instance crashes (10.2.0.3 I believe) if you resize when the sga_target is a multiple of 4G. I think the circumstances were

 

1. SGA_TARGET 12G

2. DB_CACHE_SIZE was increased

 

Regards

-Krish

 

From:oracle-l-bounce@freelists.org [mailto:oracle-l-bounce@freelists.org] On Behalf Of Peter McLarty
Sent: Thursday, December 06, 2007 7:58 AM
To: oracle-l
Subject: Altering dymanic SGA parameters and ORA-00376


 

Hi

I am sure this is a totally dumb question but does anyone know if changing parameters dynamically for SGA settings like increasing shared_pool_size can cause a DB to crash and show many problem datafiles with ORA-00376.

I am thinking SAN failure of some sort, we relocated the database to another set of LUNS from a different SAN and did datafile recovery and all is good, but just trying to isolate the causes, alert log shows a read error on an index datafile just seconds before it had the alter for the SGA parameters and then crash.

Interestingly it had to use 4 archivelogs to conduct the recovery which cover about 20 minutes prior to the crash.

Some hypothesis to  consider ,based on the above information is what I am looking for.
It is Solaris 10 and its Sun Storage but i don't have available the models, the server is a T2200, 16 VCPU's

Or if someone has had a similar experience and what you found out
We are going to try and do a root cause analysis tomorrow if no issues are present when the users hit it again

1am here and I am off to bed

All help appreciated

Cheers

--
Peter McLarty <peter.mclarty@pacificdbms.com.au>
Pacific DBMS Pty Ltd



 


------------------------------------------------------------------------------
NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. Thank you.

==============================================================================


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