DB2 for LUW 11.1 移行手順ガイド

© 2016 IBM Corporation

DB2 for LUW 11.1 移行手順ガイド

© 2016 IBM Corporation2

本資料掲載事項は、ある特定の環境・使用状況においての正確性がIBMによって確認されていますが、すべての環境において同様の結果が得られる保証はありません。これらの技術を自身の環境に適用する際には、自己の責任において十分な検証と確認を実施いただくことをお奨めいたします。

© Copyright IBM Japan Systems Engineering Co., Ltd. 2016


目次

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

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

§ 3. 移行作業- 3-1. DB2 11.1のインストール- 3-2. シナリオに共通して必要な移行前のタスク- 3-3. 移行作業

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

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

• 参考：オンライン・バックアップ・イメージを利用した移行シナリオ

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

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

§ 4. フォールバックのシナリオについて§ 5. DB2クライアントの移行

§ 6. 環境によって必要となるタスク

3


1. はじめに

§ この資料の位置づけ- この資料は ISE発行の資料「DB2 V10.1移行手順ガイド」をV11.1用に改定したものです。

- DB2 10.5 以前のバージョンから DB2 11.1 への移行手順を、いくつかのシナリオを想定して記述しました。

§ この資料で想定する環境- エディション : 単一パーティション・データベース

- プラットフォーム : Linux/AIX/Windows

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

• http://www.ibm.com/software/data/support/lifecycle/


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

§ マニュアル/Knowledge Center- DB2 11.1 Knowledge Center

https://www.ibm.com/support/knowledgecenter/ja/SSEPGG_11.1.0/com.ibm.db2.luw.kc.doc/welcome.html• DB2 バージョン 11.1 へのアップグレード

https://www.ibm.com/support/knowledgecenter/ja/SSEPGG_11.1.0/com.ibm.db2.luw.qb.upgrade.doc/doc/c0023662.html- DB2 Upgrade Portal (以前は「migration roadmap」と呼ばれていました)

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

§ 参考資料- The DB2Night Show #182: DB2 LUW V11.1 Upgrade Best Practices and Tips!

• http://www.dbisoftware.com/blog/db2nightshow.php?id=694- DB2 for LUW V11.1 : Upgrade and Recovery Enhancements

• http://www.idug.org/p/bl/ar/blogaid=510

- DB2 on Cloud• http://www.ibm.com/analytics/us/en/technology/cloud-data-services/db2-on-cloud/index.html

§ その他の移行関連情報- 『DB2 9.5/9.7/10.1から10.5へうまく移行するためのガイド』

• http://www.ibm.com/developerworks/jp/data/products/db2/download/db2-105_migration-guide/index.html

- 『DB2 V9.5/V9.7からV10.1へうまく移行するためのガイド』• http://www.ibm.com/developerworks/jp/data/products/db2/migrationguide/db2_101.html

- 『DB2 V8からV9.5/V9.7へうまく移行するためのガイド』• http://www.ibm.com/developerworks/jp/data/library/dataserver/j_d-db2migration03/


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

§ DB2 11.1サーバーへのアップグレード- 以下のバージョンのDB2サーバーから直接アップグレード可能

• DB2 9.7• DB2 10.1• DB2 10.5

- DB2 9.5以前のサーバーからDB2 11.1 サーバーにアップグレードする場合、以下の方法でアップグレードするか、またはデータの移動によるアップグレードを行う(「2.3 移行シナリオの比較」参照)

• まず DB2 9.7 の新 FixPack 環境へアップグレード

• 次に DB2 11.1 へアップグレード

§ サポートするクライアント- 以下のDB2クライアントが、DB2 11.1サーバーにアクセス可能

• DB2 9.7• DB2 10.1• DB2 10.5

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

クライアントの構成情報、ノード、DBのカタログ情報はそのまま維持される• DB2 9.7• DB2 10.1• DB2 10.5

- DB2 9.5以前のクライアントからDB2 11.1クライアントにアップグレードする場合、以下の方法でアップグレードするか、または、新規にインストールしたV11.1クライアントで構成、カタログを再度実行する

• まず DB2 9.7 クライアントの新 FixPack 環境へアップグレード

• 次に DB2 11.1 クライアントへアップグレード


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

§ インストール前提条件の確認- db2prereqcheck コマンドを使用して、システムがインストール前提条件を満たしているかどうかを検査可能

§ サポートプラットフォームの前提条件- DB2データベースのインストール要件については、下記Webサイトにて確認

1. System requirements for IBM DB2 for Linux, UNIX, and Windowshttp://www.ibm.com/support/docview.wss?uid=swg27038033

* DB2 11.1が稼働をサポートするOS, Hypervisor, コンパイラ, 言語などの情報

2. DB2 11.1 Knowledge Center [DB2 データベース製品のインストール要件]http://www.ibm.com/support/knowledgecenter/ja/SSEPGG_11.1.0/com.ibm.db2.luw.qb.server.doc/doc/r0025127.html

* 全体のロードマップ / 上述[1. System requirements..] に含まれない情報(Federationの要件等)

3. Operating systems for a specific producthttp://www.ibm.com/software/reports/compatibility/clarity/osForProduct.html

* 上述[1. System requirements..] のサイトでも同様の情報を検索可能

4. Hypervisors supported by a specific producthttp://www.ibm.com/software/reports/compatibility/clarity/vesForProduct.html

* 上述[1. System requirements..] のサイトでも同様の情報を検索可能


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

§ DB2 11.1での変更点- Solaris / HP-UX / Linux on Power(BigEndian) がサポート対象外となった

上記環境の移行パスについては、「サポート対象外となった環境の移行」を参照

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

• http://www.ibm.com/support/knowledgecenter/ja/SSEPGG_11.1.0/com.ibm.db2.luw.qb.upgrade.doc/doc/c0022266.html

- [組み込み SQL アプリケーションの 32 ビットと 64 ビットのサポート]• http://www.ibm.com/support/knowledgecenter/ja/SSEPGG_11.1.0/com.ibm.db2.luw.apdv.embed.doc/doc/c0020913.html


２. 移行シナリオの決定

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

• 現行のバージョン

• 現行のエディション

• サーバーのリプレイスの有無

• 移行作業として確保できる時間

• データベースのサイズ等

§ 目次2-1. DB2 11.1への移行作業

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

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

2-4. DB2 11.1 移行作業フロー


2-1. DB2 11.1への移行作業

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

(詳細は2-2を参照)- 今回は単一パーティション・データベースでの移行手順を想定する



§ アップグレードパスに関するサマリーは以下の通り- 本資料では単一パーティションDBから単一パーティションDBへの移行を想定

- その他のアップグレードパスおよびアップグレード方法については、以下の情報を参照

移行元V11.1 単一パーティ

ション・データベース

V11.1 複数パー

ティション (DPF)DB2 pureScale® Feature を使用した

V11.1 V9.7、 V10.1 または V10.5 単一パーティション・データベース

ありありあり

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

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

ありあり。インスタンスをV11.1 複数パーティション・データベースから DB2 pureScaleインスタンスに直接アップグレードすることはできません。インスタンスとデータベースをV11.1 にアップグレードする前または後に、データをまず単一パーティションに統合し、それからその単一パーティション・データベースのインスタンスを DB2 pureScaleインスタンスに変換してください。

DB2 pureScale Feature を使用したV10.1 またはV10.5

なしなしあり。DB2 pureScale サーバーのアップグレードの説明に従ってください

移行先


§ DB2各バージョンにおけるエディションの対応関係- V9.7からV11.1までのDB2サーバー製品エディション一覧


DB2バージョン V9.7 V10.1 V10.5 V11.1

製品エディション

(同等のエディションが同じ行に並んでいます)

－ Advanced Enterprise Server Edition

Enterprise Server Edition

－－ Advanced Workgroup Server Edition

