Re: Direct path load failure

Thanks a lot. We will try to see if we are lucky enough and are hitting the first one i.e. bug related to APPEND hint (i.e. related to bad rowid) and that can be passed though if we would be able to do that load manually using conventional load method . And hopefully, when it says about a bad rowid, it's for the source table from which it's picking data from and not the one to which it's loading data to. And that source table is smaller one though that is also partitioned and having bitmap indexes on that. But yes , if this works then, subsequent loads should not fail as those will not pick the same bad rowids from the source table again.

Regards
Lok

On Tue, May 11, 2021 at 3:05 PM Ghassan Salem <salem.ghassan_at_gmail.com> wrote:

> you can try removing the hint and see. I see no other way around it.
> If going to 19.11 is problematic, try asking for a one-off, as there are
> one-offs for 19.8, ...
>
> rgds
>
> On Tue, May 11, 2021 at 11:05 AM Lok P <loknath.73_at_gmail.com> wrote:
>
>> Thank You So much. So it seems more like we are hitting this bug case and
>> there is no workaround. So wondering as because applying patches will take
>> time as it has to move through all lower environments till production. So
>> what would be the short term workaround to get rid of this error at the
>> current moment and persist data on the target table without failure. As
>> because the customer is waiting to see/fetch those data in the downstream
>> system so it's a showstopper for us?
>>
>> And thinking , if anyway we can cross check if it's really the first one(
>> 2396979.1) in which the APPEND hint causing an issue or its the bug one
>> i.e. 27658166 which has no workaround.
>>
>> Regards
>> Lok
>>
>> On Tue, May 11, 2021 at 2:23 PM Ghassan Salem <salem.ghassan_at_gmail.com>
>> wrote:
>>
>>> It may be bug 27658166, there are one-offs for several version, check
>>> with support if they have one for your 19.5, or upgrade to 19.11.
>>>
>>> rgds
>>>
>>> On Tue, May 11, 2021 at 10:44 AM Lok P <loknath.73_at_gmail.com> wrote:
>>>
>>>> Yes there are ~20+ bitmap indexes( on individual columns ) and one
>>>> primary key index present in this Range-HASH composite partition table.
>>>> all the indexes are local. It's exadata X5. The oracle version is
>>>> 19.5.0.0.0. I see we have historical partitions compressed using the
>>>> "ARCHIVE HIGH" option.
>>>>
>>>> Regards
>>>> Lok
>>>>
>>>> On Tue, May 11, 2021 at 1:40 PM Ghassan Salem <salem.ghassan_at_gmail.com>
>>>> wrote:
>>>>
>>>>> Lok,
>>>>> what version? Exa or not? with bitmap index on the table? hcc?
>>>>>
>>>>> rgds
>>>>>
>>>>> On Tue, May 11, 2021 at 9:42 AM Lok P <loknath.73_at_gmail.com> wrote:
>>>>>
>>>>>> We have an INSERT statement inside a procedure which looks like
>>>>>> below. It keeps on failing with Ora-0600 even if we try to rerun multiple
>>>>>> times. And we got below doc which is matching with the symptom and its
>>>>>> stating its because of a bad rowid issue and APPEND hint is the one
>>>>>> triggering the error so need to get rid of the APPEND hint. Also Oracle
>>>>>> support agrees on the same. But APPEND was there because making the data
>>>>>> load fast as it dumps 100's of millions of rows at one shot into the target
>>>>>> table. So removing append seems to create other performance related
>>>>>> problems for us. Also that INSERT query is part of a complex procedure
>>>>>> which does multiple other inserts based on run time variables till it
>>>>>> reaches that point. So I wanted to understand if there was any other way
>>>>>> around to get rid of this error and fix this issue.
>>>>>>
>>>>>> insert /*+append parallel(4)*/ into tabl1(....) select
>>>>>> /*+parallel(4)/...;
>>>>>>
>>>>>> ORA-00600: internal error code, arguments:
>>>>>> [kdiblsorget:rowidIllegal], [4008], [4008], [], [], [], [], [], [], [], [],
>>>>>> []
>>>>>>
>>>>>> INSERT with APPEND Hint = ORA-600[kdiblsorget:rowidIllegal] (Doc ID
>>>>>> 2396979.1)
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Lok
>>>>>>
>>>>>

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