ORA-39006, ORA-39065,ORA-25306,ORA-39079 while exporting using EXPDP

Encountered the following error messages which attempting to do an export of a database using Data Pump utility with 10.2.0.4:

ORA-39006: internal error
ORA-39065: unexpected master process exception in DISPATCH
ORA-39079: unable to enqueue message DG,KUPC$S_3_20090213124234,MCP, ,1,Y
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 86
ORA-06512: at "SYS.KUPC$QUE_INT", line 924
ORA-25306: Cannot connect to buffered queue's owner instance

ORA-39097: Data Pump job encountered unexpected error -39079
ORA-39065: unexpected master process exception in KUPC$QUEUE_INT.PUT_STATUS
ORA-39079: unable to enqueue message DG,KUPC$S_3_20090213124234,MCP, ,1,Y
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 86
ORA-06512: at "SYS.KUPC$QUE_INT", line 924
ORA-25306: Cannot connect to buffered queue's

This seems to be a bug but couldn't find any published information in metalink. Setting the value for the parameters aq_tm_processes to 4 from a value of 0 worked. There are several other databases with the default setting of 0, but they don't seem to have problems with expdp. Hopefully, this will have a fix in 10.2.0.5.

Hope this helps others who encounter similar errors.

Bypassing/ignoring or skipping ORA-1555 errors

I was researching a corruption issue using various Metalink link notes and stumbled upon a note/bug which provides a way to ignore or skip ORA-1555 errors for queries. Obviously, this will result in getting inconsistent data/result-set. As of now, I am not sure as to what type situations will have a practical use of this feature. This is available in Oracle 11g 11.1.0.7. This is done using a hint - SCN_ASCENDING.

Example:

In Session 1:

chandra@AEDB01:11g> Select Distinct phone from acs_emp;

PHONE
--------------------
972-500-8999

1 row selected.

In Session 2:

chandra@AEDB01:11g> Select /*+ scn_ascending */ * from acs_emp;

While this session is in progress, I have updated the phone column:

Back in Session 1:

chandra@AEDB01:11g> update acs_emp set phone='888-888-8888';

100000 rows updated.

chandra@AEDB01:11g> commit;

Commit complete.

Back to Session 2 where our select was in progress: You will notice that we got data which was NOT consistent with the data which existed at the point in time when the query was initiated. The SCN got changed in the middle - meaning inconsistent / questionable data!. Without the above mentioned HINT, it wouldn't have been possible to see such inconsistent result set. Hopefully, this hint is a well-intentioned one.

650831 972-500-8999
650831 972-500-8999
650831 972-500-8999
650831 972-500-8999
650831 972-500-8999
650831 972-500-8999
650831 972-500-8999
650831 972-500-8999
650831 972-500-8999
650831 972-500-8999
650831 972-500-8999
652088 888-888-8888
652088 888-888-8888
652088 888-888-8888
652088 888-888-8888
652088 888-888-8888
652088 888-888-8888
652088 888-888-8888
652088 888-888-8888
652088 888-888-8888
652088 888-888-8888