DB2の勉強会 CLUB DB2の2012/5/25開催の勉強会資料です。なぜDB管理が必要かという説明と、DB2の管理コマンド・ツールの説明です。

1. 初心者歓迎！DB2の使い方②
管理ツール編
2012/05/25
日本アイ・ビー・エム ソフトウェア事業部
下佐粉 昭 (しもさこ あきら) rev. 3

2. 自己紹介
下佐粉 昭 ( しもさこ あきら )
和歌山県生まれ
2001年 IBMに中途入社
以来、DB2関連の仕事多し
現在はビジネスパートナー様向け技術支援
■書籍
「即戦力のDB2管理術」
– http://db2.jugem.cc/?eid=2341 （書籍紹介）
「XML-DB開発 実技コース」（共著）
「DB2 逆引きリファレンス」（共著)
■オンライン
Twitter - @simosako 全内容をWEBで公開しています
– http://twitter.com/simosako http://db2watch.com/
Unofficial DB2 Blog
– http://db2.jugem.cc/
2

3. 今日のテーマ：DB2管理の基本を理解する
SQLは、大まかには多くのデータベースで共通
でも、管理コマンドはデータベースごとに全然違う
–必要な「理由」はだいたい同じ
重要なのは、「なぜその管理作業が必要なのか？」の理解
【今日のテーマ】
•なぜ必要か？を理解しましょう！
•最低限の管理が実行できるように、DB2コマンドの基礎を把握しましょう！
3

4. 目次
DB2の運用管理 - 最低限必要な管理
– データベースの管理とは？
• バックアップ
• 表の再編成
• 統計情報の更新
– 管理の自動化
この資料の記述は、DB2 10.1を対象にしています
4

5. データベースの管理とは？
データベースは、他のソフトウェア・ミドルウェアとは異なる特性がある
何が異なるのか
– データ量は増え続ける
– トランザクション量は増え続ける
– 実行されるSQLは変化していく
データベースは作ってから、別のフェーズが始まる
– 動いていて同然
– 止まると怒られる
定期的なメンテナンス（管理）が必要
5

6. データベースの管理とは
バックアップ
表の再編成 日常的に必要となる管理作業
＝最低限必要な作業
統計情報の更新
6

7. バックアップはなぜ必要か？
DB管理者(DBA)の仕事で一番大切なのはバックアップ
– その他の管理については「する」・「しない」の選択の余地がある
– バックアップに「しない」は無い
• BIのような、全データが別のDB上にある場合は例外
RAIDはバックアップではない
– 運用ミスで削除したら戻せない
• 機械が故障する確率と、人間がミスする確率 RAID5
– バックアップがあれば、運用ミスもなんとかなります
表領域以外にログ（トランザクションログ）のバックアップが重要
– 本番運用では、ログはアーカイブログに設定する
最近は、リストア時間が重要なケースも増えている
7

8. 【復習】DB2のログ（トランザクションログ）
DB2のログは大きくアクティブ・ログとアーカイブ・ログに分類される
アクティブ・ログ：現在使用中（処理中）のログ。LOGPATHで指定したパスに置かれる
アーカイブ・ログ：使用済みのログファイル。LOGARCHMETH1で指定したパスにコピーされる
ログファイルの総量
DB CFGのLOGFILSZ , LOGPRIMARY,LOGSECONDパラメタで調整
循環ロギングとアーカイブロギング
–循環ロギング：古いログファイルを再利用して使いまわし、アーカイブしない ←デフォルト
–アーカイブロギング：ログを保存し、古いものはLOGARCHMETH1 にコピー ←本番DBはこちらに変更
–DB CFGのLOGARCHMETH1を設定（DISK:D:¥db2logarc¥ など）するとアーカイブロギングに
○循環ロギング ○アーカイブロギング
1 2次ログ 1 2 3 4 5
(LOGSECOND)
アクティブ・ログ
n 2 1 2 （LOGPATH）
アーカイブ・ログ LOGARCHMETH1
3 で指定したディレク
1次ログ アクティブ・ログ (LOGARCHMETH1)
トリへコピー
(LOGPRIMARY) （LOGPATH）
詳細は以下のURLを参照
http://pic.dhe.ibm.com/infocenter/db2luw/v10r1/index.jsp?topic=%2Fcom.ibm.db2.luw.admin.ha.doc%2Fdoc%2Fr0006082.html
8

