Important considerations for XML data movement
There are a number of restrictions, prerequisites, and reminders to consider when importing or exporting XML data. Review these considerations before importing or exporting XML data.
Keep the following consideration in mind when exporting or importing
XML data:
- Exported XML data is always stored separately from the main data file containing exported relational data.
- By
default, the export utility writes XML data in Unicode. Use the
xmlchar
file type modifier to have XML data written in the character code page, or use thexmlgraphic
file type modifier to have XML data written in UTF-16 (the graphic code page) regardless of the application code page. - XML
data can be stored in non-Unicode databases, and the data inserted
into an XML column is converted from the database codepage to UTF-8
before insertion. In order to avoid the possible introduction of substitution
characters during XML parsing, character data to be inserted should
consist only of code points that are part of the database codepage.
Setting the
enable_xmlchar
configuration parameter tono
blocks the insertion of character data types during XML parsing, restricting insertion to data types that do not undergo codepage conversion, such as BIT DATA, BLOB, or XML. - When
importing or loading XML data, the XML data is assumed to be in Unicode
unless the XML document to import contains a declaration tag that
includes an encoding attribute. You can use the
xmlchar
file type modifier to indicate that XML documents to import are encoded in the character code page, while thexmlgraphic
file type modifier indicates that XML documents to import are encoded in UTF-16. - The import and load utilities reject rows that contain documents that are not well-formed.
- If the XMLVALIDATE option is specified for the import utility or the load utility, documents that successfully validate against their matching schema are annotated with information about the schema used for validation as they are inserted into a table. Rows containing documents that fail to validate against their matching schema are rejected.
- If the XMLVALIDATE option is specified for an import or load utility and multiple XML schemas are used to validate XML documents, you might need to increase the catalog cache size configuration parameter catalogcache_sz. If increasing the value of catalogcache_sz is not feasible or possible, you can separate the single import or load command into multiple commands that use fewer schema documents.
- When you export XML data specifying an XQuery statement, you might export Query and XPath Data Model (XDM) instances that are not well-formed XML documents. Exported XML documents that are not well-formed cannot be imported directly into an XML column, because columns defined with the XML data type can contain only complete, well formed XML documents.
- The CPU_PARALLELISM setting during a load is reduced to 1 if statistics are being collected.
- An XML load operation requires the use of shared sort memory to proceed. Enable SHEAPTHRES_SHR or INTRA_PARALLEL, or turn on the connection concentrator. By default, SHEAPTHRES_SHR is set, so shared sort memory is available on the default configuration.
- You cannot specify the SOURCEUSEREXIT option or SAVECOUNT parameter of the LOAD command when loading a table containing an XML column.
- As with LOB files, XML files have to reside on the server side when using the LOAD command.
- When loading XML data to multiple database partitions in a partitioned database environment, the files containing the XML data must be accessible to all database partitions. For example, you can copy the files or create an NFS mount to make the files accessible.