DB2 V10.1 移行手順ガイド - IBM...AIX バージョン 7.1 Technology Level (TL) 0 および Service Pack (SP) 3 - 64bitのAIX カーネルが必要 - C++ ランタイムの最小レベルでは、xlC.rte

© 2012 IBM Corporation 1

DB2 V10.1 移行手順ガイド

＜第 1.00 版 2012年8月8日＞


本資料掲載事項は、ある特定の環境・使用状況においての正確性がIBMによって確認されていますが、すべての環境において同様の結果が得られる保証

はありません。これらの技術を自身の環境に適用する際には、自己の責任において十分な検証と確認を実施いただくことをお奨めいたします。

© Copyright IBM Japan Systems Engineering Co., Ltd. 2012/ © 2012 IBM Corporation


1. はじめに 1-1. 移行に関連する情報のご紹介 1-2. アップグレード可能なサーバーとクライアント 1-3. サポートするプラットフォーム、前提

2. 移行シナリオの決定

2-1. DB2 V10.１への移行作業 2-1-1. DB2 V10.1へのアップグレードパスについて 2-1-2. DB2 V10.1 移行作業フロー

2-2. 移行シナリオの比較

3. 移行作業 3-1. DB2 V10.１のインストール 3-2. 移行作業前後のタスク

3-2-1. シナリオに共通して必要な移行前のタスク 3-2-2. シナリオに共通して必要な移行後のタスク 3-2-3. 環境によって必要となるタスク

3-3. 移行作業 3-3-1. 同一サーバ、同一インスタンスでの移行手順 3-3-2. 新規インスタンスへの移行手順（BACKUP/RESTOREを使用）

– 参考：リダイレクト・リストアについて – 参考：オンライン・バックアップ・イメージを利用した移行シナリオ

3-3-3. 新規インスタンスへの移行手順（データ移行ユーティリティを使用）

4. フォールバックのシナリオについて

5. DB2クライアントの移行

目次


1. はじめに

この資料の位置づけこの資料は ISE発行の資料「DB2 V9.5移行手順ガイド」をV10.1用に改定

したものです。 DB2 V9.7 以前のバージョンから DB2 V10.1 への移行手順を、いくつかの

シナリオを想定して記述しました。

この資料で想定する環境エディション: 単一パーティションESE プラットフォーム: AIX/Windows

DB2のサポート期間下記URLに記載されているサポート終了時期を確認して移行計画を立て

て下さい。 http://www-01.ibm.com/software/data/support/lifecycle/

http://www-01.ibm.com/software/data/support/lifecycle/




1-1. 移行に関連する情報の紹介

マニュアル/Information Center DB2 10.1 Information Center

http://pic.dhe.ibm.com/infocenter/db2luw/v10r1/index.jsp

DB2 バージョン 10.1 へのアップグレード http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.qb.upgrade.doc/doc/c0023662.html

DB2 10.1 PDFマニュアル(日本語) http://www-01.ibm.com/support/docview.wss?rs=71&uid=swg27024479#jp_main

DB2 バージョン10.1 へのアップグレード http://public.dhe.ibm.com/ps/products/db2/info/vr101/pdf/ja_JP/DB2Upgrading-db2upgj1010.pdf

DB2 Upgrade Portal (以前は「migration roadmap」と呼ばれていました) http://www-304.ibm.com/support/docview.wss?rs=71&uid=swg21200005

Upgrading to DB2 Version 10.1 roadmap http://www-304.ibm.com/support/docview.wss?uid=swg21573228

参考資料 DB2 10 for LUW Upgrade Best Practices - IDUG Webinar - Friday, June 22

http://home.ca.inter.net/~ccdb2/Downloads/CCDB2_DB210LUWUpgradeBestPractices-Melanie.pdf

その他の移行関連情報『DB2 V9.5/V9.7からV10.1へうまく移行するためのガイド』『DB2 V8からV9.5/V9.7へうまく移行するためのガイド』

http://www.ibm.com/developerworks/jp/data/library/dataserver/j_d-db2migration03/

http://pic.dhe.ibm.com/infocenter/db2luw/v10r1/index.jsp

http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.qb.upgrade.doc/doc/c0023662.html

http://www-01.ibm.com/support/docview.wss?rs=71&uid=swg27024479



http://public.dhe.ibm.com/ps/products/db2/info/vr101/pdf/ja_JP/DB2Upgrading-db2upgj1010.pdf






http://www-304.ibm.com/support/docview.wss?uid=swg21573228










1-2. アップグレード可能なサーバーとクライアント

DB2 V10.1サーバーへのアップグレード以下のバージョンのDB2サーバーから直接アップグレード可能

DB2 V9.5 DB2 V9.7 DB2 V9.8 (pureScale)

DB2 V9.1以前のサーバーからDB2 V10.1 サーバーにアップグレードする場合まず DB2 V9.5 の最新 FixPack 環境へアップグレード次に DB2 V10.1 へアップグレード

サポートするクライアント以下のDB2クライアントが、DB2 V10.1サーバーにアクセス可能

DB2 V9.1(*注1)

DB2 V9.5 DB2 V9.7 (*注1)V9.1はサポートが終了しているため延長サポートが必要です (2012/8月現在)

DB2 V10.1クライアントへのアップグレード以下のバージョンのDB2クライアントから直接アップグレード可能

DB2 V9.5 DB2 V9.7

DB2 V9.1以前のクライアントからDB2 V10.1クライアントにアップグレードする場合まず DB2 V9.5 クライアントの最新 FixPack 環境へアップグレード次に DB2 V10.1 クライアントへアップグレード


1-3. サポートするプラットフォーム、前提

インストール前提条件の確認 db2prereqcheck コマンドを使用して、システムがインストール前提条件を

満たしているかどうかを検査可能サポートプラットフォームの前提条件

OS ハードウェア

AIX AIX バージョン 6.1 Technology Level (TL) 6 およびService Pack (SP) 5 AIX バージョン 7.1 Technology Level (TL) 0 および Service Pack (SP) 3 - 64bitのAIX カーネルが必要 - C++ ランタイムの最小レベルでは、xlC.rte 11.1.0.1 および xlC AIX rte 11.1.0.1 (以降) のファイル・セットが必要 ※ DB2 V10.1では AIX5.3 はサポートされません。

64 ビットのコモン・ハードウェア・リファレンス・プラットフォーム (CHRP) アーキテクチャー (POWER3 プロセッサー・ベースのシステム以外) サポートされている AIX オペレーティング・システムを実行できるすべてのプロセッサー

HP-UX HP-UX 11iv3 (11.31) (以下が付属): PHSS_37202 / PHKL_41481 / PHKL_42035 / PHKL_42335 / PHKL_41588 / PHSS_41496 HP-UX 11iv4 ※ DB2 V10.1では HP-UX 11iv2 はサポートされません。また32bitクライアントもサポートされません。

Itanium ベースの HP Integrity Series システム互換性があると明記されていて、指定のオペレーティング・システム、すべての対応するサポート対象ソフトウェア、および変更されていない関連アプリケーションを十分に実行できるハードウェア。



サポートプラットフォーム (続き)


Linux Red Hat Enterprise Linux (RHEL) 5 Update 6 Red Hat Enterprise Linux (RHEL) 6 SUSE Linux Enterprise Server (SLES) 10 Service Pack 3 SUSE Linux Enterprise Server (SLES) 11 Service Pack 1 Ubuntu 10.04 ※ DB2 V10.1 では Ubuntu 8.0.4.x はサポートされません。

x86 (Intel Pentium、Intel Xeon、および AMD) の 32 ビット Intel および AMD プロセッサー x64 (64 ビットの AMD64 および Intel EM64T プロセッサー) POWER® (Linux をサポートする System i®、System p®、および POWER Systems) System z®: System z196、 System z10®、または System z9®

Solaris Solaris 10 64 ビット・カーネル Update 9 ※ DB2 V10.1 では Solaris 9 はサポートされません。

UltraSPARC または SPARC64 プロセッサー Solaris x64 (Intel 64 または AMD64)



サポートプラットフォーム (続き)


Windows クライアント

Windows XP Professional / Enterprise / Ultimate (32bitおよび64bit) Service Pack 3 以降 Windows Vista Business / Enterprise / Ultimate (32bitおよび64bit) Service Pack 2 Windows 7 Professional / Enterprise / Ultimate (32bitおよび64bit) Service Pack 1

サポートされている Windows オペレーティング・システムを実行できる Intel および AMD のすべてのプロセッサー

Windows サーバー

Windows 2003 Datacenter Edition / Enterprise Edition / Standard Edition (32bitおよび64bit) Service Pack 2 以降 Windows 2003 R2 Datacenter Edition / Enterprise Edition / Standard Edition (32bitおよび64bit) Service Pack 2 以降 Windows Server 2008 Datacenter Edition / Enterprise Edition / Standard Edition (32bitおよび64bit) Service Pack 2 以降 Windows Server 2008 R2 Datacenter Edition / Enterprise Edition / Standard Edition (32bitおよび64bit) Service Pack 2 以降

サポートされている Windows オペレーティング・システムを実行できる Intel および AMD のすべてのプロセッサー


最新情報は以下のInformation Centerで確認 [32 ビットと 64 ビットの DB2 サーバーのサポートの変更点]


[組み込み SQL アプリケーションの 32 ビットと 64 ビットのサポート] http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.

apdv.embed.doc/doc/c0020913.html

前提ソフトウェアについて以下のURLで前提ソフトウェアを公開

http://www.ibm.com/software/data/db2/udb/sysreqs.html




http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.apdv.embed.doc/doc/c0020913.html

http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.apdv.embed.doc/doc/c0020913.html

http://www.ibm.com/software/data/db2/udb/sysreqs.html


２. 移行シナリオの決定

移行元および移行先の環境に応じて移行シナリオを検討し、決定します。検討する項目には、以下が含まれます。

現行のバージョンサーバーのリプレイスの有無移行作業として確保できる時間データベースのサイズ等

目次

2-1. DB2 V10.１への移行作業 2-1-1. DB2 V10.1へのアップグレードパスについて 2-1-2. DB2 V10.1 移行作業フロー 2-2. 移行シナリオの比較


2-1. DB2 V10.１への移行作業

アップグレードパスと今回想定する手順についてアップグレードパスは単一・複数パーティション、pureScale featuresの有無によっ

て異なる(詳細は2-1-1を参照) 今回は単一パーティション ESEでの移行手順を想定する


2-1-1. DB2 V10.1へのアップグレードパスについて

アップグレードのパスに関するサマリーは以下の通り本資料では単一パーティションESEから単一パーティションESEへの移行を想定その他のアップグレードパスについては、以下の情報を参照

V10.1 単一パーティション ESE

V10.1 複数パーティション (DPF)

DB2 pureScale® Feature を使用した

V10.1

V9.5 またはV9.7 単一パーティション ESE

ありありあり

V9.5 または V9.7 複数パーティション (DPF)

あり。インスタンスを

V10.1 をアップグレードする前、またはアップグレードした後に、1 つを除くすべてのパーティションをドロップ。

ありあり。V10.1 複数パーティション ESE から DB2 pureScale インスタンスへのインスタンスのアップグレードはブロックされる。インスタンスとデータベースをV10.1 にアップグレードする前、またはアップグレードした後に、データを単一パーティションに統合し、その単一パーティション ESE

インスタンスを DB2 pureScale インスタンスに変換してください。

DB2 pureScale Feature

を使用した V9.8

なしなしあり。DB2 バージョン 9.8 インスタンスのアップグレードの説明に従ってください

http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.qb.upgrade.doc/doc/t0060164.html







EXPORT/LOADを使用

（ケース３）

同一インスタンスで移行

（ケース１）

BACKUP/RESTORE

を使用（ケース２）

2-1-2. DB2 V10.1への移行作業フロー

2章移行シナリオの決定

3-1章 DB2 V10.1のインストール

3-2-1章移行前タスクの実施

3-3-1章インスタン

スの移行(db2iupgrade)

3-3-2章インスタンスの作成(db2icrt)


3-3-3章データベース作成(create db)

3-3-3章オブジェクト作成

3-3-1章データベースの移行(upgrade db)

3-3-2章 DBバックアップ取得(backup db)

3-3-3章移行データの抽出(EXPORTコマンド)

3-3-3章移行データの投入(LOADコマンド)

3-3-2章 DBのリストア(restore db)

3-2-2章移行後タスクの実施


解説： DB2 V10.1への移行作業フロー

移行作業のフローについて採用する移行シナリオによって、移行のために必要となる手順は異なります。採用

