CONSTRAINT_NAME_FROM_INDEX: [Y | N ]

This transform is valid for the following object types:TABLE and CONSTRAINT object types.

This transform parameter affects the generation of the pk or fk constraint which reference user created indexes. If set to Y, it forces the name of the constraint to match the name of the index.

If set to N (the default), then the constraint is created as named on the source database.

CONSTRAINT_NOVALIDATE:[Y|N]

The default value for this parameter is N. If the parameter is set to Y, then constraints are not validated during import. Validating constraints during import that were valid on the source can be unnecessary and slow the migration process. Validation can be done after import.

You cannot choose CONSTRAINT_NOVALIDATE = Y for tables with the following properties because these constraints must be in the VALIDATE state to complete the import:

• Reference partitioned table
• Reference partitioned child table
• Table with Primary key OID
• Table is clustered

CONSTRAINT_USE_DEFAULT_INDEX: [Y | N ]

This transform is valid for the following object types:TABLE and CONSTRAINT object types.

This transform parameter affects the generation of index relating to the pk or fk constraint. If the transform parameter is set to Y, then the transform forces the name of an index automatically created to enforce the constraint to be identical to the constraint name. In addition, the index is created and defined using the default constraint definition for the target database, and will not use any special characteristics that might have been defined in the source database.

Default Indexes are not allowed unless they use standard schema integrity constraints, such as UNIQUE, PRIMARY KEY, or FOREIGN KEY. Accordingly, if you run an Oracle Data Pump import from a system where no restrictions exist, and you have additional constraints in the source index (for example, user generated constraints, such as a hash-partitioned index), then these additional constraints are removed during the import.

If set to N (the default), then the index is created as named and defined on the source database.

DISABLE_ARCHIVE_LOGGING:[Y | N]

This transform is valid for the following object types: INDEX and TABLE.

If set to Y, then the logging attributes for the specified object types (TABLE and/or INDEX) are disabled before the data is imported. If set to N (the default), then archive logging is not disabled during import. After the data has been loaded, the logging attributes for the objects are restored to their original settings. If no object type is specified, then the DISABLE_ARCHIVE_LOGGING behavior is applied to both TABLE and INDEX object types. This transform works for both file mode imports and network mode imports. It does not apply to transportable tablespace imports.

Note:

If the database is in

mode, then the

option does not disable logging when indexes and tables are created.

DWCS_CVT_IOTS: [Y | N ]

This transform is valid for TABLE object types.

If set to Y, it directs Oracle Data Pump to transform Index Organized tables to heap organized tables by suppressing the ORGANIZATION INDEX clause when creating the table.

If set to N (the default), the generated DDL retains the table characteristics of the source object.

DWCS_CVT_CONSTRAINTS: [Y | N ]

This transform is valid for the following object types:TABLE and CONSTRAINT object types.

If set to Y, it directs Oracle Data Pump to create pk, fk, or uk constraints as disabled.

If set to N (the default), it directs Oracle Data Pump to createpk, fk, or uk constraints based on the source database status.

INMEMORY:[Y | N]

This transform is valid for the following object types: TABLE and TABLESPACE

The INMEMORY transform is related to the In-Memory Column Store (IM column store). The IM column store is an optional portion of the system global area (SGA) that stores copies of tables, table partitions, and other database objects. In the IM column store, data is populated by column rather than row as it is in other parts of the SGA, and data is optimized for rapid scans. The IM column store does not replace the buffer cache, but acts as a supplement so that both memory areas can store the same data in different formats. The IM column store is included with the Oracle Database In-Memory option.

If Y (the default value) is specified on import, then Data Pump keeps the IM column store clause for all objects that have one. When those objects are recreated at import time, Data Pump generates the IM column store clause that matches the setting for those objects at export time.

If N is specified on import, then Data Pump drops the IM column store clause from all objects that have one. If there is no IM column store clause for an object that is stored in a tablespace, then the object inherits the IM column store clause from the tablespace. So if you are migrating a database, and you want the new database to use IM column store features, then you can pre-create the tablespaces with the appropriate IM column store clause and then use TRANSFORM=INMEMORY:N on the import command. The object then inherits the IM column store clause from the new pre-created tablespace.

