[Fwd: Re: Altering dymanic SGA parameters and ORA-00376]

That was in 10.2.0.2 when I hit it. And you didn't have to be resizing anything. Just have your SGA be an exact multiple of 4G. I do not remember the errors nor can I find the bug 

krish.hariharan@xxxxxxxxxxxx wrote:
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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] *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@xxxxxxxxxxxxxxxxxx <mailto:peter.mclarty@xxxxxxxxxxxxxxxxxx>> 
Pacific DBMS Pty Ltd
--- Begin Message --- That was in 10.2.0.2 when I hit it. And you didn't have to be resizing anything. Just have your SGA be an exact multiple of 4G. I do not remember the errors nor can I find the bug 

krish.hariharan@xxxxxxxxxxxx wrote:
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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] *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@xxxxxxxxxxxxxxxxxx <mailto:peter.mclarty@xxxxxxxxxxxxxxxxxx>> 
Pacific DBMS Pty Ltd

--- End Message ---

Other related posts: