Autoconfig failing with ORA-00603: ORACLE server session terminated by fatal error

Hi,

We were in the process of applying the RUP4 in our R12 development environment. As part of this activity, we had to run autoconfig and autoconfig failed with the following error:

Running Profile Process 1 of 2 for BIS_TOP
Executing script in InstantiateFile:
/apps/INSTANCE_NAME/apps/tech_st/10.1.3/perl/bin/perl -I /apps/INSTANCE_NAME/apps/tech_st/10.1.3/perl/lib/5.8.3 -I /apps/INSTANCE_NAME/apps/tech_st/10.1.3/perl/lib/site_perl/5.8.3 -I /apps/INSTANCE_NAME/apps/apps_st/appl/au/12.0.0/perl -I /apps/INSTANCE_NAME/apps/tech_st/10.1.3/Apache/Apache/mod_perl/lib/site_perl/5.8.3/i686-linux-thread-multi /apps/local/INSTANCE_NAME/inst/apps/CONTEXT_NAME/admin/scripts/adexecsql.pl sqlfile=/apps/local/INSTANCE_NAME/inst/apps/CONTEXT_NAME/admin/install/bisdblrp.sql

DECLARE
*
ERROR at line 1:
ORA-00603: ORACLE server session terminated by fatal error

-------
alert log - ORA-00600: internal error code, arguments: [16500], [kqddlu]


The following changes were made in the environment recently:

- Refresh from production
- Database upgrade to 10.2.0.4 from 10.2.0.2


Troubleshooting tips:

The bisdblrp.sql creates two db links EDW_APPS_TO_WH and APPS_TO_APPS. This sql was failing outside of autoconfig with the same error. The script actually drops (if the links already exists) and recreates the db links.The script also spools the output. The spool showed that we were facing this issue while trying to drop the above db links. In the meanwhile, I queried dba_db_links and found two entries for each of the above links. This was the reason for the error we were seeing. Fix was to delete the rows for these db links from sys.link$ table and then run autoconfig. Autoconfig ran fine without issues.

Upon further analysis, I found that the issue was happening due to import of sys.link$ after refresh as one of the post refresh tasks. We are adopting this import process as we have large number of private db links in our database. So the sequence of events were like this:

- export the sys.link$ table from the target database before destroying the database.
- clone the database from production
- refresh the apps from production and run autoconfig as part of this activity
- import the sys.link$ table to get back all the db links.

- Aravind Kamath Posral