DB２即戦略管理術

DBに求められる基本機能

隔離性

複数で操作している時にデータの整合性を確保するための専有機能

原子性

データ操作の全部成功か全部失敗かを保証する機能

高速性

データアクセスの高速性を保証する

インデックスを作り少ない手順で目的のデータにアクセスする

メモリによく使用するデータを格納してディスクI/Oを減らす

耐久性

ログに処理を書き込む事で障害時にデータを失わない機能

SQL問い合わせ

高度なDB操作を柔軟かつ簡単に記述できる言語

DB2の内部構造

インスタンス

複数のDBを管理するグループ

エージェント

発行されたSQLを受け取り、解析・実行し結果をDB2クライアントに返す

基本的に１エージェントに対し１コネクション

バッファープール

ディスクキャッシュで、データは一時的にバッファープールで操作され、後でディスク装置に書きだされる

また、ディスクから直接データを読み込む事をせず、全てバッファープールを介して行われる

IO

IOサーバ

エージェントからの要求に対し、ディスク装置にアクセスしバッファーにコピーする

IOクリーナ

バッファー上で更新されたが、データが更新されていないものをディスクに書きだす

表スペース

データ、表は表スペースに作成される

表スペースはコンテナーと呼ばれるディスク領域の集まり

トランザザクション

ロガー

エージェントからSQL更新処理を受け取り、ロガーに伝え、ログバッファーに書き出しCOMMITするタイミングでログパスに書きだす

ログバッファー

一時的なメモリ領域

ログパス

ディレクトリ上のトランザクションログ

ユーザ認証と権限

DB２自体は、ユーザの認証を外部に移譲している

OS側のユーザを作成し、OS側出認証し、それに対してユーザ権限を与える

インスタンスの作成と起動

インスタンスユーザ

通常のDBユーザ

分離ユーザ(fence User)

DB2独自のユーザで、以下実行用ユーザ

ストアドプロシージャ

影響度を最小限にするため

ユーザ定義関数(UDF)

DBと表の作成

インスタンス

db2listコマンド

インスタンス一覧の取得

db2idropコマンド

インスタンスの削除

db2startコマンド

インスタンス起動

表にデータを入れる

INSER文

データを１件ずつ投入

IMPORTコマンド

大量のデータをがっさり取り込む。（ログあり）

LOADコマンド

大量のデータをがっさり取り込む（ログなし)

制約

チェック制約

与えられた条件に一致するデータしか投入できない

プライマリーキー制約

主キー

必ずインデックスが設定される

参照整合性制約（外部キー）

２つの表で整合性をとるための制約

表の再編成

REORGコマンド

統計情報の更新

RUNSTATSコマンド

接続解除

TERMINATEコマンド

接続解除の時点でファイル実行が終了

CONNECT RESETコマンド

DBの接続解除後にファイルの続きを実行する

DB２のコマンド実行

システムコマンド

DB2の操作用コマンドで全てdb2から始まる

CLPコマンド

通常のコマンドで"db2 コマンド"として投入する

DB作成時のポイント

DB作成後に変更できないモノ

DBの文字コード

文字コードによって必要なバイト数が違う

文字コードの変換時のオーバヘッド

文字の並び順

文字列自体の並び順。通常デフォルトのまま

デフォルトページサイズ

DB2のデータ操作時の最小読み書き単位

4,8,16,32KBの中から選択

ページサイズが適切でないと

余分なデータ取得

不要なディスクI/O

バッファプールの使用率低下

DBパスとストレージパス

DBパス

DB2の設定情報を格納するだけで、サイズは小さくアクセス頻度も少ないのであまり意識しない

ストレージパス

データが格納される物理パス

DB構成パラメータ

DB　CFG

DB構成パラメータ

DBごとに設定でき、チューニング項目が最も多い

DBM CFG

ＤＢＭ構成パラメータ

DBCFGの上位パラメータに位置し、インスタンス全体の設定を行う

レジストリー変数

特殊な設定を行うパラメータ

OS環境変数で設定する

通常はプロファイルレジストリーで設定する

本番環境用の最低限の設定

ログを設定する

ログのDBパスを高速デバイスに張り替える

ログの最大サイズを設定

LOGFILSIZ

ログファイル１つのサイズ。（4kb単位)

LOGPRIMARY

1次ログ

最初に(LOGFILSIZ*LOGPRIMARY)が確保

LOGSECOND

２次ログ

LOGPRIMARYが足らなくなると、LOGFILSIZ*LOGSECONDを確保

ロギング

循環ロギング

ログファイルを上書きして再使用する

アーカイブログ

ログファイルを上書きしないで貯めこむ

再編成が必要な理由

データの入れ替えによって物理的にデータのばらつきができ、ディスクアクセスが増大するため

再編成

デフラグメンテーション

定期的にデータを並び替える

コンパクション

データ間の隙間をつめる

最適な再編成とは？

データの傾向によって最適が違うためコマンドによって指定できる

一度に多くの行を取得するWHERE句で使用される

多くのSQLのWHERE句で指定されている

再編成が必要かどうか

REORGCHKコマンド

用意された式で再編成が必要かチェックされる

REORGコマンド

INPLACEオプションあり

シャドーコピーで実施

メリット

インデックスも同時再編成

高速処理

LOBの再編成が可能

デメリット

表サイズの２倍程度の一時領域が必要

REORG中の表は更新できない

途中で再編成を中止できない。

一時領域にコピーしながら再編成をする

INPLACEオプションなし

インプレースで実施

自身の表領域内で再編成をする

メリット

一時領域がいらず、同一内に20％空きがあれば十分

REORG中の更新が可能

一時停止、再開が可能

デメリット

ログの使用料が増加する

インデックスの再編成が別に必要

効率的な再編成

再編成を減らす

PCTFREE

データページ内にどの程度余白を残すか

予め余分にページサイズをとっておく事で、増大しても再編成が必要としない様にする

クラスターインデックス

INSERT時の断片化を防ぐもの

Subtopic

アクセスプランの役割

1.クライアントがSQLを発行

2.SQLをエージェントが受け取る

3.アクセスプランが実行される

1.SQLの書き換え

2.複数のアクセスプランを作成

3.コストの見積もり

4.アクセスプランの決定

4.アクセスプランに沿って実行される

良くないアクセスプランとは？

実際のデータやインデックスと一致しないアクセスプラン

アクセスプランの統計情報とは

行数

SYSSTAT.TABLES

この列はどの程度値が散らばっているか

SYSSTAT.COLDIST

列の取り得る値は何種類あるか（カーディナリティ

SYSSTAT.COLUMS

インデックスの有無

SYSSTAT.INDEXES

統計情報の基本

RUNSTATSコマンド

統計情報をシステムカタログ表に格納

統計の精度を上げるには

データに偏りがある場合

通常は、データの分散を計算していない

DISTRIBUTIONオプションを使用すると、データの偏りも含めて統計をとる

列が文字列の場合

通常は前方一致の統計しか取得しない

LIKE統計を実施

詳細な統計情報の収集、アクセスプランの精度に直結するがコストがかかる

効率的に統計をとる

どのタイミングで統計情報をとるか？

表のデータを大きく入れ替えたとき

新しくインデックスを作成したとき

更新、削除が多く実施され表のデータの20％以上が入れ替わった場合

REORGを実行した後

RUNSTASの実行時間を短くする

RUNSTATSの実行時間は行数に比例する

頻繁に使用される列にのみ対してRUNSTATSを実行

表の一部のみで統計をとる（サンプリング

SYSTEM

ページ単位で雑

BERNOULI

行単位で細かく

バックアップに統計情報も含まれる

基本的なチューニング

パフォーマンスとは？

システム応答時間

スループット

リソース使用率

チューニングとは？

限られたリソースをトレードオフする事

チューニングには限界点が存在し、限界点に近づくほどチューニングが難しくなる（チューニングの作業時間コストが増加する）

チューニングの範囲を決める

ヒアリングをして遅い部分を特定する

遅いとは？

応答速度

画面切り替え速度

いつぐらいから？

特定の処理の時のみか？

Subtopic

問題を切り分けて調査する

チューニングする対象は一度にひとつでシステム全体への影響を確認する

