With the latest release of DB2, IBM Corp. is poised to reshape the database landscape. Big Blue speaks very proudly and boldly about its new adaptive technology. In Version 8.2, IBM has realized some of the promise adaptive technology has to offer, but the company still has a way to go before the self-configuring, self-tuning and self-healing capabilities achieve their full potential.
One of my absolute favourite improvements is DB2’s use of multiquery optimization. DB2 looks at the different queries in your workload and matches their common elements. It then stores the execution plans of those common elements. Whenever any query comes up that has that common element, DB2 already has the execution plan worked out so it doesn’t have to recalculate it. This feature greatly increases the efficiency of your queries. In my tests, I saw as much as a 30 per cent performance gain.
DB2’s self-tuning capabilities allow both DBAs and non-DBAs to configure their databases for maximum efficiency in two seconds, once you’ve gone through the well-designed setup wizard. That’s not to say that DB2 configures everything on your server and renders your DBA obsolete. DB2 still can’t rearrange your data and log files for optimal performance, nor can it answer the configuration questions for you. The person doing the configuration still needs to have some knowledge of the applications, queries, and usage of the database for DB2 to tune it correctly.
DB2 is now also self-healing — well, somewhat. It monitors some important health indicators, such as deadlock rates, lock escalation, and HADR (High Availability Disaster Recovery) Log Delay, and an admin can set up script triggers to fix problems when certain conditions exist, such as if the deadlock rate gets too high.
DB2’s capacity for healing itself is definitely a step in the right direction, but for it to be a truly self-healing engine, it needs to offer a list of default actions for each indicator rather than forcing the DBA to script single solutions. DB2 should be smart enough to learn what it takes to fix the database in your environment, and its approach should be more proactive by trying a list of common fixes before human intervention is required.
IBM has made some pretty significant advances in HADR. DB2 8.2 can be configured to ship logs to a standby server automatically and the standby server can be configured to automatically apply the logs.
DB2 uses its new automatic client redirect capability to, as the name suggests, redirect the client requests to the standby server if the primary database goes down. Clients, each managing their own connections, will never know the difference. This functionality will greatly improve your high-availability solution. The redirect capability resides in the client library rather than being implemented by using a third monitoring host, which is a huge benefit because you don’t have to rely on another server to act as a heartbeat mechanism.
Version 8.2 also introduces a new recovery feature that combines restore and rollforward commands into one statement, making it very easy to restore a database with multiple log files. I typed in the very simple recover command, and specified a date and time to which I wanted to restore. DB2 did all the work from there.
DB2 8.2 sees many significant improvements over its previous versions. Some have global significance in the database market, such as its intelligent multiquery optimization, which puts IBM leagues ahead of its competitors. Other advances, such as the new backup feature, are very nice but not terribly earth-shattering when compared to other databases. The self-healing capabilities are also a good start, although they need improvement.
McCown is senior corporate DBA at SourceCorp.
042011