される移行シナリオに応じて必要な作業を確認し、移行計画を立案してください。上記のスライドでは、各シナリオ毎の大まかな作業の単位を表しています。

このガイドの構成についてこのガイドでは、上記スライドの作業単位に対応して、各種作業の詳細を記述いた

します。移行シナリオに応じて、必要な部分を抜粋して参照してください。


ケース1 ケース2 ケース3

概要同一インスタンス上で、インスタンス/DBの移行を実施

同一サーバ上にDB2 V10.1新規インスタンスを作成し、移行を実施

新規サーバにDB V10.1新規インスタンスを作成し、移行を実施

移行先サーバー移行元と同一移行元と同一新規マシン

移行先インスタンス移行元と同一新規インスタンス新規インスタンス

移行に使用するツール

db2iupgrade/upgrade db BACKUP/RESTORE or EXPORT/LOAD

BACKUP/RESTORE or EXPORT/LOAD

備考移行に必要なDISK領域が最小 V9.5以降からの移行で選択可能フォールバック時にインスタンスの再作成および、DBリストアが必須

DB2 V9.1以前からの移行が可能（EXPORT/LOADを使用）新旧DB分のDISK領域が必要移行前インスタンス/DBの温存が可能（Windowsの場合、V8以降）

新規マシンに移行する際に使用

db2iupgrade

upgrade DB

2-2. 移行シナリオの比較

BACKUP or

EXPORT

DB2V9.5,9.7 => DB2 V10.1 移行元DB2 DB2V10.1

RESTORE or

LOAD

BACKUP or

EXPORT

移行元DB2 DB2V10.1

RESTORE or

LOAD

DBサーバ DBサーバ DBサーバ（旧） DBサーバ（新）


解説：移行シナリオの比較

BACKUP/RESTOREを使用した移行とデータ移動ユーティリティによる移行の比較 BACKUP/RESTOREによる移行と、データ移動ユーティリティによる移行を比較した場合、両者で最

も異なるのは、「データベース全体の移行処理を行うかどうか」です。 BACKUP/RESTOREを使用してデータベースの移行を行う場合、データベース全体に対して一括し

た移行処理が実施できるため、オブジェクトの種類/数にかかわらず一定の手順で移行が可能です。ただし、下記の条件では、BACKUP/RESTOREによる移行ができないため、データ移動ユーティリ

ティを使用してください。 WindowsからUNIX/Linux等、異なるプラットフォーム間での移行を行う場合。

メリットデメリット

BACKUP/RESTOREを使用オブジェクトの種類/数にかかわらず一定の手順で移行が可能

バックアップファイルは一括して取得する必要があるため、一括して取得するDISK領域を確保できない場合、移行手順の構築が難しい移行の際、SMS->DMSの変更はできない

データ移動ユーティリティを使用異なるプラットフォーム間での移行が可能表単位の移行なので、表スペースへの表の配置等、物理設計が柔軟に見直し可能。テーブル毎にEXPORTするため、全データを一括して抽出/保持するDISK領域がない場合でも移行可能。

移行するオブジェクトを手動で作成する必要がある。オブジェクトの種類/数が多い場合に手順が煩雑となる。

移行方法によるメリット、デメリット


３. 移行作業

決定した移行シナリオに応じて必要な作業を実施します。ケース１：同一インスタンスで移行ケース２： BACKUP/RESTOREを使用ケース３： EXPORT/LOADを使用

目次

3-1 DB2 V10.1のインストール 3-2. 移行作業前後のタスク 3-2-1. シナリオに共通して必要な移行前のタスク 3-2-2. シナリオに共通して必要な移行後のタスク 3-2-3. その他環境によって必要となるタスク 3-3-1. 同一インスタンスでの移行 3-3-2. BACKUP/RESTOREを使用した移行手順 3-3-3. データ移動ユーティリティによる移行



（ケース３）


（ケース１）

BACKUP/RESTORE


3-1. DB2 V10.1のインストール

















3-1. DB2 V10.1のインストール

インストールの変更点・注意事項インストール方式の変更点日本語パッケージの導入について DB2製品の複数パスへの導入についてライセンス登録について

インストール手順前提条件の確認インストール方式の選定インストールの実行

db2setupの場合 db2_installの場合（Windows以外）


3-1. インストールの変更点、注意事項１

インストール方式の変更点 db2_installコマンドは推奨されておらず、将来のリリースで削除される予

定です。

以下のインストール方式にてインストールを行います。 db2setup

– JAVAプログラムによるGUIツール GUIツールのため、UNIX/LinuxではXサーバが必要

– インストールする機能の詳細な選択、ユーザー及びグループの作成、インスタンスの作成と構成が可能

db2_install （Windows以外、※非推奨、将来のリリースで削除） – スクリプトによる対話形式でのインストール（GUIが必要なし） – インストールする機能の選択や、ユーザー及びグループの作成、インスタンスの作

成/構成はできない。 – インストール・パス及び、インストールする製品の選択は可能

応答ファイルによるインストール – セットアップ設定、構成値を格納したファイルを元にサイレント・インストールが可能

手動インストール（非推奨）

– tarファイルの手動解凍によるインストール


解説：インストール方式の変更点

インストール・ツールのサポート

インストール方式 Windows LinuxおよびUNIX

db2setup ありあり

db2_install なしあり

応答ファイルありあり

手動インストール (tarファイルの解凍)

なしあり

参照先 DB2 Information Center：DB2のインストール方式

http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.qb.server.doc/doc/c0008711.html



3-1. インストールの変更点、注意事項２

日本語メッセージの導入について DB2 V9.5以降では、DB2製品と日本語メッセージは同じCDメディアに格納

されています。 National Language Pack(以下、NLPack)の導入は必要ありません。

Fix packについては、Windows以外のプラットフォームでは、NLPackは別に提供され

ています。

参考 DB2 V9.1では、Windows以外のプラットフォームでは、DB2製品と日本語メッセージ

は別のCDメディアに格納されます。 – 日本語メッセージの表示のためにはNLPackの導入が必要です。

National Language Packの導入方法

[DB2製品と同時に導入する場合] db2setup/db2_install/応答ファイルのいずれでも使用可能です。

それぞれのオプションは「解説」を参照してください。

[すでに導入されているDB2製品に追加で導入する場合] db2_installスクリプトは使用できません。

db2setup/応答ファイルのどちらかを使用してください


解説：日本語メッセージの導入について

日本語メッセージを導入する場合 db2setupの場合

「インストールタイプ：カスタム」を選択し、「インストールする言語の選択」で「日本語」を選択する。

db2_installの場合「-L JP」キーワードで、日本語の導入を指定する。

応答ファイルによるインストールの場合応答ファイル中の「LANG」キーワードにJPを指定する。

日本語メッセージが導入されたことを確認する方法(AIX) 日本語メッセージが導入されたことを確認するコマンドの実行例

上記の例で指定したパラメーターの意味について –「-q 」：インストール済みのDB2製品およびフィーチャーをリストする –「-b /opt/IBM/db2/V10.1」：インストール先を指定 –「-a」：可視のフィーチャーだけでなく、非表示のコンポーネントもすべてリストする

# /opt/IBM/db2/V10.1/install/db2ls -q -b /opt/IBM/db2/V10.1 -a | grep Messages

DB2_PRODUCT_MESSAGES_EN 10.1.0.0 0 Product Messages - English

DB2_PRODUCT_MESSAGES_JP 10.1.0.0 0 Product Messages - Japanese


3-1. インストールの変更点、注意事項３

DB2製品の複数パスへの導入について V9.1からは全てのプラットフォームで、同一サーバ上の複数のパスへの

導入が可能になりました。これまで通り、1導入パスに対して複数インスタンスを作成可能。なおかつ、同一サーバに複数のインストールが可能。

それに伴い、任意のパスへインストール可能となっています。 32bit版と64bit版のDB2製品コードは、同一サーバ上で共存することはで

きません。 32bit版の製品コードが導入されているサーバへ、64bit版の製品コードを導入した

場合、32bit版の製品コードはアンインストールされ、インスタンスは64bit版へ移行されます。


3-1. インストールの変更点、注意事項４

ライセンスの登録についてライセンスファイルについて

DB2 V10.1では、ライセンスファイルは「Activation CD」と書かれた独立したCDメディアで提供されます。

上記CD内の「<Mount Point>/db2/license/」にある、「db2xxx.lic」がライセンスファイルです。

ライセンス登録の方法 db2licmを使用したライセンスファイル登録コマンド >db2licm –a <ライセンスファイルの格納パス>/db2xxx.lic

DB2 V10.1では、導入パスごとにライセンス情報が独立しています。複数のパスにDB2製品を導入した場合、それぞれの導入パスごとにライセンス

登録のオペレーションが必要です。


3-1. インストール作業の流れ

インストールイメージを導入先に展開

インストールの実行

ライセンス情報の登録

前提条件の確認


3-1. インストール：前提条件の確認






3-1. インストール：前提条件の確認

下記のURLよりDB2 V10.1の前提条件を確認 http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.lu

w.qb.server.doc/doc/r0025127.html

db2prereqcheckコマンドで前提条件を満たしているかを確認 db2prereqcheck コマンドを使用することで、特定のDB2バージョンのインストールを開

始しなくても、システムが DB2インストール前提条件を満たしているかどうかを判別できます。

オペレーティング・システム・レベル、Linux ディストリビューション、AIX® Technology Level、C ライブラリーおよびランタイム・パッチ、クライアント、uDAPL、GPL、または

DB2 pureScale® 固有の要件などの前提条件を検査します。下記のURLよりコマンドの実行方法を確認できます。


http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.qb.server.doc/doc/r0025127.html

http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.qb.server.doc/doc/r0025127.html




解説： db2prereqcheckの実行例

# ./db2prereqcheck

==========================================================================

Checking DB2 prerequisites for DB2 database version 10.1.0.0 on operating system "AIX"

Validating kernel level ...

Required minimum operating system kernel level : "6.1".

Actual operating system kernel level: "7.1".

Requirement matched.

Validating AIX technology level and service pack ...

Required minimum technology level: 0 Service pack: 3

Actual technology level: 0 Service pack: 3

Requirement matched.

Validating XL C/C++ Runtime ...

Required minimum XL C/C++ Runtime level: 11.1.0.1

Actual version: 11.1.0.1 Requirement matched.

DBT3533I The db2prereqcheck utility has confirmed that all installation prerequisites were met for DB2 database server . Version: "10.1.0.0".


3-1. インストール：イメージの展開

必要に応じてインストールイメージの展開を実施するダウンロードサイトで提供されているDB2 V10.1は、アーカイブされた状態

です。 AIX/Linuxの場合はtarコマンドによる展開、Windowsの場合は自己展開

ファイルの起動による展開を行う必要があります。

下記の場合はこの作業は必要ありません製品CDから直接インストールを行う場合


3-1. インストール：インストールの実行






3-1. インストール：インストールの実行

この節では、下記の２通りのインストール方法について記述します。 db2setupを使用した、Java GUIによるインストール

Windowsプラットフォームでの実行例

db2_installを使用したCUIによるインストール（UNIX/Linuxのみ) AIXプラットフォームでの実行例なおこの方法は非推奨で、将来のバージョンでは削除される可能性があります。


解説：インストールの実行 db2setup

解凍したディレクトリ配下のdb2setupを起動します。



「製品のインストール」からセットアップ・ウィザードを起動します。



「使用許諾契約」への同意を選択し、インストールタイプを選択します。ここでは「カスタム」インストールを選択します。



応答ファイルを作成するかどうかを選択し、「インストールする機能の選択」へ進みます。

ここで、インストール・フォルダを指定することも可能です。



インストールする言語を選択します。日本語メッセージの表示が必要な場合、「日本語」が選択されていること

を確認します。



IBM® Secure Shell (SSH) Server for Windowsのインストールをします。ここでは「システム始動時に IBM SSH サーバーを自動開始する」を選択し

ます。



DB2の導入パスを区別するための「DB2コピー名」を入力します。 DB2 インフォメーション・センターのロケーションとしてIBM Webサイトを指定

します。



作成するDB2インスタンスの構成を設定します。ポート番号、サービス名等が

設定可能



DASで使用するユーザー名、パスワードを入力します。「同じユーザー名とパスワードを残りのDB2サービスで使用する」にチェックを入れた場合、後

続のプロセスで作成するインスタンスオーナー等も同じユーザーで作成されます。その後の「通知のセットアップ」では「通知を送信するようにDB2サーバーをセットアップする」の

チェックを外します。



「オペレーティング・システム・セキュリティーを使用可能にする」を選択し、インストールを開始します。



