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

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/

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

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

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

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

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

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）

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の適用で任意の時間へ（ロールフォワード）

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

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

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

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

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

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|時刻]

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 履歴が自動記録される

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

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]

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索引 ８データベージ（例：散らばっている） ４データベージ（例：かたまっている）

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中のインデックスへのアクセスを禁止

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

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

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

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では範囲を越えたものは無い

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

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

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%サンプリング

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の新機能

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

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

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

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

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

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)

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

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

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] インスタンス停止

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

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

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 システム全体も しくはインスタン ス内 レジストリ変数 更新 影響範囲