9. バックアップとしてのログ
ログファイルがあると、
– イメージ全体をリストアした後に、ログを適用することでPoint in
time (任意の時間)にリストア可能に
• もし、Point in timeのリストアが不要の場合、LOGの管理をす
る必要はなくなります（一般的な本番用途ではLOGを保存し
ます）
例） 毎日、AM3時にフルバックアップしているシステムで、10月20日の
AM9時の時点までリストアしたい場合
1. 10/20 AM3時のバックアップをリストア
2. 保存しておいたログファイルを10/20 AM9時まで適用
リストアで戻る範囲 LOGの適用で任意の時間へ（ロールフォワード）
時刻
AM3 AM9
10/19 10/20 10/21
9

10. BACKUP
DB2のバックアップは、BACKUP DATABASEコマンドで行うのが基本
BACKUP DATABASE mydb TO backup_dir [INCREMENTAL [DELTA]] [COMPRESS]
– 機能
• データベース単位、表スペース単位でバックアップ
• 差分バックアップ可能 (INCREMENTAL [DELTA]キーワード)
• オンラインバックアップ可能(ONLINEキーワード)
• イメージの圧縮可能(COMPRESSキーワード)
• 必要なログファイルをバックアップイメージに含める事が可能(INCLUDEキーワー
ド)
– データだけでなく、構成パラメタやコンテナ(表領域のディスク）の物理位置等もバックア
ップされる
– OSのファイルコピーは使用しない
• ストレージの高速コピー機能を使用したい場合はSET WRITE SUSPENDコマンド
を使用する
10

11. DB2のバックアップ(全体の概念図)
表領域、ログの両方をバックアップする事が重要
オンライン・オフライン
どちらでも実行可能
表領域- CREATE TABLESPACE
Backupコマンドで指定した領域
Backup
コンテナ コンテナ コンテナ コマンド Backupファイル
表データそのものが入っている INCLUDE LOGSオプションでバック
アップファイルにLOGを含める
LOG領域- LOGPATHで指定
LOGARCHMETH1で指定した領域
logmgr
アクティブLOGフ プロセス アーカイブLOGファ
アーカイブLOGファ
アーカイブLOGファ
イル
ァイル イル
イル
トランザクションを記録したログ logmgrはアクティブLOGが一定のサイズに達すると
DB2より自動的に起動され、LOGARCHMETH1で指
定された先にLOGをコピーする
11

12. 差分バックアップ
差分バックアップ機能
– 変更点（差分）のみを取得する機能
– 累積（INCREMENTAL）かデルタ（INCREMENTAL DELTA）かを選択で
きる
INCREMENTAL
時間の経過
フル 累積 累積 累積
INCREMENTAL DELTA
時間の経過
フル デルタ デルタ デルタ
12

13. BACKUPオプションの選択
オフラインか、オンラインか
– オンラインバックアップ
• ログがアーカイブモードである事が必須条件
• イメージをリストアするにはログファイルも必要
– オフラインの方が高速
– オフライン状態を作るには、QUIESCE コマンドが便利
• http://pic.dhe.ibm.com/infocenter/db2luw/v10r1/index.jsp?topic=%2F
com.ibm.db2.luw.admin.cmd.doc%2Fdoc%2Fr0008635.html
差分バックアップのメリット
– バックアップ時間の短縮、ストレージ量の削減
差分バックアップのデメリット
– リストアに時間がかかる
– デルタの場合、途中の差分が無くなるとリストアできなくなる
– LOB列がある表は差分が取れない（BLOB,CLOB,DBCLOB）
フルバックアップと差分バックアップをうまく混合することで効果的なバックアップを実
現可能
13

14. 【参考】 WRITE SUSPEND,RESUMEコマンド
HDD（表領域）への書き込みを一時的に停止させて、ファイルコピーコマンドで
データ移動を行うためのコマンド
SET WRITE {SUSPEND | RESUME} FOR DATABASE
– 主に、高速コピー機能が付いたストレージ装置がある環境で使用される
– SUSPEND中はディスクへのI/Oが行われなくなる。
– ディスクI/Oが必要な処理はブロックされる
• ログバッファ(メモリ)に収まる範囲であれば更新処理も可能
考慮点がありますので、下記ガイドを参照してください
DB2 V9 運用管理ガイド：DB2 Split mirror概要
http://www-06.ibm.com/jp/domino01/mkt/dminfo.nsf/doc/00442F7F
14

15. リストア
リストアのためのコマンド
–RECOVER DATABASEコマンド
–RESTORE DATABASEコマンド＋ROLLFORWARDコマンド
RECOVER DATABASE db名 TO [END OF LOGS|時刻]
リストアの注意点
–時刻の指定方法に注意
• 本番運用ではUSING LOCAL TIME を指定しましょう（RECOVERのデ
フォルトですが）
• 例）RECOVER DB SAMPLE TO 2007-01-31-04.00.00 USING LOCAL
TIME
–BACKUPコマンドは、コンテナの物理的な位置を覚えている
• デバイスが無いと戻らない
• 別のデバイス、別のディレクトリに移動させるにはREDIRECT
RESTORE
15

16. 【参考】 DB2 10.1新機能：タイムトラベル照会
過去データへのアクセス機能
employees
EmpID Dept System_start System_end
CREATE TABLE時に履歴を保存するように設定 12345 M15 05/31/2000 12/31/9999
できる機能
履歴が自動記録される
– 履歴は拡張されたSELECT文で参照可能 employees_history
EmpID Dept System_start System_end
12345 J13 11/15/1995 01/31/1998
12345 M24 01/31/1998 05/31/2000
過去の特定時点でのデータを容易に参照可能 67890 K25 11/15/1995 03/31/2000
– 仕組みをアプリケーション側で実装不要 社員ID12345が所属する部署を得るSQL
– リスクとコストの削減、開発期間短縮 SELECT Dept FROM employees
WHERE EmpID=12345
社員ID12345が1997年12月1日に所属していた
用途：監査要件、コンプライアンス、 ... 部署を得るSQL
SELECT Dept FROM employees
FOR SYSTEM_TIME AS OF ’12/01/1997’
WHERE EmpID=12345
16

17. 表の再編成はなぜ必要か？
時間の経過と共に、データ領域は順番がばらばらに並ぶようになっていく
–データの更新、追加、削除の繰り返しが要因
–削除済みの領域は再利用される
–行の長さは一定では無いので、削除済みの場所に新しい行が入らない
場合も
並びがばらばらになると、速度が低下する
SELECT * FROM T WHERE ID < 5
初期状態
データがまとまっているので、ディスクアクセス
１ ２ ３ ４ が少なく済む
時間が経つと...
１ ３ ４ ２
データの順番がバラバラなので、複数回のディ
スクアクセス（ディスクヘッドの移動）が必要
17

18. REORG
DB2ではREORG コマンドでデータを並べなおす
– REORGを実行中に読み書きアクセス可能
並べなおす基準は？
1.REORG時にインデックスを指定 解放ページ範囲：スペース解放のための移動とクリーンアップ
2.クラスター・インデックス 空き
経
過
時
3.プライマリ・キー スペース
間
充填 ページ範囲：スペースを埋めるための移動とクリーンアップ
REORG TABLE テーブル名 [INPLACE] [ALLOW {READ|WRITE|NO} ACCESS]
REORG INDEXES ALL FOR TABLE テーブル名 [ALLOW {READ|WRITE|NO} ACCESS]
18

19. クラスター率と、クラスター・インデックス
更新処理が多い表は、時間が経過すると、クラスター率が低下していく
クラスター率とは
– データが「欲しい順番どおりに物理的に並んでいる率」
– 物理的に順番どおりに並んでいると、取り出すのが速い
クラスター・インデックスとは
– クラスター索引が作成された表ではキー値が近いものでかたまるように
INSERTされる
– 読み取ったページに次のキーが入っている確立が上がり、取り出しページ数
が少なく、効率が上がる
Cluster索引を作成する例
非Cluster索引 create table xxxxx (……..)
create index yyyyy on xxxx (….) cluster Cluster索引
Primary KeyとCluster索引を両方指定する例
create table xxxxx ( c1 integer not null, ……..)
create unique index yyyyy on xxxx (c1 asc) cluster
alter table xxxx add primary key (c1)
８データベージ（例：散らばっている） ４データベージ（例：かたまっている）
19

20. 【参考】REORGコマンド
REORGはオンライン動作可能
– REORG中にユーザーが対象のテーブル、インデックスにアクセス
可能
INPLACEを指定すると、インプレース動作
テーブルのREORG
REORG TABLE テーブル名 [INPLACE] [ALLOW {READ|WRITE|NO} ACCESS]
•ALLOW READ ACCESS - REORG中のテーブルへのアクセスを読み取りのみ許可
•ALLOW WRITE ACCESS - REORG中のテーブルへの読み書きアクセスを許可（INPLACE指定時にのみ指定可能）
•ALLOW NO ACCESS - REORG中のテーブルへのアクセスを禁止（INPLACEとの同時指定不可）
インデックスのREORG（テーブル毎）
REORG INDEXES ALL FOR TABLE テーブル名 [ALLOW {READ|WRITE|NO} ACCESS]
•ALLOW READ ACCESS - REORG中のインデックスへのアクセスを読み取りのみ許可
•ALLOW WRITE ACCESS - REORG中のインデックスへの読み書きアクセスを許可
•ALLOW NO ACCESS - REORG中のインデックスへのアクセスを禁止
20

21. REORGの考慮点（１）
オプションの選択
–シャドーコピーか、インプレースか
–実行中にアクセスを許す必要があるか
メリット デメリット
シャドーコピー 高速 表と同じサイズのテンポラリ領域が
必要
表と同時にインデックスの
REORGが可能 REORG中は書き込み不可
途中で一時停止できない
インプレース テンポラリ領域が不要 シャドーコピーと比較して遅い
REORG中の更新アクセス可能 同一表領域に10-20%の空きが必
要
一時停止、再開が可能
ログが増える
21

22. REORGの考慮点（２）
REORGの要・不要の判断
– 更新（INSERT/UPDATE/DELETE)が多い表に対してREORGを行う
– REORGCHKで判断
• デフォルトでRUNSTATSが事前に走る（後述）
ちゃんとした運用の場合、CURRENT STATISTICSで良いはず
• 「＊」が出たらREORGをスケジュールする
• 構造上、どうしても消えない「＊」はあります
REORG不要な表
– 追記のみで削除や更新がなく、増える一方の表（監査ログなど）
– データを丸ごと入れ替えた後は、参照のみの表（BIなど）
– MDCを使った表
REORGの回数を減らす
– PCTFREEの値
– レンジ・パーティショニング（DB2 9） - 巨大な表の場合
22