If you do not use the INMEMORY transform, then you must individually alter every object to add the appropriate IM column store clause.

Note:

The INMEMORY transform is available only in Oracle Database 12c Release 1 (12.1.0.2) or later.

See Oracle Database Administrator’s Guide for information about using the In-Memory Column Store (IM column store).

INMEMORY_CLAUSE:"string with a valid in-memory parameter”

This transform is valid for the following object types: TABLE and TABLESPACE.

The INMEMORY_CLAUSE transform is related to the In-Memory Column Store (IM column store). The IM column store is an optional portion of the system global area (SGA) that stores copies of tables, table partitions, and other database objects. In the IM column store, data is populated by column rather than row as it is in other parts of the SGA, and data is optimized for rapid scans. The IM column store does not replace the buffer cache, but acts as a supplement so that both memory areas can store the same data in different formats. The IM column store is included with the Oracle Database In-Memory option.

When you specify this transform, Data Pump uses the contents of the string as the INMEMORY_CLAUSE for all objects being imported that have an IM column store clause in their DDL. This transform is useful when you want to override the IM column store clause for an object in the dump file.

The string that you supply must be enclosed in double quotation marks. If you are entering the command on the command line, be aware that some operating systems can strip out the quotation marks during parsing of the command, which causes an error. You can avoid this error by using backslash escape characters (

). For example:

transform=inmemory_clause:\"INMEMORY MEMCOMPRESS FOR DML PRIORITY CRITICAL\"

Alternatively you can put parameters in a parameter file. Quotation marks in the parameter file are maintained during processing.

Note:

The INMEMORY_CLAUSE transform is available only in Oracle Database 12c Release 1 (12.1.0.2) or later.

See Oracle Database Administrator's Guide for information about using the In-Memory Column Store (IM column store). See Oracle Database Reference for a listing and description of parameters that can be specified in an IM column store clause

LOB_STORAGE:[SECUREFILE | BASICFILE | DEFAULT | NO_CHANGE]

This transform is valid for the object type TABLE.

LOB segments are created with the specified storage, either SECUREFILE or BASICFILE. If the value is NO_CHANGE (the default), then the LOB segments are created with the same storage that they had in the source database. If the value is DEFAULT, then the keyword (SECUREFILE or BASICFILE) is omitted, and the LOB segment is created with the default storage.

Specifying this transform changes LOB storage for all tables in the job, including tables that provide storage for materialized views.

The LOB_STORAGE transform is not valid in transportable import jobs.

OID:[Y | N]

This transform is valid for the following object types: INC_TYPE, TABLE, and TYPE.

If Y (the default value) is specified on import, then the exported OIDs are assigned to new object tables and types. Oracle Data Pump also performs OID checking when looking for an existing matching type on the target database.

If N is specified on import, then:

• The assignment of the exported OID during the creation of new object tables and types is inhibited. Instead, a new OID is assigned. Inhibiting assignment of exported OIDs can be useful for cloning schemas, but does not affect referenced objects.

• Before loading data for a table associated with a type, Oracle Data Pump skips normal type OID checking when looking for an existing matching type on the target database. Other checks using a hash code for a type, version number, and type name are still performed.

OMIT_ENCRYPTION_CLAUSE: [Y | N ]

This transform is valid for TABLE object types.

If set to Y, it directs Oracle Data Pump to suppress column encryption clauses. Columns which were encrypted in the source database are not encrypted in imported tables.

If set to N (the default), it directs Oracle Data Pump to create column encryption clauses, as in the source database.

PCTSPACE:some_number_greater_than_zero

This transform is valid for the following object types: CLUSTER, CONSTRAINT, INDEX, ROLLBACK_SEGMENT, TABLE, and TABLESPACE.

The value supplied for this transform must be a number greater than zero. It represents the percentage multiplier used to alter extent allocations and the size of data files.

You can use the PCTSPACE transform with the Data Pump Export SAMPLE parameter so that the size of storage allocations matches the sampled data subset. (See the SAMPLE export parameter.)

