Parameter DIRECT: Conventional Path Export Versus Direct Path Export [ID 155477.1]引用

Parameter DIRECT: Conventional Path Export Versus Direct Path Export [ID 155477.1]

---

 

Modified 24-JUN-2010     Type BULLETIN     Status PUBLISHED

 

In this Document
  Purpose
  Scope and Application
  Parameter DIRECT: Conventional Path Export Versus Direct Path Export
     1. Introduction.
     2. Performance issues.
     3. Restrictions. 
     4. Security considerations. 
     5. Typical errors.
     6. Known defects. 
  References

---

Applies to:

Enterprise Manager for RDBMS - Version: 8.1.7.4 to 11.1.0.6 - Release: to 11.1
Oracle Server - Enterprise Edition - Version: 7.3.0.0 to 11.1.0.6   [Release: 7.3.0 to 11.1]
Oracle Server - Personal Edition - Version: 7.3.3.0 to 11.1.0.6   [Release: 7.3.3 to 11.1]
Oracle Server - Standard Edition - Version: 7.3.0.0 to 11.1.0.6   [Release: 7.3.0 to 11.1]
Information in this document applies to any platform.
***Checked for relevance on 24-Jun-2010***

Purpose

This document provides information about the advantages and known problems, when exporting data from an Oracle database in the Direct Path mode.

Scope and Application

The article is intended for users of the Oracle7, Oracle8, Oracle8i, Oracle9i, and Oracle10g databases who wish to use the EXPORT utility to export data from an Oracle database in a Direct Path mode, rather than the usual Conventional Path mode. The article gives information about the difference between both modes, the advantages of a Direct Path export, but also the restrictions, some security considerations, the typical error messages, and some Direct Path related bugs with possible workarounds. 
This document is only applicable to the original Export client (exp). For Oracle10g, we recommend to use the new Export Data Pump (expdp) and Import Data Pump (impdp) clients. For Data Pump specific details, see also: 
Note:552424.1 "Export/Import DataPump Parameter ACCESS_METHOD - How to enforce a method of loading and unloading data ?"

Parameter DIRECT: Conventional Path Export Versus Direct Path Export

1. Introduction.

1.1. Starting with Oracle7 release 7.3, the Export utility provides two methods for exporting table data: 
- Conventional Path Export 
- Direct Path Export 

1.2. Conventional path Export. 
Conventional path Export uses the SQL SELECT statement to extract data from tables. Data is read from disk into the buffer cache, and rows are transferred to the evaluating buffer. The data, after passing expression evaluation, is transferred to the Export client, which then writes the data into the export file. 

1.3. Direct path Export. 
When using a Direct path Export, the data is read from disk directly into the export session's program global area (PGA): the rows are transferred directly to the Export session's private buffer. This also means that the SQL command-processing layer (evaluation buffer) can be bypassed, because the data is already in the format that Export expects. As a result, unnecessary data conversion is avoided. The data is transferred to the Export client, which then writes the data into the export file. 

1.4. The parameter DIRECT specifies whether you use the direct path Export (DIRECT=Y) or the conventional path Export (DIRECT=N). 

1.5. To use direct path Export, specify the DIRECT=Y parameter on the command line or in the parameter file. The default is DIRECT=N, which extracts the table data using the conventional path. 

1.6. This parameter is only applicable to the original export client. Export DataPump (expdp) uses a Direct Path unload by default and switches to External Table mode if required.

2. Performance issues.

2.1. Direct path Export can be much faster than Conventional path Export because the SQL command-processing layer is bypassed.

2.2. You may be able to improve performance by increasing the value of the RECORDLENGTH parameter when you invoke a direct path Export.  Your exact performance gain depends upon the following factors: 
- DB_BLOCK_SIZE 
- the types of columns in your table 
- your I/O layout (the drive receiving the export file should be separate from the disk drive where the database files reside) 

The following values are generally recommended for RECORDLENGTH: 
- multiples of the file system I/O block size 
- multiples of DB_BLOCK_SIZE 

For example, invoking a Direct path Export with a maximum I/O buffer of 64kb can improve the performance of the Export with almost 50%. This can be achieved by specifying the additional Export parameters DIRECT and RECORDLENGTH. E.g.:

> exp system/manager FILE=exp_full.dmp LOG=exp_full.log /
FULL=y DIRECT=y RECORDLENGTH=65535

> imp system/manager FILE=exp_full.dmp LOG=imp_full.log /
FULL=y RECORDLENGTH=65535 

2.3. A Direct path Export does not influence the time it takes to Import the data. That is, an export file created using Direct path Export or Conventional path Export, will take the same amount of time to Import.

3. Restrictions.

3.1. Command-line versus interactive. 
You cannot invoke a direct path Export using the interactive method. To invoke a direct path Export, you must use either the command-line method or a parameter file. 