Workgroup Server Edition

Express Edition －

Personal Edition －－－

Developer Edition

★印は相互にエディション切替

可能(詳しくは次ページ参照)

★

★

★

★


解説： DB2各バージョンにおけるエディションの対応関係（補足）

§ 基本的には、移行元(現行)と同じ製品エディションを選択する

§ 以下の点も考慮して移行先エディションを検討- Express Editionの廃止

• V11.1ではExpress Editionが廃止され、推奨される移行先は Workgroup Server Edition- ライセンスの切り替えについて

• DB2 10.5以降、以下4つのエディションのインストール・イメージが同一となり、DB2を再インストールせずライセンスファイルの切り替え（削除・追加）によって、別エディションに移動することができるようになった

• Advanced EnterpriseServerEdition• Enterprise Server Edition• Advanced Workgroup Server Edition• Workgroup ServerEdition

• [ライセンスの更新]http://www.ibm.com/support/knowledgecenter/ja/SSEPGG_11.1.0/com.ibm.db2.luw.qb.server.doc/doc/t0061044.html

- 各エディションによって提供される機能については、以下を参照

・DB2 製品エディションと DB2 オファリングの機能http://www.ibm.com/support/knowledgecenter/ja/SSEPGG_11.1.0/com.ibm.db2.luw.licensing.doc/doc/r0053238.html

- Direct Editionの登場

• オンプレミスとクラウドのいずれの環境でも利用できる低価格の月額ライセンス

• DB2 Direct Standard Edition にはDB2 Workgroup Server Edition のデータベース機能が含まれ、DB2 Direct Advanced Edition には、 DB2 Advanced Enterprise Server Edition のデータベース機能が含まれる

• Cognosはバンドルされない

• (参考) IBM developerWorks[DB2 11.1 for Linux, UNIX, and Windows 登場！]http://www.ibm.com/developerworks/jp/data/library/db2/db2_11_1_for_linux_unix_windows/index.html

V11.1New !!


解説： DB2各バージョンにおけるエディションの対応関係（補足）

§ （参考）無償版の入手方法について- 外部サイトからダウンロード可能

http://www.ibm.com/analytics/us/en/technology/db2/db2-trials.html• DB2 Data Server Trial (including pureScale, BLU Acceleration)

* 試用版(90日限定)： AIX/Linux x64/zLinux/Linux on Power/Windows x64• Warehouse Component Trial (including DPF)

* 試用版(90日限定)： AIX/Linux x64/zLinux/Linux on Power/Windows x64• DB2 Express-C

* 無償版(日数制限無)： Linux x64/Windows x64


シナリオ1 シナリオ2 シナリオ3

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

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

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

移行元バージョン

V9.7, 10.1, 10.5 V9.7, 10.1, 10.5V9.5以前（EXPORT/LOADのみ可能）

V9.7, 10.1, 10.5V9.5以前（EXPORT/LOADのみ可能）

移行先サーバー

移行元と同一移行元と同一新規マシン

移行先インスタンス

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

移行に使用するツール

db2iupgrade/upgrade db BACKUP/RESTOREまたは EXPORT/LOAD

BACKUP/RESTOREまたは EXPORT/LOAD

備考 l移行に必要なDISK領域が小

lフォールバック時にインスタンスの再作成および、DBリストアが必須

l新旧DB分のDISK領域が必要l移行前インスタンス/DBの温存が可能（Windowsの場合、V8以降）lCodesetなどDB作成時に決定される属性を変更したい場合は、EXPORT/LOAD

l新規マシンに移行する際に使用lCodesetなどDB作成時に決定される属性を変更したい場合は、EXPORT/LOAD

15

db2iupgradeupgrade DB

DB2 9.7,10.1,10.5=> DB2 11.1

移行元DB2 DB2V11.1

RESTORE orLOAD

移行元DB2 DB2V11.1

RESTORE orLOAD

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

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

BACKUP orEXPORT

BACKUP orEXPORT


§ 選択可能な移行方法は以下の要素から絞り込まれる- 移行先のサーバー(筐体)が同一か、異なるか

- 移行元（現行）システムのDB2バージョンがV9.7以上であるか、V9.5以下であるか

- 移行元・先のOSが同一か、異なるか。異なる場合、同一エンディアンか否かなど

§ 現行DB2バージョンがV9.7以上の場合：- 以下いずれかの方法を選択可能

• db2iupgrade （ただし同一筐体内の移行に限る）

• オフライン・バックアップ・リストア（※）

• データ移行ユーティリティー（Export/Load）

§ 現行DB2バージョンがV9.5以下の場合：

• データ移行ユーティリティー（Export/Load）

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

(※) オフライン・バックアップ・リストアは、以下いずれである場合に選択可能・Windows間の移⾏・同⼀エンディアンのプラットフォーム同⼠であるUNIX/Linux間の移⾏


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

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

るのは、「データベース全体の移行処理を行うかどうか」です。

- BACKUP/RESTOREを使用してデータベースの移行を行う場合、データベース全体に対して一括した移行処理が実施できるため、オブジェクトの種類/数にかかわらず一定の手順で移行が可能です。

- ただし、下記の条件では、BACKUP/RESTOREによる移行ができないため、データ移動ユーティリティを使用してください。

• WindowsからUNIX/Linux等、異なるプラットフォーム間での移行を行う場合。

メリットデメリット

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

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

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

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


サポート対象外となった環境の移行

§ Solaris/HP-UX/Power on Linux(Big Endian)版DB2の移行について- Solaris/HP-UX/Power on Linux(Big Endian)版はV11.1ではサポート対象外となります。

- 上記プラットフォーム上データベースのV11.1への移⾏⽅法• 同⼀エンディアンのプラットフォーム同⼠のUnix・Linux間の移⾏は、バックアップ・リストアによって可能です。

• 実機検証にてLinux on Power Big Endian からAIXへは、バックアップ・リストアによる移行が可能であることを確認済み

• 移動ユーティリティー(Export/Load)を用いる移動であれば、すべてのプラットフォーム同士での移行を行うことができます。

• [異なるオペレーティング・システムおよびハードウェア・プラットフォーム間のバックアップおよびリストア操作]http://www.ibm.com/support/knowledgecenter/ja/SSEPGG_11.1.0/com.ibm.db2.luw.admin.ha.doc/doc/c0005960.html


2-4. DB2 11.1への移行作業フロー

19

EXPORT/LOADを使用

（ケース３）

同一インスタンスで移行

（ケース１）

BACKUP/RESTOREを使用（ケース２）

2章移行シナリオの決定

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

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

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-4章移行後タスクの実施


解説： DB2 11.1への移行作業フロー

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

じて必要な作業を確認し、移行計画を立案してください。

- 上記のスライドでは、各シナリオ毎の大まかな作業の単位を表しています。

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

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


３. 移行作業

§ 決定した移行シナリオに応じて必要な作業を実施します。- ケース１：同一インスタンスで移行

- ケース２： BACKUP/RESTOREを使用

- ケース３： EXPORT/LOADを使用

§ 目次3-1 DB2 11.1のインストール

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

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

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

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

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

3-3-2. BACKUP/RESTOREを使用した移行手順

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


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

22


（ケース３）


（ケース１）


















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

§ インストール手順は、DB2製品マニュアルをご確認ください。- DB2 10.5 Knowledge Center[DB2 セットアップ・ウィザードのウォークスルー]

• https://www.ibm.com/support/knowledgecenter/ja/SSEPGG_10.5.0/com.ibm.db2.luw.qb.server.doc/doc/t0059589.html• V11.1も導入手順は変わりません。


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

24


（ケース３）


（ケース１）


















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

§ シナリオに共通して必要な移行前のタスク- DB2 11.1 以降でサポートされなくなった機能の確認と、必要に応じた変更

