管理の手引き
旧バージョンのデータベース・マネージャーで作成されたデータベースを正常に移行するには、
次のことを考慮する必要があります。
データベースをバージョン 7 に移行しようとするときには、
前提条件または制約事項がいくつかあるので、それについて知っておいてください。
- 移行が行えるのは、V5.x または V6 からだけです。
DB2 V1.2 パラレル・エディションからの移行はサポートされていません。
DB2 (データベース・マネージャー) のこれよりも前のバージョンは、
V5.x または V6 に移行してから V7 に移行します。
- データベースを V7 サーバーに移行するために、
V7 クライアントの移行コマンドを出すことができます。
ただし、古い DB2 クライアントの移行コマンドでは、
データベースを V7 サーバーに移行することはできません。
- 異なるプラットフォーム間での移行はサポートされません。
- ご使用のデータベース内のユーザー・オブジェクトが、
オブジェクト修飾子として V7 の予約済みスキーマ名を持つことはできません。
これらの予約済みスキーマ名には SYSCAT、SYSSTAT、および SYSFUN があります。
- データベースを移行する前に、BIGINT、REAL、DATALINK、
または REFERENCE という名前のユーザー定義の特殊タイプの名前を変更しなければなりません。
- 次のいずれかの状態のデータベースは移行することができません。
- バックアップ保留状態
- ロールフォワード保留状態
- 1 つまたは複数の表スペースが正常状態ではない
- トランザクション不整合
- 下位レベル (V5.x または V6) データベースのバックアップを復元することはできますが、
下位レベル・ログのロールフォワードはサポートされません。
データベースを移行するには、SYSADM 権限が必要です。
移行する際には新旧両方のカタログにスペースが必要です。
必要になるディスク・スペースの量は、データベースの数とサイズ、
および複雑さによって異なります。
これらのオブジェクトには、すべての表と視点が入ります。
現在データベース・カタログが占めているディスク・スペースの少なくとも 2 倍のディスク・スペースを使用可能にしておく必要があります。
ディスク・スペースが十分にないと、移行は失敗します。
SYSCAT 表スペースが SMS タイプの表スペースである場合、
ログ・ファイルに関連するデータベース構成パラメーターを更新することも考慮する必要があります。
これらのログ・ファイルのスペースが不足しないように (理由コード 3 の SQL1704N になる)、
logfilsiz、logprimary、
および logsecond の値を大きくしてください。
スペースが不足した場合は、
ログ・スペース・パラメーターを大きくして、
MIGRATE DATABASE コマンドを出し直してください。
データベースの移行を計画するときは、
2 つのバージョンの製品の非互換性の影響について考慮してください。
バージョン 7 の拡張機能を利用するためには、
データベースを移行した後で、
データベースおよびデータベース・マネージャー構成を調整する必要があります。
移行前と移行後の構成パラメーター値を記録して比較すれば、
この調整を簡単に行うことができます。
(GET DATABASE CONFIGURATION コマンドおよび GET DATABASE MANAGER CONFIGURATION コマンドについては、
コマンド解説書 を参照してください。)
次に、データベースを移行する場合に行う必要のあるステップを示します。
移行を開始するには、その前にデータベース・マネージャーを始動する必要があります。
移行の前に
注: | 移行前ステップは、以前のリリース (すなわち、新しいリリースに移行する前の、
あるいは、新しいリリースをインストールする前の現行のリリース) で行う必要があります。
|
- 移行の制約事項に関する未解決の問題がないことを確認します。
- すべてのアプリケーションおよびエンド・ユーザーを、
移行する各データベースから切断します (必要に応じて、
LIST APPLICATIONS コマンドまたは FORCE APPLICATIONS コマンドを使用してください)。
- DB2CKMIG 移行前ユーティリティーを使用して、
データベースが移行可能かどうか判別します (このユーティリティーの使用についての詳細は、
ご使用のプラットフォームに対応した概説およびインストール を参照してください)。
Windows NT または OS/2 では、
インストール時にこのツールを実行するようにプロンプトが出されますが、
UNIX ベースのシステムでは、
このツールはインスタンスの移行時に自動的に呼び出されるということに注意してください。
- データベースをバックアップします。
移行は回復不可能なプロセスです。
バージョン 6 の予約済みスキーマ名を変更する前にデータベースのバックアップを取ると、
DB2 UDB バージョン 7 を使用してデータベースを復元することができなくなります。
このデータベースを復元するには、
前のバージョンのデータベース・マネージャーを使用しなければなりません。
警告!
データベースのバックアップを取っていない場合は、
移行が失敗すると、
DB2 UDB バージョン 7 または以前のバージョンのデータベース・マネージャーを使用してデータベースを復元することができなくなります。
また、バックアップが取られた時点と、
バージョン 7 へのアップグレードが完了する時点の間に
行われたデータベース・トランザクションは、
回復不能であることも知っている必要があります。
すなわち、バージョン 7 のインストールおよび移行の完了に続く時点で、
データベースを (バージョン 7 レベルに) 復元する必要が起きた場合、
バージョン 7 のインストールよりも前に書き込まれたログはロールフォワード回復では使用できません。
移行
- 次のいずれか 1 つを使用して、データベースを移行します。
- MIGRATE DATABASE コマンド
- RESTORE DATABASE コマンド (データベースの全バックアップを復元する場合)
- sqlemgdb - データベース移行 API
OS/2 の場合:
DB2CIDMG 移行ユーティリティーは DB2 (OS/2 版) だけで使用できます。
これは、
構成 / インストール / 配布 (Configuration/Installation/Distribution (CID)) 体系環境で実行されます。
これは、
LAN ベースのワークステーションでリモートから操作員不在のインストールおよび構成を行えるようにします。
CID 移行を使用するには、ご使用の LAN に NetView DM/2 が必要です。
UNIX ベースのシステムの場合: 特定のインスタンス内のすべてのデータベースを移行しない場合の作業については、
ご使用のプラットフォームに対応した概説およびインストール に説明があります。
移行の後で
- 任意選択で、DB2UIDDL ユーティリティーを使用して、
独自のスケジュールによる固有索引の段階的な移行を容易に管理することもできます。
(バージョン 5 で作成された DB2 バージョン 5 のデータベースは、
このツールを利用して据え置き固有性検査を行う必要はありません。
これは、バージョン 5 で作成された固有索引にはすでにこれらのセマンティクスがあるためです。
ただし、それ以前のバージョンからバージョン 5 に移行されたデータベースの場合は、
DB2UIDDL ユーティリティーを使用して固有索引を変更しない限り、
これらのセマンティクスが自動的に付与されることはありません。)
このユーティリティーは、
ユーザー表に対する固有索引用に CREATE UNIQUE INDEX ステートメントを生成し、
そのステートメントをファイルに書き込みます。
このファイルを DB2 CLP コマンド・ファイルとして実行すると、
固有索引がバージョン 7 セマンティクスに変換されます。
このユーティリティーの詳細については、
概説およびインストール を参照してください。
- 任意選択で、SQL 照会のパフォーマンスに特に重大な影響を与える表に対して RUNSTATS コマンドを出すこともできます。
古い統計は移行データベースに保存されます。
この統計は、RUNSTATS コマンドを呼び出さない限り更新されません。
- 任意選択で、
DB2RBIND ユーティリティーを使用して、
すべてのパッケージの再妥当性検査を行ったり、
またはパッケージが最初に使用されるときにパッケージ再妥当性検査が暗黙で生じるようにすることもできます。
- バージョン 7 で Explain 表を使用する計画の場合は、
任意選択で Explain 表を移行することができます。
詳細については、
第 26 章, SQL Explain 機能
を参照してください。
- バージョン 7 の拡張機能を十分活用できるように、
データベースとデータベース・マネージャー構成パラメーターを調整してください。
[ ページのトップ | 前ページ | 次ページ | 目次 | 索引 ]