Escolar Documentos
Profissional Documentos
Cultura Documentos
PREAMBLE
Export and import—the undisputed workhorses of Oracle utilities. We’ve been using export and import since this software
first hit the streets and are learning more about them each time we put them to use. They play a role in the design and
implementation of a backup/recovery strategy. In this paper we will introduce export and import and
• Look at a handful of their common parameters
• Discuss some of their non-shared parameters
• Discuss the role they play in a robust comprehensive backup strategy.
At the live presentation during the conference, we will look at export/import modes of operation and exporting data
through a UNIX compressed pipe. Export and import, from day one, require a thorough understanding of what they can do,
what they are designed to accomplish, and what can go wrong when not used properly. Let’s get our feet wet.
EXPORT AND IMPORT PARAMETERS
Both these handy utilities share many parameters, whereas others are unique to each one. Online help is displayed by running
each program with the parameter value help=y as shown next.
For purposes of this paper, I have cut out the bottom of these two help displays as the parameters listed towards the bottom are for more advanced
discussions of export and import.
/u01/app/oracle/product/9.0.1> exp help=y
Export: Release 9.0.1.0.0 - Production on Thu Sep 13 21:55:49 2001
(c) Copyright 2001 Oracle Corporation. All rights reserved.
You can let Export prompt you for parameters by entering the EXP
command followed by your username/password:
Or, you can control how Export runs by entering the EXP command followed
by various arguments. To specify parameters, you use keywords:
Paper 503
DBA
You can let Import prompt you for parameters by entering the IMP
command followed by your username/password:
Or, you can control how Import runs by entering the IMP command followed
by various arguments. To specify parameters, you use keywords:
The sheer volume of these parameters seems overwhelming at first—let’s delve into some common parameters first
then look at some unique to each tool. After each section, we will look at a few common requirements and how to use export
and import with the parameters discussed so far.
PARAMETERS COMMON TO EXPORT AND IMPORT
Although we will not look at all the parameters listed in these help screens, we’ll spend some time on the most common. The
secret to becoming comfortable with export and import is to keep it simple at first, then move forward into using more
complicated scenarios.
USERID
This parameter is followed by the username and password running the export/import session. Normally the account is
deliberately privilege rich so it can export data from or import data into multiple schemas. If you run from an account the $
character (e.g., OPS$ABRAMSON) in UNIX, you need to escape the $ or enclose the username/password combination in single
quotes as shown next.
exp userid='ops$abramson/yatfg'
imp userid=ops\$abramson/yatfg
BUFFER
This parameter instructs Oracle on how much memory to allocate as a work are for the export/import session. The default
allocated is simply not enough and you would be wise right from the start to code values of 1,000,000 bytes or more. A few
examples of using buffer are shown next.
Paper 503
DBA
Coding grants=n causes the message Note: grants on tables/views/sequences/roles will not be exported to be displayed. This is not
fatal to the export session.
INDEXES {Y|N}
Coding indexes=y on an export is dealt with in the same manner as the behaviour of the grants parameter. The indexes
themselves are not dumped to the export file, simply the appropriate SQL statements required to create the indexes after their
table data is brought in by import.
Coding indexes=n causes the message Note: indexes on tables will not be exported, as well not fatal to the export session.
ROWS {Y|N}
This parameter instructs export to extract the data as well as the data definitions to the export file. On the other end, this
parameter influences import as to whether the data itself (rows in the tables in the export file) should be brought in to the
specified schema(s).
Coding rows=n displays the warning Note: table data (rows) will not be exported.
FULL {Y|N}
This parameter, though common to export and import, has different meanings to each.
• When used with export, full=y instructs Oracle to do a full export, extracting all data definitions and data for all schemas
in the database. For example, SQL statements to create the tablespaces are written to an export file written with this
parameter set to y.
• When used with import, full=y instructs Oracle to import the entire contents of the export file. Think of this parameter as
a directive to import the full file.
LOG
This parameter is followed by the name of a file to track and save the operation and results of the export/import session. Be
smart when naming the log file. The last line of the log file will display two pieces of very useful information—the completion
status of the work and whether there were any errors encountered. These errors are usually in the form of Oracle or EXP/IMP
messages as shown next.
EXP-00011: OPS$ABRAMSON.ALTIMA does not exist
Paper 503
DBA
OWNER
This parameter lists one or more owners whose objects are to be exported. The schema names, if more than one, are
separated by commas. The list of multiple schemas should be bound by parentheses as shown in the next listing. This listing
as well shows the problem that comes up when using parentheses on the UNIX command line in ksh and bash.
exp owner=(track,avenue)
ksh: syntax error: `(' unexpected
exp owner=(track,avenue)
bash: syntax error near unexpected token `owner=(t'
Note how the singular of owner is still used even if exporting multiple owners.
TABLES
This parameter instructs export to include the specified list of tables in the export session. As with owner, the same rules with
commas and parentheses apply.
TRIGGERS {Y|N}
This parameter, when coded with a value n, tells export not to write table level trigger PL/SQL code to the export file. In many
situations, this is desirable to ensure that triggers are not created and allowed to fire unbeknownst to you as you perform an
Paper 503
DBA
import. Rest assured, the behaviour of triggers on an import is such that the triggers are created after the corresponding table
has been defined and its date brought in.
The directive triggers=n DOES NOT WORK in any version of Oracle8i; this is a known bug that is not fixed until 9i.
EXAMPLE #4
Requirement: As user GILMOUR (password crazy) perform an export of data from the WATERS schema.
Solution: exp userid=gilmour/crazy file=waters_data log=waters_data_out buffer=2000000 owner=gilmour
EXAMPLE #5
Requirement: As user GILMOUR (password crazy) perform an export of data from only the BRICK_IN_THE_WALL table
belonging to WATERS.
Solution: exp userid=gilmour/crazy file=waters_data log=waters_data_out buffer=2000000
tables=waters.brick_in_the_wall
This example is the first time (in this paper) you could very easily find yourself in a pickle had you coded owner=waters and
tables=brick_in_the_wall. This would generate an Oracle EXP error similar to the following. We will be covering more about
conflicts between parameters at the presentation during Live 2002.
EXP-00026: conflicting modes specified
EXP-00000: Export terminated unsuccessfully
EXAMPLE #6
Requirement: As user GILMOUR (password crazy) perform an export of data belonging to MASON, WRIGHT, and COUNSEL.
Solution: exp userid=gilmour/crazy file=mwc_data log=mwc_data_out buffer=2000000
owner=\(mason,wright,counsel\)
IGNORE {Y|N}
At first glance, this parameter can be confusing—its value instructs Oracle what to do on an import when it tries to bring a
table in that already exists in the target schema. The logic shown in the next listing best describes the behaviour of At first
glance, this parameter can be confusing—its value instructs Oracle what to do on an import when it tries to bring a table in
that already exists in the target schema. The logic shown in the next listing best describes the behaviour of y and n for the
ignore parameter.
an issue (e.g., importing the multi-million / multi-gigabyte tables), using commit=y can help ensure the import sessions runs
successfully to completion.
FROMUSER / TOUSER
These two parameters are the pièce de resistance (also referred to as the cat’s meow in America) with import. This is how you
take data from one schema (PIPERAT for example) and bring it into target schema with a different name (say something like
THEGATESOFDAWN). The next listing show an import session using these parameters.
INDEXFILE
The value coded for this parameter is the name of a text file to which all the table, index, and constraint definition SQL*Plus
text will be written. No data is brought in and no objects are created. This text file can be edited and run in SQL*Plus. A
snippet of code from an import using indexfile=echoes.sql is shown next.
EXAMPLE #7
Requirement: As user WISHYOU (password werehere), create a text file containing all the SQL statements contained in an
export file pulled from the AXIOM database.
Solution: imp userid=wishyou/werehere file=axiom_full log=axiom_full_in buffer=2000000 full=y
indexfile=axiom_full.sql
EXAMPLE #8
Requirement: As user THELUNATIC (password isinthegrass), create a copy of the USANDTHEM schema in the MONEY
target schema. The tables in the MONEY schema have been created and are all empty.
Solution: imp userid=thelunatic/isinthegrass file=usandthem_full log=usandthem_full_in buffer=2000000
fromuser=usandthem touser=money ignore=y
Paper 503
DBA
Paper 503
DBA
This method for verification of your exports is quick and almost fool proof. Murphy’s law dictates that something
may end up going wrong some day with one of your database exports. Checking the export file using this indexfile= approach
will increase the likelihood that your exports are usable and will not return an all too familiar error as shown next.
IMP-00009: abnormal end of export file
WRAPUP
We have covered quite a bit of ground in this paper. Many readers may already be familiar with the in’s and out’s of using
export and import. As you become more and more comfortable with their power and their parameters, you will understand
the relationship between parameters and how they affect one another. My advice to any DBA, be it one with 6 weeks or 6
years experience, is get to know export and import like the back of your hand. Experiment with different export scenarios and
test your exports, test your exports, and test your exports.
ABOUT THE AUTHOR: Michael S. Abbey is the lead in a very successful offering of remote DBA services with the Pythian
Group in Ottawa Canada. Michael has co-authored 10 works in the Oracle Press series, the most
successful being the Beginner’s Guide series. Michael is an instructor at the IOUG’s University
Master Class, delivering guidance in the area of Advanced DBA Best Practices. He has been
working with the Oracle Server for the past 16 years, having seen versions 3 through 9i.
Paper 503