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 the xmlgraphic 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 to no 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 the xmlgraphic 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.