Amit,
What was your evidence that it "corrupted" an index and needed to be
rebuilt? An "ORA-" error? A trace file dump? Something else?
Was the index on the master table, or on the MV?
Thanks!
-Tim
On 12/12/2023 4:49 AM, Amit Saroha wrote:
Thanks, Tim. I was able to figure out using the note that MV log truncation was in progress while another process started using the table and make sense to me. However, seems it corrupted the index even though the index was active and valid and all DMLs failed on the failed with the same error. After the index is rebuild the DML works fine so I am wondering why it corrupted a index and not any other things and is it possible to see whether it really corrupted the index using alert log or any other mechanism?
Thanks for your help.
On Mon, Dec 11, 2023 at 1:52 PM Tim Gorman <tim@xxxxxxxxxxxxxxxxx> wrote:
Amit,
If you search MOS with the keywords "ora 600 ktspgfb-1" then in
the resulting list of hits you should see Oracle Support note
#285847.1 (entitled "/ORA-600 [ktspgfb-1]/"), which is a master
note for this issue. In this article, there are filters for the
version affected. According to your trace output, you are using
Oracle database version 19.18, and the clicking the button to
filter for issues related to "19.18" in the article yields...
* Oracle Support note #34291262.8 (entltled "/Bug 34291862 -
ORA-600 [ktspgfb-1] or ORA-600[ktecgsc:objdchk_kcbgtcr_5] on
update mv master table/")
As the article title suggests, Oracle bug 34291862 involves
updates to the master table of a materialized view.
To determine if OE_ORDER_LINES is a master table in a materialized
view, please consider running queries like...
select owner, mview_name from all_mview_detail_relations where
detailobj_owner = 'ONT' and detailobj_name =
'OE_ORDER_LINES_ALL' and detailobj_type = 'TABLE';
...or...
select owner, mview_name from all_mview_detail_relations where
detailobj_name = 'OE_ORDER_LINES' and detailobj_type = 'VIEW';
...and perhaps also check with Oracle Support to see if they have
considered this chain of evidence?
Hope this helps,
-Tim
On 12/11/2023 10:17 AM, Amit Saroha wrote:
Hi All,
We are experiencing ORA-600 is routinely raised, which is
negatively affecting our operations. We've been working with
Oracle, but there hasn't been much progress, so I thought I'd ask
the specialists here if they might assist.
The problem is always raised on one table in our EBS system,
OR_ORDER_LINES_ALL, and this table is heavily used 24 * 7 with a
lot of INSERT + UPDATES.
Our database contains 19c. I looked through the alert log and the
trace file but couldn't make much sense of it, for example, using
the below queries I figured out when the issue occurred and in
the enclosed trace file with 3M rows I can see the below rows
meaningful as they show an update statement but I don't see
anything wrong with the statement and why would it cause ORA-600.
Please offer any insights you have if possible.
SELECT ORIGINATING_TIMESTAMP, DETAILED_LOCATION, MESSAGE_LEVEL,
MESSAGE_TEXT, PROBLEM_KEY
FROM V$DIAG_ALERT_EXT
WHERE MESSAGE_LEVEL = 1
AND MESSAGE_TEXT LIKE '%ORA-00600%'
ORDER BY ORIGINATING_TIMESTAMP DESC;
SELECT * FROM V$DIAG_TRACE_FILE_CONTENTS WHERE trace_filename =
'cebsprd_ora_165301_i848794.trc' ORDER BY TIMESTAMP;
Best Regards,
AMIT