3.2. Export mode. 
You cannot use the DIRECT=Y parameter when exporting in tablespace-mode  (i.e. when specifying the parameter TRANSPORT_TABLESPACES=Y).  You can use the DIRECT=Y parameter when exporting in full, user or table mode (i.e.: when specifying FULL=Y or OWNER=scott or TABLES=scott.emp). 

3.3. Objects and LOBs. 
In versions of Export prior to 8.1.5, you could not use direct path Export for tables containing objects and LOBs. If you tried to, their rows were not exported. This behavior has changed in Oracle8i and Oracle9i. Rows in tables that contain objects and LOBs will now be exported using conventional path, even if direct path was specified. Import will correctly handle these conventional path tables within direct path dump files. 
Note that when you use Export release 8.0 on an Oracle9i database, then Export doesn't export rows from tables containing objects and LOBs when you have specified a direct path load (DIRECT=y). 

3.4. Export parameter QUERY. 
The parameter QUERY applies ONLY to conventional path Export. It cannot be specified in a direct path export (DIRECT=Y).  This QUERY parameter allows you to select a subset of rows from a set of tables when doing a table mode export. For example, if user scott wants to export only those employees whose job title is salesman and whose salary is less than 1600, he could do the following (this example is UNIX-based):

> exp scott/tiger TABLES=emp QUERY=/"WHERE job=/'SALESMAN/' and sal/<1600/" 

3.5. Export parameter BUFFER. 
The BUFFER parameter applies ONLY to conventional path Export. It has no effect on a direct path Export. This BUFFER parameter specifies the size (in bytes) of the buffer used to fetch rows. It determines the maximum number of rows in an array, fetched by Export.  For direct path Export, use the RECORDLENGTH parameter to specify the size of the buffer that Export uses for writing to the export file. 

3.6. Export parameter RECORDLENGTH. 
The RECORDLENGTH parameter specifies the length (in bytes) of the file record. You can use this parameter to specify the size of the Export I/O buffer (highest value is 64 kb). Changing the RECORDLENGTH parameter affects only the size of data that accumulates before writing to disk.  It does not affect the operating system file block size.  If you do not define this parameter, it defaults to your platform-dependent value for BUFSIZ (1024 bytes in most cases). 

3.7. Character Set Conversion. 
A Direct path Export can only export the data when the NLS_LANG environment variable of the session who is invoking the export, is equal to the database characterset. If NLS_LANG is not set (default is AMERICAN_AMERICA.US7ASCII) and/or NLS_LANG is different, Export will display the warning EXP-41 and abort with EXP-0. For example:

EXP-00041: Export done in server's UTF8, different from user's character set WE8ISO8859P1 
EXP-00000: Export terminated unsuccessfully.

Setting NLS_LANG to the same value as the database character set (e.g.: NLS_LANG=AMERICAN_AMERICA.UTF8 in previous example), and retrying the export, will resolve this error. 
Note that this restriction only applies when exporting with an Oracle8i and below export utility. 

3.8. Compatibility. 
When using an Oracle7 or lower EXPORT release on an Oracle8i or higher release database, you have to use the default CONVENTIONAL path export (i.e.: do not specify DIRECT=YES in the export command statement).
Also beware that export does not export rows from tables containing objects and LOBs when you use Export release 8.0 on an Oracle8i or higher release database and have specified a direct path load (DIRECT=Y).

4. Security considerations.

4.1. Virtual Private Database (VPD) and Oracle Label Security are enforced during a Conventional Path Export. The export will terminate successfully, but with the warning: EXP-79 "Data in table %s is protected. Conventional path may only be exporting partial table." 
VPD and Oracle Label Security (Fine Grained Access Control - FGAC) are not enforced during Direct Path Exports. 

4.2. The following users are exempt from Virtual Private Database and Oracle Label Security enforcement regardless of the export mode (Direct or Conventional), application, or utility used to extract data from the database:
a. the database user SYS; 
b. database users granted the Oracle9i EXEMPT ACCESS POLICY privilege, either directly or through a database role. 
WARNING! 
- Any user who is granted the Oracle9i EXEMPT ACCESS POLICY privilege is completely free from the enforcement of VPD and Oracle Label Security. This is a powerful privilege and should be carefully managed. 
- The Oracle9i EXEMPT ACCESS POLICY privilege does not affect the enforcement of traditional object privileges such as SELECT, INSERT, UPDATE, and DELETE. These privileges are enforced even if a user has been granted the EXEMPT ACCESS POLICY privilege.

5. Typical errors.

5.1. EXP-00067 
Meaning: "Direct path cannot export %s which contains object or lob data." 
An Oracle7 and Oracle8 Direct Path export give EXP-67 because of tables with LOB datatype. Workaround: use Conventional Path export. 
Advanced Queueing (AQ) tables with LOB datatypes can also cause EXP-67 When these AQ tables are not being used, then dropping these tables could be another workaround (see references). 

