Dealing with DBMS Complexity

The Database Management Systems we use are becoming more complex – there can be no denying this basic fact of life. Each and every new version of your favorite DBMS adds new features, functions, and options that further complicate database administration. Oh, yes, someone, somewhere wanted each of those new features and they may be making life easier for them. But, on the whole, our DBMSs are becoming bloated monsters with too many features that we never use. 

Actually, this is increasingly true for the entire software industry, not just for the DBMS. Take for example, Word, Microsoft’s ubiquitous word processor. How many of us use more than 20% of its features? Very few, I’d guess. But each of us has to install all of those features and it makes the software harder to use and harder to manage, while consuming more disk space. 

I guess we’re all living with this as best we can, but what are the real costs of DBMS feature bloat? The potential costs are many. Consider a scenario where a new version of your favorite DBMS is installed, and then:

• someone uses a feature that the company is not ready to support either because proper training has not been conducted or proper procedures were not yet in place;
• someone uses a feature the wrong way, or at least in a way that causes performance degradation or complicates database maintenance;
• the DBAs forbid certain features from use (even when they might help) because the company has not yet decided how to support them;
• someone writes code that is very complex because they did not understand how to use a new feature, so they hand-coded it themselves.

And these are just a few simple, yet costly scenarios. But trouble can be brewing even if the perception is that everything is fine. Perhaps the DBAs are ready to support a new feature and the developers even know how to use the feature. But now the SQL becomes more complex because it takes 600 lines of code when before it was 100 lines with the additional work embedded in an application program. This additional complexity goes from the application program to the SQL. Yes, the overall application may become more efficient, but it also can become more difficult to debug, maintain and augment in the future because the SQL is now much more complex.

What can be done? Well, there is no bullet-proof method of avoiding the perils of DBMS feature bloat. But proper DBA practices and procedures can diminish its impact, at least somewhat. Be sure to perform due diligence for each new DBMS version to be installed. This should include in-depth technical training from the vendor (or another qualified source) such that the DBAs understand every new feature added to the new version. The next step is for the DBAs to procure a training program for the rest of the company to bring developers and users up-to-speed on the new features. Different levels of training will be required for different types of developers and users. Finally, be sure to establish the proper policies and procedures for how best to use each new feature. This might involve simply updating current procedures or possibly writing completely new ones for significant new DBMS functionality.

Keep in mind, too, that dealing with complex new DBMS features and functions is not just a new version issue. Many times DBMS vendors sneak new features into point-releases and maintenance “fix packs.” So, you might innocently download what you perceive to be a bug fix from the DBMS vendor’s web site and lo’ and behold you have a new feature. Take proper precautions with every new piece of code that is applied to your DBMS environment. Work patches into your test environment first and treat them like significant new releases until you are know the features they comprise. Read the accompanying documentation that is provided (that is, if it is provided) to learn about the functionality of each new fix pack. And attend your local user groups and form a network of DBA friends who can share their experiences with new fix packs, releases, and versions.

The bottom line is just to use common sense: do not apply any new DBMS software to your environment until you know what it can do and are ready to support it. Do this with care and speed though. You don’t want to be viewed as a bottleneck. When application developers are clamoring for new DBMS features it is more difficult to delay an upgrade. If the DBMS functionality can minimize the cost and effort of application development, pressure will be applied to the DBA group to migrate swiftly to the new release. An additional issue that will coerce rapid adoption of a new release is when DBMS problems are fixed in the new release (instead of through regular maintenance fixes).

As you learn to deal with your particular DBMS and vendor, you will become better acquainted with its release schedule. To be an effective custodian of the DBMS the DBA will need to know how often the DBMS vendor releases a new version. Some vendors have rapid release cycles with new releases coming out every year to 18 months. Others take longer, but put out more maintenance fixes during the interim. Each approach can be good or bad depending upon the needs of your environment. If you always want to support leading edge features, a rapid release cycle is good. However, if your shop is more conservative, a DBMS that changes so quickly can be difficult to support. A rapid release cycle will cause conservative organizations either to upgrade more frequently than they would like or to utilize outdated DBMS software that is unlikely to have the same level of support as the latest more recent release.