The latest issue of IBM Database Magazine has an interesting article titled Healthcare’s XML Heartbeat. In this article, Ken North describes the rise and rise of XML in the healthcare industry. He talks about the key role that XML is playing in the emergence of electronic medical records, the efficient exchange of information, and increasing levels of interoperability. The article gives great insight into the XML-based electronic medical records environment at UCLA Health System.

Why won’t Oracle publish results for the Transaction Processing over XML (TPoX) benchmark?

We know that Oracle has implemented TPoX demonstration and test systems. Oracle has demonstrated TPoX systems at their conferences. Also, Oracle has included TPoX tests and data in their research efforts and as part of their X-Files demonstration. So we know that Oracle has used TPoX. Why won’t they publish benchmark results?

Oracle claims that the TPoX benchmark is narrowly scoped and that it doesn’t handle the diverse use cases of XML. They are correct in that TPoX does not model multiple scenarios. It models only one scenario… a security trading scenario that uses a real-world XML Schema (FIXML). Such a scenario involves a high volume of relatively small XML documents. The benchmark takes into account write, update, delete, indexing, XML schema, logging, concurrency, and other database considerations. While the TPoX benchmark does indeed model only one scenario, it makes sure to incorporate a real-world mix of XML-related operations for that scenario.

Database benchmarks are always focused on a specific usage scenario, and TPoX is no exception. Relational database benchmarks have always taken the same approach: TPC-C focuses on OLTP systems, TPC-W on web-based transaction systems, TPC-H on ad-hoc decision support systems, TPC-R on decision support systems with precomputed and materialized views. There are database benchmarks that focus on SAP workloads, and so on. The reason for this approach is that combining all these diverse use cases into a single benchmark would lead to a test scenario that does not represent anything in the real world. In the same spirit, TPoX focuses on just one of various common XML use cases. Other XML benchmarks that focus on other use cases, such as XML content and full-text search, are also desirable but yet to be defined.

TPoX is entirely open-source (with major contributions from Intel and IBM). In TPoX 1.3 contributors from the University of Furtwangen in Germany have added initial support for Oracle Database and Microsoft SQL Server. In particular, they adjusted the TPoX queries to support Oracle Database and SQL Server syntax, and they have extended the TPoX workload driver so it connects to Oracle Database and Microsoft SQL Server. Anybody, including Oracle, is welcome to enhance, revise, or modify the TPoX benchmark as they deem appropriate for meaningful benchmarking.

The TPoX benchmark is a useful measuring stick for the many organizations who have transactional systems with small XML documents. I am amused that Oracle, on the one hand continually highlights the need for separately handling the diverse XML uses cases, and then on the other hand complains that TPoX handles only one use case and not a diverse range of use cases. Don’t they realize that they are contradicting themselves

Oracle also claims that TPoX attempts to follow the Transaction Processing Performance Council (TPC) approach, and that the TPC approach deviates from production system workloads. It is true that many people, including myself, consider some of the TPC benchmarks to have flaws. However, they still serve a purpose for people who are evaluating database options. Although the benchmarks are not a direct indication of a performance in an end user’s environment, they are still a useful tool for indicating relative performance.

I am not aware of any any alternative XML benchmarks proposed by Oracle. If Oracle has an XML benchmark that they believe is better, it would be great for everyone in the industry if they would bring it forward. Everyone would benefit from such a move, especially the people who are trying to evaluate their XML storage options. I am curious to know why Oracle hasn’t published any benchmark results for its XML capabilities, and instead focuses its efforts on debates that are difficult to resolve. IBM has published both TPoX benchmarks results and internal benchmark results. When are Oracle going to step up to the plate?

Oracle has long claimed that the fact that Oracle Database has multiple different ways to store XML data is an advantage. At last count, I think they have something like seven different options:

• Unstructured
• XML-Object-Relational, where you store repeating elements in CLOBs
• XML-Object-Relational, where you store repeating elements in VARRAY as LOBs
• XML-Object-Relational, where you store repeating elements in VARRAY as nested tables
• XML-Object-Relational, where you store repeating elements in VARRAY as XMLType pointers to BLOBs
• XML-Object-Relational, where you store repeating elements in VARRAY as XMLType pointers to nested tables
• XML-Binary

Their argument is that XML has diverse use cases and you need different storage methods to handle those diverse use cases. I don’t know about you, but I find this list to be a little bewildering. How do you decide among the options? And what happens if you change your mind and want to change storage method?

But back to my original question… Why don’t Oracle publish results for the TPoX benchmark? Perhaps it is because Oracle are still trying to figure out which of their seven storage options is best to use

Many organizations are putting their forms “online”. If you are working on an electronic forms project, I’d like to let you know about a couple of useful resources that my colleague Bryan Patterson has been busy creating:

• A step-by-step tutorial that shows you how to create an electronic forms-based solution. You don’t need to purchase any software to get this demo working in your environment. It uses the trial version of Lotus® Forms to create and manage the online forms; it uses the no-charge version of DB2® Express-C to receive and store the XML data; it uses the no-charge version of IBM Data Studio Developer to create a simple Web service; and it uses the no-charge WebSphere Application Server Community Edition. To see the tutorial, go to Build an intelligent eForms solution based on DB2 pureXML, Lotus Forms, and Web services.
• A video that provides an overview for the above solution and walks through the step-by-step tutorial. To see the video, go to Create an electronic form solution with DB2 pureXML and Lotus Forms.

Make sure to check out the list of resources for both of these… they contain some useful links.

It seems like every conference I go to this year has successively stronger ties to virtual networking. There are increasing levels of Twitter activity being shown on giant displays. It’s interesting to watch conference attendees routinely ignore giant displays, until they realize that one is showing real-time tweets about the conference, and then stopping in their tracks to take in the twitter stream.