23. REORGCHKコマンド(1/2)
テーブルやインデックスが再編成必要かどうかを、判断する材料を提供する
ユーティリティー
REORGCHK [UPDATE STATISTICS|CURRENT STATISTICS] [ON TABLE テーブル名]
テーブル名を指定
•ALLを指定すると、全テーブルが対象に
•USERを指定すると、実行ユーザの所有する全テーブルが対象に
UPDATE STATISTICS - RUNSTATSで統計情報を更新後に実行（デフォルト）
CURRENT STATISTICS - 現在の統計情報で実行
８つの計算式を統計情報に適用して、その式の範囲から外れるテーブル、イン
デックスには＊印が付く(＊が多いほどREORGが必要)
23

24. REORGCHKコマンド(2/2)
実行例
※実行結果の一部を切り出したものです
表統計:
F1: 100 * OVERFLOW / CARD < 5
F2: 100 * (データ・ページ数の有効スペース使用率) > 70
F3: 100 * (必須ページ数/合計ページ数) > 80
式1～3
式1～3で範囲を超えたものは無い
SCHEMA.NAME CARD OV NP FP ACTBLK TSIZE F1 F2 F3 REORG
----------------------------------------------------------------------------------------
表: SIM.EMP_PHOTO 8 0 1 1 - 712 0 - 100 ---
----------------------------------------------------------------------------------------
索引統計:
F4: CLUSTERRATIO または正規化された CLUSTERFACTOR > 80
F5: 100 * (リーフ・ページで使用されたスペース / 空ではないリーフ・ページで使用できるスペース) > MIN(50, (100 - PCTFREE))
F6: (100 - PCTFREE) * (1 つ下のレベルの索引で使用できる合計スペース / すべてのキーで必要な合計スペース) < 100 式4～8
F7: 100 * (疑似削除された RID の数 / RID の合計数) < 20
F8: 100 * (疑似的な空のリーフ・ページ数 / リーフ・ページの合計数) < 20
SCHEMA.NAME INDCARD LEAF ELEAF LVLS NDEL F4 F5 F6 F7 F8 REORG
---------------------------------------------------------------------------------------
表: SIM.EMP_PHOTO
索引: SIM.PK_EMP_PHOTO 8 1 0 1 0 100 - - 0 0 -----
---------------------------------------------------------------------------------------
式4～8では範囲を越えたものは無い
24

