ORA-6512 During Full Export

Wednesday, January 16, 2008

Running Oracle on Solaris 10. Encountered the error below when testing a full export after applying CPUJan2008. Encountered the same error previously in another database after applying CPUOct2007 on an Oracle database.

EXP-00008: ORACLE error 6550 encountered
ORA-06550: line 1, column 18:
PLS-00201: identifier ‘SYS.DBMS_DEFER_IMPORT_INTERNAL’ must be declared
ORA-06550: line 1, column 7:
PL/SQL: Statement ignored
ORA-06512: at “SYS.DBMS_SYS_SQL”, line 1204
ORA-06512: at “SYS.DBMS_SQL”, line 323
ORA-06512: at “SYS.DBMS_EXPORT_EXTENSION”, line 97
ORA-06512: at “SYS.DBMS_EXPORT_EXTENSION”, line 126
ORA-06512: at line 1

Metalink Note 464672.1 lists the problem as Bug 6392040 and provides a solution.


One important statement to consider from Metalink Note 464672.1:

“There is no fix in this bug because the export utility is no longer supported in 11g and should be replaced by the Data Pump Export.”

Additional References
Metalink Note 464862.1 – “EXP-00008 PLS-00201 When Performing Full Database Export After Applying CPUOCT2007”

Bug 6510213 – “INSTALLED CPUOCT2007; NOW EXP GETS THE ERRORS EXP-00008,ORA-06550,PLS-00201”


Oracle 10gr2 Permissions On Oracle Home

Wednesday, January 9, 2008

I installed Oracle Client on an HP-UX 11.11 server. Logged in as the Oracle software owner (e.g. oracle Unix account), I can access all the usual Oracle utilities such as SQL*Plus. However, one of our developers was getting the error below when invoking SQL*Plus.

$ sqlplus
ksh: sqlplus: not found

Their Unix account does not belong to the Unix dba group, which explains why I don’t see the problem when I login to my Unix account which is a member of the dba group.

In Metalink I had a bookmark to Note 335063.1. The note references Bug 4516865 for which there is a patch. I tried to install the patch which essentially replaces $ORACLE_HOME/install/changePerm.sh with an updated version. The file in the patch is for, but I am running so the patch apply fails.

% opatch apply
Invoking OPatch


ApplySession applying interim patch ‘4516865’ to
OH ‘/disk01/app/oracle/product/10.2.0/client_1’
ApplySession failed: ApplySession failed to

prepare the system.
ApplySession: Required component(s)
[ oracle.rdbms.rsf,, higher version found. ] not present in the Oracle
Home or a higher version found.
System intact, OPatch will not attempt to restore the system

OPatch failed with error code 73

Since the existing changePerm.sh version was newer (September 2006), I just executed the script in $ORACLE_HOME/install.

% cd $ORACLE_HOME/install
% ./changePerm.sh

Disclaimer: The purpose of this script is to relax permissions on some of the files in the database Oracle Home so that all clients can access them. Please note that Oracle Corporation recommends using the most restrictive file permissions as possible for your given implementation. Running this script should be done only after considering all security ramifications.

-n Do you wish to continue (y/n) [n]:
Finished running the script successfully
Please see /tmp/changePerm_err.log for errors and /tmp/changePerm.log for the log of events

That modified the permissions and solved the problem. The developer is now able to execute SQL*Plus.

Update (10-Jan-2008)
While installing Oracle on another database server and closely reading the Patch Set Notes, Post-Installation Tasks Section 7.3 explains the possible need to run the changePerm.sh script. I seemed to have missed that in a previous install.

kcrrwkx: nothing to do

Wednesday, January 2, 2008

Running Oracle Standard Edition on Solaris 9. Encountered a trace file in my background_dump_dest location regarding the archiver process. Upon opening the trace file, I found many entries of the error shown below:

*** 2008-01-02 14:21:49.970
kcrrwkx: nothing to do (end)

A quick search on Metalink using “kcrrwkx nothing to do” as the criteria, I find Metalink Note 372364.1. This is labeled as Bug 4883174 with two possible solutions.

1.This message has zero impact, and can be ignored. Except that the trace files will be consuming disk space, which can be manually removed or running a cron job to clean up.

2. The one-off patch (4883174) for fixing this issue is also available for some platforms.

It is also mentioned the problem is fixed in 11g and possibly in Searching the Patch Set – List of Bug Fixes indicates the problem is fixed in that Oracle version. I have two other databases running and have confirmed the archiver errors do not exist there.

In the end I chose solution #1 as this server will be replaced with new hardware running Solaris 10 and Oracle Maybe if Oracle releases that version soon.