![Location is bookmarked]( "Location is bookmarked")
Performing
Data Pump Exports and Imports
The Data Pump Export utility loads row data from database tables, as well as object metadata, into dump file sets in a proprietary format that only the Data Pump Import utility can read. The dump file sets, which are operating system files, contain data, metadata, and control information. Dump file sets usually refer to a single file, such as the default export dump file expdat.dmp.
Quite a few of the Data Pump Import utility's features are mirror images of the Data Pump Export utility features. However, some features are exclusive to the Data Pump Import utility.
In the following sections, we'll look at Data Pump types, modes, and parameters, as well as some examples.
Data Pump Export Methods
You can interface with the Data Pump Export and Import utilities through the command line, using a parameter file, or interactively. Let's now examine the various methods.
| Note |
Performing a Data Pump export or import of data using manual methods is tedious and error-prone. OEM provides excellent export and import wizards that let you quickly perform an export or import. You can also schedule these jobs using OEM. Before you use the OEM's wizards, however, it's good to go through the manual processes to understand what's involved in using the Data Pump Export and Import utilities. |
Using the Command Line
You can use the Data Pump Export utility from the command line in a manner similar to the traditional export utility. Note that by default, you specify the username/password combination after the keyword expdp. Here's a simple example:
$ expdp system/manager DIRECTORY=dpump_dir1 DUMPFILE=expdat1.dmp
As you can see, the command-line option would quickly get tiring if you were doing anything but the simplest type of exports.
Using a Parameter File
Rather than specifying the export parameters on the command line, you can put them in a parameter file. You then simply invoke the parameter file during the actual export. Here's an example of a parameter file:
SCHEMAS=HR DIRECTORY=dpump_dir1 DUMPFILE=system1.dmp SCHEMAS=hr
Once you create the parameter file, all you need to do in order to export the HR schema is invoke expdp with just the PARFILE parameter:
$ expdp PARFILE=myfile.txt
| Note |
You can use all command-line export parameters in an export parameter file. The only exception is the parameter PARFILE itself. |
Using Interactive Data Pump Export
Several of you are probably familiar with the interactive feature of the old export and import utilities. All you needed to do during an interactive export or import was type exp or imp at the command line, and Oracle would prompt you for the rest of the information. Interactive Data Pump is quite different from the interactive mode of the older utilities. As you'll see in the following sections, Data Pump's interactive mode isn't meant to be used in the same way as the exp/imp interactive mode—you can't start an interactive job using the Data Pump Export (or Import) utility. You can use the interactive mode only to intervene during a running job.
In Data Pump Export, you use the interactive method for one purpose only: to change some export parameters midstream while the job is still running. There are two ways to get into the interactive mode. The first is by pressing the Ctrl+C combination on your keyboard, which interrupts the running job and displays the export prompt (export>) on your screen. At this point, you can deal interactively with the Export utility, with the help of a special set of interesting commands, which I'll explain later in this chapter in the "Interactive Mode Export Parameters (Commands)" section.
The second way to enter the interactive mode of operation is by using the ATTACH command. If you are at a terminal other than the one where you started the job, you can attach to the running job by specifying the ATTACH parameter.
| Note |
In Data Pump, the interactive mode means that the export or import job stops logging its progress on the screen and displays the export> (or import>) prompt. You can enter the special interactive commands at this point. Note that the export or import job keeps running throughout, without any interruption. |
You can also perform Data Pump Export and Import operations easily through the OEM Database Control interface. To use this feature, start the Database Control, select Maintenance, and then choose Utilities. On the Utilities page, you can see the various choices for exporting and importing data.
Data Pump Export Modes
As in the case of the regular export utilities, you can perform Data Pump Export jobs in several modes:
-
Full export mode: You use the FULL parameter when you want to export the entire database in one export session. You need the EXPORT_FULL_DATABASE role to use this mode.
-
Schema mode: If you want to export a single user's data and/or objects only, you must use the SCHEMAS parameter.
-
Tablespace mode: By using the TABLESPACES parameter, you can export all the tables in one or more tablespaces. If you use the TRANSPORT_TABLESPACES parameter, you can export just the metadata of the objects contained in one or more tablespaces. You may recall that you can export tablespaces between databases by first exporting the metadata, copying the files of the tablespace to the target server, and then importing the metadata into the target database.
-
Table mode: By using the TABLES parameter, you can export one or more tables. The TABLES parameter is identical to the TABLES parameter in the old export utility.
Schema mode is the default mode for Data Pump Export and Import jobs. If you log in as follows, for example, Data Pump will automatically perform a full export of all of SYSTEM's objects:
$ expdp system/sammyy1
If you are the SYSTEM user, you can export another schema's objects by explicitly using the SCHEMAS parameter, as shown in Listing 14-3.
$ expdp system/sammyy1 DUMPFILE=scott.dmp SCHEMAS=SCOTT
Export: Release 11.1.0.6.0 - Production on Tuesday, 25 March, 2008 12:19:31
Copyright (c) 2003, 2007, Oracle. All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 -
Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
FLASHBACK automatically enabled to preserve database integrity.
Master table "SCOTT"."SYS_SQL_FILE_SCHEMA_01" successfully loaded/unloaded
Starting "SYSTEM"."SYS_EXPORT_SCHEMA_01": system/******** dumpfile=scott.dmp
schemas=SCOTT
total estimation using BLOCKS method: 192 KB
Processing object type SCHEMA_EXPORT/USER
Processing object type SCHEMA_EXPORT/SYSTEM_GRANT
Processing object type SCHEMA_EXPORT/ROLE_GRANT
Processing object type SCHEMA_EXPORT/DEFAULT_ROLE
Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Processing object type SCHEMA_EXPORT/TABLE/TABLE
Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX
Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Processing object type SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
Processing object type SCHEMA_EXPORT/CONSTRAINT/REF_CONSTRAINT
Processing object type SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
. . exported "SCOTT"."DEPT"
. . exported "SCOTT"."EMP"
. . exported "SCOTT"."SALGRADE"
. . exported "SCOTT"."BONUS"
Dump file set for SYSTEM.SYS_EXPORT_SCHEMA_01 is:
/u01/app/oracle/product/10.2.0/db_1/admin/orcl/dpdump/scott.dmp
Job "SYSTEM"."SYS-EXPORT_SCHEMA_01" successfully completed AT 18:25:16
Data Pump Export Parameters
Some of the Data Pump Export utility parameters will be familiar to you from the traditional export utility. Others are quite new. Here, I'll briefly run through the parameters, providing detailed explanations for the most important parameters. For this discussion, I've grouped the parameters into the following categories:
-
File- and directory-related parameters
-
Export mode-related parameters
-
Export filtering parameters
-
Encryption-related parameters
-
Estimation parameters
-
The network link parameter
-
Interactive mode export parameters
-
Job-related parameters
Note that you can use all the export parameters at the command line or in parameter files, except for those listed in the "Interactive Mode Export Parameters (Commands)" section.
File- and Directory-Related Parameters
You can specify several file- and directory-related parameters during a Data Pump Export job. These include the DIRECTORY, DUMPFILE, FILESIZE, PARFILE, LOGFILE, NOLOGFILE, and COMPRESSION parameters.
DIRECTORY
The DIRECTORY parameter refers to the directory object to be used for dump files and log files. See the "Using Directory Objects" section earlier in this chapter for details.
DUMPFILE
The DUMPFILE parameter provides the name (or list) of the dump file(s) to which the export dump should be written. The DUMPFILE parameter replaces the FILE parameter in the old export utility. You can provide multiple dump filenames in several ways:
-
Create multiple dump files by specifying the %U substitution variable. The substitution variable will start at 01 and can go up to 99. For example, a specification like exp%U.dmp can be expanded into filenames such as exp01.dmp, exp02.dmp, exp03.dmp, and so on.
-
Provide multiple files in a comma-separated list.
-
Specify the DUMPFILE parameter multiple times for a single export job.
| Note |
If you specify the %U notation to indicate multiple dump files, the number of files you can create is equal to the value of the PARALLEL parameter. |
If you don't specify the DUMPFILE parameter, Oracle will use the default name expdat.dmp for the export dump file, just as it did with the traditional export utility.
FILESIZE
The FILESIZE parameter is purely optional, and it specifies the size of the dump file in bytes by default. You may use bytes, kilobytes, megabytes, and gigabytes to specify the FILESIZE parameter. If you don't specify this parameter, the dump file has no limits on its size. If you use the FILESIZE parameter by specifying, say 10MB, as the maximum dump file size, your export will stop if your dump file reaches its size limit, and you can restart it after correcting the problem.
PARFILE
The PARFILE parameter stands for the same thing it did in the traditional export utility: the parameter file. As explained earlier in this chapter, you can specify export parameters in a parameter file, instead of entering them directly from the command line.
LOGFILE and NOLOGFILE
You can use the LOGFILE parameter to specify a log file for your export jobs. Here's what you need to remember regarding this parameter:
-
If you just specify the LOGFILE parameter without the DIRECTORY parameter, Oracle automatically creates the log file in the location you specified for the DIRECTORY parameter.
-
If you don't specify this parameter, Oracle creates a log file named export.log.
If you specify the parameter NOLOGFILE, Oracle does not create its log file (export.log). You still see the progress of the export job on the screen, but Oracle suppresses the writing of a separate log file for the job.
REUSE_DUMPFILES
You can specify the REUSE_DUMPFILE parameter to overwrite an export dump file. By default, the database doesn't overwrite dump files. You can specify the value Y to overwrite a dump file and the value N for the default behavior, which is not to use older dump files. Here's an example showing how to specify this parameter during an export job:
$ expdp hr DIRECTORY=dpump_dir1 DUMPFILE=hr.dmp TABLES=employees REUSE_DUMPFILES=y
Of course, you must make sure that you don't need the contents of the preexisting dump file, hr.dmp.
COMPRESSION
The COMPRESSION parameter enables the user to specify which data to compress before writing the export data to a dump file. By default, all metadata is compressed before it's written out to an export dump file. You can disable compression by specifying a value of NONE for the COMPRESSION parameter, as shown here:
$ expdp hr/hr DIRECTORY=dpump_dir1 DUMPFILE=hr_comp.dmp COMPRESSION=NONE
The COMPRESSION parameter can take any of the following four values:
-
ALL: Enables compression for the entire operation.
-
DATA_ONLY: Specifies that all data should be written to the dump file in a compressed format.
-
METADATA_ONLY: Specifies all metadata be written to the dump file in a compressed format. This is the default value.
-
NONE: Disables compression of all types.
Export Mode-Related Parameters
The export mode-related parameters are FULL, SCHEMAS, TABLES, TABLESPACES, TRANSPORT_TABLESPACES, and TRANSPORT_FULL_CHECK. You've already seen all these parameters except the last one, TRANSPORT_FULL_CHECK, in the "Data Pump Export Modes" section earlier in this chapter.
The TRANSPORT_FULL_CHECK parameter checks to make sure that the tablespaces you are trying to transport meet all the conditions to qualify for the transportable tablespaces job. Using this parameter, you can specify whether to check for dependencies between objects inside the transportable set and the other objects in the database. For example, an index is entirely dependent on the table, since it doesn't have any meaning without the table. However, a table isn't dependent on an index, since the table can exist without an index.
You can set the TRANSPORT_FULL_CHECK parameter to a value of Y or N. If you set TRANSPORT_FULL_CHECK=Y, the Data Pump Export job will check for two-way dependencies. If you have a table in the transportable tablespace but not its indexes, or your tablespace contains indexes without their tables, the export job will fail. If you set TRANSPORT_FULL_CHECK=N, the Data Pump Export job will check for one-way dependencies. If your transportable tablespace set contains tables without their indexes, the export will succeed. However, if the set contains indexes without their tables, the export job will fail.
Export Filtering Parameters
Data Pump contains several parameters related to export filtering. Some of them are substitutes for old export parameters; others offer new functionality. Let's look at these important parameters in detail.
CONTENT
By using the CONTENT parameter, you can filter what goes into the export dump file. The CONTENT parameter can take three values:
-
ALL exports both table data and table and other object definitions (metadata).
-
DATA_ONLY exports only table rows.
-
METADATA_ONLY exports only metadata.
Here's an example:
$ expdp system/manager DUMPFILE=expdat1.dmp CONTENT=DATA_ONLY
| Note |
The CONTENT=METADATA_ONLY option is equivalent to the ROWS=N option in the original export utility. |
EXCLUDE and INCLUDE
The EXCLUDE and INCLUDE parameters are two mutually exclusive parameters that you can use to perform what is known as metadata filtering. Metadata filtering enables you to selectively leave out or include certain types of objects during a Data Pump Export or Import job. In the old export utility, you used the CONSTRAINTS, GRANTS, and INDEXES parameters to specify whether you wanted to export those objects. Using the EXCLUDE and INCLUDE parameters, you now can include or exclude many other kinds of objects besides the four objects you could filter previously. For example, if you don't wish to export any packages during the export, you can specify this with the help of the EXCLUDE parameter.
| Note |
If you use the CONTENT=DATA_ONLY option (same as the old ROWS=Y parameter), you aren't exporting any objects—just table row data. Naturally, in this case, you can't use either the EXCLUDE or INCLUDE parameter. |
Simply put, the EXCLUDE parameter helps you omit specific database object types from an export or import operation. The INCLUDE parameter, on the other hand, enables you to include only a specific set of objects. Following is the format of the EXCLUDE and INCLUDE parameters:
EXCLUDE=object_type[:name_clause] INCLUDE=object_type[:name_clause]
For both the EXCLUDE and INCLUDE parameters, the name clause is optional. As you know, several objects in a database—such as tables, indexes, packages, and procedures—have names. Other objects, such as grants, don't. The name clause in an EXCLUDE or an INCLUDE parameter lets you apply a SQL function to filter named objects.
Here's a simple example that excludes all tables that start with EMP:
EXCLUDE=TABLE:"LIKE 'EMP%'"
In this example, "LIKE 'EMP%'" is the name clause.
The name clause in an EXCLUDE or INCLUDE parameter is optional. It's purely a filtering device, allowing you finer selectivity within an object type (index, table, and so on). If you leave out the name clause component, all objects of the specified type will be excluded or included.
In the following example, Oracle excludes all indexes from the export job, since there is no name clause to filter out only some of the indexes:
EXCLUDE=INDEX
You can also use the EXCLUDE parameter to exclude an entire schema, as shown in the following example:
EXCLUDE=SCHEMA:"='HR'"
The INCLUDE parameter is the precise opposite of the EXCLUDE parameter: it forces the inclusion of only a set of specified objects in an export. As in the case of the EXCLUDE parameter, you can use a name clause to qualify exactly which objects you want to export. Thus, you have the ability to selectively choose objects at a fine-grained level.
The following three examples show how you can use the name clause to limit the selection of objects:
INCLUDE=TABLE:"IN ('EMPLOYEES', 'DEPARTMENTS')"
INCLUDE=PROCEDURE
INCLUDE=INDEX:"LIKE 'EMP%'"
The first example is telling the Data Pump job to include only two tables: employees and departments. In the second example, the INCLUDE parameter specifies that only procedures should be included in this export job. The third example shows how you can specify that only those indexes that start with EMP should be part of the export job.
The following example shows how you must use slashes (\) to escape the double quotation marks:
$ expdp scott/tiger DUMPFILE=dumphere:file%U.dmp schemas=SCOTT EXCLUDE=TABLE:\"='EMP'\", EXCLUDE=FUNCTION:\"='MY_FUNCTION''\",
| Note |
The EXCLUDE and INCLUDE parameters are mutually exclusive. You can use one or the other, not both simultaneously in the same job. |
When you filter metadata by using the EXCLUDE or INCLUDE parameters, remember that all objects that depend on any of the filtered objects are processed in the same fashion as the filtered object. For example, when you use the EXCLUDE parameter to exclude a table, you'll also be automatically excluding the indexes, constraints, triggers, and so on that are dependent on the table.
REMAP_DATA
The REMAP_DATA parameter enables you to replace the values in a column with a new value. The new values for a column are specified by a remap function. You can use this parameter when you're moving data from a production system to a test system and would like some columns containing sensitive information to be changed for privacy reasons. You can use the same remapping function to remap both child and parent columns in a referential constraint.
The following example shows how to apply remapping functions to two columns in a table:
$ expdp hr DIRECTORY=dpump_dir1 DUMPFILE=remap1.dmp TABLES=employees
REMAP_DATA=hr.employees.employee_id:hr.remap.minus10
REMAP_DATA=hr.employees.first_name:hr.remap.plusx
In the example, the EMPLOYEE_ID and FIRST_NAME columns from the employees table are remapped using the two functions REMAP10 and PLUSX that belong to the package named REMAP.
DATA_OPTIONS
The DATA_OPTIONS parameter lets you specify options on handling specific types of data during an export. You can only specify the value XML_CLOBS for this parameter (DATA_OPTIONS=XML_CLOBS).
QUERY
The QUERY parameter serves the same function as it does in the traditional export utility: it lets you selectively export table row data with the help of a SQL statement. The QUERY parameter permits you to qualify the SQL statement with a table name, so that it applies only to a particular table. Here's an example:
QUERY=OE.ORDERS: "WHERE order_id > 100000"
In this example, only those rows in the orders table (owned by user OE) where the order_id is greater than 100,000 are exported.
SAMPLE
Using the SAMPLE parameter, which was brand new in Oracle Database 10g Release 2, you have the capability to export only a subset of data from a table. The SAMPLE parameter lets you specify a percentage value ranging from .000001 to 100. This parameter has the following syntax:
SAMPLE=[[schema_name.]table_name:]sample_percent
Here's an example:
SAMPLE="HR"."EMPLOYEES":50
You specify the sample size by providing a value for the SAMPLE_PERCENT clause. The schema name and table name are optional. If you don't provide the schema name, the current schema is assumed. You must provide a table name if you do provide a schema name. Otherwise, the sample percent value will be used for all the tables in the export job. In the following example, the sample size is 70 percent for all tables in the export job because it doesn't specify a table name:
$ expdp hr/hr DIRECTORY=dpump_dir1 DUMPFILE=sample.dmp SAMPLE=70
TRANSPORTABLE
The TRANSPORTABLE parameter enables you to specify whether you want the database to export the metadata for specific tables (and partitions and subpartitions) when doing a table mode export. You can specify either ALWAYS or NEVER as values for the TRANSPORTABLE parameter. Here's an example:
$ expdp sh DIRECTORY=dpump_dir1 DUMPFILE=hr.dmp TABLES=employees TRANSPORTABLE=always
There's no default value of this parameter.
Enforcing Encryption of the Export Data
You can use one or more of the following encryption-related parameters to specify whether data must be encrypted before it's written to a dump set: ENCRYPTION, ENCRYPTION_ALGORITHM, ENCRYPTION_MODE, and ENCRYPTION_PASSWORD. Let's take a closer look at each of these parameters.
ENCRYPTION
Use the ENCRYPTION parameter to specify whether or not to encrypt data before it's written to a dump file. You can assign the following values to the ENCRYPTION parameter:
-
ALL: Encrypts all data and metadata
-
DATA_ONLY: Encrypts only data written to the dump file set
-
ENCRYPTED_COLUMNS_ONLY: Specifies encryption for only encrypted columns using the TDE feature
-
METADATA_ONLY: Specifies the encryption of just the metadata
-
NONE: Specifies that no data will be encrypted
| Note |
You can enforce encryption by specifying either the ENCRYPTION or the ENCRYPTION_PASSWORD parameter or both. If you specify the ENCRYPTION_PASSWORD parameter only, the ENCRYPTION parameter will default to the value of ALL. |
If you don't specify the ENCRYPTION or the ENCRYPTION_PASSWORD parameter, the ENCRYPTION parameter defaults to NULL. If you omit the ENCRYPTION parameter but specify the ENCRYPTION_PASSWORD parameter, the ENCRYPTION parameter defaults to ALL.
The following example shows how to specify just the data and nothing else:
$ expdp hr DIRECTORY=dpump_dir1 DUMPFILE=hr.dmp JOB_NAME=test1 ENCRYPTION=data_only ENCRYPTION_PASSWORD=foobar
ENCRYPTION_ALGORITHM
The ENCRYPTION_ALGORITHM parameter specifies the encryption algorithm to use in the encryption of data. The default value is AES128, and you can also specify AE192 and AES256. The following example shows how to specify this parameter:
$ expdp hr DIRECTORY=dpump_dir1 DUMPFILE=hr.dmp ENCRYPTION_PASSWORD=foobar ENCRYPTION_ALGORITHM=AES128
ENCRYPTION_MODE
The ENCRYPTION_MODE parameter specifies the type of security to be performed by the database when you choose to encrypt data during an export. The parameter can take three values: DUAL, PASSWORD, and TRANSPARENT. The default value for this parameter depends on whether you specify the other encryption-related parameters, as shown here:
-
If you specify only the ENCRYPTION parameter, the default mode is TRANSPARENT.
-
If you specify the ENCRYPTION_PASSWORD parameter and the Oracle Encryption Wallet is open, the default is DUAL.
-
If you specify the ENCRYPTION_PASSWORD parameter and the Oracle Encryption Wallet is closed, the default is PASSWORD.
DUAL mode enables you to create a dump set that you can import later using either the Oracle Encryption Wallet or the password you specified with the ENCRYPTION_PASSWORD parameter. You can use DUAL mode when you want to import the data into a site that doesn't use the Oracle Encryption Wallet.
PASSWORD mode enables you to secure a dump file set when you transmit it to a remote database, but requires you to provide a password using the ENCRYPTION_PASSWORD parameter during the export. The database will require you to provide the same password during the import of the dump file set.
TRANSPARENT mode enables you to create a dump file set without using the ENCRYPTION_PASSWORD parameter. You use this parameter when you're importing the same database from which you exported the dump file set.
Here's an example that shows how to specify the dual value for the ENCRYPTION_MODE parameter.
$ expdp hr DIRECTORY=dpump_dir1 DUMPFILE=hr.dmp ENCRYPTION=all ENCRYPTION_PASSWORD=encrypt_pwd ENCRYPTION_ALGORITHM=AES256 ENCRYPTION_MODE=dual
ENCRYPTION_PASSWORD
You can use the ENCRYPTION_PASSWORD parameter to encrypt table data or metadata in the export dump file to prevent unauthorized users from reading data from the dump set. Note that if you specify ENCRYPTION_PASSWORD and omit the ENCRYPTION parameter, the database encrypts all data written to the export dump set.
| Note |
If you export a table with encrypted columns but don't specify the ENCRYPTION_PASSWORD parameter, the database stores the encrypted table column or columns as clear text in the export dump file when you do this. The database issues a warning when this happens. |
You can supply any password you want when you export a table, even if the table has encrypted columns. The password you supply doesn't have to be the same as the password you use when encrypting a table column. If you set the ENCRYPTION_MODE parameter to PASSWORD or DUAL, the database requires that you also specify the ENCRYPTION_PASSWORD parameter.
The following example shows how to pass a value of testpass for the ENCRYPTION_PASSWORD parameter:
$ expdp hr TABLES=employee_s_encrypt DIRECTORY=dpump_dir
DUMPFILE=hr.dmp ENCRYPTION=ENCRYPTED_COLUMNS_ONLY
ENCRYPTION_PASSWORD=testpass
The dump file for the export will encrypt the encrypted columns in the employees table.
Estimation Parameters
Two interesting parameters enable you to estimate how much physical space your export job will consume: ESTIMATE and ESTIMATE_ONLY.
ESTIMATE
The ESTIMATE parameter will tell you how much space your new export job is going to consume. The space estimate is always in terms of bytes. You can specify that the database provide you the space estimates using either the number of database blocks (BLOCKS option) in the objects that are going to be exported or the optimizer statistics (STATISTICS option) for the tables. The following is the syntax of the ESTIMATE parameter specification:
By default, Oracle estimates the export job space requirements in terms of blocks. It simply takes your database block size and multiplies it by the number of blocks all the objects together will need. Here is an example of what you'll see in your log file (and on the screen):
Estimate in progress using BLOCKS method . . . Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA Total estimation using BLOCKS method: 654 KB
Since the space estimation in terms of blocks is the default behavior, you don't need to specify the ESTIMATE parameter during the export. However, if you have analyzed all your tables recently, you can ask the Data Pump Export utility to estimate the space requirements by using the statistics the database has already calculated for each of the tables. In order to tell the database to use the database statistics (rather than use the default BLOCKS method), you need to specify the ESTIMATE parameter in the following manner:
ESTIMATE=STATISTICS
Here's what you'll see in your log file when you use the ESTIMATE=STATISTICS parameter:
Estimate in progress using STATISTICS method . . . Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA . estimated "SYSTEM"."HELP" 35.32 KB Total estimation using STATISTICS method: 65.72 KB
ESTIMATE_ONLY
While the ESTIMATE parameter is operative only during an actual export job, you can use the ESTIMATE_ONLY parameter without starting an export job. Listing 14-4 shows one such example.
$ expdp system/sammyy1 estimate_only=y Export: Release 11.1.0.6.0 - Production on Saturday, 22 March, 2008 11:19:4 Copyright (c) 2003, 2007, Oracle. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - P tion With the Partitioning, OLAP, Data Mining and Real Application Testing optio FLASHBACK automatically enabled to preserve database integrity. Starting "SYSTEM"."SYS_EXPORT_SCHEMA_01": system/******** estimate_only=y Estimate in progress using BLOCKS method . . . Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA . estimated "SYSTEM"."REPCAT$_AUDIT_ATTRIBUTE" 64 KB . . . . estimated "SYSTEM"."SQLPLUS_PRODUCT_PROFILE" 0 KB Total estimation using BLOCKS method: 320 KB Job "SYSTEM"."SYS_EXPORT_SCHEMA_01" successfully completed at 11:20:16 C:\>
Although the log indicates that the export job "successfully completed," all the previous job really did was to estimate the space that you will need for the actual export job.
The Network Link Parameter
The Data Pump Export utility provides a way to initiate a network export. Using the NETWORK_LINK parameter, you can initiate an export job from your server and have Data Pump export data from a remote database to dump files located on the instance from which you initiate the Data Pump Export job.
Here's an example that shows you how to perform a network export:
$ expdp hr/hr DIRECTORY=dpump_dir1 NETWORK_LINK=finance DUMPFILE=network_export.dmp LOGFILE=network_export.log
In the example, the NETWORK_LINK parameter must have a valid database link as its value. This means that you must have created the database link ahead of time. This example is exporting data from the finance database on the prod1 server.
Let's say you have two databases, called local and remote. In order to use the NETWORK_LINK parameter and pass data directly over the network, follow these steps:
-
Create a database link to the remote database, which is named remote in this example:
SQL> CREATE DATABASE LINK remote 2 CONNECT TO scott IDENTIFIED BY tiger 3 USING 'remote.world';
-
If there isn't one already, create a Data Pump directory object:
SQL> CREATE DIRECTORY remote_dir1 AS '/u01/app/oracle/dp_dir';
-
Set the new directory as your default directory, by exporting the directory value:
$ export DATA_PUMP_DIR=remote_dir1
-
Perform the network export from the database named remote:
$ expdp system/sammyy1 SCHEMAS=SCOTT FILE_NAME=network.dmp NETWORK_LINK=finance
You'll see that the Data Pump Export job will create the dump file network.dmp (in the directory location specified by remote_dir1) on the server hosting the database named local. However, the data within the dump file is extracted from the user scott's schema in the remote database (named remote in our example). You can see that the NETWORK_LINK parameter carries the dump files over the network from a remote location to the local server. All you need is a database link from a database on the local server to the source database on the remote server.
| Caution |
You can't use Data Pump in the normal way to export data from a read-only database. This is because Data Pump can't create the necessary master table or create external tables on a read-only tablespace. Using the network mode, however, you can export data from a read-only database on server A to dump files on server B, where Data Pump is running. |
The Encryption Parameter
If your export data dump file includes encrypted column data columns, you can use the new ENCRYPTION_PASSWORD parameter to supply a password, to prevent the writing of the encrypted column data as clear text in the dump file set. When you import a dump file that was created using an encryption password this way, you'll need to supply the password. Here's an example of using the ENCRYPTION_PASSWORD parameter:
Job-Related Parameters
Several of the Data Pump Export parameters can be classified as job-related parameters. I'll briefly discuss the important ones here.
JOB_NAME
The JOB_NAME parameter is purely optional. You can use this parameter to give an explicit name to the export job, instead of letting Oracle assign a default name. Remember that Oracle gives the master table, which holds critical information about your export job, the same name as the name of the job.
STATUS
The STATUS parameter is useful while you're running long jobs, as it provides you with an updated status at intervals that you can specify. The parameter takes integer values that stand for seconds. The default is 0 and will show new status when it's available. If you want to reassure yourself with minute-by-minute updates concerning a Data Pump job you're currently running, use the STATUS parameter, as shown in Listing 14-5.
$ expdp system/manager STATUS=60 . . .
. . .
Worker 1 Status:
State: EXECUTING
..Object Schema: SYSTEM
..Object Name: SYS_EXPORT_SCHEMA_01
Object Type: SCHEMA_EXPORT/TABLE/TABLE_DATA
Completed Objects: 1
Total Objects: 65
. . exported "SYSTEM"."REPCAT$_SITES_NEW"
Job: SYS_EXPORT_SCHEMA_01
Operation: EXPORT
Mode: SCHEMA
State: EXECUTING
Bytes Processed: 69,312
Percent Done: 99
Current Parallelism: 1
Job Error Count: 0
Dump File: C:\ORACLE\PRODUCT\11.1.0\ADMIN\EXPORT\EXPDAT6.DMP
bytes written: 1,748,992
. . .
The STATUS parameter shows the overall percentage of the job that is completed, the status of the worker processes, and the status of the current data objects being processed. Note that the Data Pump log file will show the completion status of the job, whereas the STATUS parameter gives you the status of an ongoing Data Pump job.
FLASHBACK_SCN
The FLASHBACK_SCN parameter specifies the system change number (SCN) that Data Pump Export will use to enable the Flashback utility. If you specify this parameter, the export will be consistent as of this SCN.
The following example shows how you can export the user HR's schema up to the SCN 150222:
FLASHBACK_TIME
The FLASHBACK_TIME parameter is similar to the FLASHBACK_SCN parameter. The only difference is that here you use a time, instead of an SCN, to limit the export. Oracle finds the SCN that most closely matches the time you specify, and uses this SCN to enable the Flashback utility. The Data Pump Export operation will be consistent as of this SCN. Here's an example:
$ expdp system/sammyy1 DIRECTORY=dpump_dir1 DUMPFILE=hr_time.dmp
FLASHBACK_TIME="TO_TIMESTAMP('25-05-2008 17:22:00', 'DD-MM-YYYY HH24:MI:SS')"
| Note |
FLASHBACK_SCN and FLASHBACK_TIME are mutually exclusive. |
PARALLEL
PARALLEL is the mighty parameter that lets you specify more than a single active execution thread (worker process) for your export job. Using the PARALLEL parameter means that your jobs will use multiple threads for their execution. You can change the degree of parallelism on the fly by using the ATTACH command. Note that the Data Pump PARALLEL parameter has nothing to do with the Oracle parallel execution features, but they can work together.
The default value of the PARALLEL parameter is 1, meaning a single-thread export operation writing to a single dump file. If you specify anything more than 1 as the value for the PARALLEL parameter, you also should remember to specify the same number of dump files, so the multiple execution threads can simultaneously write to the multiple dump files. Here's an example that shows how you can set the level of parallelism to 3, forcing the export job to write in parallel to three dump files:
$ expdp system/manager DIRECTORY=dpump_dir1 DUMPFILE=par_exp%U.dmp PARALLEL=3
In this example, the DUMPFILE parameter uses the substitution variable %U to indicate that multiple files should be generated, of the format par_expNN.dmp, where NN is a two-character integer starting with 01. Since the PARALLEL parameter is set to 3, the substitution variable will create three files with the following names: par_exp01.dmp, par_exp02.dmp, and par_exp03.dmp.
Note that you don't need to use the %U substitution variable to generate multiple dump files when you choose a value greater than 1 for the PARALLEL parameter. You could simply use a comma-separated list of values, as follows:
$ expdp system/manager DIRECTORY=dpump_dir1 DUMPFILE=(par_exp01.dmp,par_exp02.dmp,par_exp03.dmp)
Be aware that if you don't have sufficient I/O bandwidth, you may actually experience a degradation in Data Pump performance with the PARALLEL parameter.
| Caution |
If you specify the PARALLEL parameter, make sure you allocate the same number of dump files as the degree of parallelism. You must also remember that the higher the degree of parallelism, the higher the memory, CPU, and network bandwidth usage as well. |
ATTACH
The ATTACH parameter attaches your Data Pump client session to a running job and places you in an interactive mode. You can use this parameter only in conjunction with the username/password combination; you can't use any other export parameters along with it. Here's an example:
The ATTACH parameter is very important, as it's one of the two ways to open an interactive Data Pump job, as explained in the following section.
Interactive Mode Export Parameters (Commands)
As I mentioned earlier in this chapter, the interactive mode of Data Pump is quite different from the interactive export and import mode in the older utilities. Traditionally, the interactive mode gave you the chance to enter a limited set of export/import parameters at the command line in response to the queries made by the export or import utility. You use the interactive mode in the new Data Pump technology only to intervene in the middle of a running job, to either suspend the job or modify some aspects of it. You can enter the interactive mode of Data Pump Export in either of two ways:
-
Use the Ctrl+C keyboard combination during a Data Pump Export job, if you want to enter the interactive mode from the same session where you are running the Data Pump job.
-
Use a separate session or even a separate server to attach yourself to a running session by using—what else?—the ATTACH command. (You can also attach to a stopped job.) When you successfully attach yourself to a job, you'll be able to use specific export parameters in an interactive mode. I use the word parameters, but you may also refer to these as interactive export commands.
| Note |
In the Data Pump Export (and Import) utility, the only way to get into an interactive mode of operation is by using the Ctrl+C sequence or by opening another session and "attaching" yourself to that session. You cannot start an interactive Data Pump session from the command line. |
Let's examine when you might use the interactive mode in a Data Pump Export job. Suppose that you started a job in the evening at work and left for home. At midnight, you check the status of the job and find that it's barely moving. You can easily start another session, and then connect to the running job and monitor it by using the ATTACH command. When you do this, the running job does not pause. Instead, it opens an interactive window into the running session so you can change some parameters to hasten the crawling export job via a special set of interactive Data Pump Export commands. Using the ATTACH parameter, you can restart jobs that are stalled because of a lack of space in the file system, instead of having to start a new job from the beginning. This feature comes in especially handy when dealing with exports and imports of large amounts of data.
Listing 14-6 shows an example of using the ATTACH command.
[orcl] $ expdp system/sammyy1 ATTACH=system.sys_export_schema_01
Export: Release 11.1.0.6.0 - Production on Tuesday, 25 March, 2008 11:58:08
Copyright (c) 2003, 2007, Oracle. All rights reserved.
Job: SYS_EXPORT_SCHEMA_01
Owner: SYSTEM
Operation: EXPORT
Creator Privs: FALSE
GUID: F24953A52C006A63E0340060B0B2C268
Start Time: Monday, 14 March, 2005 11:03:03
Mode: SCHEMA
Instance: orcl
Max Parallelism: 1
EXPORT Job Parameters:
Parameter Name Parameter Value:
CLIENT_COMMAND system/********
State: EXECUTING
Bytes Processed: 0
Current Parallelism: 1
Job Error Count: 0
Dump File: /u01/app/oracle/product/10.2.0/db_1/admin/orcl/dpdump/expdat.dmp
bytes written: 4,096
Worker 1 Status:
State: EXECUTING
| Note |
You may attach multiple clients to a single job. |
You can attach to a running job by using the ATTACH command as just shown, or by simply using the Ctrl+C (^C) sequence on the server where the job is actually running. When you use the Ctrl+C sequence, you get the interactive export prompt (export>), indicating that Data Pump is awaiting your interactive commands. Here's an example:
Starting "SYSTEM"."SYS_EXPORT_SCHEMA_01": system/******** Estimate in progress using BLOCKS method . . . (You stop the export job by using the ^C sequence) export>
Note that when you use the ATTACH command or the Ctrl+C sequence to interactively attach to a job, you don't stop the running job itself. The commands will merely stop the display of the job messages on the screen and present you with the prompt (export>).
From the interactive prompt, you can use several options to influence the progress of the currently executing Data Pump job. You may intervene during a running export or import job, not only when you issue the ATTACH command or Ctrl+C sequence, but also when the jobs temporarily fail. For example, your export job may run out of dump file space, as shown by the following set of entries in your export log file:
Processing object type SCHEMA_EXPORT/TABLE/COMMENT Processing object type SCHEMA_EXPORT/VIEW/VIEW Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT ORA-39095: Dump file space has been exhausted: Unable to allocate 524288 bytes Job "SYSTEM"."SYS_EXPORT_SCHEMA_01" stopped due to fatal error at 18:40 . . .
One option is to end this idle export job with the following interactive command:
export> KILL_JOB
More likely, you would want the job to resume by adding more space to your directory. Here's how you can use the ADD_FILE command to add files to your export directory:
export> ADD_FILE=data_dump_dir:expdat02.dmp
Once you finish adding space to the export directory, you use the interactive command START_JOB to continue the stopped export job, as shown here:
To resume the logging of the output on your screen, you issue the CONTINUE_CLIENT command, as shown here:
export> CONTINUE_CLIENT Job SYS_EXPORT_SCHEMA_01 has been reopened at Sunday, 20 March, 2005 19:15 Restarting "SYSTEM"."SYS_EXPORT_SCHEMA_01": system/******** parfile=test_export.par . . .
In a Data Pump Import job, your space-related problems are most likely to be caused by running out of room in the tablespaces that contain the tables into which you are importing. In such a case, the import job will stop in the middle. You can add space to the relevant tablespaces, and then use the ATTACH command to attach to the held-up job, followed by the START_JOB and CONTINUE_CLIENT commands as shown in the preceding example.
| Note |
You must be a DBA, or have the EXP_FULL_DATABASE or IMP_FULL_DATABASE role, in order to attach and control Data Pump jobs of other users. |
Table 14-1 provides a summary of the interactive Data Pump Export commands.
|
Command |
Description |
|---|---|
|
ADD_FILE |
Adds a dump file to the dump file set. |
|
CONTINUE_CLIENT |
Returns to logging mode. The job will be restarted if it was idle. |
|
EXIT_CLIENT |
Quits the client session and leaves the job running. |
|
HELP |
Provides summaries of the usage of the interactive commands. |
|
KILL_JOB |
Detaches and deletes the job. |
|
PARALLEL |
Changes the number of active workers for the current job. |
|
START_JOB |
Starts or resumes the current job. |
|
STATUS |
Sets the frequency of job monitoring (in seconds). The default (0) will show the new status when available. |
|
STOP_JOB |
Performs an orderly shutdown of the job execution and exits the client. |
Open table as spreadsheet| Tip |
STOP_JOB=IMMEDIATE performs an immediate shutdown of the Data Pump job. |
I'll explain the important interactive Data Pump parameters in the following sections, grouped in the categories of client-related parameters, job-related parameters, and other parameters.
Client-Related Interactive Parameters
The CONTINUE_CLIENT parameter will take you out of interactive mode and resume the running export job. Your client connection will still be intact, and you'll continue to see the export messages on your screen. However, the EXIT_CLIENT parameter will stop the interactive session, as well as terminate the client session. In both of these cases, the actual Data Pump Export job will continue to run unhindered.
Job-Related Interactive Parameters
You can use several job-related parameters from any interactive session you open with an export session using the ATTACH command. You can use the STOP_JOB command to stop the export job in an orderly fashion. To stop it immediately, use the STOP_JOB=IMMEDIATE command. You can choose to resume any export jobs you've stopped in this manner with the START_JOB command.
If you decide that you don't really want to continue the job you've just attached to, you can terminate it by using the KILL_JOB parameter. Unlike the EXIT_CLIENT parameter, the KILL_JOB parameter terminates both the client as well as the export job itself.
To summarize, the job-related interactive parameters work as follows:
-
STOP_JOB stops running Data Pump jobs.
-
START_JOB resumes stopped jobs.
-
KILL_JOB kills both the client and the Data Pump job.
| Note |
You can restart any job that is stopped, whether it's stopped because you issued a STOP_JOB command or due to a system crash, as long as you have access to the master table and an uncorrupted dump file set. |
Other Interactive Parameters
From the interactive prompt, you can use the ADD_FILE parameter to add a dump file to your job, if you find that the dump file is filling rapidly and may not have any more free space left. You can also use the HELP and STATUS parameters interactively, and both of these parameters function the same way as their command-line counterparts.
Data Pump Export Examples
Let's look at a few simple Data Pump Export job specifications that demonstrate some of the concepts you've learned in this chapter. The first example creates an export dump file of just two tables: employees and jobs.
$ expdp hr/hr TABLES=employees,jobs DUMPFILE=dpump_dir1:table.dmp NOLOGFILE=Y
The following example shows how to use a parameter file, as well as how to use the CONTENT and EXCLUDE parameters. The CONTENT=DATA_ONLY specification means you are exporting just rows of data and excluding all object definitions (metadata). The EXCLUDE parameter requires that the countries, locations, and regions tables be omitted from the export. The QUERY parameter stipulates that all the data in the employees table, except that belonging to department_id 20, be exported. The parameter file, exp.par, has the following information:
DIRECTORY=dpump_dir1
DUMPFILE=dataonly.dmp
CONTENT=DATA_ONLY
EXCLUDE=TABLE:"IN ('COUNTRIES', 'LOCATIONS', 'REGIONS')"
QUERY=employees:"WHERE department_id !=20 ORDER BY employee_id"
You can then issue the following command to execute the exp.par parameter file:
The following example illustrates a schema mode export. You don't see any mention of the SCHEMA parameter, because Data Pump will export a schema (of the exporting user) by default.
$ expdp hr/hr DUMPFILE=dpump_dir1:expschema.dmp LOGFILE=dpump_dir1:expschema.log
| Note |
By default, the Data Pump Export utility will run the export in schema mode. |
The following example shows how you can export specific tables from a specific schema:
$ expdp hr/hr TABLES=employees,jobs DUMPFILE=dpump_dir1:hrtable.dmp NOLOGFILE=Y
Here's an interesting Data Pump Export example, showing how to use the PARALLEL, FILESIZE, and JOB_NAME parameters. It also illustrates the use of the DUMPFILE parameter when there are multiple dump files.
$ expdp hr/hr FULL=Y DUMPFILE=dpump_dir1:full1%U.dmp, dpump_dir2:full2%U.dmp FILESIZE=2G PARALLEL=3 LOGFILE=dpump_dir1:expfull.log JOB_NAME=expfull
Now that you've seen how the Data Pump Export utility works, you're ready to look at the Data Pump Import utility features.
Data Pump Import Types and Modes
As in the case of a Data Pump Export job, you can perform a Data Pump Import job from the command line or use a parameter file. Interactive access to the Import utility is available, but it is different from what you are used to when working with the traditional import utilities. The interactive framework is analogous to the interactive access to the Data Pump Export utility, as you'll see shortly.
You can use Data Pump Import in the same modes as Data Pump Export: table, schema, tablespace, and full modes. In addition, you can employ the TRANSPORTABLE_TABLESPACES parameter to import the metadata necessary for implementing the transportable tablespaces feature.
You must have the IMPORT_FULL_DATABASE role in order to perform one of the following:
-
Full database import
-
Import of a schema other than your own
-
Import of a table that you don't own
| Note |
You'll need the IMPORT_FULL_DATABASE role to perform an import if the dump file for the import was created using the EXPORT_FULL_DATABASE role. |
Data Pump Import Parameters
As in the case of the Data Pump Export utility, you control a Data Pump Import job with the help of several parameters when you invoke the impdp utility. For this discussion, I've grouped the parameters into the following categories:
-
File- and directory-related parameters
-
Filtering parameters
-
Job-related parameters
-
Import mode-related parameters
-
Remapping parameters
-
The TRANSFORM parameter
-
The NETWORK_LINK parameter
-
The Flashback parameters
File- and Directory-Related Parameters
The Data Pump Import utility uses the PARFILE, DIRECTORY, DUMPFILE, LOGFILE, and NOLOGFILE commands in the same way as the Data Pump Export utility does. However, SQLFILE is a file-related parameter unique to the Import utility.
The SQLFILE parameter is similar to the old import utility's INDEXFILE parameter. When you perform a Data Pump Import job, you may sometimes wish to extract the DDL from the export dump file. The SQLFILE parameter enables you to do this easily, as shown in the following example:
$ impdp system/sammyy1 DIRECTORY=dpump_dir1 DUMPFILE=scott.dmp SQLFILE=dpump_dir2:finance.sql SCHEMAS=scott
In this example, the SQLFILE parameter instructs the Data Pump Import job to write all the DDL pertaining to the scott schema to the scott.dmp file, located in the directory dpump_dir2. Of course, you must have created dpump_dir2 prior to issuing this command, using the CREATE DIRECTORY AS command. The DIRECTORY=dpump_dir1 parameter value tells the Data Pump Import utility where to find the dump file scott.dmp, from which the Data Pump Import job will extract the DDL for user scott's schema. This example also shows how you can use multiple directories in a single Data Pump job.
Listing 14-7 shows the output from running the previously specified Data Pump Import job.
[oracle@localhost ] $ impdp system/sammyy1 DIRECTORY=dpump_dir1
DUMPFILE=scott.dmp SQLFILE=dpump_dir2:finance.sql SCHEMAS=scott
Import: Release 11.1.0.6.0 - Production on Tuesday, 25 March, 2008 12:23:07
Copyright (c) 2003, 2007, Oracle. All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 -
Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Master table "SYSTEM"."SYS_SQL_FILE_SCHEMA_01" successfully loaded/unloaded
Starting "SCOTT"."SYS_SQL_FILE_SCHEMA_01": system/******** dumpfile=scott.dmp
sqlfile=scott.sql schemas=scott
Processing object type SCHEMA_EXPORT/USER
Processing object type SCHEMA_EXPORT/SYSTEM_GRANT
Processing object type SCHEMA_EXPORT/ROLE_GRANT
Processing object type SCHEMA_EXPORT/DEFAULT_ROLE
Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Processing object type SCHEMA_EXPORT/TABLE/TABLE
Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX
Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Processing object type SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
Processing object type SCHEMA_EXPORT/CONSTRAINT/REF_CONSTRAINT
Processing object type SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
Job "SYSTEM"."SYS_SQL_FILE_SCHEMA_01" successfully completed at 18:42:20
[oracle@localhost] $
It's important to remember that the SQLFILE parameter just extracts the SQL DDL to the specified file—no actual data import takes place. By using this parameter, you can extract a SQL script with all the DDL from your export dump file. The DDL in SQLFILE lets you peek at what the import job will execute.
If you edit the finance.sql file, you'll see uncommented, ready-to-use SQL DDL statements to re-create user scott's schema. Listing 14-8 shows the first few lines of the script obtained by using the SQLFILE parameter.
-- CONNECT SYSTEM
-- new object type path is: SCHEMA_EXPORT/USER
CREATE USER "SCOTT" IDENTIFIED BY VALUES 'F894844C34402B67'
DEFAULT TABLESPACE "USERS"
TEMPORARY TABLESPACE "TEMP"
PASSWORD EXPIRE
ACCOUNT UNLOCK;
-- new object type path is: SCHEMA_EXPORT/SYSTEM_GRANT
GRANT UNLIMITED TABLESPACE TO "SCOTT";
-- new object type path is: SCHEMA_EXPORT/ROLE_GRANT
GRANT "CONNECT" TO "SCOTT";
GRANT "RESOURCE" TO "SCOTT";
-- new object type path is: SCHEMA_EXPORT/DEFAULT_ROLE
ALTER USER "SCOTT" DEFAULT ROLE ALL;
-- new object type path is: DATABASE_EXPORT/SCHEMA/PROCACT_SCHEMA
-- CONNECT SCOTT
BEGIN
sys.dbms_logrep_imp.instantiate_schema(schema_name=>'SCOTT',
export_db_name=>'SALES', inst_scn=>'643491');
COMMIT;
END;
/
new object type path is: SCHEMA_EXPORT/TABLE/TABLE
--CONNECT SYSTEM
CREATE TABLE "SCOTT"."DEPT"
( "DEPTNO" NUMBER(2,0),
"DNAME" VARCHAR2(14),
"LOC" VARCHAR2(13)
) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "USERS" ;
. . .
Note that you'll get the SQL to re-create not only tables and indexes, but all objects, including any functions and procedures in user scott's schema.
The other important file-related Data Pump Import parameter is the new REUSE_DATAFILES parameter. This parameter tells Data Pump whether it should use existing datafiles for creating tablespaces during an import. If you specify REUSE_DATAFILES=Y, the Data Pump Import utility will write over your existing datafiles.
Filtering Parameters
You use the CONTENT parameter, as in the case of a Data Pump export, to determine whether you'll load just rows (CONTENT=DATA_ONLY), rows and metadata (CONTENT=ALL), or just metadata (CONTENT=METADATA_ONLY).
The EXCLUDE and INCLUDE parameters have the same meaning as in an export, and they are mutually exclusive:
-
Use the INCLUDE parameter to list the objects that you wish to import.
-
Use the EXCLUDE parameter to list the objects you don't want to import.
Here's a simple example of using the INCLUDE parameter. The specification restricts the import to only table objects. Only the persons table will be imported.
INCLUDE=TABLE:"= 'persons'"
You can use the clause INCLUDE=TABLE:"LIKE 'PER%'" to export only those tables whose name start with PER. You can also use the INCLUDE parameter in a negative fashion, by specifying that all objects with a certain syntax be ignored, as shown here:
INCLUDE=TABLE:"NOT LIKE 'PER%'"
Note that if you use the CONTENT=DATA_ONLY option, you cannot use either the EXCLUDE or INCLUDE parameter during an import.
You can use the QUERY parameter as well to filter data during an import. (In the older export and import utilities, you could use the QUERY parameter only during an export.) You can use the QUERY parameter to specify an entire schema or a single table. Note that if you use the QUERY parameter during import, Data Pump will use only the external tables data method, rather than the direct-path method, to access the data.
You can use the TABLE_EXISTS_ACTION parameter to tell Data Pump import what to do when a table already exists. You can provide four different values to the TABLE_EXISTS_ACTION parameter:
-
With SKIP (the default), Data Pump will skip a table if it exists.
-
The APPEND value appends rows to the table.
-
The TRUNCATE value truncates the table and reloads the data from the export dump file.
-
The REPLACE value drops the table if it exists, re-creates it, and reloads it.
Job-Related Parameters
The JOB_NAME, STATUS, and PARALLEL parameters carry identical meanings as their Data Pump Export counterparts. Note that if you have multiple dump files, you should specify them either explicitly or by using the %U notation, as shown earlier in the coverage of Data Pump Export parameters.
Import Mode-Related Parameters
You can perform a Data Pump import in various modes, using the TABLE, SCHEMAS, TABLESPACES, and FULL parameters, just as with the Data Pump Export utility. You can use the TRANSPORTABLE_TABLESPACES parameter when you wish to transport tablespaces between databases.
You use the TRANSPORT_FULL_CHECK parameter in a manner analogous to its use under Data Pump Export, when you're performing a transportable tablespaces operation. The TRANSPORT_FULL_CHECK parameter is applicable to a tablespace transport only if you're using the NETWORK_LINK parameter.
The TRANSPORT_DATAFILES import parameter is used during a transportable tablespaces operation, to specify the list of datafiles the job should import into the target database. You must first copy these files from the source system to the target server. Here's a simple example that illustrates how to use the transport tablespaces-related import parameters:
$ impdp salapati/sammyy1 DIRECTORY=dpump_dir1 \ > NETWORK_LINK=source_database_link \ > TRANSPORT_TABLESPACES=users TRANSPORT_FULL_CHECK=Y \ > TRANSPORT_DATAFILES='/wkdir/data/tbs6.f'
Remapping Parameters
The remapping parameters clearly mark the superiority of this utility over the older import utility by expanding Oracle's ability to remap objects during the data import process. The remapping parameters are REMAP_TABLES, REMAP_SCHEMA, REMAP_DATAFILE, and REMAP_TABLESPACE. While you did have the ability to remap schemas in the old export and import utilities (by using the FROMUSER/TOUSER specification), you couldn't remap datafiles and tablespaces. I explain the remapping parameters briefly in the following sections.
REMAP_TABLE
The REMAP_TABLE parameter enables you to rename a table during an import operation that uses the transportable method. In addition to renaming regular tables, you can also specify the REMAP_TABLE parameter to provide your own name for the individual partitions of a portioned table that you have exported using the transportable method. This way, you can prevent Oracle from giving default names to the partitions and subpartitions imported by the Data Pump Import utility. Following is an example that shows how to specify the REMAP_TABLE parameter to rename a table:
$ impdp hr/HR DIRECTORY=dpump_dir1 DUMPFILE=newdump.dmp - TABLES=hr.employees REMAP_TABLE=hr.employees:emp
The REMAP_TABLE parameter changes the hr.employees table to the hr.emp table during the import operation.
REMAP_SCHEMA
Using the REMAP_SCHEMA parameter, you can move objects from one schema to another. You need to specify this parameter in the following manner:
$ impdp system/manager DUMPFILE=newdump.dmp REMAP_SCHEMA=hr:oe
In this example, HR is the source schema, and Data Pump Import will import all of user HR's objects into the target schema OE. The Import utility can even create the OE schema if it doesn't already exist in the target database. Of course, if you want to just import one or more tables from the HR schema and then into the OE schema, you can do that as well, by using the TABLES parameter.
REMAP_DATAFILE
When you are moving databases between two different platforms, each with a separate file-naming convention, the REMAP_DATAFILE parameter comes in handy to change file system names. The following is an example that shows how you can change the file system from the old Windows platform to the new UNIX platform. Whenever there is any reference to the Windows file system in the export dump file, the Import utility will automatically remap the filename to the UNIX file system.
REMAP_TABLESPACE
Sometimes, you may want the tablespace into which you are importing data to be different from the tablespace in the source database. The REMAP_TABLESPACE parameter enables you to move objects from one tablespace into a different tablespace during an import, as shown in the following example. Here, Data Pump Import is transferring all objects from the tablespace example_tbs to the tablespace new_tbs.
$ impdp hr/hr REMAP_TABLESPACE='example_tbs':'new_tbs' DIRECTORY=dpump_dir1 \ PARALLEL=2 JOB_NAME=TESTJOB_01 DUMPFILE=employees.dmp NOLOGFILE=Y
REMAP_DATA
You can specify the REMAP_DATA parameter to remap data while importing it into tables. You may want to use it, for example, when you're regenerating primary keys to avoid conflict with existing data. You must create the remap function that determines the remapped values of the columns you want to change.
Here's an example that shows how to specify the REMAP_DATA parameter during import:
$ impdp hr DIRECTORY=dpump_dir1 DUMPFILE=expschema.dmp TABLES=hr.employees REMAP_DATA=hr.employees.first_name:hr.remap.plusx
The PLUSX function from the REMAP package remaps the FIRST_NAME column in this example.
TRANSPORTABLE
The TRANSPORTABLE parameter lets you tell the database whether it should use the transportable option during a table-mode import. The two possible values are ALWAYS and NEVER, the latter being the default value.
Note that you can use the TRANSPORTABLE parameter only if you also specify the NETWORK_LINK parameter. Here's an example:
$ impdp system TABLES=hr.sales TRANSPORTABLE=always
DIRECTORY=dpump_dir1 NETWORK_LINK=dbs1
PARTITION_OPTIONS=departition
TRANSPORT_DATAFILES=datafile_name
If you don't specify the TRANSPORTABLE parameter, by default, the import job uses the direct path or external table method during the import.
DATA_OPTIONS
The DATA_OPTIONS parameter is the counterpart to the DATA_OPTIONS parameter during export operations. You can specify only the SKIP_CONSTRAINT_ERRORS value for this parameter during an import (DATA_OPTIONS=SKIP_CONSTRAINT_ERRORS). The SKIP_CONSTRAINT_ERRORS option lets the import operation continue even if the database encounters any nondeferred constraint violations.
The TRANSFORM Parameter
Suppose you are importing a table from a different schema or even a different database. Let's say you want to make sure that you don't also import the objects' storage attributes during the import—you just want to bring in the data that the table contains. The TRANSFORM parameter lets you specify that your Data Pump Import job should not import certain storage and other attributes. Using the TRANSFORM parameter, you can exclude the STORAGE and TABLESPACE clauses, or just the STORAGE clause, from a table or an index.
During a Data Pump (or traditional) import, Oracle creates objects using the DDL that it finds in the export dump files. The TRANSFORM parameter instructs Data Pump Import to modify the DDL that creates the objects during the import job.
The TRANSFORM parameter has the following syntax:
TRANSFORM = transform_name:value[:object_type]
where the syntax elements represent the following:
-
Transform name: You can modify four basic types of an object's characteristics using four possible options for the TRANSFORM_NAME component. Here are the options and what they stand for:
-
SEGMENT ATTRIBUTES: Segment attributes include physical attributes, storage attributes, tablespaces, and logging. You can instruct the import job to include the previous attributes by specifying SEGMENT_ATTRIBUTES=Y (the default for this parameter) as the transform name. When you do this, the import job will include all four of the segment attributes, along with their DDL.
-
STORAGE: You can use the STORAGE=Y (default) specification to get just the storage attributes of the objects that are part of the import job.
-
OID: If you specify OID=Y (the default value), a new OID is assigned to object tables during the import.
-
PCTSPACE: By supplying a positive number as the value for this transform, you can increase the extent allocation size of objects and the datafile size by a percentage equal to the value of PCTSPACE.
-
-
Value: The value of the TRANSFORM parameter can be Y (yes) or N (no). You've already seen that the default value for the first three transform names is Y. This means that, by default, Data Pump imports an object's segment attributes and storage features. Alternatively, you can set the value for these parameters to N. If you assign a value of N, you specify not to import the original segment attributes and/or the storage attributes. The PCTSPACE transform name takes a number as its value.
-
Object type: The object type specifies which types of objects should be transformed. You can choose from tables, indexes, tablespaces, types, clusters, constraints, and so on, depending on the type of transform you're employing for the TRANSFORM parameter. If you don't specify an object type when using the SEGMENT_ATTRIBUTES and STORAGE transforms, the transforms are applied to all tables and indexes that are part of the import.
Here's an example of using the TRANSFORM parameter:
$ impdp hr/hr TABLES=hr.employees \ DIRECTORY=dpump_dir1 DUMPFILE=hr_emp.dmp \ TRANSFORM=SEGMENT_ATTRIBUTES:N:table
In this example, the SEGMENT_ATTRIBUTES transform is applied with the value of N. The object type is table. This specification of the TRANSFORM parameter means that the import job will not import the existing storage attributes for any table.
The NETWORK_LINK Parameter
Using the NETWORK_LINK parameter, you can perform an import across the network without using dump files. The NETWORK_LINK parameter enables the Data Pump Import utility to connect directly to the source database and transfer data to the target database. Here's an example:
$ impdp hr/hr TABLES=employees DIRECTORY=dpump_dir1 SCHEMAS=SCOTT \ EXCLUDE=CONSTRAINT NETWORK_LINK=finance
In this example, finance is the network link. It is a valid database link, created by you beforehand using the CREATE DATABASE LINK command. Thus, the database shown in the database link is your source for the import job. Data Pump will import the table employees from the remote database finance to your instance where you run the Data Pump Import job. In a network import, the Metadata API executes on the remote instance, extracts object definitions, and re-creates necessary objects in your local instance. It then fetches data from the remote database tables and loads them in your local instance, using the INSERT INTO . . . SELECT SQL statement, as follows:
SQL> INSERT INTO employees(emp_name,emp_id) . . . SELECT (emp_name,emp_id) FROM
finance
Note that a Data Pump network import doesn't involve a dump file, as Data Pump will import the table from the source to the target database directly.
Here's an example showing how to use the NETWORK_LINK parameter to perform a direct import from a remote database into a local database:
-
Create a database link in the remote database:
SQL> CREATE DATABASE LINK remote CONNECT TO system IDENTIFIED BY sammyy1 USING 'remote.world'; -
If there isn't one already, create a Data Pump directory object:
SQL> CREATE DIRECTORY remote_dir1 AS '/u01/app/oracle/dp_dir';
-
Set the new directory as your default directory, by exporting the directory value:
$ export DATA_PUMP_DIR=remote_dir1
-
Perform the network import from the database named remote, using the following Data Pump Import command:
[local] $ impdp system/sammyy1 SCHEMAS=scott NETWORK_LINK=remote
Listing 14-9 shows the output of the Data Pump job specification in this example, using the NETWORK_LINK parameter.
Import: Release 11.1.0.6.0 - Production on Tuesday, 25 March, 2008 12:00:32
Copyright (c) 2003, 2007, Oracle. All rights reserved.
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.0.0 - Beta
With the Partitioning, OLAP and Data Mining options
FLASHBACK automatically enabled to preserve database integrity.
Starting "SYSTEM"."SYS_IMPORT_SCHEMA_01": system/******** schemas=SCOTT
NETWORK_LINK=remote
Estimate in progress using BLOCKS method . . .
Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 32 KB
Processing object type SCHEMA_EXPORT/USER
Processing object type SCHEMA_EXPORT/SYSTEM_GRANT
Processing object type SCHEMA_EXPORT/ROLE_GRANT
Processing object type SCHEMA_EXPORT/DEFAULT_ROLE
Processing object type SCHEMA_EXPORT/TABLESPACE_QUOTA
Processing object type SCHEMA_EXPORT/TABLE/TABLE
. . imported "SCOTT"."TEST" 96 rows
Job "SYSTEM"."SYS_IMPORT_SCHEMA_01" successfully completed at 06:59
[local] $
The Flashback Parameters
The FLASHBACK_TIME parameter enables you to import data consistent as of the flashback time you specify in your import job. Oracle finds the SCN closest to the time you specify, and enables the Flashback utility using this SCN. For example, look at the following import statement:
$ impdp system/manager FLASHBACK_TIME="TO_TIMESTAMP('01-06-2005 07:00:00;',
'DD-MM-YYYY HH24:MI:SS')"
Note that the FLASHBACK_TIME parameter does the same thing as the old CONSISTENT parameter in the traditional import utility.
The FLASHBACK_SCN parameter is similar to the FLASHBACK_TIME parameter, except that you directly specify the SCN.
Whether you use the FLASHBACK_TIME or the FLASHBACK_SCN parameter, it is the SCN that plays the key role in determining the flashback time with which your imported data will be consistent.
Interactive Import Parameters
All the interactive export parameters shown in Table 14-1 are valid for interactive import as well, with one exception: the ADD_FILE command is valid only for Data Pump Export jobs. As with Data Pump Export jobs, when you use the Ctrl+C sequence, the import job will pause, and you'll see the import> prompt, enabling you to enter any of the interactive import commands from there.