25. 【参考】REORGCHKコマンドの結果
REORGCHKコマンドの結果からREORGを行うかどうかを判断する
– マニュアル「コマンド・リファレンス」のREORGCHKから引用
– http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.
db2.luw.admin.cmd.doc/doc/r0001971.html
索引を再編成する際の提案を以下に示します。
•公式 1、2、および 3 の計算結果がその公式によって設定された境界を超えない
で、 公式 4、5、または 6 の計算結果が設定された境界を超える場合、 索引を再
編成することをお勧めします。
•公式 7 の計算結果だけが設定された境界を超えて、公式 1、2、3、4、5、および
6 の結果は設定された境界内にある場合、 索引再編成の CLEANUP オプション
を使用して索引をクリーンアップすることをお勧めします。
•公式 8 の計算結果だけが設定された境界を超える場合、索引再編成の
CLEANUP PAGES オプションを使用して索引の疑似空白ページをクリーンアップ
することをお勧めします。
•admin_get_tab_info および admin_get_index_info 関数内の
RECLAIMABLE_SPACE 列に、表および索引の再利用可能なスペースの量 (キ
ロバイト) が示されます。この値を使用して、 RECLAIM EXTENTS オプションを指
定した再編成をいつ実行すべきか判断することができます。
RECLAIMABLE_SPACE の詳細、 およびスペース再利用の有効性を評価する
方法については、関連リンクを参照してください。
25

