データベース変更管理 は、データベースに対して加える必要がある変更を判断し、変更の仕様を指定し、それらの変更による影響を評価し、変更を配置するプロセスです。
データベース・スキーマの変更が必要になる場合があります。その理由は、新しいビジネス要件、マージャー、法的変更、アプリケーションの変更など、さまざまです。スキーマ変更には、論理データベース・オブジェクト (例えば、表、列、主キー、制約など) と物理データベース・オブジェクト (例えば、データベース、表スペース、バッファー・プール、索引など) の両方に対する変更が含まれます。
データベース・オブジェクトの変更操作は、そのタイプに関わらず、多くの場合単純な操作ではありません。
変更は、しばしば従属オブジェクトに影響を与えることがあり、場合によっては基礎データにも影響を与えることがあります。
こうした依存関係を分析して保守するプロセスは、従来、時間がかかる上に間違いを犯しやすいという性質のものです。
下の図に示されているような、標準的なデータベース環境を考えてみましょう。
この環境では、最初は新しいアプリケーションとデータベース設計の変更が専用開発システムに導入されます。
次にテスト・システムでそれらの妥当性が検査され、最後に組織の実動システムに配置されます。
開発システム、テスト・システム、実動システムのそれぞれの全体設計は、通常は非常に似ていますが、各システムに適用されるビジネス・ルールは異なる場合がほとんどです。
実動データベースは厳しいビジネス・ルールの下で運用され、1 日 24 時間 週 7 日で稼働しなければなりません。
テスト・データベースもまた、テスト対象の処理が実動システムで正しく稼働することを保証する必要があるため、厳しいビジネス・ルールの下で運用されます。
しかし、テスト・データベースには、実動システムで必要とされるレベルの可用性は必要ありません。
実動システムおよびテスト・システムとは対照的に、開発データベースでは、開発者が随時変更を加える必要があるため、ビジネス・ルールの数はもっと少ないのが普通です。
こうしたそれぞれ異なるデータベース・システムを管理するプロセスでは、DBA はしばしば以下のタスクを実行する必要があります。
- 開発システムまたはテスト・システムを、実動システムのポイント・イン・タイム・コピーになるように同期させる
- あるシステムから別のシステムへ変更をプロモート (マイグレーション) する。
- データベース環境に加えられた変更を取り消す。
- 後で参照できるように、履歴基本モデルを作成する。
- 変更を監査して変更の影響を把握する。
- データベースの構造上の変更のライフ・サイクルを管理する。
- 2 つのオブジェクト・セットを比較して違いを判別する。
- 変更案のデータベースへの影響を分析する。
- ターゲット・データベースへの変更の配置を管理する。
- 変更でオブジェクトのドロップと再作成が必要になる場合にデータのロードおよびアンロードを行う。
- データを移動する。
- 変更の結果として作動不能になったパッケージを再バインドする
- 従属オブジェクトをリフレッシュまたは再定義する。
多くの場合、変更管理はデータベース管理者にとって時間のかかる難しいプロセスです。変更管理には、以下の課題があるからです。
- スキーマ変更を認識できないとシステム保全性の面で危険である。
- 関連するすべてのスキーマ変更要素を見つけるのは困難である。
- スキーマ変更の影響を分析するのは時間がかかる。
- データのマイグレーションには、実際のマイグレーションの前に綿密で広範囲に及ぶ計画が必要である。
- データベースへの変更の適用には、データベースの構造に関する専門的な知識が必要になる。
- SQL 構文を習得するのは容易ではない。
変更管理ソフトウェアを使用すると、信頼性が高まりヒューマン・エラーが減るので、変更管理のプロセスが簡単になります。