The following sections describe points you should consider when you export particular database objects.
If transactions continue to access sequence numbers during an export, then sequence numbers might be skipped. The best way to ensure that sequence numbers are not skipped is to ensure that the sequences are not accessed during the export.
Sequence numbers can be skipped only when cached sequence numbers are in use. When a cache of sequence numbers has been allocated, they are available for use in the current database. The exported value is the next sequence number (after the cached values). Sequence numbers that are cached, but unused, are lost when the sequence is imported.
All data in a LOB column does not need to be held in memory at the same time. LOB data is loaded and unloaded in sections.
Oracle also recommends that you convert existing
LONG columns to LOB columns. LOB columns are subject to far fewer restrictions than
LONG columns. Further, LOB functionality is enhanced in every release, whereas LONG functionality has been static for several releases.
The contents of foreign function libraries are not included in the export file. Instead, only the library specification (name, location) is included in full database mode and user-mode export. You must move the library's executable files and update the library specification if the database is moved to a new location.
If the data you are exporting contains offline locally managed tablespaces, then Export will not be able to export the complete tablespace definition and will display an error message. You can still import the data; however, you must create the offline locally managed tablespaces before importing to prevent DDL commands that may reference the missing tablespaces from failing.
Directory alias definitions are included only in a full database mode export. To move a database to a new location, the database administrator must update the directory aliases to point to the new location.
Directory aliases are not included in user-mode or table-mode export. Therefore, you must ensure that the directory alias has been created on the target system before the directory alias is used.
The export file does not hold the contents of external files referenced by
BFILE columns or attributes. Instead, only the names and directory aliases for files are copied on Export and restored on Import. If you move the database to a location where the old directories cannot be used to access the included files, then the database administrator (DBA) must move the directories containing the specified files to a new location where they can be accessed.
The contents of external tables are not included in the export file. Instead, only the table specification (name, location) is included in full database mode and user-mode export. You must manually move the external data and update the table specification if the database is moved to a new location.
In all Export modes, the Export utility includes information about object type definitions used by the tables being exported. The information, including object name, object identifier, and object geometry, is needed to verify that the object type on the target system is consistent with the object instances contained in the export file. This ensures that the object types needed by a table are created with the same object identifier at import time.
Note, however, that in table mode, user mode, and tablespace mode, the export file does not include a full object type definition needed by a table if the user running Export does not have execute access to the object type. In this case, only enough information is written to verify that the type exists, with the same object identifier and the same geometry, on the Import target system.
The user must ensure that the proper type definitions exist on the target system, either by working with the DBA to create them, or by importing them from full database mode or user-mode exports performed by the DBA.
It is important to perform a full database mode export regularly to preserve all object type definitions. Alternatively, if object type definitions from different schemas are used, then the DBA should perform a user mode export of the appropriate set of users. For example, if
table1 belonging to user
scott contains a column on
type1, then the DBA should perform a user mode export of both
scott to preserve the type definitions needed by the table.
Inner nested table data is exported whenever the outer containing table is exported. Although inner nested tables can be named, they cannot be exported individually.
Queues are implemented on tables. The export and import of queues constitutes the export and import of the underlying queue tables and related dictionary tables. You can export and import queues only at queue table granularity.
When you export a queue table, both the table definition information and queue data are exported. Because the queue table data and the table definition is exported, the user is responsible for maintaining application-level data integrity when queue table data is imported.
You should be cautious when exporting compiled objects that reference a name used as a synonym and as another object. Exporting and importing these objects will force a recompilation that could result in changes to the object definitions.
The following example helps to illustrate this problem:
CREATE PUBLIC SYNONYM emp FOR scott.emp; CONNECT blake/paper; CREATE TRIGGER t_emp BEFORE INSERT ON emp BEGIN NULL; END; CREATE VIEW emp AS SELECT * FROM dual;
If the database in the preceding example were exported, then the reference to
emp in the trigger would refer to
blake's view rather than to
scott's table. This would cause an error when Import tried to reestablish the
If an export operation attempts to export a synonym named
DBMS_JAVA when there is no corresponding
DBMS_JAVA package or when Java is either not loaded or loaded incorrectly, then the export will terminate unsuccessfully. The error messages that are generated include, but are not limited to, the following: EXP-00008, ORA-00904, and ORA-29516.
If Java is enabled, then ensure that both the
DBMS_JAVA synonym and
DBMS_JAVA package are created and valid before rerunning the export.
If Java is not enabled, then remove Java-related objects before rerunning the export.
You can export tables with fine-grained access control policies enabled. When doing so, consider the following:
The user who imports from an export file containing such tables must have the appropriate privileges (specifically, the
EXECUTE privilege on the
DBMS_RLS package so that the tables' security policies can be reinstated). If a user without the correct privileges attempts to export a table with fine-grained access policies enabled, then only those rows that the exporter is privileged to read will be exported.
If fine-grained access control is enabled on a
SELECT statement, then conventional path Export may not export the entire table because fine-grained access may rewrite the query.
Only user SYS, or a user with the
EXP_FULL_DATABASE role enabled or who has been granted
EXEMPT ACCESS POLICY, can perform direct path Exports on tables having fine-grained access control.