26. 統計情報の更新はなぜ必要か？
より良い「アクセスプラン（実行計画）」作成のため
データが大きく変更されたら統計情報を更新する必要がある
DB2クライアント
SQL
①SQLの書き換え
エージェント
②複数のアクセス
プラン候補を作成
統計情報
③コストの見積もり
④アクセスプランの
決定
26

27. RUNSTATS 多くの場合、この
基本形でOK
RUNSTATSコマンドで統計情報を更新する
RUNSTATS ON TABLE スキーマ名.表名
RUNSTATS ON TABLE スキーマ名.表名 AND INDEXES ALL
（※DB2 10.1からスキーマ名が省略可能になっています）
– RUNSTATS実行中でも表に読み書きアクセス可能
データに「偏り」がある場合、
少し進んだ使い方 拡張統計を試してください
– ①拡張統計で収集する
RUNSTATS ON TABLE スキーマ名.表名 WITH DISTRIBUTION
RUNSTATS ON TABLE スキーマ名.表名 WITH DISTRIBUTION AND SAMPLED
DETAILED INDEXES ALL
表を5%サンプリング
– ②サンプリングでRUNSTATSの実行時間を短くする
RUNSTATS ON TABLE SIM.DEPARTMENTS WITH DISTRIBTION TABLESAMPLE
BERNOULLI (5)
27

28. ■参考文献 「DB2 UDBバージョン8.2のRUNSTATS」（サンプル多数で分かりやすい）
http://ibm.com/jp/domino01/mkt/dminfo.nsf/doc/002B4A0C
補足：RUNSTATSのパターン
■基本統計を取得するケース
--- 表のみ
RUNSTATS ON TABLE スキーマ名.表名
--- インデックスのみ
RUNSTATS ON TABLE スキーマ名.表名 FOR INDEXES ALL
--- 表とインデックス両方
RUNSTATS ON TABLE スキーマ名.表名 AND INDEXES ALL
■拡張統計を取得するケース
--- 表のみ
RUNSTATS ON TABLE スキーマ名.表名 WITH DISTRIBUTION
--- インデックスのみ
RUNSTATS ON TABLE スキーマ名.表名 FOR DETAILED INDEXES ALL
--- 表とインデックス両方
RUNSTATS ON TABLE スキーマ名.表名 WITH DISTRIBUTION AND SAMPLED DETAILED INDEXES ALL
■サンプリングを実施するケース ※インデックスのサンプリング(INDEXSAMPLE)はDB2 10.1の新機能
--- 表のデータを5%、インデックスを10%のサンプリング
RUNSTATS ON TABLE SIM.DEPARTMENTS WITH DISTRIBUTION AND SAMPLED DETAILED INDEXES ALL
TABLESAMPLE BERNOULLI (5) INDEXSAMPLE BERNOULLI (10)
※以下マニュアルより引用、一部修正、追記をしたものです
http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.explain.doc/doc/r0021347.html
28