SEGMENT_ATTRIBUTES:[Y | N]

This transform is valid for the following object types: CLUSTER, CONSTRAINT, INDEX, ROLLBACK_SEGMENT, TABLE, and TABLESPACE.

If the value is specified as Y, then segment attributes (physical attributes, storage attributes, tablespaces, and logging) are included, with appropriate DDL. The default is Y.

SEGMENT_CREATION:[Y | N]

This transform is valid for the object type TABLE.

If set to Y (the default), then this transform causes the SQL SEGMENT CREATION clause to be added to the CREATE TABLE statement. That is, the CREATE TABLE statement explicitly says either SEGMENT CREATION DEFERRED or SEGMENT CREATION IMMEDIATE. If the value is N, then the SEGMENT CREATION clause is omitted from the CREATE TABLE statement. Set this parameter to N to use the default segment creation attributes for the tables being loaded. (This functionality is available with Oracle Database 11g release 2 (11.2.0.2) and later releases.

STORAGE:[Y | N]

This transform is valid for the following object types: CLUSTER, CONSTRAINT, INDEX, ROLLBACK_SEGMENT, and TABLE.

If the value is specified as Y, then the storage clauses are included, with appropriate DDL. The default is Y. This parameter is ignored if SEGMENT_ATTRIBUTES=N.

TABLE_COMPRESSION_CLAUSE:[NONE | compression_clause]

This transform is valid for the object type TABLE.

If NONE is specified, then the table compression clause is omitted (and the table is given the default compression for the tablespace). Otherwise, the value is a valid table compression clause (for example, NOCOMPRESS, COMPRESS BASIC, and so on). Tables are created with the specified compression. See Oracle Database SQL Language Reference for information about valid table compression syntax.

If the table compression clause is more than one word, then it must be contained in single or double quotation marks. Also, your operating system can require you to enclose the clause in escape characters, such as the backslash character. For example:

TRANSFORM=TABLE_COMPRESSION_CLAUSE:\"COLUMN STORE COMPRESS FOR QUERY HIGH\"

Specifying this transform changes the type of compression for all tables in the job, including tables that provide storage for materialized views.

XMLTYPE_STORAGE_CLAUSE:[TRANSPORTABLE BINARY XML | BINARY XML]

There is no default. If the transform is not used, then he source datatype in the dumpfile is the datatype defined on the target, and the NOT TRANSPORTABLE clauses remain as they are.

Oracle recommends that you use the TRANSPORTABLE BINARY XML XMLType with Oracle Database 23ai to store data in a self-contained binary format. This format supports sharding and greater scalability. It does not store the metadata used to encode or decode XML data in a central table (central token tables and schema registries), which simplifies the XML data storage and makes it easier to transport. If TRANSPORTABLE BINARY XML is set, then it forces the TRANSPORTABLE clause to be present in table creation DDLs for Binary XML data. This data type is available for Oracle Database 21c and Oracle Database 19c in Oracle Cloud Infrastructure.

Use the BINARY XML storage XMLType (which is non-transportable) to store the data in a post-parse, binary format designed specifically for XML data. Binary XML is compact, post-parse, XML schema-aware XML data. The metadata used to encode or decode XML data is stored efficiently in a central table. When BINARY XML is set, it forces the NOT TRANSPORTABLE clause to be present in table creation DDLs for Binary XML data. When tables with Binary XML data have neither TRANSPORTABLE nor NOT TRANSPORTABLE clauses, the default is NOT TRANSPORTABLE, and the XMLType column remains stored as Binary XML.

You can export and import data of type XMLType regardless of the source database XMLType storage format (object-relational, binary XML or CLOB). However, Oracle Data Pump exports and imports XML data as binary XML data only. The underlying tables and columns used for object-relational storage of XMLType are consequently not exported. Instead, they are converted to binary form and exported as self-describing binary XML data with a token map preamble.

Because XMLType data is exported and imported as XML data, the source and target databases can use different XMLType storage models for that data. You can export data from a database that stores XMLType data one way and import it into a database that stores XMLType data a different way. For details, see Oracle XML DB Developer’s Guide