IBM puts some thought into DB2
Adaptive technology bolsters database's manageability
With the latest release of DB2, IBM 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 favorite improvements, an application of self-tuning, 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 percent performance gain, a significant increase.
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. Companies may now be able to hire less skilled DBAs because human knowledge is no longer needed to tune the database: Admins will not need to keep lists of parameters to check for tuning anymore.
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. Further, 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. Admins may select from three synchronization modes to choose the level of consistency they want between the two databases.
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 use of a third monitoring host, which is a huge benefit because it means you don’t have to rely on another server to act as a heartbeat mechanism.