- 移行前の情報を保管する

• 構成パラメーター等、各種構成情報

• 移行前のパフォーマンス情報、EXPLAIN情報

• 移行前バックアップ

- 移行時のエラー情報および診断情報収集の準備

- テスト環境での移行


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


（ケース３）


（ケース１）


















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

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

• DB2 11.1以降でサポートされなくなった機能の確認と、必要に応じた変更

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

• 移行前のパフォーマンス情報、EXPLAIN情報

• 移行前バックアップ

• フォールバック計画の検討

• 移行時のエラー情報および診断情報収集の準備

• テスト環境での移行

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

• DB2インスタンスの、32bitから64bitへの移行（UPGRADE DBコマンドを使用する場合）

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

• upgrade処理の制約事項が該当しないことを確認

• データベースが移行できる状態にあることの確認（db2ckupgrade)- データ移動ユーティリティを使用して移行する際のタスク（3-3-3を参照）

• オブジェクトのDDLを現行データベースから取得

• 移行先データベースに、オブジェクトを事前作成

§ この章では、「移行シナリオにかかわらず共通で行うべきタスク」について記述します。- シナリオ固有のタスクに関しては、各シナリオの章（3-3）を参照してください。


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

§ DB2 11.1以降でサポートされなくなった機能の確認と、必要に応じた変更- DB2マニュアルを確認し、DB2 11.1以降でサポートされなくなった機能、非推奨となった機能を使用してい

ないことを確認します。

- 特に、下記の点には注意してください。

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

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

• 移行前の構成を保管するために、db2supportコマンドを実行してください。

• db2supportコマンドは、DB2の構成に関する下記の情報を一括して取得します。• データベース・マネージャー構成パラメーター

• データベース構成パラメーター

• DB2レジストリー変数

• システムカタログ表のEXPORTデータ（「-cl 0」オプション使用時）

• 統計情報等、オプティマイザーの動作に関する情報（「-cl 0」オプション使用時）

• その他DB2システムに関する各種情報

• 実行コマンド例

>db2support <出力パス> –d <DB名> -cl 0


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

§ 移行前の情報を保管する（続き）- 移行前のパフォーマンス情報、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 11.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



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

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

• 移行手順に含まれる問題の発見

• V11.1での変更点がもたらす影響を事前に評価

• アプリケーションに移行後の環境を提供し、移行の影響をテスト

• 移行作業に要する時間見積もりの精密化

等、複数のメリットを得ることが可能です。

- DB2 11.1およびDB2 10.5以前のバージョンは同一サーバ上での共存が可能です。• 独立したテスト環境を用意することが難しい場合でも、他のバージョンが稼働する環境に事前にインストールし、稼働環境

の縮小版を構築することで、テスト環境の構築が可能です。

• ただし、DB2 11.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診断エラーのキャプチャー・レベル (DIAGLEVEL) = 3通知レベル (NOTIFYLEVEL) = 3$ db2 update dbm cfg using DIAGLEVEL 4DB20000I UPDATE DATABASE MANAGER CONFIGURATIONコマンドが正常に完了しました。

$ db2 update dbm cfg using NOTIFYLEVEL 4DB20000I UPDATE DATABASE MANAGER CONFIGURATIONコマンドが正常に完了しました。

$ db2 get dbm cfg | grep LEVEL診断エラーのキャプチャー・レベル (DIAGLEVEL) = 4通知レベル (NOTIFYLEVEL) = 4


3-3. 移行作業

§ 次のページから、実際のデータベース移行の方法について解説します。- 3-3-1. 同一サーバ、同一インスタンスでの移行手順

• 参考： V10.5FP7以降のバージョンにおけるフォールバック

- 3-3-2. 新規インスタンスへの移行手順（BACKUP/RESTOREを使用）

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

• 参考：オンライン・バックアップ・イメージを利用した移行シナリオ

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


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

34


（ケース３）


（ケース１）












3-3-2章 DBバックアップ取得(backup db) 3-3-3章移行データの抽

出(EXPORTコマンド)





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

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

§ この移行シナリオの特徴- DB2 9.7/10.1/10.5の既存インスタンスをそのまま11.1へ移行する。（db2iupgradeを使用）

- DBのBACKUP/RESTOREや、データ移動ユーティリティによるデータ移動が必要ない。

DBサーバ（現行）

MIGDB

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


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

36

インスタンスの移行

データベースの移行

移行後タスクの実施

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

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

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


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

37







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

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

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

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

• SMSの場合• SYSCATSPACEの使用ページ数（Used Pages)と同じだけの空き容量が、SYSCATSPACEの格納されているドライブ/ファイルシス

テムに存在することを確認してください。使用済みページ数およびフリーページは「LIST TABLESPACESコマンドおよび、MON_GET_TABLESPACE表関数」によって確認が可能です。SYSCATSPACEのコンテナ・ファイルがどこに格納されているかは、「LIST TABLESPACE CONTAINERSもしくはMON_GET_CONTAINER表関数によって確認が可能です。

• DMSの場合• SYSCATSPACEを自動ストレージまたはAUTORESIZE を使用せずにDMSで作成している場合、使用ページ数（Used Pages）と同

じだけの空き容量が、SYSCATSPACEのフリーページ数（Free Pages）にあることを確認してください。使用済みページ数およびフリーページは「 LIST TABLESPACE Sコマンドおよび、MON_GET_TABLESPACE表関数」によって確認可能です。フリーページ数が、合計ページ数の50%未満で空き容量が不足している場合、「Alter Tablespace」コマンドを使用して拡張します。

• 自動ストレージまたはAUTORESIZE を使用しているDMSの場合は、SYSCATSPACEの使用ページ数（Used Pages)と同じだけの空き容量が、SYSCATSPACEの格納されているストレージパスに存在することを確認してください。ストレージパスはADMIN_GET_STORAGE_PATHS表関数で確認可能です。

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

• SYSCATSPACEの使用ページ数（Used Pages）の2倍の空き容量が、一時表スペースを格納しているドライブ/ファイルシステムに存在することを確認してください。使用済みページ数およびフリーページは「LIST TABLESPACE Sコマンドおよび、MON_GET_TABLESPACE表関数」によって確認可能です。

• DMS一時表スペースの場合• SYSCATSPACEの使用ページ数（Used Pages）の2倍の空き容量が、一時表スペースのフリーページ数（Free Pages）にあることを

確認してください。使用済みページ数およびフリーページは「LIST TABLESPACE Sコマンドおよび、MON_GET_TABLESPACE表関数」によって確認可能です。


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

§ 確保するべき空き容量の確認方法

$ db2 list tablespacesshow detail

現在のデータベースの表スペース

表スペース ID = 0名前 = SYSCATSPACEタイプ = データベース管理スペース

内容 = すべての永続データ。 REGULAR 表スペース。

状態 = 0x0000詳しい説明:正常

合計ページ数 = 16384使用できるページ数 = 16380使用したページ = 15548フリー・ページ = 832最高水準点 (ページ) = 15548ページ・サイズ (バイト) = 8192エクステント・サイズ(ページ) = 4プリフェッチ・サイズ(ページ) = 4コンテナー数 = 1

＜省略＞

使用済みページ数が15548ページ、

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

現在の使用容量は

15548 x 8192 / 1024 / 1024 = 121.4MB

SYSCATSPACEで約122MB、

また、TEMPSPACE1に244MBの空き容量が必要。


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



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

あることを確認します。

- db2ckupgradeコマンドは下記の項目のチェックを行います。• カタログされたデータベースが実際に存在している。

• データベースが不整合な状態ではない。

• データベースがバックアップ・ペンディング状態ではない。

• データベースがリストア・ペンディング状態ではない。

• データベースがロールフォワード・ペンディング状態ではない。

• 表がロード・ペンディング状態ではない。