セットアップの正常終了を確認し、追加のインストールの必要がなければ「完了」を選択する。



スタートメニューから「コマンドウインドウ」を起動する。 ([スタート] -> [すべてのプログラム] -> [IBM DB2] -> [DB2COPY1] -> [コマンドウィンドウ])

db2levelコマンドを実行し、DB2 10.1が正常に導入できたことを確認する。


解説：インストールの実行 db2_install

db2_installコマンドについて UNIXおよびLinuxで提供されており、CUIからDB2のインストールが可能コマンド解説書

http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/topic/com.ibm.db2.luw.admin.cmd.doc/doc/r0023669.html

ESEを導入する際の、実行コマンドの例 db2_install -b /opt/IBM/db2/V10.1_01 -p ESE -L JP

上記の例で指定したパラメータの意味について

– 「-b /opt/IBM/db2/V10.1」：インストール先を指定 – 「-p ESE」：インストールするDB2

製品を指定（例ではESE） – 「-L JP」：日本語パッケージの

導入を指定

考慮点 db2_installを使用する場合、導入するコンポーネントの選択ができません。

– 応答ファイル使用時の、「INSTALL_TYPE=COMPLETE」オプションに相当します。 – そのため、db2setup使用時にはデフォルトでは選択されないコンポーネントも含めて、インストール・イメージにあ

る全てのコンポーネントが導入されます。

db2setupではオプションだが、db2_installでは導入されるオプション（下記のコンポーネントが導入されることによる弊害は、とくにありません）

– Informix データ・ソース・サポート – コントロール・サーバー – 等

CUIからの導入を行い、かつ導入するコンポーネントを選択したい場合は、応答ファイルによる導入を選択してください。



解説：インストールの実行 db2_install # ls

db2 db2_install db2ls db2setup nlpack

db2_deinstall db2ckupgrade db2prereqcheck installFixPack

# ./db2_install -b /opt/IBM/db2/V10.1 -p ESE -l /work/db2/db2_install.log -f NOTSAMP -t /work/db2/db2_install.trc -L JP

DBI1324W db2_install コマンドのサポートは推奨されていませ

ん。詳しくは、DB2 インフォメーション・センターを参照してください。

DB2 インストールを初期化しています。

実行されるタスクの合計数: 46

実行される全タスクの合計見積もり時間: 2241 秒

タスク #1 を開始します。

説明: ご使用条件受諾のチェック

見積もり時間 1 秒

タスク #1 が終了しました。

タスク #2 を開始します。

説明: root 特権を使用したインストールのための基本クライアント・サポート

見積もり時間 4 秒

タスク #2 が終了しました。

(中略)

正常に実行が完了しました。

詳しくは、「/work/db2/db2_install.log」にある DB2

インストール・ログを参照してください。


解説：インストールの実行 db2_install

# cd /opt/IBM/db2/V10.1

# ls

.licbkup adsm das function include32 lib32 misc security32

.metadata bin dasfcn gse infopop lib64 msg security64

Readme bnd db2tss gskit install license properties tivready

acs cfg doc ha instance logs rdf tools

adm conv dsdriver include java map samples

# cd /opt/IBM/db2/V10.1/install

# ./db2ls

インストール・パスレベルフィックスパック特別なインストール番号インストール日付インストーラー UID

---------------------------------------------------------------------------------------------------------------------

/opt/IBM/db2/V10.1 10.1.0.0 0 Fri Jun 15 15:05:16 2012 JST 0>

# ./db2ls -q -b /opt/IBM/db2/V10.1

インストール・パス : /opt/IBM/db2/V10.1

フィーチャーの応答ファイル ID レベルフィックスパックフィーチャーの説明

---------------------------------------------------------------------------------------------------------------------

BASE_CLIENT 10.1.0.0 0 Base client support

JAVA_SUPPORT 10.1.0.0 0 Java support

SQL_PROCEDURES 10.1.0.0 0 SQL procedures

BASE_DB2_ENGINE 10.1.0.0 0 Base server support

CONNECT_SUPPORT 10.1.0.0 0 Connect support

DB2_DATA_SOURCE_SUPPORT 10.1.0.0 0 DB2 data source support

＜以下略＞

「-q -b」オプションで、指定したインストール・パスに導入されているコンポーネントを確認可能


3-1. インストール：ライセンス情報の登録






3-1. ライセンス情報の登録

ライセンス情報の登録 (※3-3-1, 3-3-2, 3-3-3のインスタンスの作成もしくは移行後に行います)

ダウンロードで入手したDB2製品を使用して、ライセンス情報の登録を行う場合を想定して記述します。（CDから登録する場合は、Activation CDの「/db2/license」を参照してください）

ダウンロード用に提供されているActivation CDのイメージは、ZIP圧縮されています。サーバ上にunzip用のツールが導入されていない場合は、PC上で展開した上でライセンスファイル（db2xxxx.lic）のみをサーバに転送してください。

$ db2licm -l

製品名: "DB2 Enterprise Server Edition"

ライセンス・タイプ: "ライセンス登録なし"

有効期限: "ライセンス登録なし"

製品 ID: "db2ese"

バージョン情報: "10.1"

$ db2licm -a db2ese_c.lic

LIC1402I ライセンスが正常に追加されました。

LIC1426I この製品は現在、ご使用条件の指定に基づいてご使用いただくことができます。この製品をご使用いただく

には、次のディレクトリーにある IBM ご使用条件への同意が必要です: “/opt/IBM/db2/V10.1/license/ja_JP.sjis”

$ db2licm -l

製品名: "DB2 Enterprise Server Edition"

ライセンス・タイプ: "CPU オプション"

有効期限: "永続"

製品 ID: "db2ese"

バージョン情報: "10.1"

制約ポリシー: "ソフト・ストップ"

機能:

DB2 pureCluster: "ライセンスなし"



（ケース３）


（ケース１）

BACKUP/RESTORE


3-2. 移行作業前後のタスク

















3-2. 移行作業前後のタスク

3-2章では、移行作業の前後に必要なタスクを抜き出して記述します。 3-2-1. シナリオに共通して必要な移行前のタスク

DB2 V10.1 以降でサポートされなくなった機能の確認と、必要に応じた変更移行前の情報を保管する

– 構成パラメーター等、各種構成情報 – 移行前のパフォーマンス情報、EXPLAIN情報 – 移行前バックアップ

移行時のエラー情報および診断情報収集の準備テスト環境での移行

3-2-2. シナリオに共通して必要な移行後のタスク移行の残作業移行に伴う変更のチェックその他の作業

3-2-3. その他環境によって必要となるタスク Qレプリケーション環境の移行 MSCS環境の移行 HADR環境の移行



（ケース３）


（ケース１）

BACKUP/RESTORE


3-2-1. シナリオに共通して必要な移行前のタスク

















3-2-1. シナリオに共通して必要な移行前のタスク

DB2 V10.1への移行前に行うべき作業は下記のように分類されます。移行シナリオにかかわらず、共通で行うべきタスク

DB2 10以降でサポートされなくなった機能の確認と、必要に応じた変更移行前の情報を保管する

– 構成パラメーター等、各種構成情報 – 移行前のパフォーマンス情報、EXPLAIN情報 – 移行前バックアップ

フォールバック計画の検討移行時のエラー情報および診断情報収集の準備テスト環境での移行

UPGRADE DBやBACKUP/RESTOREを使用する際のタスク（3-3-1を参照） DB2インスタンスの、32bitから64bitへの移行（UPGRADE DBコマンドを使用する場合）移行処理のため、表スペース、ログファイルのサイズを一時的に拡張する upgrade処理の制約事項が該当しないことを確認データベースが移行できる状態にあることの確認（db2ckupgrade)

データ移動ユーティリティを使用して移行する際のタスク（3-3-3を参照）オブジェクトのDDLを現行データベースから取得移行先データベースに、オブジェクトを事前作成

この章では、「移行シナリオにかかわらず共通で行うべきタスク」について記述します。

シナリオ固有のタスクに関しては、各シナリオの章（3-3）を参照してください。


3-2-1. 移行シナリオに共通の作業

DB2 V10.1以降でサポートされなくなった機能の確認と、必要に応じた変更『DB2 V9.5/9.7からV10.1へうまく移行するためのガイド』を確認し、DB2 V10.1以降でサポー

トされなくなった機能、非推奨となった機能を使用していないことを確認します。特に、下記の点には注意してください。

タイプ 1 索引は DB2V9.7 で廃止されました。DB2 V9.5 から DB2 V10.1にアップグレードする場合はアップグレード前に、既存のタイプ 1 索引をタイプ 2 索引に変換してください。

移行前の情報を保管する構成パラメーター等、各種構成情報

移行前の構成を保管するために、db2supportコマンドを実行してください。 db2supportコマンドは、DB2の構成に関する下記の情報を一括して取得します。

– データベース・マネージャー構成パラメーター – データベース構成パラメーター – DB2レジストリー変数 – システムカタログ表のEXPORTデータ（「-cl 0」オプション使用時） – 統計情報等、オプティマイザーの動作に関する情報（「-cl 0」オプション使用時） – その他DB2システムに関する各種情報

実行コマンド例 >db2support <出力パス> –d <DB名> -cl 0


3-2-1. 移行シナリオに共通の作業（続き）

移行前の情報を保管する（続き）移行前のパフォーマンス情報、EXPLAIN情報

パフォーマンスが重要なアプリケーションに関しては、事前にパフォーマンス情報やアクセスパスの情報を取得し、移行後の環境と比較することをお勧めします。

db2batchを使用した、パフォーマンス情報の取得 – パフォーマンス情報としては、通常は業務で使用されているバッチ処理やオンライン処理の

処理時間が使用されますが、db2batchコマンドを使用してSQL単体でのベンチマーク情報を事前に取得しておくことも可能です。

– 実行コマンド例 >db2batch -d <DB名> -f <SQL格納ファイル> -r <出力ファイル> -o r 10 p 5 e yes * 「r 10」：出力ファイルに結果セットを何行出力するか。この例では10行出力する。 * 「p 5」：出力するパフォーマンス情報のレベルを指定する。「p 5」の場合、各種スナップショットまで出力する。 * 「e yes」：SQL実行と同時にEXPLAIN情報をEXPLAIN表へ書き込む

EXPLAIN情報の取得 – 移行前の処理時間とともに、どのようなアクセスパスを使用していたかという情報は、DB処

理のパフォーマンスに関する問題判別を行う上で非常に重要です。可能な限り、移行前のEXPLAIN情報を取得するよう計画してください。

– 実行コマンドの例は、次ページの解説を参照してください。

移行前バックアップ DB2 V10.1への移行を行った後に、移行前のバージョンへ逆移行する方法は提供されてい

ません。そのため、フォールバック計画の策定とともに、移行前バックアップをどの時点で取得しておくかを計画に含めてください。


解説： EXPLAIN情報の取得

EXPLAIN情報取得の流れ EXPLAIN表を作成する

EXPLAIN表が存在しない場合、下記のコマンドによりEXPLAIN表を作成してください。

>db2 –tvf ~/sqllib/misc/EXPLAIN.DDL *デフォルトではテーブルスペースの指定はされていません、必要に応じてDDLを修正してください。

EXPLAIN情報の収集静的SQLの場合は、バインド時にEXPLAINオプションを指定して収集します。

> bind program1.bnd blocking all grant public explain all – バインド時にEXPLAIN情報を収集していなかった場合、db2explnツールからEXPLAIN情報を収

集することも可能です。

動的SQLの場合は、SET CURRENT EXPLAIN MODEステートメントを実行後にSQLを実行します。

コマンドの実行例 – db2 set current explain mode explain – db2 –tvf <SQL格納ファイル> – db2exfmt –d <DB名> -1



テスト環境での移行本番環境での実移行を行う前に、必ずテスト環境での試行を実施してください。

テスト環境での試行を行うことにより、

移行手順に含まれる問題の発見 V10.1での変更点がもたらす影響を事前に評価アプリケーションに移行後の環境を提供し、移行の影響をテスト移行作業に要する時間見積もりの精密化

等、複数のメリットを得ることが可能です。 DB2 V10.1およびDB2 V9.5、DB2 V9 は同一サーバ上での共存が可能です。

独立したテスト環境を用意することが難しい場合でも、他のバージョンが稼働する環境に事前にインストールし、稼働環境の縮小版を構築することで、テスト環境の構築が可能です。

ただし、DB2 V10.1の前提条件を満たすために、OSへのFix適用等が必要となる場合がありますので注意してください。



