| USERID | RECORDLENGTH |
| BUFFER | INCTYPE |
| FILE | COMMIT |
| SHOW | HELP |
| IGNORE | LOG |
| GRANTS | DESTROY |
| INDEXES | INDEXFILE |
| ROWS | CHARSET |
| FULL | FEEDBACK |
| FROMUSER | MLS* |
| TOUSER | MLS_LISTLABELS* |
| TABLES | MLS_MAPFILE* |
| *Trusted Oracle7 Server parameter. | |
Default: operating system dependent
The BUFFER (buffer size) parameter determines the number of rows in the array inserted by Import. The following formula gives a rough approximation of the buffer size that inserts a given array of rows:
buffer_size = rows_in_array * maximum_row_size
The size in bytes of the buffer through which data rows are transferred.
Additional Information: See your operating Oracle system-specific documentation to determine the default value for this parameter.
Release 6 export files only
Specifies the NLS character set used in the export file.
Use of this parameter is not recommended. It is only provided for compatibility with previous versions. Eventually, it will no longer be supported.
If you are using Oracle7 Server's Export, the character set is specified within the export file, and conversion to the current database's character set is automatic. Specification of this parameter serves only as a check to ensure that the export file's character set matches the expected value. If not, an error results.
Valid values for CHARSET are contained in the V$NLS_PARAMETERS view. Consult the Oracle7 Server Reference for details.
COMMIT
Specifies whether Import should commit after each array insert. By default, Import commits after loading each object and Import will perform a rollback when an error occurs before continuing with the next object.
Specifying COMMIT=Y prevents rollback segments from growing inordinately large and improves the performance of large imports. Enabling this parameter is advisable if the table has a uniqueness constraint. If the import is restarted, any rows that have already been imported will be rejected with a non-fatal error. Note that, if there is no uniqueness constraint, enabling this parameter could produce duplicate rows when re-importing the data.
DESTROY
Specifies whether the existing data files making up the database should be reused. That is, the DESTROY option specifies that IMPORT should include the reuse option in the datafile clause of the CREATE TABLESPACE command.
The export file contains the datafile names used in each tablespace. Attempting to create a second database on the same machine (for testing or other purposes) has the undesirable effect of overwriting the original database's data files when creating the tablespace. With this parameter set to N (the default), an error occurs if the data files already exist when the tablespace is created.
To eliminate this error when importing into a secondary database, pre-create the tablespace and specify its data files. (Specifying IGNORE=Y suppresses the object creation error that the tablespace already exists.)
To bypass the error when importing into the original database, specify IGNORE=Y to add to the existing data files without replacing them. To reuse the original database's data files after eliminating their contents, specify DESTROY=Y.
Note that, if you have pre-created your tablespace, you should specify DESTROY=N or your pre-created tablespace will be lost.
FEEDBACK
Default: 0 (zero)
If set to other than zero, specifies that Import should display a progress meter in the form of a dot for x number of rows imported. For example, were you to specify FEEDBACK=10, import would display a dot each time 10 rows had been imported. The FEEDBACK value applies to all tables being imported, it cannot be set on a per table basis.
FILE
The name of the Export file to import.
FROMUSER
A list of schemas containing objects to import. The default is a user mode import. That is, all objects for the current user are imported. (If the TABLES parameter is also specified, then a table mode import is performed.)
When importing in user mode, all other objects in the export file are ignored. The effect is the same as if the export file had been created in user mode (or table mode). See ![[*]](jump.gif)
for the list of objects that are imported in user mode and table mode.
For example, the following command treats the export file as though it were simply a user mode export of SCOTT's objects:
IMP system/manager FROMUSER=scott
If user SCOTT does not exist in the current database, then his objects are imported into the importer's schema -- in this case, the system manager's. Otherwise, the objects are installed in SCOTT's schema. If a list of schemas is given, each schema can be specified only once. Duplicate schema names are ignored.
Note: Specifying FROMUSER=SYSTEM does not import system objects. It imports only those objects that belong to user SYSTEM.
To import system objects (for example, user definitions and tablespaces), you must import from a full export file specifying FULL=Y.
FULL
Specifies whether to import the entire export file or not. This parameter can be specified only by a user with the IMP_FULL_DATABASE role enabled.
GRANTS
Specifies whether to import grants or not.
HELP
Displays a description of import parameters.
IGNORE
Specifies how object creation errors should be handled. Specifying IGNORE=Y causes Import to overlook object creation errors when attempting to create database objects. For objects other than tables, if you specify IGNORE=Y, Import continues without reporting the error. If you accept the default IGNORE=N, Import logs and/or displays the object creation error before continuing.
For tables, IGNORE=Y causes rows to be imported into existing tables. No message is given. IGNORE=N causes an error to be reported, and the table is skipped if it already exists.
Note that only object creation errors will be ignored, operating system, database, SQL, etc. errors will not be ignored and may cause processing to stop.
In situations where multiple refreshes from a single export file are done with IGNORE=Y, certain objects can be created multiple times (although they will have unique system-defined names). This can be prevented for certain objects, for example, constraints, by doing an export in table mode with the CONSTRAINTS=NO option. Note that, if a full export is done with the CONSTRAINTS option set to NO, no constraints for any tables will be exported. See for information about which objects you can prevent from being exported.
Warning: When importing into existing tables, if no column in the table is uniquely indexed, then rows could be duplicated if they were already present in the table. (This warning applies to non-incremental imports only. Incremental imports replace the table from the last complete export and then rebuild it to its last backup state from a series of cumulative and incremental exports.)
INCTYPE
Specifies the type of incremental import. Valid values are SYSTEM and RESTORE. See the section called "Importing Incremental, Cumulative and Complete Export Files" later in this chapter for more information.
INDEXES
Specifies whether to import indexes or not.
INDEXFILE
Specifies a file to receive index-creation commands.
When this parameter is specified, index-creation commands are extracted and written to the specified file, rather than used to create indexes in the database. Tables and other database objects are not imported.
The file can then be edited (for example, to change storage parameters) and used as a SQL script to create the indexes. This is the most efficient way to create indexes for new tables--even if the index file is not edited. To make it easier to identify the indexes defined in the file, the export file's CREATE TABLE statements and CREATE CLUSTER statements are included as comments.
Note: As of release 7.1, the commented CREATE TABLE statement in the indexfile no longer includes primary/unique key clauses.
Perform the following steps to make use of this feature:
Specifies a file to receive informational and error messages. If specified, all information written to the terminal display is also written to the log.
MLS
Used when importing data into a secure database. Specifies that the export file contains Multi-Level Security (MLS) labels. For more information on this parameter, see the Trusted Oracle7 Server Administrator's Guide.
MLS_LISTLABELS
When specified, lists the MLS labels in the export file. For more information on this parameter, see the Trusted Oracle7 Server Administrator's Guide.
MLS_MAPFILE
When specified, maps the MLS labels in the export file to the labels used in the target database for the import. For more information, see the Trusted Oracle7 Server Administrator's Guide .
RECORDLENGTH
Default: operating system dependent
Specifies the length in bytes of the file record. The RECORDLENGTH parameter is required when you import to another operating system that uses a different default value.
Additional Information: See your Oracle operating system-specific documentation to determine the default value for this parameter.
ROWS
Specifies whether to import the rows of table data or not.
SHOW
When specified, the contents of the export file will be listed to the display and not imported. SHOW is not typically used with other parameters.
TABLES
Specifies a list of table names to import. Use an asterisk (*) to indicate all tables. When specified, this parameter initiates a table mode import, which restricts the import to tables and their associated objects, as listed . The number of tables that can be specified at the same time is dependent on command line limits and buffer settings. Although you can qualify table names with schema names (as in SCOTT.EMP) when exporting, you cannot do so when importing. In the following example, the TABLES parameter is specified incorrectly:
IMP system/manager TABLES=(jones.accts, scott.emp,scott.dept)
The valid specification to import these tables should be:
IMP system/manager FROMUSER=(scott,jones) TABLES=(accts,emp,dept)
If user SCOTT does not exist in the current database, then his tables are imported into the importer's schema -- in the above example, the system/manager's. Otherwise, the tables and associated objects are installed in SCOTT's schema.
TOUSER
Specifies a list of usernames to whose schemas data will be imported. The IMP_FULL_DATABASE role is required to use this parameter.
To import to a different schema than the one that originally contained the object, specify TOUSER. For example:
IMP system/manager FROMUSER=scott TOUSER=joe TABLES=emp
If multiple schemas are specified, then the schema names are paired. For example,
IMP system/manager FROMUSER=(scott,fred) TOUSER=(joe, ted)
imports SCOTT's objects into JOE's schema, and FRED's objects into TED's schema.
USERID
The username/password of the user performing the import.