• 表が再配分ペンディング状態ではない。

• (バージョン9.8 以降の場合) すべての表スペース・コンテナー・パスに同じマウント・ポイントを使用している。

• バージョン9.8 フィックスパック3 以降の場合、データベースの入出力書き込み操作がサスペンドされない。また、サスペンド中でない。

• システム・ビューに依存するMQT が存在しない。

• 表スペースが正常な状態である。

• データベースに、名前が ARRAY、BINARY、CURSOR、DECFLOAT、ROW、VARBINARY、またはXML の、ユーザー定義タイプ (UDT) が含まれていない。

• データベースに、組み込みの DATALINK データ・タイプが含まれていない。

• データベースに、SYSPUBLIC という名前のスキーマがない。

• データベースに、データベース・アップグレード失敗の原因となる、システム・カタログ表内の孤立行がない。

• HADR 1 次データベースとして使用可能になっているデータベースが正常に接続できる。

• バージョン9.7 (すべてのフィックスパック)、バージョン10.1 (すべてのフィックスパック)、およびバージョン10.5 フィックスパック 6 以前では、HADR データベースの役割はスタンバイではありません。

• SYSCATSPACE が DMS 表スペースであり、AUTORESIZE が使用不可の場合、SYSCATSPACE には合計ページのうち少なくとも 50% の未使用ページがある。

• データベースが XML Extender には使用不可である。

• データベースが未加工ログを使用していない。



§ データベースが移行できる状態にあることの確認（続き）- db2ckupgradeコマンドは、インスタンスの移行処理中に暗黙的に実行されます。上記項目のチェックにパス

しない場合、db2iupgradeによるインスタンスの移行処理は失敗します。


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

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

• <DB2 11.1インストールディレクトリ>/bin-実行コマンド例

>db2ckupgrade <DB名> -l <ログファイル名>

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

$ cd /opt/IBM/db2/V11.1/bin$ ls -l db2ckupgrade-r-xr-xr-x 1 bin bin 13083 5月 21 03:50 db2ckupgrade$ ./db2ckupgrade sample -l /tmp/db2ckupgrade.logDBT5508I db2ckupgrade ユーティリティーは正常に完了しました。データベースをアップグレードできます。

$ cat /tmp/db2ckupgrade.log実行中のDB2CKUPGRADE のバージョン: VERSION "11.1"

データベース: "SAMPLE"

DBT5508I db2ckupgrade ユーティリティーは正常に完了しました。データベースをアップグレードできます。

DB2 11.1のdb2ckupgradeであ

ることが確認できる。


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

44








§ インスタンスの移行- インスタンスの移行のためには、DB2 11.1の導入パス配下のdb2iupgradeコマンドを使用します。

- db2iupgradeコマンド実行

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

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

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

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

- 作業の流れ

• UNIX/Linuxでは、/tmpに5GB以上の空き容量があることを確認

• DB2の停止を行う

• rootユーザーもしくは管理者権限でログオンする

• db2iupgradeコマンドの実行

• インスタンス・オーナーとして再ログオン

• DB2の開始を行う


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

§ データベースの移行- インスタンスの移行を行った後、移行したインスタンス配下のデータベースをDB2 11.1 に移行する必要が

あります。

- upgrade DBコマンドの実行

• データベースの移行はupgrade DBコマンドで行います。

• $ db2 upgrade db <DB名> [ user <ユーザーID> using <パスワード> ]• ローカルDBに対してupgrade DBコマンドを実行する場合はユーザーID/パスワードは必要ありません。

- 作業の流れ

• インスタンスオーナーもしくは、SYSADM権限を持つユーザーとしてログオンする。

• upgrade DBコマンドを実行する。

• upgrade DBコマンドが正常に完了したことを確認する。

• 移行後のデータベースに接続し、簡単な照会を実行します。

- UPGRADEが正常に完了しない場合

• データベースの移行が失敗すると、エラー・メッセージ SQL1704N が失敗の原因を説明した理由コードとともに返却されます。DB2 Knowledge Centerの「メッセージ・リファレンス」でこの SQL エラー・コード参照してください。各理由コードに対しての対応策も上記マニュアル中に記載されています。

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



§ データベース移行後のログファイルの拡張子について- V10.5までは、UPGRADE DATABASEコマンドにより、旧バージョンのアクティブ・ログ・ファイルの拡張子

は.MIGに変更され、不要となった過去のアクティブ・ログが識別可能となっていました。

- V11.1では、ロールフォワード処理としてV10.5 FP7 から V11.1 までのログを適用することが出来るようになったことから、ログファイル拡張子のリネームは行われなくなりました。

• V11.1から可能になったロールフォワード処理については詳しくは、「参考：V10.5FP7以降のバージョンにおけるフォールバック」をご参照ください。

- アップグレード前のログファイルの扱いは、移行前バージョンにより異なります。

• V10.1/10.5 からの移行であれば、アップグレード前の未アーカイブ・ログ・ファイルは上位レベルからアーカイブされるため、アクションは不要です。

• V9.7からのアップグレードでは、未アーカイブ・ログ・ファイルはアーカイブされず、アクティブログパスに残るため、手動でバックアップ/アーカイブ/管理する必要があります。

• どのログがDB2旧バージョンからのものかを確認する目的で、db2cklogコマンドを利用することができます。

> db2cklog CHECK 80 to 94 ARCHLOGPATH <path where logfiles stored>



§ DASの移行- DASはV9.7以降非推奨となりましたので、移行を行う必要はありません。

- sshが利用可能な環境であれば、Data Server Manager および Data Studioにてサーバー環境に接続することでGUIベースでサーバ構成や、コマンド実行などの操作を行うことができます。

• Windows環境でもIBM SSH Server を構成することでssh接続を利用可能となります

- 参考：SIL [Data Server Manager利用ガイド]• http://www.ibm.com/developerworks/jp/analytics/library/ba-dsm_guide/index.html


参考：V10.5FP7以降のバージョンにおけるフォールバック

§ バージョンアップ実施の際には、サービス再開前に移行後環境でのバックアップを取得することを強く推奨します。

§ V11.1では下記の方法によって、移行前に取得したバックアップ（V10.5FP7以降に限る）から新の状態までの回復も可能となりました。 (※単一インスタンスまたはpureScale環境の場合)- V10.5までは、V11.1移行後に生成されたログを適用することができませんでした。

- V11.1へインスタンス移行後、初回バックアップの取得前に障害が発生した場合、移行前環境がV10.5FP7以降のバージョンかつアーカイブロギングモードで運用されていた状況に限り、移行前環境で取得したバックアップ（オンライン/オフラインいずれも可）とロールフォワードによるV11.1の障害発生時点までの回復がサポートされます。

BackupImage

Log

A

ROLLFORWARD DATABASE

V10.5 FP7 or later

1. V11.1 DBの削除2. V11.1 インスタンスの削除3. V10.5 インスタンス作成4. Restore オンラインDBバックアップ5. RollFoward to ポイントインタイムA

