Reading a DataPump import log after an 11g to 19c migration: what the common ORA errors actually mean

ORA-31684 — Object type already exists

ORA-31684: Object type TABLESPACE:"USERS" already exists
ORA-31684: Object type ROLE:"SELECT_CATALOG_ROLE" already exists
ORA-31684: Object type DIRECTORY:"DATA_PUMP_DIR" already exists

What it means: the object DataPump is trying to create is already present in the target database.

Most common cause: the target environment was provisioned before the import ran — tablespaces, standard Oracle-supplied roles, directories, and contexts already exist because the DBA created the environment (or because Oracle creates them by default in every new database) before impdp ever started. Across the migrations reviewed here this is consistently the single largest category by line count.

Two variants worth knowing by name, both seen in practice:

• A custom PASSWORD_VERIFY_FUNCTION pre-created on the target on purpose (to satisfy a profile that references it) shows up here too — its appearance means the pre-creation step worked, not that something went wrong.
• A target admin/service account whose name collides with a source schema (e.g. a PDB's own ADMIN account matching a schema named ADMIN in the source data) triggers the same error on CREATE USER — worth a second look specifically because it's a naming collision, not a simple pre-provisioning match.

ORA-39083 — Object type failed to create with error

This one is a wrapper — the actual cause is the error nested underneath it, not ORA-39083 itself. Across several migrations, the nested error has taken multiple distinct forms:

• ORA-01917 (user or role does not exist) — seen with SYSTEM_GRANT, PROCACT_SYSTEM: grant references a role/user (OLAP_DBA, OLAP_USER, OWBSYS) tied to an optional component installed on the source but not present on the target
• ORA-01919 (role does not exist) — seen with ROLE_GRANT: same pattern at the role-grant level instead of the privilege-grant level
• ORA-20000 (custom application error) — seen with PROCACT_SYSTEM: a component's own install-check PL/SQL (e.g. Workspace Manager's version check) fails because that component isn't configured the same way on the target
• ORA-01555 (snapshot too old) — seen with INDEX on large partitioned tables: undo/rollback segment too small for how long a large index build took during import — a resourcing issue, not a metadata one
• ORA-27476 (object does not exist) — seen with Scheduler PROCOBJ/job: a Scheduler job references a job class that wasn't exported or pre-created on the target
• ORA-01950 (no privileges on tablespace) — seen with INDEX: the importing schema has no quota on the tablespace the index needs
• ORA-01931 (cannot grant to a role) — seen with SYSTEM_GRANT e.g. GRANT UNLIMITED TABLESPACE TO <role>: UNLIMITED TABLESPACE cannot be granted to a role in Oracle — fails on every migration where the source had this grant on a role, regardless of target setup

The pattern across all of these: ORA-39083 by itself tells you that one DDL statement failed, never why — the nested error and the "Failing sql is:" text underneath it are the only useful parts of the message.

ORA-39082 — Object type created with compilation warnings

ORA-39082: Object type PROCEDURE:"<SCHEMA>"."<PROC_NAME>" created with compilation warnings
ORA-39082: Object type PACKAGE BODY:"<SCHEMA>"."<PKG_NAME>" created with compilation warnings
ORA-39082: Object type TYPE:"<SCHEMA>"."<TYPE_NAME>" created with compilation warnings

What it means: the object itself was created — the code exists — but it didn't compile cleanly.

Most common cause: during a full-database import, PL/SQL objects can be created before everything they depend on has been imported yet (a procedure referencing a table, type, or another package that comes later in the import order). This is consistently one of the largest categories by line count, spanning procedures, views, package bodies, and types. The standard next step, run once as SYS after the import finishes:

@?/rdbms/admin/utlrp.sql

SELECT owner, object_type, COUNT(*) FROM dba_objects
WHERE status = 'INVALID' GROUP BY owner, object_type ORDER BY owner, object_type;

Reading the log

Rather than scrolling through hundreds of lines in order, group by error code first — it tells you immediately which of the patterns above you're looking at, and how much of each:

grep -oE "ORA-[0-9]+" import.log | sort | uniq -c | sort -rn

Then pull the nested error and object type for ORA-39083 lines specifically, since the outer code alone doesn't say what actually failed:

grep -B1 -A2 "ORA-39083" import.log

One error code is deliberately not covered here: ORA-31685 (object failed due to insufficient privileges) means the object wasn't created at all, and it's shown up with genuinely different causes across different migrations depending on the object type — worth its own dedicated look rather than a quick entry in this list.

The takeaway