データを保存することにより、データ構造またはメタデータを変更した場合、あるいは、ある表から別の表にデータをマイグレーションした場合に、ターゲット・データベースでデータがどのように出現するのかを制御できます。
Optim™ Database
Administrator では、拡張された形での変更機能がサポートされています。
拡張変更機能は、ALTER ステートメントを使用して変更を簡単に実装することができない場合に必要になります。
拡張変更機能では、表データを保存および保持し、表をドロップしてから再作成した後、データを再ロードします。
さらに、ある表から別の表にデータをマイグレーションする場合にも、データを保存および保持する必要があります。
変更管理スクリプト・エディターで「コマンドのプレビュー」リンクをクリックすると、Optim Database
Administrator により変更のためのコマンドが生成されます。
この製品はまた、データを保存する必要があることを検出すると、アンロード・コマンドと再ロード・コマンドを自動的に生成します。
DB2® メンテナンス・コマンドも自動的に生成されます。
その後、コマンドを変更することが必要な場合、「データ・オプション」をクリックして、「データ保存のカスタマイズ」ウィザードを開始することができます。
そのウィザードでは、使用するアンロードと再ロードの方法、アンロード・コマンドと再ロード・コマンド、および生成する DB2 メンテナンス・コマンドを変更したりすることができます。
データ保存は、以下の場合に有用です。
- 表をドロップするとき
- 表をドロップする場合は、後で使用できるように、特に変更を取り消す必要があるときに備えて、その表のデータをファイルに保存する必要があります。
- 表を作成するとき
- 表を作成する場合に、別の表からその表にデータを取り込む必要がある
場合があります。「変更管理」メインメニュー項目
の下の「データのマイグレーション」操作を使用して、データを表に
マイグレーションできます。次に、変更管理スクリプト・エディターの「コマンド」セクションで「データ・オプション」をクリックすることにより、ロードするデータをカスタマイズできます。
「データ保存のカスタマイズ」ウィザードが開始します。
このウィザードでは、ある表からアンロードして新しい表にロードしたいデータをマッピングする手順が提供されます。
ヒント: ファイルから新しい表にデータを取り込む場合は、LOAD ユーティリティー
または IMPORT ユーティリティーを使用できます。「オブジェクト・リスト」で、新しい表を右クリックし、メニューから適切な操作を選択します。
- 破壊変更を実行する場合
- 変更を行う際に表をドロップしてから再作成する必要がある場合、その表のデータをアンロードしてから再ロードする必要があります。
- 表から表にデータをマイグレーションする場合
- データをマイグレーションする場合、データをソース表からアンロードしてから、そのデータをターゲット表に再ロードする必要があります。
「データ保存のカスタマイズ」ウィザードの「アンロードおよび再ロード情報」ページで、いくつかのアクションを実行することができます。
表を選択し、「照会の変更」チェック・ボックスを選択して、表に合わせてアンロード・コマンドをカスタマイズできます。
同じように、「マッピングの変更」チェック・ボックスを選択して、再ロード・コマンドをカスタマイズできます。
さらに、アンロード・コマンドおよび再ロード・コマンドのカスタマイズを支援するためのページが、ウィザードで表示されます。
ある種の変更を正しく配置するには、データ保存変更コマンドのカスタマイズが必要です。
制約事項: 変更コマンドを生成すると、データ保存のデフォルト項目が常に再生成されます。
「データ保存のカスタマイズ」ウィザードを再実行した場合、前に生成されたデータ保存コマンドがどこかで取り込まれることはありません。
アンロードおよび再ロード・コマンドの方式
Optim Database
Administrator は、データのアンロードおよび再ロードのためのいくつかの異なる方法をサポートします。
「データ保存のカスタマイズ」ウィザードの「データ・アンロードおよび再ロード情報の指定」ページで、アンロードおよび再ロード操作で使用する方法を選択およびカスタマイズできます。
次の表に示すように、選択したアンロード・コマンド方式のタイプによって、外部データ保存か内部データ保存かが決まります。
表 1. サポートされるアンロード方式とデータ保存タイプアンロード・プロバイダー |
データ保存のタイプ |
DEL データ・フォーマットの EXPORT |
外部 |
EXPORT IXF データ・フォーマット |
外部 |
高性能アンロード (DB2 HPU アンロード・コマンド) |
外部 |
内部データ保存プロバイダー |
内部 |
内部データ保存カーソル・プロバイダー |
内部 |
外部データ保存の場合、データは外部ファイルに保存されます。
データは、エクスポート・コマンドまたは DB2 HPU のどちらかを使用して、外部ファイルにアンロードされます。
データは、インポート・コマンドまたはロード・コマンドを使用して、外部ファイルから再ロードされます。
どちらのコマンドが使用されるかは、選択した再ロード・コマンド方式によって異なります。
ある表から別の表へのデータのマイグレーションを実行する場合は、データを外部ファイルに保存しなければならないため、外部データ保存を使用する必要があります。
内部データ保存の場合、データはデータベース内部に保存されます。
表が変更されると、データベース内の表が名前変更されてシャドー表が作成されます。
表が再作成された後、再作成された変更後の表にシャドー表のデータが移されます。
データの移動には、INSERT ステートメントが使用されるか、カーソルからのロードが使用されます。
どちらが使用されるかは、選択したアンロード・コマンド方式によって異なります。
デフォルトでは、シャドー表のための名前変更には接頭部「SHAD_」が使用されます。
その名前の表が既に存在する場合は、既存の表がドロップされた後でシャドー表が作成されます。
内部アンロード方式のオプションをカスタマイズすることにより、別の接頭部が使用されるよう指定したり、同じ名前の表が既に存在する場合は別の接頭部を使用してシャドー表を作成したりできます。
内部データ保存ではファイル入出力の必要がないため、外部保存よりも高速になります。
しかし、内部データ保存を使用するときは、データベース内に十分なスペースを確保しておく必要があります。
要件: 高性能アンロードをアンロード方式として指定するには、DB2 High Performance Unload (HPU) for Multiplatforms または DB2 High Performance Unload (HPU) for Workgroups をインストールする必要があります。そうでない場合、生成されたアンロード・コマンドが失敗します。
これらの製品は別価格で、別個にインストールされます。
データがトリガーを持つ表に再ロードされるとき、インポート・コマンドでデータが再ロードされる場合、または INSERT ステートメントでデータ・ファイルからデータが再ロードされる場合のみ、トリガーがアクティブになります。
ロード・ユーティリティーはトリガーに関連付けられたビジネス・ルールを実施することができないため、ロード・コマンドでデータが再ロードされる場合、またはカーソルからのロードを使用してデータ・ファイルからデータが再ロードされる場合は、トリガーはアクティブになりません。
トリガーがアクティブにならないようにする場合は、どのトリガーもデータがロードされた後に作成されるように、ロード・コマンド (またはカーソルからのロード) を使用するか、または生成された変更コマンドを変更します。
重要: トリガーがアクティブになる再ロード方式を選択した場合、変更コマンド・ファイルを確認してデータが再ロードされる順序を検証してください。
Optim Database
Administrator には、意図したとおりにトリガーがアクティブになるようにデータを自動的に再ロードする機能はありません。
データ保存の高度な手法
データ保存の高度な手法として、以下があります。
- 列のドロップ
- 生成されたアンロード・コマンドおよび再ロード・コマンドをカスタマイズすることにより、列のドロップを簡単に管理できます。ドロップされる列のデータが保存されるようにコマンドを変更することができます。また、アンロードされた列が再ロードされる列に適切にマップされるように、再ロード・コマンドをカスタマイズすることもできます。
- 非 NULL 列の追加
- デフォルト値のある列の場合、NOT NULL 列を追加するのは簡単です。
列にデフォルト値がない場合は、「データ保存のカスタマイズ」ウィザードの「アンロード・コマンドのカスタマイズ」ページで、アンロード・コマンドの SELECT 節をカスタマイズします。
- 自動キャスト機能の使用
- アンロード列と再ロード列のデータ・タイプが一致しない場合、自動キャスト機能を使用すると不一致を解決できます。
「データ保存のカスタマイズ」ウィザードの「アンロードおよび再ロード情報」ページまたは「アンロード・コマンドのカスタマイズ」ページで「自動キャスト」を選択すると、Optim Database
Administrator により、エクスポートまたはアンロード・ステートメントの SELECT 節に CAST 列関数が自動的に追加されます。
「デフォルト照会」を選択すると、デフォルトの SELECT 節に戻すことができます。
制約事項: 「自動キャスト」オプションまたは「デフォルト照会」オプションを選択すると、SELECT 文節に加えた追加の変更はすべて失われます。
サポートされる DB2 メンテナンス・コマンド
変更管理プロセス全体を通じて、特定のデータベース・パッケージが作動不能になったり、統計が不正確になったりする可能性があります。
例えば、オブジェクトのドロップ時には、DB2 によってパッケージに無効または作動不能のマークが付けられます。
再バインド・コマンドを発行し、最新の統計に基づいて、パッケージを再作成する必要があるかもしれません。
DB2 メンテナンス・コマンドには、以下のものが含まれます。
- Runstats コマンド
- データベースが変更された後、またはデータが表にロードされた後、統計を再生成することが重要です。
- Reorg コマンド
- 表に変更があったときは、すべての索引を再編成する必要があります。
また、表スペースの変更時には、すべての表と索引を再編成する必要もあります。
「データ保存のカスタマイズ」ウィザードの「メンテナンス・コマンド (Maintenance Commands)」ページで、該当オプションをクリアしない限り、モデルのフォワード・エンジニアリング時に Optim Database
Administrator によってデフォルトで REORG TABLE コマンドが発行されます。
また、Optim Database
Administrator では、表の再編成後に統計をリフレッシュするために、runstats コマンドが自動的に生成されます。
さらに、再編成後のデータの利点を活用するために、アプリケーション・パッケージをすべて再バインドする必要もあります。
reorg コマンドの効果の詳細は、「DB2 コマンド・リファレンス」を参照してください。
- 再バインド・コマンド
- 変更コマンドの中に以下の DROP ステートメントが含まれている場合、パッケージを再バインドする必要があります。
- TABLE
- TRIGGER
- MQT
- UDF
- VIEW
- ALIAS
- INDEX
- STRUCTURE TYPE
変更を複数回実行した場合も、パフォーマンスの向上のために、パッケージを再バインドしてください。
変更管理スクリプトに定義された変更から影響をうけるパッケージに対しては、Optim Database
Administrator によって再バインド・コマンドが生成されます。
- フラッシュ・パッケージ・キャッシュ・コマンド
- 統計の更新後、パッケージ・キャッシュをフラッシュすることによって、更新後の統計が動的 SQL ステートメントで使用されるようにして、パフォーマンスを高めるようにしてください。