5.2. EXP-00041 
Meaning: "Export done in server's %s, different from user's character set %s" 
A Direct Path export gives EXP-41 and EXP-0 when the export session characterset (NLS_LANG) is different than the database characterset. 
Solution: make the user session NLS_LANG equal to database characterset (when problem persists: re-run script catexp.sql). 

5.3. EXP-00079 
Meaning: "Data in table %s is protected. Conventional path may only be exporting partial table" 
A Conventional Path export uses the SQL SELECT statement to extract the data. As a result, the "Fine Grained Access Control" policies also apply during the Conventional Path export. 
Solution: in Oracle8i perform the export as user SYS or perform a Direct Path Export. In Oracle9i the privilege EXEMPT ACCESS POLICY can be used, regardless of the export mode.

6. Known defects.

Below an overview of known DIRECT path related defects in the various export releases:

Bug:498891 Direct Export can use excessive private memory
Fixed: 7.3.4.0 Workaround: use Conventional Path export 

Bug:514344 Direct EXPORT may omit trailing NULLs causing IMP-9 for very long rows.
Fixed: 7.3.4.0 Workaround: Use larger RECORDLENGTH (64000). 

Bug:558511 Direct Export generated on platform with totally different code page (e.g. EBCDIC) will cause IMP-10 (e.g. when importing on ASCII platform).
Fixed: 8.0.6.0 Workaround: use Conventional Path export 

Bug:690413 Direct Export could raise ORA-600 [729] (space leak) if it fails due to running out of disk space, or similar problem. 
Fixed: 8.0.6.0 Workaround: use Conventional Path export or ensure that Export does not fail (disk or similar cause). 

Bug:1092638 Direct Export with MTS may result in a dump (ORA-7445). 
Fixed: 8.1.7.0 Workaround: don't use MTS for Direct export. 

Bug 1324748 Direct Export of an IOT may yield ORA-600 [2845] if the primary key ends with a ROWID column (not a public bug)
Fixed: 8.1.7.1 Workaround: use Conventional Path export 

Bug:1672945 Direct Export causes ORA-600 [729] when tablespace is offline 
Fixed: 9.0.1.0 Workaround: use Conventional Path export or make sure tablespace if online when starting Export. 

Bug:1477959 Direct Export for a table containing columns of type ROWID could fail with ORA-600 [6193] or ORA-600 [6190] or ORA-4030 
Fixed: 8.1.7.4 and 9.0.1.3 and 9.2.0.1 
Workaround: use Conventional Path export 

Bug 1820663 Direct Export of a table can generate duplicate column names (not a public bug) 
Fixed: 9.2.0 Workaround: use Conventional Path export 

Bug 1686987 Direct Export can result in ORA-600 [6191] with a possible stack: kdeuwrd kdeuprd kdeuscn kueuld (not a public bug)
Fixed: 8.1.7.4 and 9.0.1.3 and 9.2.0 
Workaround: use Conventional Path export 

Bug 1805146 DROP Functional index does not clean up dictionary - Can cause corrupt export file (not a pubic bug). 
Fixed: 8.1.7.3 9.0.1.3 9.2.0.1 
Workaround: re-run export in Conventional path mode 
See also alert in:
Note:148740.1 "ALERT: Export Of Table With Dropped Functional Index May Cause IMP-20 On Import" 

Bug:2666174 Export in direct path mode can produce a corrupt export dump file if an ORA-1555 (snapshot too old) error occurs. 
Fixed: 9.2.0.5 and Oracle10g (= export will now terminate unsuccessfully with EXP-0 error) 
Workaround: Ensure that no other transaction is updating the same table, and that the size of the rollback segment is sufficient. Or use Conventional Path export. 

Bug:2308033 Direct Export of a long row and with an 8k or larger database blocksize, can result in ORA-600 [6191] or ORA-600 [6193] 
Fixed: 9.0.1.4 and 9.2.0.2 and Oracle10g 
Workaround: use Conventional Path export 

Bug:3083560 ORA-1410 / ORA-8103 from direct path export if concurrent DML occurs. 
Fixed: 9.2.0.5 and Oracle10g 
Workaround: use Conventional Path export 

Bug:3230116 Direct Export of Compressed table fails with: ORA-600 [6193] 
Fixed: 9.2.0.5 and Oracle10g 
Workaround: use Conventional Path export 

Bug:3579567 9.2.0.5 Import of Compressed table fails: IMP-9 (IMP-00009) 
Fixed: 9.2.0.6 and 10.1.0.4 and 10.2.0.1 
Workaround: use Conventional Path export 

