DBA Concerns about Native XML Storage

October 16, 2008

Recently, I have had some conversations about the impact of native XML storage in DB2 for administrators of relational databases. You may be interested in the gist of those conversations.

Some DBAs are wary of changes to their relational environments. They have a finely-tuned environment that meets their service level agreements. I understand and appreciate their apprehension regarding “new features”. After all, its good to exercise caution when vitally important parts of the business depend upon your systems. However, you should be aware that, sometimes, you can reduce server load, improve query performance, or increase throughput by using native XML storage.

I cannot unequivocally tell you that using native XML storage will improve application performance in your environment, because your performance depends on many factors, both within the realm of the database and beyond. The one thing that I can unequivocally state is that a DBA who uses native XML storage can configure the storage of native XML data (tablespace, page sizes, buffers, etc) separately from the storage settings for other relational data and often improve performance.

For a good technical article on various aspects of performance for different approaches to storing XML data in DB2, see A performance comparison of DB2 9 pureXML and CLOB or shredded XML storage.

Some DBAs have expressed a fear that native XML storage may jeopardize their jobs. This fear stems from the perception that native XML storage eliminates tasks that currently occupy large amounts of time. For instance, there may no longer be a need to shred XML schemas into relational tables, to manage the many tables that may result from shredding a complex XML format, to update database table definitions after XML schema changes, and so on. It is true that these tedious tasks may be eliminated. However, many of the administrative tasks that are needed for relational data are still needed for native XML data. For instance, administrators must:

  • Determine optimal page size for XML data
  • Determine whether to set up separate table spaces
  • Assess and set up buffer pools for XML
  • Determine and implement an XML indexing strategy
  • And so on

As you can see, the move to storing XML data in XML columns doesn’t eliminate the need for database administration. The need for fine-tuning the database remains as important as ever. The move to native XML storage does free DBAs from some of the tedium associated with setting up and updating shredding environments. Time that can possibly be spent on other tasks, or on tuning the system.

XML is here to stay. The amount of XML data that DBAs will need to manage will undoubtedly increase. After all, XML standards are increasingly emerging and being adopted. As such, it is in the best interests of DBAs to know and use the best way to manage that XML data. Native XML storage will not always be the answer to every XML storage question. Sometimes traditional relational storage methods will be best. However, one thing is certain: being able to determine the best option for XML data and being able to tune an environment with XML data for optimum performance is an increasingly valuable skill for DBAs.

My advice is… don’t be wary of native XML storage. Learn about it and know when to use it for your professional advantage.


One Response to “DBA Concerns about Native XML Storage”

  1. Eugene Says:

    I am seaching for some idea to write in my blog… somehow come to your blog. best of luck. Eugene

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: