DB2の使い方 管理ツール編

24,776
-1

Published on

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

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
24,776
On Slideshare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
115
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

DB2の使い方 管理ツール編

  1. 1. 初心者歓迎!DB2の使い方②管理ツール編2012/05/25日本アイ・ビー・エム ソフトウェア事業部下佐粉 昭 (しもさこ あきら) rev. 3
  2. 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. 3. 今日のテーマ:DB2管理の基本を理解する SQLは、大まかには多くのデータベースで共通 でも、管理コマンドはデータベースごとに全然違う –必要な「理由」はだいたい同じ 重要なのは、「なぜその管理作業が必要なのか?」の理解【今日のテーマ】•なぜ必要か?を理解しましょう!•最低限の管理が実行できるように、DB2コマンドの基礎を把握しましょう!3
  4. 4. 目次 DB2の運用管理 - 最低限必要な管理 – データベースの管理とは? • バックアップ • 表の再編成 • 統計情報の更新 – 管理の自動化 この資料の記述は、DB2 10.1を対象にしています4
  5. 5. データベースの管理とは? データベースは、他のソフトウェア・ミドルウェアとは異なる特性がある 何が異なるのか – データ量は増え続ける – トランザクション量は増え続ける – 実行されるSQLは変化していく データベースは作ってから、別のフェーズが始まる – 動いていて同然 – 止まると怒られる 定期的なメンテナンス(管理)が必要5
  6. 6. データベースの管理とは バックアップ 表の再編成 日常的に必要となる管理作業 =最低限必要な作業 統計情報の更新6
  7. 7. バックアップはなぜ必要か? DB管理者(DBA)の仕事で一番大切なのはバックアップ – その他の管理については「する」・「しない」の選択の余地がある – バックアップに「しない」は無い • BIのような、全データが別のDB上にある場合は例外 RAIDはバックアップではない – 運用ミスで削除したら戻せない • 機械が故障する確率と、人間がミスする確率 RAID5 – バックアップがあれば、運用ミスもなんとかなります 表領域以外にログ(トランザクションログ)のバックアップが重要 – 本番運用では、ログはアーカイブログに設定する 最近は、リストア時間が重要なケースも増えている7
  8. 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.html8
  9. 9. バックアップとしてのログ ログファイルがあると、 – イメージ全体をリストアした後に、ログを適用することでPoint in time (任意の時間)にリストア可能に • もし、Point in timeのリストアが不要の場合、LOGの管理をす る必要はなくなります(一般的な本番用途ではLOGを保存し ます) 例) 毎日、AM3時にフルバックアップしているシステムで、10月20日の AM9時の時点までリストアしたい場合 1. 10/20 AM3時のバックアップをリストア 2. 保存しておいたログファイルを10/20 AM9時まで適用 リストアで戻る範囲 LOGの適用で任意の時間へ(ロールフォワード) 時刻 AM3 AM910/19 10/20 10/219
  10. 10. BACKUPDB2のバックアップは、BACKUP DATABASEコマンドで行うのが基本 BACKUP DATABASE mydb TO backup_dir [INCREMENTAL [DELTA]] [COMPRESS] – 機能 • データベース単位、表スペース単位でバックアップ • 差分バックアップ可能 (INCREMENTAL [DELTA]キーワード) • オンラインバックアップ可能(ONLINEキーワード) • イメージの圧縮可能(COMPRESSキーワード) • 必要なログファイルをバックアップイメージに含める事が可能(INCLUDEキーワー ド) – データだけでなく、構成パラメタやコンテナ(表領域のディスク)の物理位置等もバックア ップされる – OSのファイルコピーは使用しない • ストレージの高速コピー機能を使用したい場合はSET WRITE SUSPENDコマンド を使用する10
  11. 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. 12. 差分バックアップ 差分バックアップ機能 – 変更点(差分)のみを取得する機能 – 累積(INCREMENTAL)かデルタ(INCREMENTAL DELTA)かを選択で きる INCREMENTAL 時間の経過 フル 累積 累積 累積INCREMENTAL DELTA 時間の経過 フル デルタ デルタ デルタ12
  13. 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. 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/00442F7F14
  15. 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 RESTORE15
  16. 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=1234516
  17. 17. 表の再編成はなぜ必要か? 時間の経過と共に、データ領域は順番がばらばらに並ぶようになっていく –データの更新、追加、削除の繰り返しが要因 –削除済みの領域は再利用される –行の長さは一定では無いので、削除済みの場所に新しい行が入らない 場合も 並びがばらばらになると、速度が低下する SELECT * FROM T WHERE ID < 5 初期状態 データがまとまっているので、ディスクアクセス 1 2 3 4 が少なく済む 時間が経つと... 1 3 4 2 データの順番がバラバラなので、複数回のディ スクアクセス(ディスクヘッドの移動)が必要17
  18. 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. 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) 8データベージ(例:散らばっている) 4データベージ(例:かたまっている)19
  20. 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. 21. REORGの考慮点(1) オプションの選択 –シャドーコピーか、インプレースか –実行中にアクセスを許す必要があるか メリット デメリット シャドーコピー 高速 表と同じサイズのテンポラリ領域が 必要 表と同時にインデックスの REORGが可能 REORG中は書き込み不可 途中で一時停止できない インプレース テンポラリ領域が不要 シャドーコピーと比較して遅い REORG中の更新アクセス可能 同一表領域に10-20%の空きが必 要 一時停止、再開が可能 ログが増える21
  22. 22. REORGの考慮点(2) REORGの要・不要の判断 – 更新(INSERT/UPDATE/DELETE)が多い表に対してREORGを行う – REORGCHKで判断 • デフォルトでRUNSTATSが事前に走る(後述) ちゃんとした運用の場合、CURRENT STATISTICSで良いはず • 「*」が出たらREORGをスケジュールする • 構造上、どうしても消えない「*」はあります REORG不要な表 – 追記のみで削除や更新がなく、増える一方の表(監査ログなど) – データを丸ごと入れ替えた後は、参照のみの表(BIなど) – MDCを使った表 REORGの回数を減らす – PCTFREEの値 – レンジ・パーティショニング(DB2 9) - 巨大な表の場合22
  23. 23. REORGCHKコマンド(1/2) テーブルやインデックスが再編成必要かどうかを、判断する材料を提供する ユーティリティー REORGCHK [UPDATE STATISTICS|CURRENT STATISTICS] [ON TABLE テーブル名] テーブル名を指定 •ALLを指定すると、全テーブルが対象に •USERを指定すると、実行ユーザの所有する全テーブルが対象に UPDATE STATISTICS - RUNSTATSで統計情報を更新後に実行(デフォルト) CURRENT STATISTICS - 現在の統計情報で実行 8つの計算式を統計情報に適用して、その式の範囲から外れるテーブル、イン デックスには*印が付く(*が多いほどREORGが必要)23
  24. 24. REORGCHKコマンド(2/2) 実行例 ※実行結果の一部を切り出したものです表統計:F1: 100 * OVERFLOW / CARD < 5F2: 100 * (データ・ページ数の有効スペース使用率) > 70F3: 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 > 80F5: 100 * (リーフ・ページで使用されたスペース / 空ではないリーフ・ページで使用できるスペース) > MIN(50, (100 - PCTFREE))F6: (100 - PCTFREE) * (1 つ下のレベルの索引で使用できる合計スペース / すべてのキーで必要な合計スペース) < 100 式4~8F7: 100 * (疑似削除された RID の数 / RID の合計数) < 20F8: 100 * (疑似的な空のリーフ・ページ数 / リーフ・ページの合計数) < 20SCHEMA.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. 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. 26. 統計情報の更新はなぜ必要か? より良い「アクセスプラン(実行計画)」作成のため データが大きく変更されたら統計情報を更新する必要がある DB2クライアント SQL ①SQLの書き換え エージェント ②複数のアクセス プラン候補を作成 統計情報 ③コストの見積もり ④アクセスプランの 決定26
  27. 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. 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 ALLTABLESAMPLE BERNOULLI (5) INDEXSAMPLE BERNOULLI (10) ※以下マニュアルより引用、一部修正、追記をしたものです http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.explain.doc/doc/r0021347.html28
  29. 29. RUNSTATSはいつ実行すべきか いつ統計情報を更新するのか? – 実際のデータと統計情報の内容にずれが生じる時 • 初期データLOAD時 • 大量のデータ入れ替え時 • インデックスなど新しいオブジェクトを作成した時 自動化 – RUNSTATSの自動実行機能があり、デフォルトでON やれば良いってものでもない – 大規模DBで、アクセスプランがころころ変わるのは怖い • 不要なら自動RUNSTATSをOFFにする – 統計情報を更新する前にバックアップしておく • db2lookの-mオプションでDDLを出力 • http://db2.jugem.cc/?eid=10229
  30. 30. 管理の自動化 BACKUP,REORG,RUNSTATSは 自動実行可能です –RUNSTATSはデフォルトでON –決められたポリシーで自動実行 • 動作時刻(メンテナンスウィ ンドウ) • 対象表 など –IBM Data Studioで設定可能 (DB2 9.7まではコントロールセン ターで設定可能)30
  31. 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) = OFF31
  32. 32. 管理の自動化:注意点 BACKUP –2世代だけの保存=最低限のバックアップ –専任の運用管理者を置けない場合に有効 REORG –動作時間と被らないように –DB2の圧縮機能を使っている場合はディクショナリ更新をどうするか要検討 自動更新対象の表を限定する事も可能 RUNSTATS –初期状態でON:更新頻度が高い表に対して実行される –大規模DBでは要考慮 大規模DBでの使用は慎重に32
  33. 33. まとめ DB2では日常の管理用にコマンドが用意されている –BACKUP • 表領域、ログの両方を保存 –REORG • プライマリ・キー、クラスター・インデックスを作成して並べ替えの 基準を –RUNSTATS • 中小規模では、自動化に任せても良い • 大きめのケースではそれぞれの表で、RUNSTATSするかしな いか、どのオプションで実行するかを決める 上記3つを、最初から運用計画に組み入れてください –いつ、すべきか、すべきでないか • リストアの手順も計画しておきましょう –できればモニタリングも考慮 • SQLの処理速度、ディスクの使用量…33
  34. 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. 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/db2docsja35
  36. 36. 参考資料 以下のページは参考資料です –良く使うDB2のコマンド –DB2のプロセス一覧(抜粋) –DB2の構成とパラメタ(復習)36
  37. 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. 38. 【参考】DB2のプロセス・スレッド構成38
  39. 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. 40. 【復習】 構成パラメタ 設定は構成パラメタの変更で行う システム(レジストリ) DB2の構成パラメタは3種類 インスタンス (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

×