Default: There is no default
Syntax and Description
REMAP_SCHEMA lines can be specified, but the source schema must be different for each one. However, different source schemas can map to the same target schema. Note that the mapping may not be 100 percent complete; see the Restrictions section below.
If the schema you are remapping to does not already exist, then the import operation creates it, provided that the dump file set contains the necessary
USER metadata for the source schema, and provided that you are importing with enough privileges. For example, the following Export commands create dump file sets with the necessary metadata to create a schema, because the user
SYSTEM has the necessary privileges:
> expdp system SCHEMAS=hr Password: password > expdp system FULL=YES Password: password
If your dump file set does not contain the metadata necessary to create a schema, or if you do not have privileges, then the target schema must be created before the import operation is performed. This is because the unprivileged dump files do not contain the necessary information for the import to create the schema automatically.
If the import operation does create the schema, then after the import is complete, you must assign it a valid password to connect to it. The SQL statement to do this, which requires privileges, is:
SQL> ALTER USER schema_name IDENTIFIED BY new_password
Unprivileged users can perform schema remaps only if their schema is the target schema of the remap. (Privileged users can perform unrestricted schema remaps.) For example,
SCOTT can remap his
BLAKE's objects to
SCOTT cannot remap
SCOTT's objects to
The mapping may not be 100 percent complete because there are certain schema references that Import is not capable of finding. For example, Import will not find schema references embedded within the body of definitions of types, views, procedures, and packages.
REMAP_SCHEMA affects only the trigger owner.
If any table in the schema being remapped contains user-defined object types and that table changes between the time it is exported and the time you attempt to import it, then the import of that table will fail. However, the import operation itself will continue.
By default, if schema objects on the source database have object identifiers (OIDs), then they are imported to the target database with those same OIDs. If an object is imported back into the same database from which it was exported, but into a different schema, then the OID of the new (imported) object would be the same as that of the existing object and the import would fail. For the import to succeed you must also specify the
TRANSFORM=OID:N parameter on the import. The transform
OID:N causes a new OID to be created for the new object, allowing the import to succeed.
Suppose that, as user
SYSTEM, you execute the following Export and Import commands to remap the
hr schema into the
> expdp system SCHEMAS=hr DIRECTORY=dpump_dir1 DUMPFILE=hr.dmp > impdp system DIRECTORY=dpump_dir1 DUMPFILE=hr.dmp REMAP_SCHEMA=hr:scott
In this example, if user
scott already exists before the import, then the Import
REMAP_SCHEMA command will add objects from the
hr schema into the existing
scott schema. You can connect to the
scott schema after the import by using the existing password (without resetting it).
scott does not exist before you execute the import operation, then Import automatically creates it with an unusable password. This is possible because the dump file,
dmp, was created by
SYSTEM, which has the privileges necessary to create a dump file that contains the metadata needed to create a schema. However, you cannot connect to
scott on completion of the import, unless you reset the password for
scott on the target database after the import completes.