186 DB2 UDB for z/OS: Application Design for High Performance and Availability
The SQL/XML functions are integrated into the DB2 engine, in contrast to the XML Extender
publishing functions that are user-defined functions. In general, SQL/XML functions
outperform XML Extender composition by an order of magnitude, especially when generating
large XML documents. For example, during a lab measurement with a 5 MB document,
SQL/XML was 20 times faster. Also, note that XML Extender cannot insert more than 10,240
rows into any table when composing an XML document.
The preferred tool for XML publishing is SQL/XML. Generally speaking, it is more flexible and
versatile than the DB2 XML Extender publishing functions, and provides better performance.
However, if for some reason you cannot use SQL/XML to get the job done, you can try to
accomplish your goal using XML Extender, and as a last resort, if XML Extender is also not
up to the job, write your own application to publish relational data as XML.
For more information about the use of DB2 and XML, see XML for DB2 Information
7.5 The future
In the previous sections, we described the functionality that is available with DB2 for z/OS
Version 8 and DB2 UDB for z/OS Version 8 XML Extender. We also described some of the
restrictions in the current architecture, mainly related to storing XML data into a relational
database, such as:
The mapping between the XML and the relational schema can be very complex, and may
require dozens of relational tables to adequately shred an XML document. Later on,
during publishing all these tables have to be joined together again to produce the XML
The mapping also has to be fixed. If the XML schema changes, one of the major
advantages of XML is its flexibility to handle documents with different schemas, the
mapping has to change, and the definition of the underlying DB2 tables also has to
change, and most likely some data has to be moved from one table to another, or two
tables or columns have to be merged.
When accessing documents that are stored intact, any subdocument level access requires
XML parsing, which is an expensive operation.
For this reason, IBM has been working on allowing XML documents to be stored in a native
XML format and data type (not stored as a CLOB or VARCHAR, or decomposed). DB2 will be
enhanced to be able to store XML documents using a native (hierarchical) storage model that
is fully integrated with DB2 with sophisticated XML indexing mechanisms.
In order to prepare for this new way to store and deal with XML inside the DB2 engine, it is
probably a good idea to also store the XML document somewhere in an intact format. This
way, whenever the native XML store arrives, you will always be able to take those “old”
documents and store them in the native XML store.
For an indication about the future directions of DB2 with XML, see:
Even though these articles are geared towards DB2 on Linux, UNIX, and Windows, they are
also indicative of the XML functions that DB2 for z/OS is going to support, although not all of
these functions may be available at the same time, and the implementation will certainly
depend on platform characteristics.