The advent of blogs dedicated to individual sessions is also interesting. These blogs provide an unintimidating venue for people who are not comfortable asking questions in a large room. They also allow a conversation to continue after the conference. Although, the traffic to them is quite limited. I imagine that we are all struggling to keep up with the bandwidth demands of these new networking tools.

But my most interesting recent experience was with the Poken goven to all conference attendees at the recent IBM Information on Demand conference in Berlin. The Poken allows you to exchange a “digital handshake” with other conference attendees. By touching Pokens, you exchange contact details, including information about your accounts on popular social networking sites like LinkedIn, Twitter, and Facebook. You can also exchange details with a special Poken to get the presentation for the session you are attending.

The first thing I must say is that I was very happy to see a Poken help desk after registering. I did need a little help because initial attempts to exchange information were not succeeding. I was not giving my Poken enough time to exchange details.

The second thing I must say is that, after using the Poken for the entire conference, I still want to give out business cards. You see, after I get a business card, I find a few minutes to write a few notes on that business card. This way I have some additional context when I return from a conference with another stack of business cards. Thankfully I continued to do this at the conference because all I get with the poken is a sequential list of new Poken friends. I can see their profile, including a photo if they uploaded one. But it does not give me enough context for a follow up (unless they are especially memorable).

So, in my opinion, the Poken is a useful addition to the business card, but it will not replace it. You may argue that I could simply write some notes elsewhere and keep track of them. But there something very easy about writing a few key words on the back of a business card. For me the best solution would be to use my smartphone to easily “poke” people. Then, if I could add notes to newly acquired “business cards” on my smartphone, I could truely consider replacing the business card.

If you want to learn more about native XML databases and DB2 pureXML, this eBook uses the fun and easy-to-understand “for Dummies” format to do just that. It introduces these topics, while guiding you to create your first native XML database. You don’t need to purchase any software to get started creating native XML databases—you simply use the freely available version of DB2. To get your copy, download DB2 pureXML for Dummies. Make sure to download it today as there are a limited number of free downloads available.

Here is a short video showing Matthias Nicola speaking about XML in the data warehouse at the IDUG conference. He talks about the new features in DB2 that support native XML data in data warehouse environments. Apologies for the choppy nature of the video. It was taken by hand with my inexpensive pocket camcorder. You can click on the HQ button in the YouTube viewer to see the higher quality version.

Attendees of the upcoming Information on Demand conference in Berlin will get a Poken with their conference badge. Poken is a new tool that offers a smart way to network and share data.

When you insert the Poken into the USB port of a computer, you are connected to the Poken website where you fill in your personal data and create a profile, including links to your profiles on social networking sites like Linked-In, Facebook, Twitter, Myspace, and so on. This will then be stored on your Poken.

To network with someone at the conference, simply hold your Poken up to theirs and exchange IDs, creating an electronic handshake. The next time you connect your Poken to a computer and go to your profile page, you will see all the profiles of exchanged IDs together with their Social Networking sites. This enables you to easily stay in contact post-conference. No more dog-eared business cards surfacing weeks later!

Not only that, but you can also use your Poken to facilitate information download. For example, you can easily obtain session information and session presentations. This is my virgin Poken experience at a conference, so I am really curious to see how it works out…

Greetings from the IDUG North America Conference in Denver, Colorado. IDUG is the International DB2 Users Group—an independent, not-for-profit organization for DB2 users by DB2 users. If you are a DB2 user, IDUG provide an invaluable resource. Here is a video showing a few short glimpses from Day 1 of the conference:

This continues my series of posts about the new features for working with native XML data in the IBM DB2 database software.

Compression reduces the amount of storage space needed for data. Data storage costs money, so minimizing this cost is very important for many organizations. Especially when storage costs can be reduced by 60% to 80%. Storage-related costs include the actual storage devices themselves, the power consumed by those storage devices, and the time spent maintaining these devices.

Another benefit of data compression is that it often improves database performance. Because the data requires less disk space, you typically have reduced levels of disk I/O activity, which can improve database performance. Also, because more data is being cached, you may also enjoy improved buffer pool hit ratios. In many cases, the performance gain due to reduced I/O and better memory utilization outweighs the extra CPU cycles required to compress and decompress the data.

When storing XML data, DB2 typically places the XML data in a location called the XML Data Area (XDA). However, if the XML data is less than 32KB in size, it can be stored with the relational data (this is called inlining).

With DB2 9.5, you can compress XML data that is inlined, allowing you to reduce storage for XML data. For instance, the XML transactions in the TPoX benchmark are typically smaller than 32k, allowing them to be inlined and compressed. In the most recent TPoX benchmark, one terabyte of raw XML data is stored in 390 gigabytes of storage, giving a compression ratio of 61%.

DB2 9.7 extends compression to all XML data, regardless of whether it is in the XDA or inlined. In other words, DB2 9.7 can compress XML data, regardless of size. (The maximum size of an individual piece of XML data that can be stored in DB2 is 2 gigabytes.)

The degree to which XML data can be compressed depends on the nature of the XML data. IBM has tested the new data compression features with six different data sets. Three of these data sets were supplied by IBM clients, and represent real world client usage. The other three data sets represent XML data sets available in the public domain. The data sets include XML documents that range in size from 2KB to 100MB. The following diagram shows the storage savings that have been achieved (this diagram is from Cindy Saracco and Matthias Nicola’s article titled Enhance business insight and scalability of XML data with new DB2 V9.7 pureXML features).

As you can see, compressing XML data typically results in 60 to 80 percent disk space savings with DB2 9.7.

Finally, I’d also like to mention that if you compress XML data, you can also compresses any indexes for that XML data. Compressed indexes also reduce physical I/O and increase buffer pool hit ratios, which often leads to a net performance gain.