Export Modes

The Export utility supports four modes of operation:

  • Full: Exports a full database. Only users with the EXP_FULL_DATABASE role can use this mode. Use the FULL parameter to specify this mode.

  • Tablespace: Enables a privileged user to move a set of tablespaces from one Oracle database to another. Use the TRANSPORT_TABLESPACE parameter to specify this mode.

  • User: Enables you to export all objects that belong to you (such as tables, grants, indexes, and procedures). A privileged user importing in user mode can import all objects in the schemas of a specified set of users. Use the OWNER parameter to specify this mode in Export.

  • Table: Enables you to export specific tables and partitions. A privileged user can qualify the tables by specifying the schema that contains them. For any table for which a schema name is not specified, Export defaults to the exporter's schema name. Use the TABLES parameter to specify this mode.

See Table 22-1 for a list of objects that are exported and imported in each mode.

Note:

The original Export utility does not export any table that was created with deferred segment creation and has not had a segment created for it. The most common way for a segment to be created is to store a row into the table, though other operations such as ALTER TABLE ALLOCATE EXTENTS will also create a segment. If a segment does exist for the table and the table is exported, then the SEGMENT CREATION DEFERRED clause is not included in the CREATE TABLE statement that is executed by the original Import utility.

You can use conventional path Export or direct path Export to export in any mode except tablespace mode.The differences between conventional path Export and direct path Export are described in "Conventional Path Export Versus Direct Path Export".


Table 22-1 Objects Exported in Each Mode

Object Table Mode User Mode Full Database Mode Tablespace Mode

Analyze cluster

No

Yes

Yes

No

Analyze tables/statistics

Yes

Yes

Yes

Yes

Application contexts

No

No

Yes

No

Auditing information

Yes

Yes

Yes

No

B-tree, bitmap, domain function-based indexes

Yes1

Yes

Yes

Yes

Cluster definitions

No

Yes

Yes

Yes

Column and table comments

Yes

Yes

Yes

Yes

Database links

No

Yes

Yes

No

Default roles

No

No

Yes

No

Dimensions

No

Yes

Yes

No

Directory aliases

No

No

Yes

No

External tables (without data)

Yes

Yes

Yes

No

Foreign function libraries

No

Yes

Yes

No

Indexes owned by users other than table owner

Yes (Privileged users only)

Yes

Yes

Yes

Index types

No

Yes

Yes

No

Java resources and classes

No

Yes

Yes

No

Job queues

No

Yes

Yes

No

Nested table data

Yes

Yes

Yes

Yes

Object grants

Yes (Only for tables and indexes)

Yes

Yes

Yes

Object type definitions used by table

Yes

Yes

Yes

Yes

Object types

No

Yes

Yes

No

Operators

No

Yes

Yes

No

Password history

No

No

Yes

No

Postinstance actions and objects

No

No

Yes

No

Postschema procedural actions and objects

No

Yes

Yes

No

Posttable actions

Yes

Yes

Yes

Yes

Posttable procedural actions and objects

Yes

Yes

Yes

Yes

Preschema procedural objects and actions

No

Yes

Yes

No

Pretable actions

Yes

Yes

Yes

Yes

Pretable procedural actions

Yes

Yes

Yes

Yes

Private synonyms

No

Yes

Yes

No

Procedural objects

No

Yes

Yes

No

Profiles

No

No

Yes

No

Public synonyms

No

No

Yes

No

Referential integrity constraints

Yes

Yes

Yes

No

Refresh groups

No

Yes

Yes

No

Resource costs

No

No

Yes

No

Role grants

No

No

Yes

No

Roles

No

No

Yes

No

Rollback segment definitions

No

No

Yes

No

Security policies for table

Yes

Yes

Yes

Yes

Sequence numbers

No

Yes

Yes

No

Snapshot logs

No

Yes

Yes

No

Snapshots and materialized views

No

Yes

Yes

No

System privilege grants

No

No

Yes

No

Table constraints (primary, unique, check)

Yes

Yes

Yes

Yes

Table data

Yes

Yes

Yes

Yes

Table definitions

Yes

Yes

Yes

Yes

Tablespace definitions

No

No

Yes

No

Tablespace quotas

No

No

Yes

No

Triggers

Yes

Yes2

Yes3

Yes

Triggers owned by other users

Yes (Privileged users only)

No

No

No

User definitions

No

No

Yes

No

User proxies

No

No

Yes

No

User views

No

Yes

Yes

No

User-stored procedures, packages, and functions

No

Yes

Yes

No


1

Nonprivileged users can export and import only indexes they own on tables they own. They cannot export indexes they own that are on tables owned by other users, nor can they export indexes owned by other users on their own tables. Privileged users can export and import indexes on the specified users' tables, even if the indexes are owned by other users. Indexes owned by the specified user on other users' tables are not included, unless those other users are included in the list of users to export.

2

Nonprivileged and privileged users can export and import all triggers owned by the user, even if they are on tables owned by other users.

3

A full export does not export triggers owned by schema SYS. You must manually re-create SYS triggers either before or after the full import. Oracle recommends that you re-create them after the import in case they define actions that would impede progress of the import.