29. RUNSTATSはいつ実行すべきか
いつ統計情報を更新するのか？
– 実際のデータと統計情報の内容にずれが生じる時
• 初期データLOAD時
• 大量のデータ入れ替え時
• インデックスなど新しいオブジェクトを作成した時
自動化
– RUNSTATSの自動実行機能があり、デフォルトでON
やれば良いってものでもない
– 大規模DBで、アクセスプランがころころ変わるのは怖い
• 不要なら自動RUNSTATSをOFFにする
– 統計情報を更新する前にバックアップしておく
• db2lookの-mオプションでDDLを出力
• http://db2.jugem.cc/?eid=102
29

30. 管理の自動化
BACKUP,REORG,RUNSTATSは
自動実行可能です
–RUNSTATSはデフォルトでON
–決められたポリシーで自動実行
• 動作時刻（メンテナンスウィ
ンドウ）
• 対象表
など
–IBM Data Studioで設定可能
（DB2 9.7まではコントロールセン
ターで設定可能）
30

31. 自動RUNSTATSの補足：リアルタイム統計情報収集機能
自動RUNSTATS機能は、2時間間隔で表の更新をチェックする
→ 表の更新が頻繁だと、自動RUNSTATSが間に合わない
リアルタイム統計情報収集機能 (DB2 9.5から追加)
–表にアクセスした時点で統計情報が最適でないと判断すると、SQLを実行
前にRUNSTATSを実行
• 5秒以内に完了しないと中止→ファブリケート（fabricate,捏造）を利用
–DB CFG "AUTO_STMT_STATS"をONで設定（デフォルトでON）
自動保守 (AUTO_MAINT) = ON
データベース自動バックアップ (AUTO_DB_BACKUP) = OFF
リアルタイム統計情
表自動保守 (AUTO_TBL_MAINT) = ON 報収集機能
自動 RUNSTATS (AUTO_RUNSTATS) = ON
リアルタイム統計 (AUTO_STMT_STATS) = ON
統計ビュー (AUTO_STATS_VIEWS) = OFF
自動サンプリング (AUTO_SAMPLING) = OFF
統計プロファイル自動作成 (AUTO_STATS_PROF) = OFF
統計プロファイル更新 (AUTO_PROF_UPD) = OFF
自動再編成 (AUTO_REORG) = OFF
31

32. 管理の自動化：注意点
BACKUP
–2世代だけの保存＝最低限のバックアップ
–専任の運用管理者を置けない場合に有効
REORG
–動作時間と被らないように
–DB2の圧縮機能を使っている場合はディクショナリ更新をどうするか要検討
自動更新対象の表を限定する事も可能
RUNSTATS
–初期状態でON：更新頻度が高い表に対して実行される
–大規模DBでは要考慮
大規模DBでの使用は慎重に
32

33. まとめ
DB2では日常の管理用にコマンドが用意されている
–BACKUP
• 表領域、ログの両方を保存
–REORG
• プライマリ・キー、クラスター・インデックスを作成して並べ替えの
基準を
–RUNSTATS
• 中小規模では、自動化に任せても良い
• 大きめのケースではそれぞれの表で、RUNSTATSするかしな
いか、どのオプションで実行するかを決める
上記3つを、最初から運用計画に組み入れてください
–いつ、すべきか、すべきでないか
• リストアの手順も計画しておきましょう
–できればモニタリングも考慮
• SQLの処理速度、ディスクの使用量…
33

34. 参考資料
CLUB DB2の過去セミナー資料公開中
– http://ibm.com/developerworks/wikis/display/clubdb2/materials
カンタン！DB2テクテク第1歩 基本機能編
– 若干古い資料ですが、各種基本コマンドの使い方がやさしく解説されています
– http://ibm.com/jp/software/data/developer/library/techdoc/kantandb2.html
db2pd利用ガイド DB2 v9対応版
– 問題判別や監視に大変有用なdb2pdの使い方解説
– http://ibm.com/jp/domino01/mkt/dminfo.nsf/doc/00217BBA
DB2 Express-Cの導入方法解説（無料のDB2で試しましょう！）
– http://www.ibm.com/developerworks/jp/offers/db2express-c/installwin_v10/ (Windows)
– http://www.ibm.com/developerworks/jp/offers/db2express-c/installlin_v10/ (Linux)
34

35. 参考資料（マニュアル）
DB2のオンラインドキュメント：インフォメーションセンター
常に最新の情報が閲覧できます。検索機能付き
– DB2 10.1版
• http://pic.dhe.ibm.com/infocenter/db2luw/v10r1/index.jsp
– DB2 9.7版
• http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp
– DB2 9.5版
• http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp
DB2のPDF版マニュアル
日本語、英語など各国語版がダウンロード可能です
– DB2 9.7版
• http://ibm.com/support/docview.wss?rs=71&uid=swg27015149
– DB2 9.5版
• http://ibm.com/support/docview.wss?rs=71&uid=swg27009728
DB2の日本語ドキュメント一覧は以下の短縮URLからも辿れます
http://j.mp/db2docsja
35

36. 参考資料
以下のページは参考資料です
–良く使うDB2のコマンド
–DB2のプロセス一覧（抜粋）
–DB2の構成とパラメタ（復習）
36

37. 良く使うコマンド
良く使うDB2のコマンド
インスタンス開始 db2start
インスタンス停止 db2stop [force]
DB作成 db2 "CREATE DB db名 ..."
DB削除 db2 "DROP DB db名"
DB一覧表示 db2 "LIST DB DIRECTORY"
接続ユーザ一覧 db2 "LIST APPLICATIONS"
DBに接続 db2 "CONNECT TO db名 USER userid USING password"
接続解除 db2 "TERMINATE"
SQLを実行 db2 "任意のSQL"
db2 +c "任意のSQL" ←AUTO COMMITをOFFにして実行
ファイルに記録し （ファイルに;区切りでコマンドやSQLを記述しておいて）
たコマンドの実行
db2 -tvf ファイル名
37

38. 【参考】DB2のプロセス・スレッド構成
38

39. 【参考】 DB2のプロセス・スレッド一覧
以下は比較的重要なプロセス・スレッドのみの抜粋です
グループ プロセス名 備考
（スレッド名)
リスナー（接続の受付） db2ipccm 同一筐体からの接続を受け付け、共有メモリ経由で通信する
db2tcpcm TCP/IP接続を受け付ける
エージェント(SQLの実行） db2agent コーディネーターエージェント：クライアント毎に用意され、SQLの実行
を制御する
db2agntp サブエージェント： db2agentから呼び出されて処理の一部を請け負う
隔離モード制御 db2fmp ストアドプロシージャやユーザ定義関数を実行するプロセス
データベース関連のプロセ db2pfchr バッファー・プール・プリフェッチャー：データをディスクからバッフ
ス・スレッド ァープールに読み込む
db2pclnr ページ・クリーナー：ダーティーデータをディスクに書き出す
db2loggr ログ・ファイルからの読み出し、およびログファイル全体の制御
db2loggw ログ・ファイルへのログ・レコードの書き込み
db2dlock デッドロックの検出
インスタンス db2sysc インスタンス全体の親：インスタンスそのもの(Windowsでは
db2syscs.exe)
関連のプロセス・スレッド
db2wdog インスタンスの異常終了を監視し、リソースをクリーンアップ
（Linux/Unixのみ）
39

40. 【復習】 構成パラメタ
設定は構成パラメタの変更で行う システム（レジストリ）
DB2の構成パラメタは３種類 インスタンス (DBM CFG)
–影響範囲が異なる データベース (DB CFG)
–調整は、DBコンフィグが中心
影響範囲 取得 更新
レジストリ変数 システム全体も db2set [-all] db2set REG1=VAL1
しくはインスタン
ス内
データベースマ インスタンス内 GET DBM CFG UPDATE DBM CFG
ネージャ(DBM) USING cfg1 val1 [cfg2
構成パラメータ val2 ...]
ー
データベース データベース GET DB CFG FOR UPDATE DB CFG FOR
(DB)構成パラ db名 db名 USING cfg1 val1
メーター [cfg2 val2 ..]
40