Re: Nothing like an ORA 600 in the middle of a recover database eh?

From: <johnbhurley_at_sbcglobal.net>
Date: Wed, 18 Mar 2009 02:30:02 -0700 (PDT)
Message-ID: <854b0d2c-0020-49c0-b524-023e511881a6_at_b16g2000yqb.googlegroups.com>



On Mar 17, 8:55 pm, Palooka <nob..._at_nowhere.com> wrote:

snip

> > So you are in the middle of a recover database and forward recovering
> > with archive logs ... then you see this:

snip

> > ORA-00283: recovery session canceled due to errors
> > ORA-00600: internal error code, arguments: [krr_init_lbufs_1], [74],
> > [66],
> > [43], [], [], [], [], [], [], [], []
> > ORA-01112: media recovery not started

snip

> > Only 1 hit in metalink but fortunately a documented bypass ( from bug
> > 7373196 evidently ).
>
> > Bypass was documented as:
>
> > So set this  parameter to 4194304  (ie 4Mb) in the init.ora/spfile
> > then that should be good enough to
> > function as a workaround and allow recovery.
> > _max_io_size=4194304
>
> > *** It did work but man what a mess.  Set the _max_io_size before
> > doing the forward recovery then you better get rid of it before
> > running normal workloads.
>
> > Supposed to be fixed in 11.2 ... ( and perhaps next 11.1 patchset? ).
>
> Wow. Horrible. I hope you were testing, rather than doing it in anger.
>
> Palooka

Yup ... testing ... hard to believe Oracle let this loose on the world.

What has happened to the quality assurance process at Oracle?

To be ( a little fair ) it doesn't happen for every recover database command and may have some relationship with how many logs you process ... how big they are ... what size ( apparently your online log buffer is perhaps.

Still ... pretty deadly ... imagine being in a real recover database crisis and you hit this! Received on Wed Mar 18 2009 - 04:30:02 CDT

Original text of this message