移行時のエラー情報および診断情報収集の準備移行時にエラーが発生した場合に、エラーについてのより詳細な情報を取得するため、

診断エラーログ（db2diag.log）及び、管理通知ログ（<INSTANCE名>.nfy）の取得レベルを4に設定することをお勧めします。

設定方法診断エラーログ >db2 update dbm cfg using diaglevel <レベル>

管理通知ログ >db2 update dbm cfg using notifylevel <レベル>

$ db2 get dbm cfg |grep LEVEL

Diagnostic error capture level (DIAGLEVEL) = 3

Notify Level (NOTIFYLEVEL) = 3

$ db2 update dbm cfg using diaglevel 4

DB20000I The UPDATE DATABASE MANAGER CONFIGURATION command completed

successfully.

$ db2 update dbm cfg using notifylevel 4

DB20000I The UPDATE DATABASE MANAGER CONFIGURATION command completed

successfully.

$ db2 get dbm cfg |grep LEVEL

Diagnostic error capture level (DIAGLEVEL) = 4

Notify Level (NOTIFYLEVEL) = 4



（ケース３）


（ケース１）

BACKUP/RESTORE


3-2-2. シナリオに共通して必要な移行後のタスク

















3-2-2. シナリオに共通して必要な移行後のタスク

シナリオ毎の移行作業後に必要となるタスクには、下記があります。すべてのタスクが必要とは限らないため、移行する環境に必要な作業を選定して実施してください。

移行の残作業アダプティブ圧縮設定の調整一時的に拡張したログ領域、カタログ表領域を縮小データベースをアクティブにしてステータスを確認移行後のアプリケーションのパフォーマンスを確認 EXPLAIN表の移行 HADRの再開パッケージの再バインド USEREXITの再作成もしくは移行

移行に伴う変更のチェック変更、追加されたレジストリー変数、構成パラメータを確認グローバル・プロファイル・レジストリー変数の移行

その他の作業統計情報の更新イベント・モニター表の移行以前のバージョンのDB2をアンインストール移行済みのルーチンより、PUBLICなEXECUTE特権を削除 LARGE DMS表スペースへの移行移行後バックアップ


3-2-2. 移行後に必要なタスク：移行の残作業

ここでは、各種シナリオによる移行を行った後に残った作業について記述します。

アダプティブ圧縮設定の調整 DB2 V10.1 より前のデータベースの、行圧縮が有効になっている既存の表をアップグレードすると、ク

ラシック行圧縮が有効になります。アダプティブ圧縮を使用する場合には、アップグレードを行った後にアダプティブ圧縮を有効にする必

要があります。手順は以下のとおりです。

ADMIN_GET_TAB_COMPRESS_INFO表関数を使用して、アダプティブ圧縮の有効性を確認します。主な戻される情報は以下のとおりです。

– ROWCOMPMODE 現在の圧縮モード。S : クラッシク行圧縮 / A : アダプティブ圧縮

– PCTPAGESSAVED_STATIC クラシック行圧縮により節約されるページのパーセンテージの見積もり

– PCTPAGESSAVED_ADAPTIVE アダプティブ圧縮により節約されるページのパーセンテージの見積もり

ALTER TABLE ステートメントに COMPRESS YES ADAPTIVE 節を指定して実行し、アダプティブ圧縮を有効に

します。既存のデータ行の変更および新規行の挿入には自動的にアダプティブ圧縮が適用されます。

REORG TABLEコマンドにRESETDICTIONARY パラメーターを指定して実行し、既存のすべての行を圧縮します。

参照 [アダプティブ圧縮設定の調整] http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.qb.upgrade.doc/doc/t0059313.

html




3-2-2. 移行後に必要なタスク：移行の残作業（続き）

一時的に拡張したログ領域、カタログ表領域を縮小 3-3-1章で、移行のための一時的なテーブルスペース領域、ログ領域の拡張をガイドしました。移行のために一時的に拡張した領域がある場合は、移行の完了後に元のサイズに戻すことが可能

です。 SMSのシステムカタログ表スペース、一時表スペースの場合

– SMSで作成している表スペースの場合は、ファイルシステムの容量を縮小してください。

実行コマンド例

DMSのシステムカタログ表スペース、一時表スペースの場合 – ALTER TABLESPACEコマンドのRESIZE/REDUCEオプションを使用して、コンテナのサイズを縮小することが可能

です。 – ただし、RAW-DMSを使用している場合は、ALTER TABLESPACEコマンドでコンテナサイズを縮小させても、OS側

から見たコンテナ領域は開放されません。

– 実行コマンド例 >db2 "alter tablespace TS1 resize ( all 1000 m )"

この例では、TS1を構成するすべてのコンテナを、それぞれ1000MBに縮小してます。

ただし、テーブルスペースのハイ・ウオーター・マークよりも小さくすることはできません。

ハイ・ウオーター・マークは、db2pdコマンドの -tablespaceオプション、または MON_GET_TABLESPACE および MON_GET_CONTAINER 表関数で確認することができます。

[root]# df -m |grep /tmp/db2

/dev/lvtmpdb2 1000.00 232.21 77% 815 2% /tmp/db2

[root]# chfs -a size=-128M /tmp/db2

ファイルシステム・サイズが 1785856 に変更されました

[root]# df -m |grep /tmp/db2

/dev/lvtmpdb2 872.00 105.23 88% 815 4% /tmp/db2

ファイルシステムが縮小されている。



一時的に拡張したログ領域、カタログ表領域を縮小（続き）ログ領域について

– ログ領域を縮小する場合は、拡張した際と同様「update db cfg」コマンドを使用して、logfilsiz、logprimary、および logsecond データベース構成パラメーターを移行前の値に再設定してください。

– 一次ログファイル数設定のコマンド例

>db2 update db cfg for <DB名> using logprimary 10

データベースをアクティブにしてステータスを確認データベースの活動化を行い、正常に活動化されるかどうかを確認します。

>db2 activate db <DB名>

DB2 9から、データベース・ディレクトリー・ファイルが変更され、自己調整メモリーなどの新しい機能のための構成情報が追加されました。このようなメモリー関連の変更点があるため、データベースの活動化後に、バッファー・プールが問題なくアクティブになるかどうかを確認してください。そのため、ACTIVATE DATABASEコマンドが成功したことを確認後に、管理通知ログを参照して下記のメッ

セージが出力されていないことを確認してください。

ADM6073W 表スペース tsname (ID tsid) は、バッファー・プール ID ondiskBP を使用するように構成されていますが、このバッファー・プールは現在アクティブ化されていません。一時的に、表スペースはバッファー・プール ID RTBP を使用します。非アクティブのバッファー・プールは、必要なメモリーが使用可能であれば、次回データベースを始動したときに使用可能になるはずです。

[db2inst3]$ db2 activate db migdb

DB20000I ACTIVATE DATABASE コマンドが正常に完了しました。



移行後のアプリケーションのパフォーマンスを確認移行前にアプリケーションのパフォーマンスや、アクセスプランを取得していた場合、同様の方法

で移行後のパフォーマンス、アクセスプランを取得し、著しい変動が無いことを確認してください。



EXPLAIN表の移行 UPGRADE処理の中では、EXPLAIN表の移行は実施されません。移行以前に取得したEXPLAIN情報を、移行後のEXPLAIN表に残しておく必要がある場合は、

db2exmigツールを使用して、EXPLAIN表の移行処理を行ってください。移行以前のEXPLAIN情報を残す必要がない場合は、EXPLAIN表をすべて削除後に、バージョン9

で提供されているDDLを利用してEXPLAIN表を再作成することも可能です。 DDLの所在 <インスタンスHOME>/sqllib/misc/EXPLAIN.DDL

$ db2exmig -d migdb -e db2inst2

DB2 Universal Database Version 10.1, 5622-044 (c) Copyright IBM Corp. 1999, 2011

Licensed Material - Program Property of IBM

IBM DATABASE 2 Explain Table Migration Tool

＜省略＞

Found all tables OK. Start migration.

Old tables renamed...begin creating new explain tables.

Creating EXPLAIN table DB2INST2.EXPLAIN_OBJECT

Creating EXPLAIN table DB2INST2.EXPLAIN_PREDICATE

Altering EXPLAIN table DB2INST2.EXPLAIN_STREAM

Creating EXPLAIN table DB2INST2.ADVISE_INDEX

begin insert into tables.

Copying to EXPLAIN table EXPLAIN_OBJECT from EMOBJ_001158746990

＜省略＞

db2exmigコマンドの使用例



HADRの再開 HADRを使用していた場合、移行直後はHADRが無効な状態になっています。3-2-3章の記述を元

に、HADRを再開してください。

パッケージの再バインドデータベースの移行直後には、ユーザー・アプリケーションおよびルーチンに関するパッケージは

すべて無効となっています。無効になったパッケージの再バインドを行う必要があります。ドロップした表、ビュー、別名、索引、トリガー、参照制約、表チェック制約などのデータベース・オブ

ジェクトに依存するパッケージも、無効な状態になります。UDF をドロップすると、パッケージは作動不能な状態になります。

明示的な再バインドを実行しなかった場合、アプリケーションから初めてパッケージが呼ばれたタイミングで、暗黙的に再バインドされます。実行中の再バインドによるオーバーヘッドを避けたい場合には、移行プロセスの完了後に REBIND コマンドか db2rbind コマンドを実行して、無効なパッケージを再バインドしてください。



パッケージの再バインド（続き）コマンドの実行例

>db2rbind <DB名> -l <ログファイル名> [all] * all オプションをつけて実行した場合、有効なパッケージも含めて、すべてのパッケージの再バインドを行います。

$ db2rbind migdb -l db2rbind.log all

データベース 'MIGDB' の再バインドが正常に行われました。

$ cat db2rbind.log

Starting time .... Wed Sep 20 20:49:16 2006

Package 'NULLID.DB2LOOK' of database 'MIGDB' succeeded to rebind. UniqueID = 72416F5356424957

Package 'NULLID.DB2MOVE' of database 'MIGDB' succeeded to rebind. UniqueID = 4342775356424957

＜省略＞

Package 'NULLID.SYSSTAT' of database 'MIGDB' succeeded to rebind. UniqueID = 5359534C564C3031

Package 'NULLID.TUPLEWRT' of database 'MIGDB' succeeded to rebind. UniqueID = 3036303632390

Succeeded to rebind = 128

Failed to rebind = 0

Ending time .... Wed Sep 20 20:49:52 2006


3-2-2. 移行後に必要なタスク：移行に伴う変更のチェック

変更、追加されたレジストリー変数、構成パラメータを確認ただし、DB2 V9.1以前のリリースからアップグレードする場合は、DB2 V9.1、V9.5で非推奨、または廃止された

レジストリー変数の除去を検討してください。

DB2 V9.1で廃止、非推奨になったレジストリーおよび構成パラメータ DB2 V9.1 で非推奨になったレジストリー変数

http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.admin.doc/doc/r0004670.htm%23r0004670__depr-rv

DB2 V9.1 で廃止されたレジストリー変数 http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.admin.doc/doc/r0004670.htm%23r0004670__disc-rv

DB2 V9.1 で非推奨になったデータベースマネージャー構成パラメータ http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.uprun.doc/doc/r0022380.htm%23r0022380__ddbm

DB2 V9.1 で非推奨および廃止になったデータベース構成パラメータ http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.uprun.doc/doc/r0022380.htm%23r0022380__ddb

DB2 V9.5で廃止、非推奨になったレジストリーおよび構成パラメータ DB2 V9.5 で非推奨になったレジストリー変数

http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=/com.ibm.db2.luw.wn.doc/doc/i0052033.html DB2 V9.5 で廃止されたレジストリー変数

http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=/com.ibm.db2.luw.wn.doc/doc/i0052379.html DB2 V9.5 で非推奨になったデータベースマネージャー構成パラメータ

http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=/com.ibm.db2.luw.qb.migration.doc/doc/r0022380.html%23r0022380__ddbm

DB2 V9.5 で非推奨および廃止になったデータベース構成パラメータ http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=/com.ibm.db2.luw.qb.migration.doc/doc/r0022380.html%23r0022380__ddb





http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.admin.doc/doc/r0004670.htm%23r0004670__disc-rv




http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.uprun.doc/doc/r0022380.htm%23r0022380__ddbm

http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.uprun.doc/doc/r0022380.htm%23r0022380__ddbm

http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.uprun.doc/doc/r0022380.htm%23r0022380__ddb

http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.uprun.doc/doc/r0022380.htm%23r0022380__ddb

http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=/com.ibm.db2.luw.wn.doc/doc/i0052033.html

