Copyright © All rights reserved. Made By Serif. Terms of use | Privacy policy
the                                                 site database change

Nobody wants to be the first to encounter all those bugs that you just know are in that new version? So, most corporations wait until the bleeding edge implementers have slogged through the upgrade until starting to plan their upgrade path. That means we have two or three versions that are considered "current" (at least by the users) in the field.   

It is quite difficult to keep up with which features are available and which are not. Version 11 is in test, but 10 is in production... well, except for that one group that is still on V9.

With all of this confusion, managing and migrating change from system to system becomes an overwhelming burden... at least without tools to assist the DBA group. This is especially so when you factor in further complications such as heterogeneity and  regulatory compliance.

And change will not slow down any time soon, so we need solutions that enable us to better manage these inevitable changes. To successfully implement an effective database change management policy you will need to consider many factors including proactive change, intelligent automation, planning and impact analysis, standardization, and availability.

Proactive change, which can eliminate future problems, can be one of the most valuable types of change. The earlier in the development cycle that required changes can be identified and implemented, the lower the overall cost of the change will be.

Automating change management processes is important, too. With limited resources and growing workloads, automation can help to reduce the amount of time, effort and human error involved in effecting database change. But simple automation is no longer sufficient. The impact of each change needs to be examined before implementation. A simple change in one area may cause a complex change in another. Intelligent automation of change management processes incorporating in-depth analysis can improve the quality of your database changes.

And speaking of analysis, an effective DBA will ensure that each change undergoes exhaustive up-front planning and analysis. Comprehensive impact and risk analysis is needed in order to gain a macro view of the change. The only way to know which change tactics are optimal is to conduct an in-depth impact analyses, and then choose the most effective, efficient, and worthwhile strategies.

Standardization is also important. With attrition, promotions and changing job roles a standardized process is needed to maintain productivity. An organized and thoroughly documented approach to completing a task reduces the learning curve, as well as training time.

Keep in mind, too that some database changes can require down time to implement. Database structures may need to be taken offline in order to effect change. But high availability is required of most applications these days, especially web-based applications. Reducing the downtime required to make a database change increases application availability. Indeed, all of the tactics discussed up to this point can help to reduce downtime when databases are being changed.

Keeping in mind everything discussed to this point, we turn our attention to the DBA. Even though the DBA is the custodian of database changes, he usually is not the one to request a change; that is typically done by the application owner or business user. There are times, too, when the DBA will request changes, for example, to address performance problems or to utilize new features or technologies. Regardless of who requests the change, the DBA is charged with carrying it out and ensuring that all changes are performed successfully and with no impact to data integrity.

Without a robust, time-tested database change procedure, the DBA will encounter difficulties. Why? Well, today’s DBMS products do not support fast and efficient database structure changes. Each DBMS provides differing levels of database change functionality. But none easily supports every type of change that might be required. One quick example: most DBMSs today do not enable a column to be added easily to the middle of an existing row. To accomplish such a task, the DBA must drop the table and recreate it with the new column added. But when the table is dropped the data is deleted, too. So the DBA must first unload the data. But what about the indexes on the table? They would have been dropped when the table was dropped, so unless the DBA knows this and recreates the indexes too, performance will suffer. The same is true for constraints, authorizations, and so on – when the table was dropped all structures related to the table were also dropped. And this is but one example of a simple change that becomes difficult to implement and manage.

And no DBMS tracks changes for compliance, manages fallback, audits, and reports on your changes, either.

Database change quickly can monopolize a DBA’s time. Preparing for change and implementing the proper tools, techniques, and procedures for database change management is one of the most important jobs undertaken by DBAs today.

                                         Craig S. Mullins, a data management strategist and researcher is
                                         president and principal consultant with Mullins Consulting, Inc.

Share your opinions and thoughts on managing database change by filling out a survey. more>

Please tell us your thoughts on how you manage database change in today’s modern environment...

How often are you managing changes in your database environment? It could be a change to a table, adding a new index, modifying security settings, or even introducing system changes. We all know that our databases are not static – far from it. They are living, breathing, changing entities.

Change is disruptive and it will be difficult to manage appropriately without a plan...

Like an iceberg, there is often more to database management needs than first meets the eye.

Database Change

A troublesome yet pervasive fact-of-life in the database industry is rapid DBMS versioning. It seems like we just start to get a handle on the latest and greatest version of our favorite DBMS and then -- wham! -- the vendor releases a new version. This is a double-edged sword because, yes, everyone clamours for new functionality, but on the other hand, you may not have even learned all of the features of the last release before the next one is upon you.