6. V10.5インスタンスにてDBのアンカタログ7. db2iupgrade V10.5 ⇒ V11.1 インスタンス8. V11.1インスタンスにてDBのカタログ9. RollFoward to ポイントインタイム A and stop(RollForward 中にUPGRADE DATABASE が行われる）

Log Log Log Log

V11.1

SQL2463N で RollForward 停止

DB

DB

UPGRADE DB

Log

insert/update/deleteinsert/update/delete

ROLLFORWARD DATABASE

DB

アップグレード後に障害発⽣

V10.5 FP7 以降のバックアップ・イメージからリカバリーすることが可能 (※アーカイブロギングのDBに限る)アップグレードを経てロールフォワードが継続される


参考：V10.5FP7以降のバージョンにおけるフォールバック（例）

§ アップグレード後に障害が発生した後のフォールバック手順詳細の例

- V11.1での作業

1. db2 deactivate db <db_name>2. db2 drop db <db_name>3. db2stop4. (必要に応じて）アーカイブログのバックアップ

5. db2idrop <instance_name>6. インスタンスホームにアップグレード前のsqllib（ディレクトリー名：sqllib_v105）が存在する場合は削除（残

っていると後続作業が失敗）


参考：V10.5FP7以降のバージョンにおけるフォールバック（例）続き

- V10.5での作業

1. db2icrt –u <fenced_user> <instance_name>2. db2start3. db2 restore db <db_name> from <bkup_directory> taken at <timestamp>

（V11.1へアップグレードする前に取得したオンラインバックアップもしくはオフラインバックアップをリストア）

4. （必要に応じて）アーカイブログのリストア

5. db2 rollforward db <db_name> to end of logs もしくは to YYYY-MM-DD-hh.mm.ss using local time→「SQL2463N The roll forward stopped because the rollforward utility has reached an upgrade operation in the

logs.」が返される

6. db2 list db directory（対象DBのdbpathを確認）

7. db2 uncatalog db <db_name>8. db2stop

- V11.1での作業

1. db2iupgrade –u <fenced_user> <instance_name>2. db2start3. db2 catalog database <db_name> on <dbpath>

（前手順No.6で確認したdbpathを指定）

4. db2 rollforward db <db_name> to end of logs もしくは to YYYY-MM-DD-hh.mm.ss using local time and stop


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

52


（ケース３）


（ケース１）


















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

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

§ この移行シナリオの特徴- DB2 9.7,10.1,10.5 の既存インスタンスは保存し、新規のインスタンスへ移行する。

- 移行にはBACKUP/RESTOREを使用する。

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

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

MIGDB

V9.7/10.1/10.5 インスタンス

MIGDB

UserExit,外部モジュール等

BACKUPイメージ

BACKUP RESTORE


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

§ V9.5以前のバックアップからの復元はできない- V9.5以前のバージョンからの移行の場合は、「3-3-3. データ移動ユーティリティを使用した移行」の手順を使

用してください。

§ V9.7, 10.1, 10.5 のバックアップをV11.1に復元後、V9.7, 10.1, 10.5 時のログは適用できない。- バージョンアップ前のログは適用不要な状態にした上で、オフライン・バックアップを取得する必要があります。

- 新規インスタンスでのログ適用を行う必要や、オンラインバックアップからの移行をしたい場合は、この章の説明と併せて、「参考：オンライン・バックアップ・イメージからの移行」を参照してください。

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

- また、プラットフォーム・ファミリー間でのリストアもできません。

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

• [異なるオペレーティング・システムおよびハードウェア・プラットフォーム間のバックアップおよびリストア操作]https://www.ibm.com/support/knowledgecenter/ja/SSEPGG_11.1.0/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によるデータベースの移行




＊「移行前のタスク」については、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 <変数名> <設定値>


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

$ db2set -all[i] DB2COMM=TCPIP[g] DB2SYSTEM=vmx-006-148[g] DB2INSTDEF=db2inst3$ db2set DB2_PARALLEL_IO=*$ db2set -all[i] DB2COMM=TCPIP[i] DB2_PARALLEL_IO=*[g] DB2SYSTEM=vmx-006-148[g] DB2INSTDEF=db2inst3$ su -root のパスワード:# cd /opt/ibm/db2/V11.1/adm# ./db2set -g DB2_PARALLEL_IO=*# ./db2set -all[i] DB2_DATABASE_CF_MEMORY=100[i] DB2COMM=TCPIP[g] DB2SYSTEM=vmx-006-148[g] DB2INSTDEF=db2inst3[g] DB2_PARALLEL_IO=*

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

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



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

- BACKUP DBコマンドの実行

• BACKUP DBは、移行前のデータベースが存在するV9のインスタンスにて行います。

• シナリオの考慮点でも記述しましたが、• オフラインバックアップが必要であること

• 移行後には、移行前のログは適用できないことに注意してください。

• BACKUPコマンドの実行（DISK上に取得する場合）

>db2 backup db <DB名> to <BACKUP先>

- RESTORE DBコマンドの実行

• 上記のBACKUP DBコマンドにて取得したバックアップ・イメージを新規のV11.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 DB xxxxx REDIRECTのセクション

RESTORE DATABASE SAMPLE-- USER <username>-- USING '<password>'FROM '/backup'TAKEN AT 20160629114008-- ON '/home/db2inst1'-- DBPATH ON '<target-directory>'INTO SAMPLE-- NEWLOGPATH '/home/db2inst1/db2inst1/NODE0000/SQL00001/LOGSTREAM0000/'-- WITH <num-buff> BUFFERS-- BUFFER <buffer-size>-- REPLACE HISTORY FILE-- REPLACE EXISTINGREDIRECT-- PARALLELISM <n>WITHOUT ROLLING FORWARD-- WITHOUT PROMPTING

RESTORE DBで指定可能なオプション

がコメントアウトされて記述されている。

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

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



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

- SET TABLESPACE CONTAINERSのセクション

• 現行環境の表スペースがDMS・SMSで作成されている場合に出力

＜省略＞

-- *****************************************************************************-- ** 表スペース名 = USERSPACE1-- ** 表スペース ID = 2-- ** 表スペース・タイプ = データベース管理スペース

-- ** 表スペース・コンテンツ・タイプ = すべての永続データ。 LARGE 表スペース。

-- ** 表スペース・ページ・サイズ (バイト) = 8192-- ** 表スペース・エクステント・サイズ (ページ) = 32-- ** 自動ストレージの使用 = いいえ-- ** ストレージ・グループ ID = -1-- ** ソース・ストレージ・グループ ID = -1-- ** データ・タグ = なし

-- ** 自動サイズ変更有効 = いいえ

-- ** 合計ページ数 = 10000-- ** 使用できるページ数 = 9952-- ** 高水準点 (ページ) = 160-- *****************************************************************************SET TABLESPACE CONTAINERS FOR 2-- IGNORE ROLLFORWARD CONTAINER OPERATIONSUSING (FILE '/home/db2ins1/db2/ts_cont/USR0001.DAT' 10000

);

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



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

- SET STOGROUP PATHS FOR IBMSTOGROUPのセクション

• 現行環境の表スペースが自動ストレージで作成されている場合に出力

- RESTORE DATABASE SAMPLE CONTINUEのセクション

＜中略＞

-- *****************************************************************************-- ** ストレージ・グループ定義-- ** デフォルトのストレージ・グループ ID = 0-- ** ストレージ・グループ数 = 1-- *****************************************************************************-- *****************************************************************************-- ** ストレージ・グループ名 = IBMSTOGROUP-- ** ストレージ・グループ ID = 0-- ** データ・タグ = なし-- *****************************************************************************SET STOGROUP PATHS FOR IBMSTOGROUPON '/home/db2inst1';

-- *****************************************************************************-- ** リダイレクト・リストアの開始-- *****************************************************************************RESTORE DATABASE TEST CONTINUE;-- *****************************************************************************-- ** ファイルの終わり

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

スクリプトの後で、RESTORE CONTINUEを発行するセクション

バックアップ・イメージ中に記録されたストレージグループIBMSTOGROUPのストレージパスが記述されているため、リストア先DB環境で使用するストレージパスへ書き換える。


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

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

メージが必要です。

- 可用性要件から、オフライン・バックアップの取得が困難なシステムも想定されるため、派生シナリオとして、オンライン・バックアップで取得したバックアップ・イメージからの移行手順に言及します。

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

取得する必要がない。

- いったん現行と同じバージョンのインスタンスへとリストアを行った後で、DB2 11.1のインスタンス移行を行うため、移行先サーバに現行と同じバージョンの製品コードが必要。

- BACKUP/RESTOREとインスタンス移行の両方を行うため、必要な手順はやや多い。



MIGDB

V9.7/10.1/10.5 インスタンス

MIGDB

UseExit,外部モジュール等

BACKUPイメージ

BACKUP RESTORE

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


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

§ システム停止のタイミング- オンラインバックアップによる移行の場合、バックアップ取得中にシステムを稼働させることが可能ですが、

更新ログの適用（Rollforward）は現行環境と同じインスタンスの時点で実施する必要があります。

- そのため、移行先環境でのログ適用が完了する前に現行環境のシステムを停止し、V11.1へのアップグレード作業中は更新ログ発生を抑止する必要があります。

移⾏先環境

現⾏環境

オンラインBACKUP取得

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

現⾏環境で稼働システム停⽌移⾏先環境で稼働

OnlineBackup

移⾏前環境と同じバージョンのインスタンスへRESTORE ROLLFORWARD DATABASE V11.1への移⾏本番稼動

Log Log Log Log Log Log


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

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

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






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

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



69


（ケース３）


（ケース１）



















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

§ この移行シナリオの特徴- DB2 の既存インスタンスは保存し、新規のインスタンスへ移行する。

- データ移動ユーティリティを使用して、データの移行を行う。

- 移行元となるDB2のバージョンに依存せず移行可能。

- CodesetなどDB作成時に決定される属性を変更できる。



MIGDB

全バージョンのインスタンス

新規DB

EXPORT LOAD

移行データ

DDL

db2look CREATE

UserExit,外部モジュール等



移行オブジェクトの作成

移行データの抽出と投入



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

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












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

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

§ 新規データベースの作成- 移行データを格納するためのデータベースを新規に作成してください。

- 下記の項目については、データベース作成時点で決定しておく必要があります。デフォルトの設定から変更する必要がある場合はデータベースの作成コマンドで指定してください。

• データベースのCodeset、Teritorry、Collate• 移行前とcodesetを変更した場合は、表定義のCHAR, VARCHARの文字列長を変更を検討する必要がある。

• データベース・ディレクトリー

• システムカタログ表スペース

• システム一次表スペース（手動にて作り直しが可能）

• アクティブログディレクトリ（DB構成パラメーターより変更可能）

• 自動ストレージを使用するかどうか（DB2 11.1では、デフォルトでON）• 自動ストレージを使用する場合、システムカタログ表スペースはDMSで作成されます。

• 自動ストレージを使用しない場合は、これまでと同様SMSで作成されます。

• 自動ストレージ使用の有無は、データベース作成のタイミングで決定する必要があり、データベース作成後に切り替えることはできません。

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

• http://www.ibm.com/support/knowledgecenter/SSEPGG_11.1.0/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の出力で明示的に付加されたスキーマが不一致を起こす可能性があります。

• SJISからUnicodeなど、DBのcodesetを変更する場合、表定義におけるCHAR, VARCHAR列長の定義を見直してください。











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 lobsinfileselect * 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 <テーブル名>;


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


（ケース３）


（ケース１）












3-3-2章 DBバックアップ取得(backup db) 3-3-3章移行データの

抽出(EXPORTコマンド)





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

§ シナリオに共通して必要な移行後のタスク- 移行の残作業

- 移行に伴う変更のチェック

- その他の作業


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

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

§ 移行の残作業• アダプティブ圧縮設定の調整

• 一時的に拡張したログ領域、カタログ表領域を縮小

• 自動ストレージ表スペースのメディア属性の確認

• データベースをアクティブにしてステータスを確認

• 移行後のアプリケーションのパフォーマンスを確認

• EXPLAIN表の移行

• パッケージの再バインド

• USEREXITの再作成もしくは移行

§ 移行に伴う変更のチェック• 変更、追加されたレジストリー変数、構成パラメータを確認

• グローバル・プロファイル・レジストリー変数の移行

§ その他の作業• 統計情報の更新

• イベント・モニター表の移行

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

• 移行済みのルーチンより、PUBLICなEXECUTE特権を削除

• LARGE DMS表スペースへの移行

• ログ・スペース・サイズの調整

• 移行後バックアップ


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

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

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

ク行圧縮が有効になります。

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

- 手順は以下のとおりです。

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

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

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

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

• ALTER TABLE ステートメントに COMPRESS YES ADAPTIVE 節を指定して実行し、アダプティブ圧縮を有効にします。既存のデータ行の変更および新規行の挿入には自動的にアダプティブ圧縮が適用されます。

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

- 参照[アダプティブ圧縮設定の調整]

• http://www.ibm.com/support/knowledgecenter/ja/SSEPGG_11.1.0/com.ibm.db2.luw.qb.upgrade.doc/doc/t0059313.html


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

§ 一時的に拡張したログ領域、カタログ表領域を縮小- 3-3-1章で、移行のための一時的なテーブルスペース領域、ログ領域の拡張をガイドしました。

- 移行のために一時的に拡張した領域がある場合は、移行の完了後に元のサイズに戻すことが可能です。

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

»実行コマンド例

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

• ただし、RAW-DMSを使用している場合は、ALTER TABLESPACEコマンドでコンテナサイズを縮小させても、OS側から見たコンテナ領域は開放されません。


>db2 "alter tablespace TS1 resize ( all 1000 m )"

[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

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

この例では、TS1を構成するすべてのコンテナを、それぞれ1000MBに縮小しています。ただし、テーブルスペースのハイ・ウオーター・マークよりも小さくすることはできません。ハイ・ウオーター・マークは、db2pdコマンドの -tablespaceオプション、またはMON_GET_TABLESPACE および MON_GET_CONTAINER 表関数で確認することができます。



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

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

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

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

§ 自動ストレージ表スペースのメディア属性の確認- 自動ストレージ表スペースは、OVERHEAD、TRANSFERRATE、DATA TAGを、その表スペースがデフォ

ルトで使用するストレージ・グループから継承します。

- V11.1 へのアップグレード後は、既存表スペースに対する設定は維持されますが、ストレージグループのOVERHEAD、TRANSFERRATE、DATA TAGは未定義の状態となります。必要に応じて、ALTERSTOGROUPステートメントを用いて再設定を行います。

- ストレージ・グループの各種設定値は、SYSCAT.STOGROUPSビューにて確認することができます。



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

• >db2 activate db <DB名>

- ハードウェア移行によるメモリサイズの変更、メモリの設定変更などがあれば、データベースの活動化後に、バッファー・プールが問題なくアクティブになるかどうかを確認してください。

• そのため、ACTIVATE DATABASEコマンドが成功したことを確認後に、管理通知ログを参照して下記のメッセージが出力されていないことを確認してください。

[db2inst3]$ db2 activate db migdbDB20000I ACTIVATE DATABASE コマンドが正常に完了しました。

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



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

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



§ EXPLAIN表の移行- UPGRADE処理の中では、EXPLAIN表の移行は実施されません。

- 移行以前に取得したEXPLAIN情報を、移行後のEXPLAIN表に残しておく必要がある場合は、db2exmigツールを使用して、EXPLAIN表の移行処理を行ってください。

- 移行以前のEXPLAIN情報を残す必要がない場合は、EXPLAIN表をすべて削除後に、バージョン11.1で提供されているDDLを利用してEXPLAIN表を再作成することも可能です。

• DDLの所在 <インスタンスHOME>/sqllib/misc/EXPLAIN.DDL

db2exmigコマンドの使用例

$ db2exmig -d sample -e db2inst4DB2 Universal Database Version 11.1, 5622-044 (c) Copyright IBM Corp. 1999, 2015Licensed Material - Program Property of IBMIBM DATABASE 2 Explain Table Migration Tool

Connecting to the Database.Connect to Database Successful.Binding package - Bind was SuccessfulMigrating Explain Tables from v9.7FP1 or later to current release.Examining the columns for table DB2INST4.EXPLAIN_INSTANCEFound table DB2INST4.EXPLAIN_STATEMENT. No changes required for this migration.Found table DB2INST4.EXPLAIN_ARGUMENT. No changes required for this migration.Examining the columns for table DB2INST4.EXPLAIN_OBJECTFound table DB2INST4.EXPLAIN_OPERATOR. No changes required for this migration.Examining the columns for table DB2INST4.EXPLAIN_PREDICATE＜略＞



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

効となっています。無効になったパッケージの再バインドを行う必要があります。

- ドロップした表、ビュー、別名、索引、トリガー、参照制約、表チェック制約などのデータベース・オブジェクトに依存するパッケージも、無効な状態になります。UDF をドロップすると、パッケージは作動不能な状態になります。

- 無効となったオブジェクトは、SYSCAT.INVALIDOBJECTSビューにて確認することができます。

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

- ADMINREVALIDATE_DB_OBJECTSプロシージャーを用いると、無効になったオブジェクトを全て再有効化することも、オブジェクト種別（ビュー、トリガー、プロシージャーなど）、スキーマ、特定オブジェクトを指定して個別に再有効化することもできます。



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

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

すべてのパッケージの再バインドを行います。

$ db2rbind sample -l db2rbind.log all

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

$ cat db2rbind.log

Starting time .... Mon Jun 27 19:34:13 2016

Package 'DB2INST4.P528204279' of database 'SAMPLE' succeeded to rebind. UniqueID = 4241747051624767Package 'NULLID.AGGDISC' of database 'SAMPLE' succeeded to rebind. UniqueID = 3138313930300＜省略＞

Package 'SYSIBMINTERNAL.P1777086123' of database 'SAMPLE' succeeded to rebind. UniqueID = 4141537051624767Package 'SYSPROC.P379831660' of database 'SAMPLE' succeeded to rebind. UniqueID = 7441507051624767

Succeeded to rebind = 333Failed to rebind = 0 (or more)

Ending time .... Mon Jun 27 19:34:34 2016


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

§ 変更、追加されたレジストリー変数、構成パラメータを確認- 過去バージョンで非推奨、または廃止されたレジストリー変数の除去を検討してください。

- DB2 9.5で廃止、非推奨になったレジストリーおよび構成パラメータ

• DB2 9.5 で非推奨になったレジストリー変数http://www.ibm.com/support/knowledgecenter/ja/SSEPGG_9.5.0/com.ibm.db2.luw.wn.doc/doc/i0052033.html

• DB2 9.5 で廃止されたレジストリー変数http://www.ibm.com/support/knowledgecenter/SSEPGG_9.5.0/com.ibm.db2.luw.wn.doc/doc/i0052379.html

• DB2 9.5 で非推奨になったデータベースマネージャー構成パラメータhttp://www.ibm.com/support/knowledgecenter/ja/SSEPGG_9.5.0/com.ibm.db2.luw.qb.migration.doc/doc/r0022380.html

• DB2 9.5 で非推奨および廃止になったデータベース構成パラメータhttp://www.ibm.com/support/knowledgecenter/ja/SSEPGG_9.5.0/com.ibm.db2.luw.qb.migration.doc/doc/r0022380.html


• DB2 9.7 で非推奨になったレジストリー変数https://www.ibm.com/support/knowledgecenter/ja/SSEPGG_9.7.0/com.ibm.db2.luw.wn.doc/doc/i0052033.html

• DB2 9.7 で廃止されたレジストリー変数http://www.ibm.com/support/knowledgecenter/SSEPGG_9.7.0/com.ibm.db2.luw.wn.doc/doc/i0052379.html

• DB2 9.7 で非推奨になったデータベースマネージャー構成パラメータhttps://www.ibm.com/support/knowledgecenter/ja/SSEPGG_9.7.0/com.ibm.db2.luw.qb.upgrade.doc/doc/r0022380.html

• DB2 9.7 で非推奨および廃止になったデータベース構成パラメータhttps://www.ibm.com/support/knowledgecenter/ja/SSEPGG_9.7.0/com.ibm.db2.luw.qb.upgrade.doc/doc/r0022380.html


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

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

• DB2 10.1 で非推奨または廃止されたレジストリー変数http://www.ibm.com/support/knowledgecenter/ja/SSEPGG_10.1.0/com.ibm.db2.luw.wn.doc/doc/i0052033.html

• DB2 10.1 で非推奨または廃止されたデータベース構成パラメータhttp://www.ibm.com/support/knowledgecenter/ja/SSEPGG_10.1.0/com.ibm.db2.luw.wn.doc/doc/i0058741.html






• DB2 11.1 で非推奨または廃止されたデータベースマネージャー構成パラメータhttp://www.ibm.com/support/knowledgecenter/ja/SSEPGG_11.1.0/com.ibm.db2.luw.wn.doc/doc/i0052553.html



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

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

定を行うことが可能です。

- V9.1から、グローバル・レジストリー変数のスコープが変更されています。

• V8.2まで：同一サーバ上の、同じバージョンのインスタンスすべてで共通。

同一サーバに、V7とV8が共存していた場合は、V7とV8で異なるグローバル・レジストリー変数を持つ。

• V9.1から：同じ導入パスから作成されたインスタンスで共通。

- グローバル・レジストリー変数はインスタンス移行の際に、移行されません。

- 移行後のインスタンスで同じグローバル･レジストリー変数の設定が必要な場合、手動で再設定してください。

- 実行コマンドの例• >$DB2DIR/adm/db2set –g <変数名>=<設定値>

$ db2set -all$ su -root のパスワード:# cd /opt/IBM/db2/V11.1/adm# ./db2set -g DB2COMM=TCPIP# exit$ db2set -all[g] DB2COMM=TCPIP

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

rootユーザーで実行する。


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

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

§ 統計情報の更新- 移行作業が完了し、移行後のパフォーマンス測定の結果問題なく移行できたことが確認できた後に、DB2

11.1での統計情報取得を計画してください。

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

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

§ イベント・モニター表の移行- DB2 11.1では、以前のバージョンで作成した既存のイベント・モニター表をアップグレードできるようになりま

した。

- アップグレードには EVMON_UPGRADE_TABLES プロシージャーを使用します。手動による表定義の変更、または表の再作成は必要ありません。

- 参照• 「リリース間でのイベント・モニター・データの保持」

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


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

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

§ 以前のバージョンのDB2をアンインストール- 同一サーバ上で移行を行い、DB2 11.1と以前のバージョンのDB2が共存している場合は、移行タスクが完

了して以前のバージョンのDB2が不要になったタイミングで、アンインストールを行ってください。

- アンインストールの方法

• Windowsプラットフォームの場合は「アプリケーションの追加と削除」から除去してください。

• UNIX/Linuxプラットフォームで、DB2提供のツールを使用してインストールした場合、アンインストールには製品CD上に提供されているdb2_deinstallコマンドを使用してください。

• SMITのような、OSネイティブのツールを使用してインストールした場合は、アンインストールにも同じツールを使用してください。


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

§ ログ・スペース・サイズの調整- DB2 V10.1にて、ログ・レコード・ヘッダーのサイズが大きくなりました。

- DB2 9.7以前のバージョンからのアップグレードを行う場合には、ログサイズの拡張を検討してください。

• ログ出力領域として約10-15%増加• 関連するDB構成パラメーター： logfilsiz / logprimary / logsecond

• logbufsz / softmax を約10-15%増加• logfilsiz DB構成パラメーターの変更をランタイムに反映させるには、DBの再活動化が必要となります

• softmax DB構成パラメーターは、V10.5で非推奨となっており、将来のリリースで削除される可能性があります

- (参考) DB2 11.1 KnowledgeCenter[アップグレード済みデータベースのログ・スペース・サイズの調整]• https://www.ibm.com/support/knowledgecenter/ja/SSEPGG_11.1.0/com.ibm.db2.luw.qb.upgrade.doc/doc/t0023289.html

- (参考) DB2 11.1 KnowledgeCenter[ログ・レコード・ヘッダー]• https://www.ibm.com/support/knowledgecenter/ja/SSEPGG_11.1.0/com.ibm.db2.luw.apdv.api.doc/doc/r0024864.html

- (参考) DB2 9.7 KnowledgeCenter[ログ・マネージャー・ヘッダー]• https://www.ibm.com/support/knowledgecenter/ja/SSEPGG_9.7.0/com.ibm.db2.luw.apdv.api.doc/doc/r0024864.html


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

§ フォールバックについて- DB2 11.1への移行後に、DB2提供のユーティリティ等を使用して移行元のバージョンに逆移行することはで

きません。

- そのため、バックアップからのリストアを前提としてフォールバックを計画する必要があります。

§ DB2の観点から、回復を計画する必要があるリソース- DB2製品コード

• システムバックアップのリストアにより復旧

- インスタンス、外部ファイル

• システムバックアップのリストアにより復旧

• 共有ディスクに配置されている場合は、インスタンスホームのバックアップからのリストア、あるいはインスタンスの再作成

- データベース• データベースのリストアにより復旧

- DB2クライアント

• 旧バージョンの再導入と、接続構成定義の適用により復旧



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

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

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

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

DB2製品コード

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

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

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

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

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

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

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

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

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

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



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

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

- 何らかの理由でシステムバックアップのリストアが難しい場合、下記のような手順でインスタンスを復旧することが可能です。

• DB2 11.1のデータベース、インスタンスを削除する。

• DB2 11.1の製品コードをアンインストール（製品コードの共存が不可能な場合）

• 移行元バージョンの製品コードを再導入（製品コードの共存が不可能な場合）

• db2icrtコマンドを使用して、移行前のインスタンスを再作成

• 移行前に取得したレジストリー変数、データベース・マネージャー構成パラメーターを再度設定

• USEREXITやストアドプロシージャー等外部ファイルを復旧

• （後続作業のデータベースリストアを実施）

§ データベースの復旧について- データベースの復旧にはRESTORE DATABASEコマンドを使用してください。

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



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

- DB2クライアントの復旧は、下記の手順で実施可能です。

• Windowsプラットフォームの場合• DB2 11.1のDB2クライアント製品コードをアンインストールする。（製品コードの共存が不可能な場合）

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

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

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

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

• Linux/UNIXプラットフォームの場合• 復旧対象のクライアント・インスタンスを削除する。

• 移行元バージョンのクライアント・インスタンスを作成する。

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

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

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


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

§ クライアント移行の方針- 移行計画をシンプルにするためには、DB2サーバと同期してDB2クライアントを移行してください。この場合、

異なるバージョン間の接続を考慮する必要はありません。

- しかし、DB2サーバと同期してクライアント移行を行うことが難しい場合、DB2サーバが先行して移行されるように、移行シナリオを検討してください。

- DB2サーバを先行して移行する形態の場合、現在のDB2クライアントがDB2 11.1のDB2サーバと接続可能かどうかを DB2 Systems Requirementsサイトで確認してください。

• DB2 Systems Requirements > Prerequisities > Database Connectorshttp://www.ibm.com/support/docview.wss?uid=swg27038033


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

§ アップグレードのオプションについて- アップグレード・オプションは、インストールするクライアントのタイプによって異なります。

- 次の表で、DB2 11.1 クライアントのタイプ別アップグレード・オプションについて説明します。

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

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

DB2 11.1 Data Server Client(Windows)

以下の 2 つのオプションがあります。

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

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

DB2 11.1 Data Server Runtime Client(Windows)

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

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

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

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



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

• 現行のクライアント・インスタンスをそのまま移行する方法• この形態がサポートされるのは、移行元のDB2クライアントがDB2 9.7、10.1、10.5 の場合のみです。これは、DB2サーバの移行処

理サポート対象と同様です。

• DB2 11.1のクライアント・インスタンスを新規作成する方法• DB2 9.5 以前のDB2クライアントからの移行を行う場合はこの方法を使用する必要があります。

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



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

• 移行対象サーバへDB2 11.1のクライアントをインストールする。

• rootユーザーもしくは管理者権限でログオンする。

• db2iupgradeコマンドを使用してクライアント・インスタンスをV11.1へ移行する。

• インスタンスオーナーからクライアント・インスタンスを開始する。

• 「DB2クライアントの移行後タスク」を実施する。

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

• インスタンスの移行を行う場合は、「3-3-1. 同一インスタンスでの移行」のdb2iupgradeコマンド実行方法を参考として実施してください。

- DB2クライアントの移行後タスクについて

• db2iupgradeコマンドの処理中にカタログ情報の移行が行われますが、移行されたカタログ情報が正常かどうかを確認するため、DB2サーバへの接続確認を行ってください。



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

• 移行対象サーバへDB2 11.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 <インスタンス名>



6. 環境によって必要となるタスク

§ Q/SQLレプリケーション環境の移行- DB2 11.1ではQ/SQLレプリケーションのアーキテクチャー・レベル(ARCH_LEVEL)は1021になります。

- 1021以前のARCH_LEVELで稼働している場合は、制御表のマイグレーションが必要になります。

• DB2 10.5 FP7以上であればARCH_LEVEL=1021です。

- ソースとターゲットのバージョンが異なる場合は、サポートされる組み合わせを確認し、移行順を検討してください。

• Qレプリケーションの互換性https://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.swg.im.iis.repl.qmig.doc/topics/iiyrqmigcoexistluw1021.html• SQLレプリケーションの互換性https://www.ibm.com/support/knowledgecenter/ja/SSTRGZ_10.2.1/com.ibm.swg.im.iis.db.repl.sqlmig.doc/topics/iiyrsmigcoexistluw1021.html

- 提供されたスクリプトを実行してマイグレーションを実施してください。詳細はこちらを参照してください。• Q Replication ARCH_LEVEL 1021 へのマイグレーション (Linux、UNIX、および Windows)https://www.ibm.com/support/knowledgecenter/ja/SSTRGZ_10.2.1/com.ibm.swg.im.iis.repl.qmig.doc/topics/iiyrqmigluw1021ovu.html• Linux、UNIX、および Windows での SQL Replication ARCH_LEVEL 1021 へのマイグレーションhttps://www.ibm.com/support/knowledgecenter/ja/SSTRGZ_10.2.1/com.ibm.swg.im.iis.db.repl.sqlmig.doc/topics/iiyrsmigluw1021.html

（※注意）ただし、11.1 GA版にはマイグレーション・スクリプトが含まれていないという問題があります。

こちらを参照してください。http://www.ibm.com/support/docview.wss?uid=swg21987948


6. 環境によって必要となるタスク（続き）

§ HADR環境の移行- HADR環境の移行については、HADR環境のアップグレードガイドをご参照ください。

- developerWorks [DB2 HADR環境のアップグレード手順ガイド] (2016年10月公開)http://www.ibm.com/developerworks/jp/analytics/library/ba-db2_hadr_upgrade/

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

のDB2コピーとしてインストールした後にインスタンスを移行することをお勧めします。

- このガイド中では、Windowsプラットフォームについても、別のDB2コピーにインストール後にインスタンス移行を行う方法を、標準としてガイドしています。

- 参照• DB2 11.1 Knowledge Center [Microsoft Cluster Server 環境での DB2 サーバーのアップグレード]

http://www.ibm.com/support/knowledgecenter/ja/SSEPGG_11.1.0/com.ibm.db2.luw.qb.upgrade.doc/doc/t0022647.html


End of Document

112

Documents

DB2 for LUW 11.1 移行手順ガイド