Database change management is the process of determining
what changes need to be made to a database, specifying those changes,
evaluating the effects of those changes, and then deploying them.
Changes to database schemas can be required for a number of reasons,
including new business requirements, mergers, legislative changes,
and application changes. Schema changes can involve changes to both logical
database objects (for example, tables, columns, primary keys,
and constraints) and to physical database objects (for example,
databases, table spaces, buffer pools, and indexes). Changing database
objects, regardless of their type, is often not a trivial operation.
Changes often impact dependent objects and sometimes even underlying
data. The process of analyzing and maintaining these dependencies
is traditionally time-consuming and prone to error.
Consider a typical database environment, like the one shown in
the following figure, in which new applications and database design
changes are initially introduced on a dedicated development system,
are then validated on a test system, and are finally deployed to the
organization's production system.
Figure 1. Typical database environment
Although the overall design of the development, test, and production
systems is typically quite similar, the business rules that govern
each system are likely to be different. The production database operates
under strict business rules and must be running 24 hours a day, 7
days a week. The test database also operates under strict business
rules to assure that what is tested will run properly in production.
However, the test database does not require the same level of availability
that the production system requires. In contrast to the production
and test systems, the development database often has fewer business
rules because developers need to constantly make changes. The process
of managing these disparate database systems often requires a DBA
to:
- Synchronize the development system or the test system to be a
point-in-time copy of the production system
- Promote (or migrate) changes from one system to another system
- Undo changes that have been made to a database environment
- Create a historical base model for future reference
- Audit changes to understand their effects
- Manage the life cycle of structural changes to databases
- Compare two sets of objects to determine how they differ
- Analyze the impact of a proposed change on a database
- Manage the deployment of changes to the target database
- Load and unload data when changes require objects to be dropped
and re-created
- Move data
- Rebind packages that have become inoperative as a result of changes
- Refresh or redefine dependent objects
Change management is often a difficult and time-consuming process
for a database administrator because it presents the following challenges:
- Failing to recognize a schema change is dangerous to system integrity.
- Finding all related schema change elements is difficult.
- Analyzing the impact of a schema change is time consuming.
- Migrating data requires thorough and extensive planning prior
to the actual migration.
- Applying changes to a database requires expert knowledge of the
database structure.
- Learning SQL syntax can be difficult.
Change management software can make the process of change management
easier because it increases reliability and reduces human error.