Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

2012/5/25 初心者歓迎!DB2の使い方② 管理ツール編 (Club DB2)
Club DB2 という、IBM DB2 の勉強会イベントで以前発表した資料です。かなり古いものなので情報が今とは異なる部分もあると思いますが、保存のためにアップロードしています。

Akira Shimosako

June 02, 2022
Tweet

More Decks by Akira Shimosako

Other Decks in Technology

Transcript

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

    View full-size slide

  2. 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  8. 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 full-size slide

  9. 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  14. 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 full-size slide

  15. 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 full-size slide

  16. 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 full-size slide

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

    View full-size slide

  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]

    View full-size slide

  19. 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索引
    8データベージ(例:散らばっている) 4データベージ(例:かたまっている)

    View full-size slide

  20. 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 full-size slide

  21. 21
    REORGの考慮点(1)
    オプションの選択
    –シャドーコピーか、インプレースか
    –実行中にアクセスを許す必要があるか
    テンポラリ領域が不要
    REORG中の更新アクセス可能
    一時停止、再開が可能
    高速
    表と同時にインデックスの
    REORGが可能
    メリット
    シャドーコピーと比較して遅い
    同一表領域に10-20%の空きが必

    ログが増える
    インプレース
    表と同じサイズのテンポラリ領域が
    必要
    REORG中は書き込み不可
    途中で一時停止できない
    シャドーコピー
    デメリット

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  24. 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 full-size slide

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

    View full-size slide

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

    View full-size slide

  27. 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 full-size slide

  28. 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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)

    View full-size slide

  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/db2docsja

    View full-size slide

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

    View full-size slide

  37. 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 full-size slide

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

    View full-size slide

  39. 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 full-size slide

  40. 40
    【復習】 構成パラメタ
    設定は構成パラメタの変更で行う
    DB2の構成パラメタは3種類
    –影響範囲が異なる
    –調整は、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 full-size slide