http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=/com.ibm.db2.luw.wn.doc/doc/i0052379.html



http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=/com.ibm.db2.luw.qb.migration.doc/doc/r0022380.html%23r0022380__ddb

http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=/com.ibm.db2.luw.qb.migration.doc/doc/r0022380.html%23r0022380__ddb


3-2-2. 移行後に必要なタスク：移行に伴う変更のチェック

変更、追加されたレジストリー変数、構成パラメータを確認(続き) DB2 V10.1で廃止、非推奨になったレジストリーおよび構成パラメータ

DB2 V10.1 で非推奨または廃止されたレジストリー変数 http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.wn.doc/doc/i0052033.html

DB2 V10.1 で非推奨または廃止されたデータベースマネージャー構成パラメータ http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.wn.doc/doc/i0058741.html

DB2 V10.1 で非推奨または廃止されたデータベース構成パラメータ http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.wn.doc/doc/i0058741.html

http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.wn.doc/doc/i0052033.html




3-2-2. 移行後に必要なタスク：移行に伴う変更のチェック（続き）

グローバル・プロファイル・レジストリー変数の移行レジストリー変数は、「グローバル･プロファイル･レジストリー変数」として複数のインスタンス間で共通

の設定を行うことが可能です。 V9.1から、グローバル・レジストリー変数のスコープが変更されています。

V8.2まで：同一サーバ上の、同じバージョンのインスタンスすべてで共通。同一サーバに、V7とV8が共存していた場合は、 V7とV8で異なるグローバル・レジストリー変数を持つ。 V9.1から：同じ導入パスから作成されたインスタンスで共通。

グローバル・レジストリー変数はインスタンス移行の際に、移行されません。移行後のインスタンスで同じグローバル･レジストリー変数の設定が必要な場合、手動で再設定してく

ださい。実行コマンドの例

>$DB2DIR/adm/db2set <変数名>=<設定値>

[db2inst2]$ db2set -all

[i] DB2CODEPAGE=943

[db2inst2]$ su -

root のパスワード:

[root /]# cd /opt/IBM/db2/V10.1/adm

[root /opt/IBM/db2/V10.1/adm]# ls -l db2set

-r-xr-xr-x 1 bin bin 70598 Aug 14 19:18 db2set

[root /opt/IBM/db2/V10.1/adm]# ./db2set -g DB2COMM=TCPIP

[root /opt/IBM/db2/V10.1/adm]# exit

[db2inst2]$ db2set -all

[i] DB2CODEPAGE=943

[g] DB2COMM=TCPIP

新規にグローバル・レベルの変数が設定されている。

rootユーザーで実行する。


移行後に必要なタスクとして、他には下記のような作業があります。

統計情報の更新

移行作業が完了し、移行後のパフォーマンス測定の結果問題なく移行できたことが確認できた後に、DB2 V10.1での統計情報取得を計画してください。

「インスタンスの移行」や「BACKUP/RESTOREを使用した移行」を実施してデータベースを移行した場合、DB2 V9.5、V9.7で取得した統計情報はそのまま保持されます。ただし、DB2 V10.1で追加された新しい統計情報は収集されていないため、「-1」という値になります。

統計情報の収集には、表の単位でRUNSTATSコマンドを実行します。

イベント・モニター表の移行 DB2 V10.1では、以前のバージョンで作成した既存のイベント・モニター表をアップグレードできるよ

うになりました。アップグレードには EVMON_UPGRADE_TABLES プロシージャーを使用します。手動による表定義

の変更、または表の再作成は必要ありません。参照

「リリース間でのイベント・モニター・データの保持」 http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.admin.mon.doc/doc/c0059114.html

3-2-2. 移行後に必要なタスク：その他の作業

http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.admin.mon.doc/doc/c0059114.html

http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.admin.mon.doc/doc/c0059114.html


移行後に必要なタスクとして、他には下記のような作業があります。

以前のバージョンのDB2をアンインストール

同一サーバ上で移行を行い、DB2 V10.1と以前のバージョンのDB2が共存している場合は、移行タスクが完了して以前のバージョンのDB2が不要になったタイミングで、アンインストールを行ってください。

アンインストールの方法 Windowsプラットフォームの場合は「アプリケーションの追加と削除」から除去してください。 UNIX/Linuxプラットフォームで、DB2提供のツールを使用してインストールした場合、アンインストールには

製品CD上に提供されているdb2_deinstallコマンドを使用してください。 SMITのような、OSネイティブのツールを使用してインストールした場合は、アンインストールにも同じツール

を使用してください。

3-2-2. 移行後に必要なタスク：その他の作業


3-2-3. その他環境によって必要となるタスク

HADR環境の移行 HADR 環境を DB2 V10.1 にアップグレードするには、 HADR を停止して 1 次データベース

がある DB2 サーバーをアップグレードしてから HADR を再初期化する必要があります。 1 次データベースを DB2 V10.1 にアップグレードすると、データベースの役割は 1 次から標準に変更されま

す。スタンバイ・データベースの DB2 V10.1 へのアップグレードはサポートされていません。

HADRをいったん停止し、次のような手順を取る必要があります。 STOP HADRコマンドを使用して一次データベースとスタンバイ・データベースでHADRを停止一次データベース側のインスタンス、データベースをV10.1へアップグレードスタンバイ側のHADRデータベースを削除スタンバイ側のインスタンスをV10.1へ移行一次データベースのバックアップを取得し、スタンバイ側へリストアを実施(*) HADRの再設定を行い、HADR環境を再起動 (*) 一次データベースのスプリット・ミラーから、db2inidbコマンドを使用してスタンバイ・データベースを初期化す

ることも可能です。

Qレプリケーション環境の移行 Q レプリケーション環境をDB2 V10.1にアップグレードするには、DB2サーバーのコントロー

ル表がDB2 V9.7レベルであることが必要です。 DB2 V9.1、V9.5、V9.7からDB2 V10.1へのアップグレードの詳細についてはDB2 Information

Centerの以下のURLを参照してください。 [Q レプリケーションおよびイベント・パブリッシングのマイグレーション]

http://pic.dhe.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.swg.im.iis.repl.qmig.doc/topics/iiyrcmig9ovu9195.html




3-2-3. その他環境によって必要となるタスク（続き）

MSCS環境の移行 MSCS環境でDB2を使用している場合、DB2 10.1インストール中にインスタンスを移行するのではなく、別

のDB2コピーとしてインストールした後にインスタンスを移行することをお勧めします。このガイド中では、Windowsプラットフォームについても、別のDB2コピーにインストール後にインスタンス

移行を行う方法を、標準としてガイドしています。参照

Microsoft Cluster Server 環境での DB2 サーバーのアップグレード http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.qb.upgrade.doc/doc/t0022647.html




（ケース３）


（ケース１）

BACKUP/RESTORE


3-3-1. 同一インスタンスでの移行

















3-3-1. 同一インスタンスでの移行手順（ケース1）

この節では、同一サーバ上、同一インスタンスでDB2 V10.1への移行を行う際の作業の流れを説明します。

この移行シナリオの特徴 DB2 9.5/9.7の既存インスタンスをそのまま10.1へ移行する。（db2iupgradeを

使用） DBのBACKUP/RESTOREや、データ移動ユーティリティによるデータ移動が

必要ない。

DBサーバ（現行）

MIGDB

9.7/9.7インスタンス=> 10.1インスタンス


3-3-1. 同一インスタンスでの移行作業の流れ

インスタンスの移行

データベースの移行

移行後タスクの実施

共通の移行前タスクの実施

UPGRADE DBやBACKUP/RESTOREを使用する際のタスク

＊「共通の移行タスク」については、3-2章を参照してください。


3-3-1. 移行前タスク







3-3-1. UPGRADE DBやBACKUP/RESTOREを使用する際のタスク

移行処理のため、表スペース、ログファイルのサイズを一時的に拡張する DB2はupgrade処理の中で、カタログ情報やログ・ファイル・ヘッダーの書き換え等を行います。こ

の書き換え処理のため、システムカタログ表スペース、一時表スペース、アクティブ・ログ・ファイルには十分な空き容量が必要となります。

システムカタログ表スペースに必要な空き容量について SMSの場合

– SYSCATSPACEの使用ページ数（Used Pages)と同じだけの空き容量が、SYSCATSPACEの格納されているドライブ/ファイルシステムに存在することを確認してください。SYSCATSPACEのコンテナ・ファイルがどこに格納されているかは、「LIST TABLESPACE CONTAINERS」コマンドで確認が可能です。

DMSの場合 – SYSCATSPACEをDMSで作成している場合、使用ページ数（Used Pages）と同じだけの空き

容量が、SYSCATSPACEのフリーページ数（Free Pages）にあることを確認してください。空き容量が不足している場合、「Alter Tablespace」コマンドを使用して拡張します。

一時表スペースに必要な空き容量について SMS一時表スペースの場合

– SYSCATSPACEの使用ページ数（Used Pages）の2倍の空き容量が、一時表スペースを格納しているドライブ/ファイルシステムに存在することを確認してください。

DMS一時表スペースの場合 – SYSCATSPACEの使用ページ数（Used Pages）の2倍の空き容量が、一時表スペースのフ

リーページ数（Free Pages）にあることを確認してください。


解説. 表スペース、ログファイルの空き容量の確認方法について

確保するべき空き容量の確認方法 $ db2 list tablespaces show detail

Tablespace ID = 0

Name = SYSCATSPACE

Type = System managed space

Total pages = 8638

Useable pages = 8638

Used pages = 8638

Free pages = Not applicable

High water mark (pages) = Not applicable

Page size (bytes) = 4096

Tablespace ID = 1

Name = TEMPSPACE1

Type = System managed space

Total pages = 4

Useable pages = 4

Used pages = 4

Free pages = Not applicable

High water mark (pages) = Not applicable

Page size (bytes) = 4096

使用ページ数が8638ページ、

ページサイズが4096(byte)なので、

現在の使用容量は

8638 x 4096 / 1024 / 1024 = 33.7MB

SYSCATSPACEに34MB、

TEMPSPACE1に68MB

の空き容量が必要。


3-3-1. UPGRADE DBやBACKUP/RESTOREを使用する際のタスク（続き）

移行処理のため、表スペース、ログファイルのサイズを一時的に拡張する（続き）

アクティブ・ログ・ファイルについてデータベースの移行処理は1UOWで実行されます。そのため、移行処理によるすべてのトランザクションを

格納できるだけのログ容量が必要です。十分に大きなログ容量を既に確保している場合は、新たな拡張は必要ありません。デフォルトのログ容量に近いサイズで運用している場合、ログ・ファイルサイズの拡張を検討してください。

ログ・ファイルのサイズを拡張する際に使用するデータベース構成パラメーター

– LOGFILSIZ ：ログファイルのサイズを4KB単位で指定する。1000の場合、1ファイル4MB

– LOGPRIMARY ：データベースがあらかじめ割り振っておくログファイルの数 – LOGSECOND ：必要になった際に、追加で割り振ることができるログファイ

ルの最大数

データベース構成パラメーターの変更コマンド – >db2 update db cfg for <DB名> using <パラメーター名> <設定値>

使用可能な最大ログ容量を求める計算式（ LOGPRIMARY + LOGSECOND ) x LOGFILSIZ x 4096


3-3-1. UPGRADE DBやBACKUP/RESTOREを使用する際のタスク（続き）

データベースが移行できる状態にあることの確認移行前の最後のタスクとして、db2ckupgradeコマンドを実行し、データベースが問題なく移行

できる状態にあることを確認します。 db2ckupgradeコマンドは下記の項目のチェックを行います。

カタログされたデータベースが実際に存在している。データベースが不整合な状態ではない。データベースがバックアップ・ペンディング状態ではない。データベースがリストア・ペンディング状態ではない。データベースがロールフォワード・ペンディング状態ではない。表がロード・ペンディング状態ではない。表が再配分ペンディング状態ではない。 (DB2 V9.8 以降の場合) すべての表スペース・コンテナー・パスに同じマウント・ポイントを使用している。 DB2 V9.8 フィックスパック 3 以降の場合、データベースの入出力書き込み操作がサスペンドされない。また、サスペンド

中でない。システム・ビューに依存する MQT が存在しない。表スペースが正常な状態である。データベースに、名前が ARRAY、BINARY、CURSOR、DECFLOAT、ROW、VARBINARY、または XML の、ユーザー定