Bug:3596139 10.1.0.2 ORA-10632 on direct path export of IOT 
Fixed: 10.1.0.4 and 10.2.0.1 
Workaround: use Conventional Path export 

Bug:3868753 ORA-1410 / ORA-8103 from direct path export if concurrent inserts against ASSM tables occur. 
Fixed: 9.2.0.7 and 10.1.0.5 and 10.2.0.1 
Workaround: use Conventional Path export 

Bug:4085785 9.2.0.6 Export of Compressed Partition: ORA-600 [6191] 
Fixed: 10.2.0.1 
Workaround: use Conventional Path export 

References

BUG:1477959 - EXPORT FOR A TABLE FAILS WITH ORA-600[6193],[1],[579],[6],[],[],[],[]
BUG:1672945 - DIRECT EXPORT CAUSES ORA-600[729] WHEN TABLESPACE IS OFFLINE.
BUG:1754922 - IMPORT OF A SIMPLE CHAR GIVES IMP-20 WITH DIRECT=Y
BUG:2308033 - DIRECT EXPORT FAILS WITH ORA-600 [6191] & [6193]
BUG:2666174 - IMPORT SKIPS TABLES CONTAINED IN THE EXPORT DUMP FILE
BUG:3083560 - WHEN EXPORTING PARTITIONED TABLE, INSERTING DATA TO THE TABLE TRIGGER ORA-1410
BUG:3230116 - DIRECT EXPORT OF COMPRESSED TABLE FAILS WITH ORA-600 [6193]
BUG:3579567 - IMP-9 WHEN IMPORTING A COMPRESSED TABLE THAT HAS BEEN EXPORTED WITH DIRECT=Y
BUG:3596139 - ORA-10632 ON DIRECT PATH EXPORT OF IOT IN MANUAL SEGMENT SPACE MANAGEMENT TBSP
BUG:3868753 - EXPORT RETURNS ORA-1410 WHEN OTHER SESSION IS EXECUTING INSERT.
BUG:4085785 - ORA-600 [6191] ON COMPRESSED PARTITION EXPORT ON VERSION WHICH INCLUDES 3230116
BUG:498891 - EXPORT DIRECT = Y , ORA 0008, ORA 603, ORA 7324, ORA 4030
BUG:514344 - DIRECT-PATH EXPORT OF TABLE ROW MAY SKIP TRAILING NULL WRITE (LEADS TO IMP-009)
BUG:558511 - IMP-10 WHEN TRYING TO IMPORT AN EXPORT FILE CREATED WITH DIRECT=Y
BUG:690413 - ORA-600 [729][545296][SPACE LEAK][][] FOUND IN ALERT FILE
NOTE:1017491.102 - EXP-41: DIRECT PATH MODE FULL DATABASE EXPORT
NOTE:1024800.6 - EXP-41 WHEN ATTEMPTING TO PERFORM DIRECT MODE EXPORT; CONVENTIONAL EXPORT MODE WORKS FINE.
NOTE:1048461.6 - EXP-00067 Performing Direct Path Export
NOTE:132904.1 - Compatibility Matrix for Export And Import Between Different Oracle Versions [Video]
NOTE:148740.1 - ALERT: Export Of Table With Dropped Functional Index May Cause IMP-20 On Import
NOTE:214369.1 - Using The Export Utility To Check For Database Corruption
NOTE:239965.1 - ORA-600 [6191] or ORA-600 [6193] on DIRECT Mode Export
NOTE:277237.1 - How to Connect AS SYSDBA when Using Export or Import
NOTE:277606.1 - How to Prevent EXP-00079 or EXP-00080 Warning (Data in Table xxx is Protected) During Export
NOTE:552424.1 - Export/Import DataPump Parameter ACCESS_METHOD - How to Enforce a Method of Loading and Unloading Data ?
NOTE:76329.1 - Conventional & Direct Path Export: Oracle Release 7.3
NOTE:90162.1 - EXP-41: On Full Direct Mode Export

Related

---

Products

---

• Enterprise Management > Enterprise Manager Consoles, Packs, and Plugins > Managing Databases using Enterprise Manager > Enterprise Manager for RDBMS
• Oracle Database Products > Oracle Database > Oracle Database > Oracle Server - Enterprise Edition
• Oracle Database Products > Oracle Database > Oracle Database > Oracle Server - Personal Edition
• Oracle Database Products > Oracle Database > Oracle Database > Oracle Server - Standard Edition

Keywords

---

LEAK; DIRECT PATH; LOB; CHARACTERSET; EXPORT UTILITY; CONVENTIONAL PATH; SPACE LEAK; UTILITY

Errors

---

EXP-0; EXP-67; EXP-41; ORA-1410; ORA-7445; ORA-1555; ORA-4030; ORA-8103; IMP-9; IMP-20