This chapter describes how you can export and import
XMLType tables for use with Oracle XML DB using Oracle Data Pump.
Note:The original Export and Import utilities are still supported in Oracle Database 11g Release 1 (11.1) for migrating data from release 11.1 to versions prior to it.
This chapter discusses the following topics:
Oracle Data Pump technology enables high-speed movement of data and metadata from one database to another. Oracle Data Pump has two command-line clients,
impdp, that invoke Data Pump Export utility and Data Pump Import utility, respectively. The
impdp clients use procedures provided in PL/SQL package
DBMS_DATAPUMP to execute export and import commands, passing the parameters entered at the command-line. These parameters enable the exporting and importing of data and metadata for a complete database or subsets of a database.
The new Data Pump Export and Import utilities (invoked with commands
impdp, respectively) have a similar look and feel to the original Export (
exp) and Import (
imp) utilities, but they are completely separate.
See Also:"Original Export and Import" in Oracle Database Utilities, for information about situations in which you should still use the original Export and Import utilities.
Data Pump Export utility (invoked with
expdp) unloads data and metadata into a set of operating system files called a dump file set. The dump file set can be imported only by the Data Pump Import utility (invoked with
Oracle XML DB supports export and import of
XMLType tables and columns that store XML data.
You can export and import this data regardless of the
XMLType storage format (structured, unstructured, or binary XML). However, Data Pump exports and imports XML data as text or binary XML data only. The underlying object-relational tables and columns used for structured storage of
XMLType are thus not exported. Instead, they are converted to binary form and then exported as self-describing binary XML data.
XMLType data stored as
CLOB instances (unstructured storage) is exported as text.
Note:Oracle Data Pump for Oracle Database 11g Release 1 (11.1) does not support the export of XML schemas, XML schema-based
XMLTypecolumns, or binary XML data to database releases prior to 11.1.
Regardless of the export format, the format of the dump file will be either
CLOB or self-describing binary XML with a token map preamble. How Oracle Data Pump stores this data in the dump file depends on the value of the export parameter,
data_options (the only valid value for this parameter is
xml_clobs.) If you specify this value on the export command line, all
XMLType data will be stored in text format in the dump file. If you do not specify the
xml_clobs parameter in the
expdp command, then the format of the
XMLType columns in the table determines the format of the data in the dump file. Table 36-1 shows the format of the
XMLType columns in the table with the corresponding format of the dump file.
|Storage Model of XMLType Columns||Dump File Format of XML Data|
Structured storage, binary XML storage, or hybrid storage (a mixture of unstructured and structured storage)
Self-describing binary XML
XMLType data is exported and imported as XML data, the source and target databases can use different
XMLType storage models for that data. This means that you can export data from a database that stores
XMLType data one way and import it into a database that stores
XMLType data a different way.
You can export
XMLType tables, whether they are XML schema-based or not. If a table is XML schema-based, then it depends on the XML schema used to define its data. This XML schema can also have dependencies on SQL object types that are used to store the data, in the case of structured storage. Therefore, exporting a user who has XML schema-based
XMLType tables also exports the following:
SQL objects types (if structured storage was used)
The following guidelines apply to exporting hierarchy-enabled tables, that is, tables that underly Oracle XML DB Repository data:
The row-level security (RLS) policies and path-index triggers are not exported for hierarchy-enabled tables. When these tables are imported, they are not hierarchy-enabled.
OWNERID are not exported for these tables. In an imported database the values of these columns could be different, so they should be reinitialized.
See Also:"Repository Resources and Database Table Security" for information about RLS policies and path-index triggers
Using the transportable tablespace feature, you can move a set of tablespaces from one Oracle database to another, whether it is XML schema-based or non-schema-based. When you export using transportable tablespaces mode, only the metadata for tables (and their dependent objects) within a specified set of tablespaces are unloaded. You can then copy the tablespace data files to another Oracle database and perform a transport tablespace import. This is generally very fast, because it involves only copying the tablespace and re-creating the tablespace metadata.
TRANSPORT_TABLESPACES parameter in
expdp to specify a list of tablespace names for which the object metadata will be exported from the source database to the target database.
You cannot export transportable tablespaces and import them to a database at a lower release level. The target database must be at the same or higher release level as the source database.
When exporting, Oracle XML DB Repository hierarchy information is lost (see "Exporting Hierarchy-Enabled (Repository) Tables"). When importing, any XML schemas referenced by the data to be imported are also imported.
Oracle XML DB supports a foldering mechanism that helps store content in the database in hierarchical structures, as opposed to traditional relational database structures. Foldering lets you use path names and URIs to refer to data (repository resources), rather than table names, column names, and so on. This foldering mechanism is not entirely supported using
However, for resources based on a registered XML schema, the
XMLType tables storing the data can be exported and imported. During export, only the XML data is exported, the relationship in the Oracle XML DB foldering hierarchy is lost.
Oracle XML DB stores the metadata (and data unrelated to XML Schema) for Oracle XML DB Repository in database schema (user account)
XDB. Because Oracle Database does not export the repository structure, these metadata tables and structures are not exported during a full database export.The entire database schema (user)
XDB is skipped during a full database export, and any database objects owned by user
XDB are not exported.
Export and import using Oracle Data Pump is described in Oracle Database Utilities. This section includes additional guidelines and examples for using commands
XMLType data. For tables with
XMLType data stored as
CLOB, Oracle Data Pump exports and imports the tables in the same way as it would do for any table.
The examples presented here use the command-line commands
impdp. After submitting such a command with a user name and command parameters, you are prompted for a password. The examples here do not show this prompting.
XMLType table has a dependency on the XML schema that was used to define it. Similarly, the XML schema has dependencies on the SQL object types created or specified for it. Importing an
XMLType table requires the existence of the XML schema and the SQL object types. When a
TABLE mode export is used, only the table related metadata and data are exported. To be able to import this data successfully, the user needs to ensure that both the XML schema and object types have been created.
The examples here assume that you are using a database with the following features:
A database with a sample schema
foo with an
XMLType column in unstructured (
CLOB) storage format
A directory object
dpump_dir, for which
WRITE privileges have been granted to the sample schema
Example 36-1 shows a table-mode export, specified using the
TABLES parameter. It exports table
foo.dmp dump file.
expdp system directory=dpump_dir dumpfile=foo.dmp tables=foo
Note:In table mode, if you do not specify a schema prefix in the
expdpcommand, the schema of the exporter is used by default.
Example 36-2 shows a table-mode import. It imports table
foo from the
foo.dmp dump file.
impdp system tables=foo directory=dpump_dir dumpfile=foo.dmp table_exists_action=append
If a table by the name
foo already exists at the time of this import, then parameter
table_exists_action appends rows at the end of the existing table. When you use
APPEND, the data is always loaded into new space; existing space, even if available, is not reused. For this reason, you might need to compress your data after the load.
Note:See, "Oracle Database Utilities", for more information about Oracle Data Pump and its command-line clients,
When performing a
Schema mode export, if you have role
EXP_FULL_DATABASE, then you can export a database schema, the database schema definition, and the system grants and privileges of that database schema.
The example here assumes that you are using a database with the following features:
x4a has created a table
x4a has a registered XML schema,
ipo, which created two ordered collection tables
x4a creates table
po2 as shown in Example 36-3.
CREATE TABLE po2 (po XMLType) XMLTYPE COLUMN po XMLSCHEMA "ipo.xsd" ELEMENT "purchaseOrder" VARRAY po.XMLDATA."items"."item" STORE AS TABLE item_oct2 ((PRIMARY KEY(NESTED_TABLE_ID, SYS_NC_ARRAY_INDEX$))) NESTED TABLE po.XMLDATA."shippedItems"."item" STORE AS sitem_nt2;
po2 is then populated and exported, as shown in Example 36-4.
expdp x4a directory=tkxm_xmldir dumpfile=x4a.dmp
Example 36-4 exports all of the following:
All data types that were generated during registration of XML schema
po2 and the ordered collection tables
sitem_nt2, which were generated during registration of XML schema
All data in all of those tables.
impdp x4a directory=tkxm_xmldir dumpfile=x4a.dmp
Example 36-5 imports all of the data in
x4a.dmp to another database, in which the user
x4a already exists.
impdp x4a directory=tkxm_xmldir dumpfile=x4a.dmp remap_schema=x4a:quine
Example 36-6 imports all of the data in
x4a.dmp (exported from the database schema of user
x4a) into database schema
quine. To remap the database schema, user
x4a must have been granted role
IMP_FULL_DATABASE on the local database and role
EXP_FULL_DATABASE on the source database.
REMAP_SCHEMA loads all of the objects from the source schema into the target schema.