義タイプ (UDT) が含まれていない。データベースに、組み込みの DATALINK データ・タイプが含まれていない。データベースに、SYSPUBLIC という名前のスキーマがない。データベースに、データベース・アップグレード失敗の原因となる、システム・カタログ表内の孤立行がない。 HADR 1 次データベースとして使用可能になっているデータベースが正常に接続できる。 HADR データベースの役割がスタンバイでない。 SYSCATSPACE が DMS 表スペースであり、AUTORESIZE が使用不可の場合、SYSCATSPACE には合計ページのう

ち尐なくとも 50% の未使用ページがある。データベースが XML Extender には使用不可である。

db2ckupgradeコマンドは、インスタンスの移行処理中に暗黙的に実行されます。上記項目のチェックにパスしない場合、db2iupgradeによるインスタンスの移行処理は失敗します。


解説. db2ckupgradeコマンドの実行方法

db2ckupgradeコマンドの実行方法について db2ckupgradeコマンドは、DB2 V10.1の導入パス配下にあります。

<DB2 V10.1インストールディレクトリ>/bin

実行コマンド例 >db2ckupgrade <DB名> -l <ログファイル名>

コマンド実行後には必ずログファイルを参照し、DB2 V10.1のdb2ckupgradeコマンドが実行されたことを確認してください。

[/home/db2inst2]$ cd /opt/IBM/db2/V10.1/bin

[/opt/IBM/db2/V10.1/bin]$ ls -l db2ckupgrade

-r-xr-xr-x 1 bin bin 9716 Jul 14 04:15 db2ckupgrade

[/opt/IBM/db2/V10.1/bin]$ ./db2ckupgrade migdb -l /tmp/db2ckupgrade.log

db2ckupgrade was successful. Database(s) can be upgraded.

[/opt/IBM/db2/V10.1/bin]$ cat /tmp/db2ckupgrade.log

Version of DB2ckupgrade being run: VERSION 10.1.

DB2 V10.1のdb2ckupgradeであることが確認できる。


3-3-1. インスタンス/データベースの移行








インスタンスの移行インスタンスの移行のためには、DB2 V10.1の導入パス配下のdb2iupgradeコマンドを使用し

ます。 db2iupgradeコマンド実行

db2iupgradeコマンドは、rootユーザーもしくは管理者権限で実行します。 – インスタンスオーナーで実行するコマンドではありません。

UNIX/Linuxの場合 – > $DB2DIR/instance/db2iupgrade -u <fencedユーザーID> <インスタンス名>

Windowsの場合 – > $DB2DIR¥bin¥db2iupgrade /u:<ユーザー名>,<パスワード> <インスタンス名> – 「 /u:<ユーザー名>,<パスワード> 」は、DB2サービスを実行するユーザー名とパスワード

$DB2DIRは、DB2 V10.1の導入パスです。デフォルトの導入パスは下記の通りです。 – UNIXの場合：/opt/IBM/db2/V10.1 – Linuxの場合：/opt/ibm/db2/V10.1 – Windowsの場合：Program Files¥IBM¥sqllib_XX （XXは数字の連番）

作業の流れ UNIX/Linuxでは、/tmpに20MB以上の空き容量があることを確認 DB2の停止を行う rootユーザーもしくは管理者権限でログオンする db2iupgradeコマンドの実行インスタンス・オーナーとして再ログオン DB2の開始を行う


3-3-1. インスタンス/データベースの移行(続き)

データベースの移行インスタンスの移行を行った後、移行したインスタンス配下のデータベースをDB2 V10.1 に移行する

必要があります。

upgrade DBコマンドの実行データベースの移行はupgrade DBコマンドで行います。 $ db2 upgrade db <DB名> [ user <ユーザーID> using <パスワード> ]

– ローカルDBに対してupgrade DBコマンドを実行する場合はユーザーID/パスワードは必要ありません。

作業の流れインスタンスオーナーもしくは、SYSADM権限を持つユーザーとしてログオンする。 upgrade DBコマンドを実行する。 upgrade DBコマンドが正常に完了したことを確認する。移行後のデータベースに接続し、簡単な照会を実行します。

UPGRADEが正常に完了しない場合データベースの移行が失敗すると、エラー・メッセージ SQL1704N が失敗の原因を説明した理由コードととも

に返却されます。DB2 Information Centerの「メッセージ・リファレンス」でこの SQL エラー・コード参照してください。各理由コードに対しての対応策も上記マニュアル中に記載されています。

upgrade DB失敗の最も一般的に見られる原因としては、ログ容量の不足が挙げられます。 – この場合理由コード「３」が返却されます。対応策としては、トランザクションログの容量を拡張してください。

http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.messages.sql.doc/doc/msql01704n.html


3-3-1. インスタンス/データベースの移行(続き)

DASの移行 DASを利用してDB2サーバの管理を行っている場合、DASインスタンスもDB2 V10.1である必要があ

ります。DB2 V9.7以前のDASからDB2 V10.1のDB2サーバを管理することはできません。 Windows では、DB2 V10.1インストール中に既存のインスタンスを自動移行することが可能ですが、

それを選択した場合は、DASも同様に DB2 V10.1へ移行されます。 DB2 V8のDASで DB2 ツール・カタログを作成している場合、作成済みのスクリプト、スケジュールを

使用する場合には、DASの移行が必要です。作成済みのスクリプト等を移行する必要がない場合は、DB2 V9のDASを削除し、DB2 V10.1のDASを新規に

作成することで、dasmigrコマンドによる移行の代替とすることも可能です。

dasmigrコマンドの実行

UNIX/Linuxの場合 – > $DB2DIR/instance/dasmigr

Windowsの場合 – > $DB2DIR¥bin¥dasmigr


作業の流れ DASオーナーとしてログオンし、DASを停止する rootユーザーもしくは管理者権限でログオンする dasmigrコマンドを実行してDASを移行する。 DASオーナーとしてログオンし、DASを開始する。

※注 DASはV9.7より非推奨の機能になっています。



（ケース３）


（ケース１）

BACKUP/RESTORE


3-3-2. BACKUP/RESTOREによる移行

















3-3-2. BACKUP/RESTOREを使用した移行手順（ケース2）

この節では、BACKUP/RESTOREコマンドを使用して、同一サーバ上もしくは新規サーバ上の、新しいインスタンスへ移行する際の作業の流れを説明します。

この移行シナリオの特徴 DB2 9.5 / 9.7の既存インスタンスは保存し、新規のインスタンスへ移行する。移行にはBACKUP/RESTOREを使用する。

DBサーバ（現行） DBサーバ（同一もしくは新規）

V10.1インスタンス（新規）

MIGDB

V9.5/9.7インスタンス

MIGDB

外部モジュール等

BACKUP

イメージ

BACKUP RESTORE


3-3-2. BACKUP/RESTOREを使用する際の考慮点

V9.1以前のバックアップからの復元はできない V9.1以前のバージョンからの移行の場合は、「3-3-3. データ移動ユーティリティ

を使用した移行」の手順を使用してください。

V9.5, 9.7のバックアップをV10.1に復元後、V9.5,9.7時のログは適用できない。 V9時点のログは適用不要な状態にした上で、オフライン・バックアップを取得す

る必要があります。新規インスタンスでのログ適用を行う必要や、オンラインバックアップからの移

行をしたい場合は、この章の説明と併せて、「参考：オンライン・バックアップ・イメージからの移行」を参照してください。

異なるプラットフォーム間のリストアについて WindowsとUNIX/Linux間のリストアはできません。また、プラットフォーム・ファミリー間でのリストアもできません。

同一のプラットフォーム・ファミリーとはエンディアンの統一されたUNIX/Linuxを指します。詳細は次のDB2 Information Centerを参照してください。

– [異なるオペレーティング・システムおよびハードウェア・プラットフォーム間のバックアップおよびリストア操作] http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.admin.ha.doc/doc/c0005960.html

http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.admin.ha.doc/doc/c0005960.html

http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.admin.ha.doc/doc/c0005960.html


3-3-2. BACKUP/RESTOREを使用する際の作業の流れ

新規インスタンスの作成

BACKUP/RESTOREによるデータベースの移行




＊「移行前のタスク」については、3-2-1章を参照してください。

＊このタスクについては、3-3章を参照してください。

＊「移行後のタスク」については、3-2-2章を参照してください。


3-3-2. 新規インスタンスの作成/データベースの移行

新規インスタンスの作成

BACKUP/RESTOREによるデータベースの移行



upgrade DBやBACKUP/RESTOREを使用する際のタスク

＊「移行前のタスク」については、3-2-1章を参照してください。

＊このタスクについては、3-3章の移行前タスクを参照してください。



3-3-2. 新規インスタンスの作成

新規インスタンスの作成同一サーバ上で移行する場合も、新規サーバへ移行する場合も移行先のインスタンスの

作成が必要です。インスタンスの作成にはdb2icrtコマンドを使用します。同一サーバ上のインスタンス名はユニークである必要があるため、同一サーバ上で移行する場合は、新規

インスタンスはこれまでのインスタンスとは異なる名称で作成してください。

db2icrtコマンド実行 db2icrtコマンドは、rootユーザーもしくは管理者権限で実行します。 UNIX/Linuxの場合

– > $DB2DIR/instance/db2icrt [-p <サービス名> ] -u <fencedユーザーID> <インスタンス名> – -p ：TCP/IPによる接続を使用する場合のサービス名/ポート番号を指定 – -u ：fenced ユーザー定義関数および fenced ストアード・プロシージャーを実行するユーザー ID の名前を指定します。サーバインスタンスを作成する際は、必須オプションです。

Windowsの場合 – > $DB2DIR¥instance¥db2icrt <インスタンス名>


作業の流れインスタンス・オーナーとなるユーザーを作成する。（UNIX/Linuxの場合） rootユーザーもしくは管理者権限でログオンする。 db2icrtコマンドにてインスタンスを作成する。


3-3-2. 新規インスタンスの作成

データベース・マネージャー構成パラメーター、レジストリー変数の移行新規にインスタンスを作成した場合、データベース・マネージャー構成パラメーター及びレ

ジストリー変数はデフォルトの値となります。必要に応じて移行前環境から設定値を移行してください。

レジストリー変数レジストリー変数には、変数のスコープによって名称が違い、それぞれ設定方法が異なります。

– DB2 グローバル・レベル・プロファイル・レジストリー：該当のDB2コピー全体に対して有効

– DB2 インスタンス・レベル・プロファイル・レジストリー：該当のインスタンスのみに有効

移行前環境に設定されているすべてのレジストリー変数をリストするには、下記のコマンドを使用します。

– >db2set –all

レジストリー変数をインスタンスレベルで設定するためには、下記のコマンドを使用します。 – >db2set [-i] <変数名>=<設定値>

レジストリー変数をグローバルレベルで設定するためには、下記のコマンドを使用します。 – >$DB2DIR/adm/db2set <変数名>=<設定値> -g – グローバルレベルのレジストリー変数の設定は、rootユーザーもしくは管理者権限で実行してください。

データベース・マネージャー構成パラメーター

データベース・マネージャー構成パラメーターは、インスタンスが保持する構成パラメーターです。下記コマンドにて取得します。

– >db2 get dbm cfg

更新には、下記コマンドを使用してください。 – >db2 update dbm cfg using <変数名> <設定値>


解説：レジストリー変数の設定

[tukiv9 /home/tukiv9]$ db2set -all

[g] DB2COMM=TCPIP

[tukiv9 /home/tukiv9]$ db2set DB2_SKIPDELETED=ON


[i] DB2_SKIPDELETED=ON

[g] DB2COMM=TCPIP

[tukiv9 /home/tukiv9]$ su -

root のパスワード:

[root /]# cd /opt/IBM/db2/V10.1/adm

[root /opt/IBM/db2/V10.1/adm]# ./db2set DB2_SKIPINSERTED=ON -g

[root /opt/IBM/db2/V10.1/adm]# exit


[i] DB2_SKIPDELETED=ON

[g] DB2_SKIPINSERTED=ON

[g] DB2COMM=TCPIP

インスタンスレベルのレジストリー変数は、インスタンスオーナーから設定

グローバルレベルのレジストリー変数は、rootユーザーから設定



BACKUP/RESTOREによるデータベースの移行このシナリオでは、データベースの移行のためBACKUP/RESTOREコマンドを使用します。 BACKUP DBコマンドの実行

BACKUP DBは、移行前のデータベースが存在するV9のインスタンスにて行います。シナリオの考慮点でも記述しましたが、

– オフラインバックアップが必要であること – 移行後には、移行前のログは適用できないこと

に注意してください。 BACKUPコマンドの実行（DISK上に取得する場合） >db2 backup db <DB名> to <BACKUP先>

RESTORE DBコマンドの実行上記のBACKUP DBコマンドにて取得したバックアップ・イメージを新規のV10.1インスタンスへリストアしま

