Statistical views are another scalability feature in DB2 9.1. Ordinarily, the query optimizer uses statistics to estimate cardinality of the data stored in tables, and this is one of the major factors used to determine an execution plan for a given query. Statistical views extend this capability to views as well, which means that now views are not only considered to be derived tables, but they’re actually treated more like tables. IBM isn’t the only one to consider blurring the line between views and tables, but it is the first to implement it.

Return to "Viper" report

DOWNLOAD PDF Click here to download InfoWorld's special report IBM DB2 "Viper" swallows XML whole

The Bottom Line IBM DB2 9.1 ("Viper") IBM, http://ibm.com/db2 Excellent  8.7 criteria score weight Manageability 8 25% Performance 9 25% Availability 9 20% Scalability 9 20% Value 8 10% Cost: Starts at $165 per user or $4,874 per processor, including first year of support and service Platforms: Linux, Unix, Windows, z/OS Bottom Line: DB2 9.1 is an excellent database with groundbreaking features. Its new hybrid data engine offers true native XML storage, allowing the entire data store to be retrieved using either SQL or XQuery, interchangeably. In addition, the new Development Workbench wins big points with its support for building XQuery expressions. Other new features include row-level compression, scalability improvements, and advanced, granular access controls. About our Reviews and Scoring Methodology

Label-based access control

Oracle has had advanced, row-level access control since Version 8.1. DB2 9.1 is catching up, albeit with a slightly different method. (Unfortunately, SQL Server doesn’t have similar functionality at all, and I hear that it’s not even being considered for the Katmai release next year.) Although the traditional methods of controlling access to row-level data (views and stored procedures) are still in play, DB2’s LBAC (label-based access control) gives you much greater reassurance by preventing users from circumventing your security measures.

For instance, using traditional access control, you could create a view that specifies that a certain user can only see customers in a certain region, or only a certain column in the customers table. A user who knows the name of the base table, however, can just query the table instead of using the view. With LBAC, on the other hand, you can specify a security policy to control access to specific columns or even specific ranges of rows.

Other databases can achieve something like this level of security using the traditional methods. The difference is in the level of administration involved. With traditional methods, for example, you can create a stored procedure to give a group of users access to data. If another group comes along you can write another stored procedure to give them the access they need as well, and so on. You have to keep up with all of the procedures you’ve written and track which groups get access to each one, but the advantage is that one stored procedure doesn’t affect the other ones -- it doesn’t take much planning.

With LBAC, you really have to plan how you want the security policy to play out. If a group comes along that needs different access, you might need to redesign your whole policy to make it run well. But for the long haul, the LBAC approach requires much less ongoing administration, because all the work is done up front. You don’t have to worry about keeping up with stored procedure versions and the like. Each approach has its place, and it’s my guess that shops employing LBAC will find themselves using a combination of both methods.

Reduce your data

DB2’s new row-level compression is one of my favorite features. It’s actually table-level compression and it can result in a direct storage savings of 45 to 75 percent.

I performed an initial benchmark just to get an idea of the performance difference between two identical tables, one that was compressed and the other that was not. I found that the performance between the two was close, but the compressed table often actually performed better than the uncompressed table (presumably because more of its data fit in memory).

For my next test, I put my database on a server that had only 1GB of RAM, to see how a smaller business might take advantage of the compression. I found that the compressed table doesn’t perform nearly as well in this scenario as it did on my server with 4GB of RAM. Because DB2 keeps the compression dictionaries in memory, my guess is that the lower memory of the server is causing the compression dictionaries to be paged to disk when the server is busy.

Whatever the actual cause for the slowdown, if you’re going to use row-level compression, make sure you thoroughly benchmark it before you put it in your production environment. Even if you have a lot of RAM you might be surprised by poor performance due to any number of conditions, especially if you don’t have a dedicated database server. All the same, if I had to pick one feature that puts DB2 ahead of any of the other databases, this would definitely be the one, because it’s going to be far more useful to the largest portion of the client base. I would imagine that Oracle and Microsoft are both scrambling to be the next to bring this to market.

Time to jump ship?

The new DB2 is a technically impressive release. It’s loaded with features that are sure to please DB2 admins and developers alike. Whether those features will be compelling enough to convince a die-hard Oracle DBA to switch platforms, however, is unclear.

In the XML department, the pureXML engine hits a home run, but its significance in the business landscape remains to be seen. The scalability features, including larger temporary work areas and statistical views, make DB2 more attractive to the high-end market, but won’t necessarily appeal to smaller customers.

Viper’s groundbreaking row-level compression is where most customers will see the greatest returns. But although this feature will definitely reduce TCO for current DB2 shops, it simply isn’t enough to justify porting to a new platform. Likewise for the myriad other features, ranging from XML query enhancements to disaster recovery improvements -- they’re compelling but not revolutionary.

All in all, this is an excellent release for current DB2 customers, but in the highly competitive relational database market it takes a lot to win new converts. DB2’s new features certainly show off IBM’s engineering know-how, and they may be laying the groundwork for something yet to come, but as of now, the worth of many of these capabilities hasn’t hit the industry yet. Maybe over the next couple releases, as IBM and its customers start to build on these technologies and do things nobody else can do, the true payoff of the DB2 vision will emerge.

Click for larger view.

Click for larger view.

Correction:
In this article, we originally misreported IBM's XML performance claims. According to IBM, DB2 9 adopters report performance increases of approximately 5 to 7 times more than what they experienced with Microsoft SQL Server or Oracle Database. The errors have been corrected.