チューニングの心得

チューニングのゴールを設定

明確な目標を立ててチューニングする

一度に一箇所のみ調整

チューニング影響の切り分けをするため一度に一つ

システム全体を考慮

変更箇所に対するシステム全体への影響度を想像する

必ず測定する

チューニング後は必ず測定し間隔で進めてはいけない

元に戻せるようにしておく

チューニング結果を元に戻せるようにしておく

チューニング方法の選択

影響の小さくかつ簡単にできるものから実施

１ハードウェアの増強

2.パラメータを調整する

DB CFGなど

3.インデックスを見直す

4.ＤＢ２独自の機能を使う/物理設計を変更

MQTやMDCなど

5.論理設計を変更

表の定義を変えたり、遅いクエリーを変更など　アプリケーションへの影響が大きい

基本コマンド

BACKUP DATABASEコマンド

基本BKUPコマンド

LIST UTILITIESコマンド

BKUPの進行状態の確認

LIST HISTORYコマンド

BACKUPの結果を確認

バックアップ種類

オンラインバックアップ

他者が操作中の状態で行う

アーカイブログでないと実施できない

オフラインバックアップ

誰も操作していない状態で行う

差分バックアップ

拡張用のBACKUP

INCREMENTALコマンド(累積)

常にフルバックアップ＋累積バックアップ

INCREMENTAL DELTA コマンド(DELTA)

フルバックアップ＋デルタバックアップ複数

バックアップイメージの圧縮

BACKUPコマンドオプション

COMPRESS

バックアップイメージのファイル例

MYDB.0.DB2.NODE00.CA00.YYYMMTT.001

MYDB

DB名

0

0

データベースBACKUP

3

表スペースBACKUP

DB2

インスタンス名

オフラインモードで作業

FORCE APPLICATIONSコマンド

強制的にDB利用中のユーザの接続を切る

リストア

RECOVERコマンド

Subtopic

バックアップの計画に重要な事

DBのサイズ

DBの更新量

DBの増加量

DBアクセスの傾向

バックアップの保存先

BACKUPが必要な量

バックアップの実行時間

リストアにかけてよい時間

*LOBがあるTBLは差分バックアップができない

その他のバックアップ方法

EXPORTコマンド

任意の条件でSELECTし、バックアップファイルを吐き出す

