Re: ROLLBACK_SEGMENTS definition

Hi Andrew,

Many thanks for the info.

Regards

Richard
"Andrew Mobbs" <andrewm_at_chiark.greenend.org.uk> wrote in message news:VUz*mqVsp_at_news.chiark.greenend.org.uk...
> Howard J. Rogers <dba_at_hjrdba.com> wrote:
> >
> >"Richard Foote" <richard.foote_at_bigpond.com> wrote in message
> >news:DwMW8.31665$Hj3.95560_at_newsfeeds.bigpond.com...
> >> Hi Howard,
> >>
> >> I thought the bug only affected Release 2 ?
> >
> >That's my understanding too.
> >
> >Guess which version I'm on????? ;-)
> >
> >>
> >> Can you please forward me the details, access to metalink in not that
easy
> >> for me at the moment :(
> >
> >Not really, Richard.... I'm ensconced in the study right now, and the
> >details of how I get into Metlink are written on a sticky bit of yellow
> >paper attached to my monitor at work.
> >
> >Oops.
> >
> >Perhaps some kind soul will oblige us both?
>
> OK, I was running a batch process creating large numbers of records,
> and everything went wonderfully for some time until they started dying
> with ORA-600 [kcbnew_3]. After that, many DML and DDL commands failed with
> the same error (not always, e.g. I could truncate some of the tables
> I'd been filling, but some truncates would fail). Any attempt to
> restart the batch processes was doomed to failure.
>
> This persisted across a instance shutdown, and as it affected all
> data, not just the data I was manipulating, I had a hunch it was
> something undo related. Creating a new undo tablespace and switching
> to it allowed me to run fine for a while before the problem
> reoccurred. Giving up on automatic undo and going back to rollback
> segments worked.
>
> So, TAR off to Oracle. Bunch of trace files and alert logs later they
> confirm the bug and confirm the workaround.
>
> Bug No. 2436895
> Product Version 9.2.0.1
> Affects Platforms Generic
> Status Code Bug (Response/Resolution)
>
> *** 06/27/02 06:54 am ***
> TAR:
> ----
> .
> PROBLEM:
> --------
> 1. Clear description of the problem encountered:
> .
> Customer runs a data generation batch process built using pro*c. He
> was running 32 concurrent copies and generating data for benchmark
> testing. There was no other activity on the system. The processes
> ran as expected for some time, then failed with ORA-600[kcbnew_3].
> After the error occurred, many but not all SQL commands failed with
> similar errors.
>
> .
> 2. Pertinent configuration information (MTS/OPS/distributed/etc)
> N/A
> 3. Indication of the frequency and predictability of the problem
> Everytime when run with undo tablespaces
> .
> 4. Sequence of events leading to the problem
> Ran multiple copies of a batch process and received the error
> .
> 5. Technical impact on the customer. Include persistent after effects.
> Large system benchmark scheduled in 2 weeks at the customer site
> with IBM. This error is preventing them from proceeding using the desired
> configuration.
>
> .
> DIAGNOSTIC ANALYSIS:
> --------------------
> --> Changing undo tablespace does not help
> --> occurs only in 9.2 as the internal error does not exist in prior
> releases
> .
> WORKAROUND:
> -----------
> -->Use Rollback segments
> --> Possibly use dictionary manage tablespace for undo information
> .
> RELATED BUGS:
> -------------
> 2414972 which is still with development
> .
> REPRODUCIBILITY:
> ----------------
> Everytime at customer site
> .
> TEST CASE:
> ----------
> not available
> .
> STACK TRACE:
> ------------
> kcbassertb1
> kcbnew+0770
> ktugnb+08ec
> ktugur+0814
> ktuchg+03d0
> ktbchg2+00a4
> kddchg+04a0
> kduovw+0f9c
> .
> .
> SUPPORTING INFORMATION:
> -----------------------
> Internal error seems to have been introduced in 9.2 and seems to be
related to
> bitmap information of the file space
> .
> 24 HOUR CONTACT INFORMATION FOR P1 BUGS:
> ----------------------------------------
> .
> DIAL-IN INFORMATION:
> --------------------
> .
> IMPACT DATE:
> ------------
> .
> *** 06/27/02 07:14 am *** (CHG: Sta-&gt;16)
> *** 06/27/02 07:14 am ***
> *** 06/27/02 07:17 am ***
> *** 06/27/02 07:24 am *** (CHG: Asg-&gt;NEW OWNER)
> *** 06/27/02 07:50 am *** (CHG: Sta-&gt;11 Asg-&gt;NEW OWNER)
> *** 06/27/02 07:50 am ***
> rdbmsrep -> assigning to 2414972's owner for confirmation
> *** 06/28/02 03:21 pm ***
> *** 06/28/02 05:39 pm *** (CHG: Sta-&gt;30)
> *** 06/28/02 05:39 pm ***
> *** 07/03/02 11:44 am *** (CHG: FixBy-&gt;9.2.0.2)
> *** 07/08/02 11:09 am *** (CHG: Sta-&gt;11)
> *** 07/08/02 11:09 am ***
>
>
Received on Wed Jul 10 2002 - 20:51:01 CDT