す。このガイドでは、リダイレクト・リストアを使用してリストアを行います。リストア用のコマンドは、V9からの新機能である「リダイレクト・リストア・スクリプトの生成」を使用して行いま

す。


参考：リダイレクト・リストアについて

リダイレクト・リストアは、リストアの実行オプションの一つであり、リストアを実行する際にテーブルスペース・コンテナのレイアウトを変更するために使用することができます。

リダイレクトリストアの特徴 RESTORE時に表スペースのコンテナの追加・変更・削除が可能 SMS表スペースでもコンテナを増やすことが可能 DMS表スペースのコンテナのFILE＜＝＞DEVICEの変更が可能 DMS表スペース＜＝＞SMS表スペースの変更は不可能異なるDB名としてリストアすることによって、同一インスタンス内にクローンDBを作成することが可能

移行のためにBACKUP/RESTOREを使用するシナリオでは、既存のテーブルスペース・コンテナを避けて新規の名称のコンテナにリストアするため新規サーバへ移行する際、新しいネーミング・ルールにあわせて、コンテナの命名規則を変更するため。新規サーバのDISK構成にあわせて物理設計を見直すため。

等、いろいろな状況で使用することが可能です。

コマンドの実行リダイレクトリストアは、下記の3種類のコマンドを組み合わせて実行します。

>RESTORE DATABASE <DB名> …… REDIRECT >SET TABLESPACE CONTAINERS >RESTORE DATABASE <DB名> CONTINUE


参考：リダイレクト・リストアについて（続き）

DB2 9からの新機能として、データベース・バックアップ・イメージから、リダイレクトリストアのためのスクリプトを生成することが可能となっています。

生成されたスクリプトを修正して使用することで、移行用のスクリプトを作成するワークロードを低減することが可能です。

スクリプトの生成方法スクリプトの生成にはRESTOREコマンドの「GENERATE SCRIPT」オプションを使用します。 db2 restore db <DB名> from <BACKUPディレクトリ> taken at <BACKUP取得時間>

redirect generate script <出力スクリプト名>

スクリプト生成の詳細については、下記の資料を参照してください。

「DB2 9新機能ワークショップ運用管理機能強化バックアップ・リカバリー」 – http://www.ibm.com/jp/domino01/mkt/dminfo.nsf/doc/004D44E6



RESTORE DATABASE MIGDB

-- USER <username>

-- USING '<password>'

FROM '/out0/backup'

TAKEN AT 20060919000842

-- DBPATH ON '<target-directory>'

INTO MIGDB

-- NEWLOGPATH '/home/db2inst2/db2/db2inst2/NODE0000/SQL00001/SQLOGDIR/'

-- WITH <num-buff> BUFFERS

-- BUFFER <buffer-size>

-- REPLACE HISTORY FILE

-- REPLACE EXISTING

REDIRECT

-- PARALLELISM <n>

WITHOUT ROLLING FORWARD

-- WITHOUT PROMPTING

;

作成スクリプトからの抜粋

RESTORE DB xxxxx REDIRECTのセクション RESTORE DBで指定可能なオプションがコメントアウトされて記述されている。

変更したいオプションを記述後に、コメントアウトを削除する。

＊下線部は、それぞれ新規のDBディレクトリー、アクティブログディレクトリーを指定できるキーワード



＜省略＞

-- *****************************************************************************

-- ** Tablespace name = TS1

-- ** Tablespace ID = 4

-- ** Tablespace Type = Database managed space

-- ** Tablespace Content Type = All permanent data. Regular table space.

-- ** Tablespace Page size (bytes) = 4096

-- ** Tablespace Extent size (pages) = 32

-- ** Using automatic storage = No

-- ** Auto-resize enabled = No

-- ** Total number of pages = 65536

-- ** Number of usable pages = 65504

-- ** High water mark (pages) = 62336

-- *****************************************************************************

SET TABLESPACE CONTAINERS FOR 4

-- IGNORE ROLLFORWARD CONTAINER OPERATIONS

USING (

FILE '/home/db2inst2/db2/tscont/ts1.DAT' 65536

);

作成スクリプトからの抜粋（続き）

SET TABLESPACE CONTAINERSのセクション

RESTORE DB CONTINUEのセクション

-- *****************************************************************************

-- ** start redirected restore

-- *****************************************************************************

RESTORE DATABASE MIGDB CONTINUE;

バックアップ・イメージ中に記録されたコンテナー情報が記述されているため、リストア先DB環境でのコンテナー情報（名称、サイズ、数等）で書き換える。

スクリプトの最後で、RESTORE

CONTINUEを発行するセクション


参考：オンライン・バックアップ・イメージからの移行

オンライン・バックアップ・イメージからの移行 BACKUP/RESTOREを使用した移行を行う場合、オフライン・バックアップにより取得し

たバックアップ・イメージが必要です。可用性要件から、オフライン・バックアップの取得が困難なシステムも想定されるため、

派生シナリオとして、オンライン・バックアップで取得したバックアップ・イメージからの移行手順に言及します。

この移行シナリオの特徴オンライン・バックアップのイメージを使用して移行が可能となるため、本番環境でオフ

ライン・バックアップを取得する必要がない。いったんV9.5インスタンスへとリストアを行った後で、DB2 V10.1のインスタンス移行を

行うため、移行先サーバにV9.5の製品コードが必要。 BACKUP/RESTOREとインスタンス移行の両方を行うため、必要な手順はやや多い。


MIGDB

V9.5インスタンス

MIGDB

UserExit、外部モジュール等

BACKUP

イメージ

BACKUP RESTORE

V9.5インスタンス => V10.1インスタンス

インスタンス／データベースを移行


移行先環境

移行前環境

システム停止のタイミングオンラインバックアップによる移行の場合、バックアップ取得中にシステムを稼働させる

ことが可能ですが、更新ログの適用はV9.5の時点で実施する必要があります。そのため、ログ適用が完了する前に移行前環境のシステムを停止し、V10.1への移行

中の更新ログ発生を抑止する必要があります。

BACKUP

イメージ

オンライン

BACKUP取得

本番稼働による更新ログ生成

V9.5インスタンスへ

RESTORE ログの適用 V10.1へ移行

移行前環境で稼働システム停止移行先環境で稼働

本番稼働

更新ログ

適用

適用

