初心者歓迎！DB2の使い方② 管理ツール編 (Club DB2)

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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）
フルバックアップと差分バックアップをうまく混合することで効果的なバックアップを実
現可能

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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]

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

24
REORGCHKコマンド(2/2)
表統計:
F1: 100 * OVERFLOW / CARD < 5
F2: 100 * (データ・ページ数の有効スペース使用率) > 70
F3: 100 * (必須ページ数/合計ページ数) > 80
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
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 -----
---------------------------------------------------------------------------------------
実行例
※実行結果の一部を切り出したものです
式1～3で範囲を超えたものは無い
式1～3
式4～8
式4～8では範囲を越えたものは無い

View Slide

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 の詳細、およびスペース再利用の有効性を評価する
方法については、関連リンクを参照してください。

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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
リアルタイム統計情
報収集機能

View Slide

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

View Slide

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

View Slide

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)

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

初心者歓迎！DB2の使い方② 管理ツール編 (Club DB2)

初心者歓迎！DB2の使い方② 管理ツール編 (Club DB2)

Akira Shimosako

More Decks by Akira Shimosako

Other Decks in Technology

Featured

Transcript