Free ESG report : Seamless data management with Avere FXT

Analysis On the 6th Feb 2007 IBM announced Viper. Yes, we know that it announced Viper in July 2006, but this is a different Viper, it just happens to have the same name. Really, it all makes perfect sense; you just have to think like IBM…..

DB2, the company’s database engine, comes in three tangy, zesty flavours:

• DB2 for z/OS (Mainframe)
• DB2 for iSeries (AS400 as was)
• DB2 for LUW (Linux, UNIX and Windows)

These three versions share about 90% of the same code base, the remaining 10 per cent is reserved for platform optimisation. Most database applications are I/O bound (particularly mainframe ones) so retaining the ability to tweak the code for each platform makes perfect sense.

Last year’s Viper was for LUW, this one is the mainframe version. So, just like the original Dodge Viper, this mainframe Viper has no truck with Windows.

For many people the most important additional feature of Viper is the new internal architecture which supports both tabular and hierarchical data structures. In other words DB2 on a mainframe finally allows XML to be stored, not by shredding, not in a CLOB, but natively in the database itself. Suddenly the worlds of web services and SOA open up for the mainframe.

This is a non-trivial change and DB2 for z/OS 9 (this Viper’s technical name) now supports the ability to query the XML data using SQL and XPath. For more detail see an excellent article by Cynthia M. Saracco here.

On the other hand, this Viper (as opposed to the one for LUW) doesn’t support XQuery. This is distinctly odd because one of the design goals of DB2 as a whole is that applications written on one platform should be portable to another with zero rewriting. Clearly, this goal cannot be met while different platforms provide different levels of XML support. This also makes rather a mockery of calling the new versions all ‘Viper’. It is possible to find papers on the company’s web site (e.g. Don Chamberlin’s article here) that talk about Viper’s capabilities. And they are about Viper. Just…. not this particular Viper. How is a poor customer supposed to know?

The other major improvement in Viper (the mainframe one) is index compression. The data row compression that was announced last year for Viper (LUW) was already supported by Viper (mainframe). Any form of compression sounds good because it saves on disk space. And, while disks may be cheap in the LUW world, they can still be wallet-numbingly expensive in mainframe land. On the other hand, data compression sounds bad because the compression/decompression takes time, potentially impacting write and query performance. Apparently not. IBM’s Rav Ahuja argues in a generic paper on compression in DB2 here that:

‘This technology can also improve performance in some scenarios, despite compression/decompression entailing CPU overhead. Accessing data from the disk is the slowest database operation. By storing compressed data on disk, fewer I/O operations need to be performed on the disk to retrieve or store the same amount of data. Therefore, for disk I/O-bound workloads (for instance, when the system is waiting/idling for data to be accessed from the disk), the query processing time can be noticeably improved.’

So, overall, is Viper for z/OS just more snake oil?

No, this is a significant advance for an excellent database engine that should keep it at the forefront for a while yet. ®

5 ways to reduce advertising network latency