DATA PUMP JOB ERROR :

ORA-31626: job does not exist
ORA-31633: unable to create master table "SYS.EXPDPFULL"
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 95
ORA-06512: at "SYS.KUPV$FT", line 1048
ORA-00955: name is already used by an existing object


/bin/grep: /datapump/full_backup/expdp_FULL.log: No such file or directory
/bin/grep: /datapump/full_backup/expdp_FULL.log: No such file or directory

Problem Symptoms:
The log shows:

create_customer_data.log:ORA-31626: job does not exist
create_customer_data.log:ORA-31633: unable to create master table "ALEPH_ADMIN.ABC01_JOB"
create_customer_data.log:ORA-06512: at "SYS.DBMS_SYS_ERROR", line 95
create_customer_data.log:ORA-06512: at "SYS.KUPV$FT", line 863
create_customer_data.log:ORA-00955: name is already used by an existing object

Cause:
The error is caused by a stopped job that remained in the dba_datapump_jobs. The new expdp job has the same name as the old expdp job.

Resolution:
Clear the old expdp job or specify a different jobname

1. Connect to SQL*Plus as ALEPH_ADMIN:
sqlplus $ALEPH_ADMIN

2. Determine in SQL*Plus which Data Pump jobs exist in the database:
-- locate Data Pump jobs:
SELECT owner_name, job_name, operation, job_mode, state, attached_sessions FROM dba_datapump_jobs WHERE job_name NOT LIKE 'BIN$%'
ORDER BY 1,2;

3. Ensure that the listed jobs in dba_datapump_jobs are not export/import Data Pump jobs that are active: status should be 'NOT RUNNING'.

4. Check with the job owner that the job with status 'NOT RUNNING' in dba_datapump_jobs is not an export/import Data Pump job that has been temporary stopped, but is actually a job that failed.

5. Determine in SQL*Plus the related master tables:
SELECT o.status, o.object_id, o.object_type, o.owner||'.'||object_name "OWNER.OBJECT"
FROM dba_objects o, dba_datapump_jobs j WHERE o.owner=j.owner_name AND o.object_name=j.job_name AND j.job_name NOT LIKE 'BIN$%' ORDER BY 4,2;

6. For jobs that were stopped in the past and won't be restarted anymore, delete the master table. E.g.:
DROP TABLE scott.sys_export_table_02;

Note: In the case of an Upgrade Express export which was getting this error, the following worked:

drop table ALEPH_ADMIN.ABC50_JOB;

                 Thread 1 Cannot Allocate New Log" Message in the Alert Log

Refer to -   Message in the Alert Log (Doc ID 435887.1)

CAUSE:

When you switch logs, all private strands have to be flushed to the current log before the switch is allowed to proceed.

SOLUTION

This is expected behavior according to development.  Following is an extract from unpublished Bug 5241081 on why this can occur during manual log switch.

"Technically all the strands need to be flushed when the log switch is being initiated and hence the messages for checkpoint not complete and private strand flush not complete are synonymous. The crux is that the strand still have transactions active which need to be flushed before this redo can be overwritten, would recommend letting Oracle perform the checkpointing by default and tune fast_start_mttr_target to achieve what one is looking for."

This issue is very easy to duplicate on any database running in archivelog mode.  When the online logs are manually switched with no sessions connected, the problem messages are not displayed in the alert log.

SQL> alter system switch logfile;
System altered.

Alert log shows the following.

Thread 1 advanced to log sequence 206
Current log# 3 seq# 206 mem# 0: +GROUP01/oasm/onlinelog/group_3.258.609176403
Current log# 3 seq# 206 mem# 1: +GROUP01/oasm/onlinelog/group_3.263.609176613

Now connect to another session (using scott/tiger schema object in the example) and leave an update TX active.

SQL> update emp set sal = sal * 1;
14 rows updated.
... do not commit and keep session active

Then manually switch the logs in the original session, and now the alert log shows the following messages.

Thread 1 cannot allocate new log, sequence 207
Checkpoint not complete
Current log# 3 seq# 206 mem# 0: +GROUP01/oasm/onlinelog/group_3.258.609176403
Current log# 3 seq# 206 mem# 1: +GROUP01/oasm/onlinelog/group_3.263.609176613

Or the following.

Thread 1 cannot allocate new log, sequence 85
Private strand flush not complete
Current log# 3 seq# 84 mem# 0: C:\ORACLE\ORA11\ORADATA\ORCL11\REDO03.LOG

This is not a problem, but expected behavior. So when you manually switch logs on a DB with any activity at all, you will likely see these messages written to the alert log.  This can also occur when have archive_lag_target set.