Complexity and DBMS
Craig S. Mullins
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.
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.
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
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?
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.
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?
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
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.
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
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.