ORA - 600 [4454]

[Former Member]

Hi Folks,

Past few months we have been experiencing a problem in our production environment.

An update deactivation occurs in production system ; post -deactivation we have noticed lock entry and parallel session which in trying to insert records into table ROOSGENQV. Actually it doesn't update anything into the table, the session keeps runing.This update session runs for long time 21000 seconds.

When we checked with end user he has confirmed doing reversal of 3-4 documents today morning and after that he did log off. But I could still see his update session was active and running more than 21000 seconds. I manually terminated session, which gives update error. If don’t terminate his session this would result ORA – 600 error, because in database logs we could see update deactivate occurs when doing SQL statement “insert into ROOSGENQV”. I have checked the oracle session; following FM was getting invoked during this time RSC1_STRUCTURE_INSTANTIATE. I understand ORA -600 [4454] occurs when we batch job/ session running for long time.

The transactions found to cause this error are FB1K & FB08 and typically it occurs only in three users.

DB Version : Oracle 9.2.0.7

Last year we have migrated database from Informix to Oracle. SAP has suggested for applying of latest patch 9.2.0.8. But we are not looking at patch update at this point of time and morever they have not provided any suppoting notes / metalink, which confirms resolution.

Any pointers to above problem would be much appreciated. Thank You.

Regards,

Priyank.

[stefan_koehler]

Hello Priyank,

at first i have to say that i don't understand your post up to 100 percent.. but let's start and maybe we are able to help you.

>> I understand ORA -600 4454 occurs when we batch job/ session running for long time.

That is correct. There was a known oracle bug 1402161, but this should be fixed in 9.2.0.1.

Then there is another metalinknote #353190.1 about that topic, which affects 9.2.0.1 to 10.1.0.4.

Solution:

> The job needs to be broken into smaller chunks. Between each chunk the session should disconnect and reconnect to reset the savepoint number.

> The problem is avoided by changing the savepoint structure from Oracle 10.2 onwards.

Metalinknote #418730.1 goes more into detail of this.

But if i understand your post correct.. you have these long running SQLs in the updater work process of SAP, right? Then you have to find out why this statement is taking so long on an insert into ROOSGENQV.

Have you already checked the wait events (ST04 => Detailed analysis => Oracle Sessions => Search for the Work-PID)?

I can only think of locks or something like that.. we need this information to help you.

Regards

Stefan