Files - Expert Oracle Database Architecture - page 122

Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

IMP-00010: not a valid export file, header failed verification
IMP-00000: Import terminated unsuccessfully

Even in the cases where IMP was able to recognize the file, there would be a great chance that the DDL generated
by the 11 g Release 2 EXP tool would not be DDL that the earlier version of Oracle would recognize. For example,
suppose you export from any release of Oracle version 9 i Release 2 or above. You would find in the export file
that every CREATE TABLE has a COMPRESS or NOCOMPRESS option added to it. Oracle9 i Release 2 added basic table
compression as a feature. If you were able to get any release of Oracle older than 9 i Release 2 to read that export file,
you'd find that the DDL it contains would fail—100 percent of the time. Not a single CREATE TABLE statement would
work because the NOCOMPRESS/COMPRESS keywords would not be recognized by the older release.
DMP files are platform-independent, so you can safely take an export from any platform, transfer it to another,
and import it (as long as the versions of Oracle permit). One caveat, however, with Windows and FTPing of files is
that Windows will consider a DMP file a text file by default and will tend to convert linefeeds (the end-of-line marker
on UNIX/Linux) into carriage return/linefeed pairs, thus totally corrupting the DMP file. When transferring a DMP
file in Windows, make sure you're doing a binary transfer. If your subsequent import won't work, check the source
and target file sizes to make sure they're the same. I can't recall how many times this issue has brought things to a
screeching halt while the file had to be retransferred.
DMP files are binary files, meaning you won't be editing them to change them. You can extract a large amount of
information from them— CREATE DDL and more—but you won't be editing them in a text editor (or any sort of editor,
actually). In the topic Expert One-on-One Oracle (Apress, 2003), I spent a great deal of time discussing the Import and
Export utilities and working with DMP files. Because these tools are falling out of favor, in place of the infinitely more
flexible Data Pump utilities, I'll defer a full discussion of how to manipulate them, extract data from them, and use
them in general to the existing first edition of this topic.

Data Pump Files
Data Pump is a file format used by at least two tools in Oracle. External tables can load and unload data in the Data
Pump format, and the new import/export tools IMPDP and EXPDP use this file format in much the same way IMP and EXP
used the DMP file format.

■ the Data Pump format is exclusive to Oracle 10 g release 1 and above—it did not exist in any Oracle9 i release,
nor can it be used with that release.

Note

Pretty much all of the same caveats that applied to DMP files mentioned previously will apply over time to
Data Pump files as well. They are cross-platform (portable) binary files that contain metadata (not stored in
CREATE/ALTER statements, but rather in XML) and possibly data. That they use XML as a metadata representation
structure is actually relevant to you and me as end users of the tools. IMPDP and EXPDP have some sophisticated
filtering and translation capabilities never seen in the IMP/EXP tools of old. This is in part due to the use of XML and
to the fact that a CREATE TABLE statement is not stored as a CREATE TABLE , but rather as a marked-up document. This
permits easy implementation of a request like “Please replace all references to tablespace FOO with tablespace BAR.”
When the metadata was stored in the DMP file as CREATE/ALTER statements, the Import utility would have had to
basically parse each SQL statement before executing it in order to accomplish the feat of changing tablespace names
(something it does not do). IMPDP , however, just has to apply a simple XML transformation to accomplish the same.
FOO, when it refers to a TABLESPACE , would be surrounded by <TABLESPACE>FOO</TABLESPACE> tags (or some other
similar representation).