[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_at_quasardb.com 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_at_freelists.org
> [mailto:oracle-l-bounce_at_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_at_pacificdbms.com.au
> <mailto:peter.mclarty_at_pacificdbms.com.au>>
> Pacific DBMS Pty Ltd
>
>
>

attached mail follows:

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_at_quasardb.com 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_at_freelists.org
> [mailto:oracle-l-bounce_at_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_at_pacificdbms.com.au
> <mailto:peter.mclarty_at_pacificdbms.com.au>>
> Pacific DBMS Pty Ltd
>
>
>

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