*** SERVICE NAME:(SYS$USERS) 2008-04-10 13:31:19.527
*** SESSION ID:(294.450) 2008-04-10 13:31:19.527
*** 2008-04-10 13:31:19.527
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [25027], [27], [0], [], [],
[], [], []
Current SQL statement for this session:
SELECT STRING_VALUE FROM MGMT_CURRENT_METRICS WHERE TARGET_GUID = :B3
AND METRIC_GUID = :B2 AND KEY_VALUE = :B1
We have also found that Oracle defined automatic optimizer statistics
collection job (GATHER_STATS_JOB) is not running properly.
In the operation details, the job appears as STOPPED
REASON="Job slave process was terminated"
I don't know if there's any relation with the ORA-600 Error. But I
don't know how to solve it.
I've looked for information about this error in metalink but I
couldn't find useful information.
do you know how to solve it?
Thank you for your help in advance.
Ismael
ORA-600 errors = Open a SR with Oracle.
HTH
-g
yes, I know. The SR was opened 5 days ago and we have no answer (Work
In Progress ...) so any help would be appreciated.
Ismael
Escalate? Is it a production system?
There should have been a trace file generated (in bdump) by the
dbms_stats scheduled job failure.
There are several errors with the package dbms_stats in 10.2.0.3 on MS
Win 32, 2 of which I have seen directly.
If you manually gather statistics on this table as a foreground
process using dbms_stats.gather_table_stats, what errors occur?
Are you ready to deploy the 10.2.0.4 patchset?
There are fixes for dbms_stats in there (check the release notes) that
might or might not apply to your issue.
good luck.
-bdbafh
When I manually gather statistics:
dbms_stats.gather_table_stats(ownname => 'SYSMAN', tabname =>
'MGMT_CURRENT_METRICS');
I get :
ORA-03113: end-of-file on communication channel
and a new ora-00600 in the alert.log. :-(
So its reproducible. That is in fact good news.
Are you familiar with the ora-600 lookup tool?
Its available on Metalink as Note: 153788.1
But seeing as you already have a service request open ... upload the
new files under the existing service request. There should be a trace
file in udump.
You might decide to manually set and lock stats for the affected table
as a work-around.
Are you planning on applying the 10.2.0.3 patch 20 anytime soon?
Its provided as part of the Critical Patch Update for April 2008.
You might find that the fix for this error has already been
incorporated in a one-off patch.
-bdbafh
Hi,
Yes, I've tried to find information in the ora-600 lookup tool ... but
no solution found.
I've uploaded the trace file, I'm waiting for the answer.
We are planning to apply the patch 20 ... but it's a 24x7 production
system and it isn't easy.
Thank you for your help.
Ismael