DEL（カンマ区切り）、IXF(バイナリ）形式で出力される

SET WRITE SUSPENDコマンド

高速コピーだが、実査には後ろでバックアップが実行されている

バックアップ運用で注意する事

バックアップイメージとアーカイブログの保存先

データ領域とは別の物理ディスクであること

バックアップに十分な容量のDISKを用意すること

DBの設定変更

アーカイブログを有効にする

差分バックアップを有効にするため、TRACKMODパラメータをYESにする

アーカイブモードにした直後に、フルバックアップをとる必要がある

Subtopic

監視とは？

事前に障害発生を防ぐ事

重要な事は平常な状態を把握しておくこと

監視すべき対象とは

プロセス

CPUやメモリ使用量

ログファイル

ストレージの使用率

トランザクション数、デッドロック数

ハードウェア層の監視で大事な事

基本的には故障していないか？

死活監視

機能が生きているか死んでいるか

NICやケーブル、プロセッサやディスク装置

OS層の監視で大事な事

リソース状況の監視が重要

原因として、予想以上にリソースを使っている事が原因になる事が多くある

CPU使用率、メモリ使用率、ハードディスク容量

AP層　DB2の監視で大事な事

死活監視が重要

DB2の表スペースは最大容量で確保されるため、実際にどの程度使用しているかはDB2から確認する必要がある

DB2の状態を確認

DB2確認機能

モニター表関数

要求メトリック

DB2ni対する処理要求、接続要求やトランザクション処理など

アクティビティメトリック

実行されているSQL

オブジェクトメトリック

表やインデックスなどへのアクセス状況

スナップショット関数

DB2のリソースを監視

リソース監視

DB2のプロセス監視

プロセス/スレッドの死活監視

DB2のメモリ監視

メモリ使用量、メモリの最高水準点

DB2のディスク監視

表スペースの使用率、トランザクションログ領域の使用率

パフォーマンス監視

1分あたりのトランザクション数(TPM)

COMMITの発行数

トランザクション数＝COMMIT発行数

SNAPDBビューから得られる値

実行したSQLの更新系SQLの割合を確認

バッファープールヒット率

I/Oリクエストのうち何割がバッファープールを占めているか

トランザクションあたりのディスク読み書き数

アプリケーションに戻された行数のうち物理的に読み取った行数の比率

通常は1より大きい値がでる

データを全部所得してからマッチさせているため

1以下の場合は、インデックスがうまく動作している

ソートに費やされた時間

ソートに掛かった時間をトランザクション数で割り1トランザクションあたりを

ロックウェイト

ロックの待ち時間の合計を図るが値が小さいので1000倍

Subtopic

デッドロック数とロックタイムアウト数

ダーティスティールの回数

パッケージキャッシュ挿入数

トランザクションログがディスクにフラッシュされるのを待機した時間

自動保守の基本

BACKUP,REORG、RUNSTATSを自動的に実施

パラメータの親子関係に注意

自動保守の親パラメータはAUTO_MAINT

親パラメータと各機能のパラメータを両方有効にする

BACKUPの自動保守で可能なこと

バックアップ実行期間

どの程度のデータが更新されるとバックアップするか

REORGの自動保守で可能なこと

対象の表を絞りこむ

オンラインかオフラインで実施可能

RUNSTATSの自動保守で可能な事

対象の表を絞りこむ

自動保守機能の注意点

RUNSTATSの自動保守間隔は2時間のため、高速なアクセスがある場合最適でない場合がある

リアルタイム統計情報更新

RUNSTATS実行から任意時間以内に終わらない場合は処理を中断する

失敗した場合は擬似の統計情報を取得する

トラブル解決の基本4step

１．冷静になってトラブル発生の前後動作を確認

障害内容の確認

障害発生時刻の確認

障害発生前に何か変更しなかったか？

2.ざっくりと問題を切り分ける

動かない場合

アプリケーションのログやネットワーク、プロセスの有無、ディスク使用率を確認

とても遅い場合

CPU使用率、ネットワーク使用率などリソースを中心に確認

3.DB2内を切り分ける

1.HDD,リソース面を確認

2.OSの障害を確認

3.DB2の障害を確認

4.DB2内部を確認

4.ログを確認し、OSコマンドで切り分け

OSコマンド

メモリ状況

vmstat,free(linux

タスクマネージャ(windows

OSのログ

syslog(linux

イベントビューア(windows

CPUログ

ps,sar(linux

タスクマネージャ(windows

ネットワーク状況

ping

nslookup

ディスク容量

vmstat,iostat,sar,df(linux

エクスプローラ,

原因不明の障害対処法

1.現状を観察

注意:スイッチオン、DB2に接続しないと使えいない

スナップショットとモニター表関数

メリット

詳細な情報を取得

デメリット

事前準備が必要

DB2コネクト必要

負荷が大きい

db2pdコマンド

メリット

db2コネクト不要

事前準備不要

デメリット

詳細な情報ではない

整合性に欠ける情報

2.仕掛けて待つ

db2diag.log

出力される情報を増やす

イベントモニターで詳細な稼働情報を取得する

イベントモニターの使い方

SQLステートメントの例

1.イベントモニターの作成

作成モニターのアクセス権限に注意

2.イベントモニターを活性化

イベントログと管理用のファイルが作成される

3.アプリケーション稼働

SQLに関する情報が.EVTファイルに格納される

4.イベントモニター非活性化

5.取得した情報の変換

バイナリ形式のため、db2evmonコマンドで変換する

よくあるトラブル

1.容量問題

ディスクス容量が限界になる問題で、テンポラリ、ログ領域、表スペースなどが対象となる

2.特定の日時だけ遅くなる

特定の日だけイベントが発生していないか確認する　ウィルスチェックやユーザの集中、バックアップなど

DB2異常終了場合

db2cos（コールアウトスクリプト)

db2が異常終了すると自動的に起動され障害時の情報を集めてログを書きだす

ネットワークやCPU使用率、I/O状況などを書きだす