参考：オンライン・バックアップ・イメージからの移行(移行作業の流れ）


移行作業の流れ

移行先環境で、V9.5 インスタンスの新規作成

BACKUP/RESTOREでデータベースを移動






3-3-2章の手順を参照

3-3-1章の手順を参照

参考：オンライン・バックアップ・イメージからの移行(移行作業の流れ）



（ケース３）


（ケース１）

BACKUP/RESTORE


3-3-3. データ移動ユーティリティによる移行


















この節では、データ移動ユーティリティを使用して、同一サーバ上もしくは新規サーバ上の、新しいインスタンスへ移行する際の作業の流れを説明します。

この移行シナリオの特徴 DB2 9.5/9.7の既存インスタンスは保存し、新規のインスタンスへ移行する。データ移動ユーティリティを使用して、データの移行を行う。移行元となるDB2のバージョンに依存せず移行可能。


V10.1インスタンス（新規）

MIGDB

移行前インスタンス

新規DB

UserExit、外部モジュール等

移行データ

DDL

EXPOR

T LOAD

db2look CREATE



移行オブジェクトの作成

移行データの抽出と投入


共通の移行前タスクの実施＊「共通の移行タスク」については、3-2-1章を参照してください。

新規インスタンス/DBの作成











3-3-3. 新規インスタンス/DBの作成

新規インスタンスの作成新規インスタンスの作成については、「3-3-2. 新規インスタンスの作成」を参照してください。

新規データベースの作成移行データを格納するためのデータベースを新規に作成してください。下記の項目については、データベース作成時点で決定しておく必要があります。デフォルトの

設定から変更する必要がある場合はデータベースの作成コマンドで指定してください。データベースのCodeset、Teritorry、Collate データベース・ディレクトリーシステムカタログ表スペースシステム一次表スペース（手動にて作り直しが可能）アクティブログディレクトリ（DB構成パラメーターより変更可能）自動ストレージを使用するかどうか（DB2 V10.1では、デフォルトでON）

– 自動ストレージを使用する場合、システムカタログ表スペースはDMSで作成されます。 – 自動ストレージを使用しない場合は、これまでと同様SMSで作成されます。 – 自動ストレージ使用の有無は、データベース作成のタイミングで決定する必要があり、データベース作成後に切

り替えることはできません。

実行コマンド db2 create database <DB名> <DB作成オプションを指定> DB作成オプションについては多岐にわたるため、DB2 Information Centerを参照してください。

– http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.admin.cmd.doc/doc/r0001941.html




3-3-3. 新規インスタンス/DBの作成（続き）

レジストリー変数、構成パラメータの移行

DB2の観点から移行すべきパラメータとしては、下記の3種類が存在します。レジストリー変数データベース・マネージャー構成パラメーターデータベース構成パラメーター

レジストリー変数及び、データベース・マネージャー構成パラメーターについては、「3-3-2 新規インスタンス

の作成」を参照してください。

データベース構成パラメーターの移行データ移動ユーティリティを使用して移行した場合、データベース構成パラメーターは移行されません。移行先サーバのシステム構成にあわせてメモリー関連パラメータの設計見直し等を行った上で、必要な項目

の移行を行ってください。










3-3-3. 移行オブジェクトの作成

移行すべきオブジェクトの特定とDDLの取得についてデータ移動ユーティリティによって移行を行う場合、データベース内に存在するオブジェ

クトの移行は手動で行う必要があります。移行の対象となるオブジェクトのDDLは、db2lookコマンドで取得可能です。

db2lookでDDLを取得可能なオブジェクトは、DB2のバージョンによって異なります。詳細は次ページの解説を参照してください。

db2lookでDDLを取得できないオブジェクトは、システムカタログ表等を参照して手動でDDLを作成する必要があります。

実行コマンド例 DBオブジェクトのDDLを取得する

– > db2look -d migdb -a -e -td % -o db2look.e.log

表スペース、バッファープール、データベース・パーティション・グループ作成用のDDLを取得 – > db2look -d migdb -l -o db2look.l.log

GRANTステートメント等権限関連のステートメントを取得

– > db2look -d migdb -a -xd -o db2look.xd.log

実行コマンドの注意点データベース・オブジェクトを取得するdb2lookのステートメントでは、トリガーやルーティンに「;（セミコロ

ン）」が含まれる場合があるため、ここでは「%」をセパレータとして使用しています。「%」をセパレータとして取得したDDLは、下記のように実行します。

– > db2 –td% -vf db2look.e.log – セパレータとしては、移行する環境のDDLに含まれない文字を選定してください。



オブジェクト移行についての考慮点シーケンスオブジェクトの値を保持したい場合、START WITHキーワードで指定してください。 UDFが外部ルーチンである場合、バイナリファイル(外部モジュール)の移行が必要です。CREATE

FUNCTIONステートメントの実行時には、EXTERNALオプションで指定した外部モジュールが存在しなくてもUDFの作成自体は可能ですが、UDFが実行される時点では、UDFが参照する外部モジュールが存在しなければなりません。

サーバー、ユーザーマッピング作成の際に必要なAUTHORIZATION/PASSWORDはdb2lookで作成されるDDLに含まれません。手動で修正する必要があります。



移行先環境でのオブジェクト作成移行先環境でのオブジェクト作成は、下記の手順で実施します。

各種DBリソース用のファイルシステム、RAW-DMSコンテナ用のドライブ、LV等を作成する。インスタンス、データベースを作成するテーブルスペース、バッファープールを作成する。（db2look –lの出力）テーブル、ビュー等のデータベースオブジェクトを生成する。（db2look –eの出力）権限設定ステートメントを実行する。（db2look –xdの出力）

コマンドの実行

db2 –tvf <DDL格納ファイル>

オブジェクト作成時の考慮点物理構成の変更に対応

– 移行元環境で実行した「db2look –l」コマンドの出力は、移行後の環境の物理構成とは異なる可能性があります。テーブルスペースのコンテナ情報や、バッファープールサイズについては、移行先の環境に合わせて見直しを行ってください。

db2lookの出力に含まれるスキーマ設定は、必要に応じて変更してください。 – データベースオブジェクトを作成する際、スキーマを明示的に宣言しなかった場合、インスタンスオー

ナーのユーザーIDが暗黙的に使用されます。 – db2lookコマンドから出力されるCREATEステートメントには、暗黙的に設定されたスキーマ（ユーザー

ID）が明示的に付加されます。 – スキーマが指定されていない場合の、暗黙的なユーザーIDの付加は、アプリケーションからのSQLアク

セスの場合も同様です。 – そのため、移行先環境でユーザーIDが変更された場合、アプリケーションから発行されるSQLに対して

暗黙的に付加されるスキーマと、db2lookの出力で明示的に付加されたスキーマが不一致を起こす可能性があります。










3-3-3. 移行データの抽出と投入

EXPORTによる移行データの抽出移行元環境からのデータ抽出にはEXPORTを使用します。 db2lookにより出力されたテーブルのCREATEステートメントを参照し、データ

抽出の漏れが発生しないよう注意してください。テーブルから全件を抽出する場合のコマンドの実行

>db2 export to <EXPORT先> OF <EXPORT形式> select * from <TABLE名称>

EXPORT形式にはDEL（文字区切り）、IXFが使用可能です。 IXF形式を利用した場合、IMPORT中にテーブルの作成が可能ですが、当ガイドでは

LOADを使用することを前提としているため、データの可読性の観点からDEL形式でのEXPORTを紹介します。


3-3-3. 移行データの抽出と投入（続き）

EXPORTによる移行データの抽出（続き）ラージオブジェクト（LOB）の抽出について

移行前のデータベースに保持されているオブジェクトとしてLOBが存在する場合、EXPORTの際に考慮点があります。

LOBのEXPORT方法 – LOBを含む表の抽出を行う際は、EXPORTコマンドを下記のように指定してください。

– >db2 export to <EXPORT先> OF <EXPORT形式> LOBS TO <LOB出力先ディレクトリ> LOBFILE <LOBファイル名> modified by lobsinfile select * from <TABLE名称>

>>-EXPORT TO--filename--OF--filetype---------------------------->

>--+-----------------------+--+-----------------------+--------->

| .-,--------. | | .-,--------. |

| V | | | V | |

'-LOBS TO----lob-path-+-' '-LOBFILE----filename-+-'

>--+-------------------------------+---------------------------->

| .--------------. |

| V | |

'-MODIFIED BY----filetype-mod-+-'


3-3-3. 移行データの抽出と投入（続き）

LOADによる移行データの投入一般的に、LOADによるデータ投入はIMPORTと比較して大幅に高速であるた

め、当ガイドではLOADによるデータ投入を前提として記述します。

コマンドの実行 load from <LOADファイル名> of <ファイル形式> replace into <テーブル名>; 初期移行を想定しているため、LOADの動作モードは「REPLACE」としています。

ラージオブジェクト（LOB）の投入についてラージオブジェクトを含むテーブルにLOADを行う場合、下記のようなオプションを追加して

ください。 load from <LOADファイル名> of <ファイル形式> LOBS FROM <LOBファイル格納ディレクトリ> modified by lobsinfile replace into <テーブル名>;



フォールバックについて DB2 V10.1への移行後に、DB2提供のユーティリティ等を使用して移行元のバー

ジョンに逆移行することはできません。そのため、バックアップからのリストアを前提としてフォールバックを計画する必

要があります。

DB2の観点から、回復を計画する必要があるリソース DB2製品コード：システムバックアップのリストアにより復旧インスタンス、外部ファイル：システムバックアップのリストアにより復旧：共有ディスクに配置されている場合は、インスタンスホームのバック

アップからのリストアあるいはインスタンスの再作成データベース：データベースのリストアにより復旧 DB2クライアント：旧バージョンの再導入と、接続構成定義の適用により復旧



移行シナリオに応じて、回復が必要なリソースを確認する。前ページに記載したすべてのリソースの回復が必ずしも必要となるわけではなく、

例えば新規インスタンスを作成し、データベースを新規インスタンスへのBACKUP/Resotreして移行した場合、インスタンスや外部ファイルの回復は必要ありません。（旧インスタンスが保管できる場合）

どのリソースの復旧が必要になるかは、下記の表を参照してください。

各リソースの復旧が必要かどうか

DB2製品コード

インスタンスデータベース DB2クライアント

既存のインスタンスを移行 *1 ありあり *3

同一サーバ上の新規インスタンスへ移行（移行前環境のDB、DBコンテナは削除）

*1 必要なし(*2) あり *3

同一サーバ上の新規インスタンスへ移行（移行前環境のDB、DBコンテナは保存）

*1 必要なし(*2) 必要なし(*2) *3

新規サーバへ移行必要なし必要なし必要なし *3

(*1) 10.1と旧バージョンで製品コードの共存が不可の場合、復旧が必要 Windows ：移行前のDB2バージョンがV8の場合共存可能。V7以前の場合共存不可能 Windows以外：バージョンを問わず共存可能

(*2) 製品コードの共存ができない場合は、復旧の必要あり。 (*3) 製品コードの共存が可能かどうかはサーバ（*1)と同様。DB2クライアントについては、

選択した移行シナリオに関わらず、構成変更を行った場合は復旧が必要。



DB2製品コード、インスタンス、外部ファイルの復旧について復旧作業に必要な時間を短縮するため、これらのリソースの復旧には、システムバッ

クアップあるいはインスタンスホームのバックアップからのリストアを使用することをお勧めします。

何らかの理由でシステムバックアップのリストアが難しい場合、下記のような手順でインスタンスを復旧することが可能です。 DB2 V10.1のデータベース、インスタンスを削除する。 DB2 V10.1の製品コードをアンインストール（製品コードの共存が不可能な場合）移行元バージョンの製品コードを再導入（製品コードの共存が不可能な場合） db2icrtコマンドを使用して、移行前のインスタンスを再作成移行前に取得したレジストリー変数、データベース・マネージャー構成パラメーターを再度設定 USEREXITやストアドプロシージャー等外部ファイルを復旧（後続作業のデータベースリストアを実施）

データベースの復旧について

データベースの復旧にはRESTORE DATABASEコマンドを使用してください。フラッシュコピーによるバックアップ運用を行っている場合、フラッシュコピーのコピー

バックによる復旧も可能です。その場合はバックアップ運用構築時に確立した復旧手順に従って復旧を行ってください。



DB2クライアントの復旧について DB2サーバの復旧を行った場合、DB2クライアントについても移行前のバージョ

ンに復旧してください。

DB2クライアントの復旧は、下記の手順で実施可能です。 Windowsプラットフォームの場合

– DB2 V10.1のDB2クライアント製品コードをアンインストールする。（製品コードの共存が不可能な場合）

– 移行前バージョンのDB2クライアントをインストールする。（製品コードの共存が不可能な場合）

– db2cfimpコマンドを使用して、移行前に取得した接続構成定義ファイルをインポートする。

クライアントの接続定義、構成パラメーターが復旧される。

取得手順は「5-1. クライアントの移行」を参照してください。

Linux/UNIXプラットフォームの場合 – 復旧対象のクライアント・インスタンスを削除する。 – 移行元バージョンのクライアント・インスタンスを作成する。 – db2cfimpコマンドを使用して、移行前に取得した接続構成定義ファイルをインポートする。

クライアントの接続定義、構成パラメーターが復旧される。

取得手順は「5-1. クライアントの移行」を参照してください。


5. DB2クライアントの移行

クライアント移行の方針移行計画をシンプルにするためには、DB2サーバと同期してDB2クライアントを移行

してください。この場合、異なるバージョン間の接続を考慮する必要はありません。しかし、DB2サーバと同期してクライアント移行を行うことが難しい場合、DB2サーバ

が先行して移行されるように、移行シナリオを検討してください。 DB2サーバを先行して移行する形態の場合、現在のDB2クライアントがDB2 V10.1

のDB2サーバと接続可能かどうかを『DB2 V9.5/V9.7からV10.1へうまく移行するためのガイド』の「サポートされるクライアント・サーバー構成一覧」で確認してください。


5. DB2クライアントの移行（続き）

アップグレードのオプションについてアップグレード・オプションは、インストールするクライアントのタイプによって異なります。次の表で、DB2 V10.1 クライアントのタイプ別アップグレード・オプションについて説明します。

アップグレード元アップグレード先アップグレード・サポートの詳細

V9.5 Data Server Client V9.7 Data Server Client (Windows)

DB2 V10.1 Data Server Client(Windows)

以下の 2 つのオプションがあります。 - DB2 10.1 Data Server Client をインストールし、「既存の処理」ウィンドウでDB2 V10.1 より前のクライアント・コピーを「アップグレード」アクションと共に選択します。クライアント・インスタンスが自動的にアップグレードされます。 - DB2 V10.1 Data Server Client の新しいコピーをインストールしてから、既存のクライアント・インスタンスを手動でアップグレードします。

V9.5 Data Server Runtime Client V9.7 Data Server Runtime Client (Windows)

DB2 V10.1 Data Server Runtime Client(Windows)

DB2 V10.1 Data Server Runtime Client を新しいコピーとしてインストールしてから、既存のクライアント・インスタンスを手動でアップグレードします。

V9.5、または V9.7 のすべてのクライアント (Linux または UNIX)

DB2 V10.1 のすべてのクライアント (Linux または UNIX)

DB2 V10.1 クライアントの新しいコピーをインストールしてから、既存のクライアント・インスタンスを手動でアップグレードします。



移行の方法について DB2クライアントの移行には下記の2方法があります。

現行のクライアント・インスタンスをそのまま移行する方法 – この形態がサポートされるのは、移行元のDB2クライアントが DB2 V9.5、V9.7 の場合

のみです。これは、DB2サーバの移行処理サポート対象と同様です。 DB2 V10.1のクライアント・インスタンスを新規作成する方法

– DB2 V9.1 以前のDB2クライアントからの移行を行う場合はこの方法を使用する必要があります。

– 構成パラメーターや接続構成情報を手動で移行する必要があります。



現行クライアント・インスタンスの移行処理による移行移行の手順

移行対象サーバへDB2 V10.1のクライアントをインストールする。 rootユーザーもしくは管理者権限でログオンする。 db2iupgradeコマンドを使用してクライアント・インスタンスをV10.1へ移行する。インスタンスオーナーからクライアント・インスタンスを開始する。「DB2クライアントの移行後タスク」を実施する。

クライアント・インスタンスの移行処理についてクライアント・インスタンスに対しても、インスタンス移行を行う場合はdb2iupgradeコマンドを

使用します。インスタンスの移行を行う場合は、「3-3-1. 同一インスタンスでの移行」のdb2iupgradeコマン

ド実行方法を参考として実施してください。

DB2クライアントの移行後タスクについて db2iupgradeコマンドの処理中にカタログ情報の移行が行われますが、移行されたカタログ情

報が正常かどうかを確認するため、DB2サーバへの接続確認を行ってください。



新規クライアント・インスタンスの作成による移行移行の手順

移行対象サーバへDB2 V10.1のクライアントをインストールする。移行前バージョンのクライアント・インスタンスより構成情報を取得する。

– 接続構成情報 – データベース・マネージャー構成パラメーター

クライアント・インスタンスを停止する。移行前バージョンのクライアント・インスタンスを削除する。新規のクライアント・インスタンスを作成する。事前に取得した構成情報を、新規インスタンスへ設定する。「DB2クライアントの移行後タスク」を実施する。移行元バージョンのDB2クライアントをアンインストールする。

クライアント・インスタンスの構成情報取得について DB2クライアントの構成情報は、db2cfexpコマンドで一括して取得可能です。実行コマンド

– db2cfexp <出力ファイル名称> backup

取得した構成情報を、新規インスタンスに設定するためにはdb2cfimpコマンドを使用します。 – db2cfimp <db2cfexpで出力したファイル名>



新規クライアント・インスタンスの作成による移行（続き）新規のクライアント・インスタンス作成について

クライアント・インスタンス作成のためには、db2icrtを使用します。 db2icrtコマンドは、rootユーザーもしくは管理者権限で実行します。 UNIX/Linuxの場合

– > $DB2DIR/instance/db2icrt –s client -u <fencedユーザーID> <インスタンス名> – -p ：TCP/IPによる接続を使用する場合のサービス名/ポート番号を指定 – -u ：fenced ユーザー定義関数および fenced ストアード・プロシージャーを実行するユーザー ID の名前を指定します。サーバインスタンスを作成する際は、必須オプションです。

Windowsの場合 – > $DB2DIR¥instance¥db2icrt –s client <インスタンス名>



End of Document

Documents

DB2 V10.1 移行手順ガイド - IBM...AIX バージョン 7.1 Technology Level (TL) 0 および Service Pack (SP) 3 - 64bitのAIX カーネルが必要 - C++ ランタイムの最小レベルでは、xlC.rte