Complexity and DBMS Release Migration

By Craig S. Mullins

Last month we talked about the increasing complexity of database management systems and the impact this has on database administration. Complexity is a pervasive issue in IT these days, particularly with DBMS software, so let’s continue this discussion.

One of the factors in determining when and how to upgrade to a new DBMS release is, of course, the functionality supported by the new release. But tightly coupled to functionality is the inherent complexity involved in supported and administering the new features. Regardless of the new “bells and whistles” that come along with a DBMS upgrade, there are always administration and implementation details that must be addressed before upgrading. It is the responsibility of the DBA group to ensure that standards are modified to include the new features, educate developers and users as to how new features work and should be used, and prepare the infrastructure to support the new DBMS functionality. These are not trivial tasks.

The type of changes required to support the new functionality must be factored into the upgrade strategy. When the DBMS vendor makes changes to internal structures, data page layouts, or address spaces, the risks of upgrading are greater. Sometimes databases must be converted to a new format as part of a version upgrade. This can causes a severe drain on productivity as DBAs waste time migrating structures instead of administering databases. Other internal changes, while not as drastic as actual database structure changes, can cause just as drastic problems. Additional testing is warranted in these situations to ensure that database utilities, DBA tools, and data extraction and movement tools still work with the revised internals.

Another mitigating complexity factor is the topology and layout of your particular database implementation. The more complex your database environment is, the more difficult it will be to upgrade to a new DBMS release. The first complexity issue is the size of the environment. The greater the number of database servers, instances, applications, and users, the greater the complexity. More servers and instances translates into additional work to actually install a new version. More applications means more potential performance problems as access paths change from one version to the next. And more users–well–we all know what that means, don’t we?

Additional concerns include the type of applications being supported. A DBMS upgrade is easier to implement if only simple, batch-oriented applications are involved. As the complexity and availability concerns of the applications increase, the difficulty of upgrading also increases. It is impossible to maintain 24/7 access to a database server while you are upgrading to a new DBMS version.

Location of the database servers also impacts the release upgrade strategy. Effectively planning and deploying a DBMS upgrade across multiple database servers at various locations supporting different lines of business increases the difficulty of upgrading. It is likely that an upgrade strategy will involve periods of supporting multiple versions of the DBMS at different locations and for different applications. Supporting different versions in production should be avoided if possible, but that is not always possible to achieve. Think about it – keeping the versions straight can be difficult if some servers are on version 6, others are on version 7, and wait, didn’t we migrate that one over there to version 8?

Finally, the complexity of the applications that access your databases must be considered. The more complex your applications are, the more difficult it will be to ensure their continuing uninterrupted functionality when the underlying DBMS is modified. If you use stored procedures and user-defined functions, a new DBMS version can change the way these “program” objects work. And the complexity of the SQL will also impact the difficulty of migrating to a new DBMS version. The more tables involved in the SQL and the more SQL features being used, the more difficult it becomes to ensure that access path changes do not impact performance. Client/server and distributed processing involves network usage and multiple server tiers, both of which complicate testing the new DBMS release.

The language used by the programs might also impact DBMS release migration due to different support for compiler versions or new ways of embedding SQL into application programs. New ODBC or JDBC drivers may be needed for a new DBMS version.

Finally, if the application uses other infrastructure software such as message queues and transaction processors this can further complicate migration because new versions of these products may be required to support the new DBMS release.

The bottom line is that increasing database complexity increases the workload on DBAs. And there is no apparent end to the rising spiral of complexity being incorporated into our database management systems.