作者：ns takatoshi 13 年以前
2691
DB２即戦略管理術
DB2の効率的な管理には、基本設定や操作手順の理解が不可欠です。特に本番環境では、ログの配置やサイズ設定が重要です。LOGFILSIZ、LOGSECOND、LOGPRIMARYといったパラメータを設定し、ログのパフォーマンスを最適化します。ロギング方法にはアーカイブログと循環ロギングの2種類があります。DBと表の作成や再編成には、db2start、db2idrop、db2listなどのコマンドが用いられます。
作者：ns takatoshi 13 年以前
2691
更多类似内容
ネットワークやCPU使用率、I/O状況などを書きだす
db2が異常終了すると自動的に起動され障害時の情報を集めてログを書きだす
特定の日だけイベントが発生していないか確認する ウィルスチェックやユーザの集中、バックアップなど
ディスクス容量が限界になる問題で、テンポラリ、ログ領域、表スペースなどが対象となる
5.取得した情報の変換
バイナリ形式のため、db2evmonコマンドで変換する
4.イベントモニター非活性化
3.アプリケーション稼働
SQLに関する情報が.EVTファイルに格納される
2.イベントモニターを活性化
イベントログと管理用のファイルが作成される
1.イベントモニターの作成
作成モニターのアクセス権限に注意
原因不明の障害対処法
2.仕掛けて待つ
イベントモニターで詳細な稼働情報を取得する
db2diag.log
出力される情報を増やす
1.現状を観察
db2pdコマンド
整合性に欠ける情報
詳細な情報ではない
事前準備不要
db2コネクト不要
スナップショットとモニター表関数
負荷が大きい
DB2コネクト必要
事前準備が必要
詳細な情報を取得
注意:スイッチオン、DB2に接続しないと使えいない
OSコマンド
ディスク容量
エクスプローラ,
vmstat,iostat,sar,df(linux
ネットワーク状況
nslookup
ping
CPUログ
ps,sar(linux
OSのログ
イベントビューア(windows
syslog(linux
メモリ状況
タスクマネージャ(windows
vmstat,free(linux
4.DB2内部を確認
3.DB2の障害を確認
2.OSの障害を確認
1.HDD,リソース面を確認
とても遅い場合
CPU使用率、ネットワーク使用率などリソースを中心に確認
動かない場合
アプリケーションのログやネットワーク、プロセスの有無、ディスク使用率を確認
障害発生前に何か変更しなかったか？
障害発生時刻の確認
障害内容の確認
RUNSTATS実行から任意時間以内に終わらない場合は処理を中断する
失敗した場合は擬似の統計情報を取得する
オンラインかオフラインで実施可能
対象の表を絞りこむ
どの程度のデータが更新されるとバックアップするか
バックアップ実行期間
親パラメータと各機能のパラメータを両方有効にする
自動保守の親パラメータはAUTO_MAINT
トランザクションログがディスクにフラッシュされるのを待機した時間
パッケージキャッシュ挿入数
ダーティスティールの回数
デッドロック数とロックタイムアウト数
ロックウェイト
ロックの待ち時間の合計を図るが値が小さいので1000倍
ソートに費やされた時間
ソートに掛かった時間をトランザクション数で割り1トランザクションあたりを
アプリケーションに戻された行数のうち物理的に読み取った行数の比率
1以下の場合は、インデックスがうまく動作している
データを全部所得してからマッチさせているため
通常は1より大きい値がでる
トランザクションあたりのディスク読み書き数
バッファープールヒット率
I/Oリクエストのうち何割がバッファープールを占めているか
1分あたりのトランザクション数(TPM)
SNAPDBビューから得られる値
実行したSQLの更新系SQLの割合を確認
COMMITの発行数
トランザクション数＝COMMIT発行数
DB2のディスク監視
表スペースの使用率、トランザクションログ領域の使用率
DB2のメモリ監視
メモリ使用量、メモリの最高水準点
DB2のプロセス監視
プロセス/スレッドの死活監視
スナップショット関数
モニター表関数
オブジェクトメトリック
表やインデックスなどへのアクセス状況
アクティビティメトリック
実行されているSQL
要求メトリック
DB2ni対する処理要求、接続要求やトランザクション処理など
機能が生きているか死んでいるか
アーカイブモードにした直後に、フルバックアップをとる必要がある
差分バックアップを有効にするため、TRACKMODパラメータをYESにする
アーカイブログを有効にする
バックアップに十分な容量のDISKを用意すること
データ領域とは別の物理ディスクであること
高速コピーだが、実査には後ろでバックアップが実行されている
DEL（カンマ区切り）、IXF(バイナリ）形式で出力される
任意の条件でSELECTし、バックアップファイルを吐き出す
強制的にDB利用中のユーザの接続を切る
DB2
インスタンス名
0
3
表スペースBACKUP
データベースBACKUP
MYDB
DB名
COMPRESS
拡張用のBACKUP
INCREMENTAL DELTA コマンド(DELTA)
フルバックアップ＋デルタバックアップ複数
INCREMENTALコマンド(累積)
常にフルバックアップ＋累積バックアップ
誰も操作していない状態で行う
アーカイブログでないと実施できない
他者が操作中の状態で行う
BACKUPの結果を確認
BKUPの進行状態の確認
基本BKUPコマンド
5.論理設計を変更
表の定義を変えたり、遅いクエリーを変更など アプリケーションへの影響が大きい
4.ＤＢ２独自の機能を使う/物理設計を変更
MQTやMDCなど
3.インデックスを見直す
2.パラメータを調整する
DB CFGなど
１ハードウェアの増強
影響の小さくかつ簡単にできるものから実施
元に戻せるようにしておく
チューニング結果を元に戻せるようにしておく
必ず測定する
チューニング後は必ず測定し間隔で進めてはいけない
システム全体を考慮
変更箇所に対するシステム全体への影響度を想像する
一度に一箇所のみ調整
チューニング影響の切り分けをするため一度に一つ
チューニングのゴールを設定
明確な目標を立ててチューニングする
問題を切り分けて調査する
チューニングする対象は一度にひとつでシステム全体への影響を確認する
ヒアリングをして遅い部分を特定する
遅いとは？
特定の処理の時のみか？
いつぐらいから？
画面切り替え速度
応答速度
チューニングには限界点が存在し、限界点に近づくほどチューニングが難しくなる（チューニングの作業時間コストが増加する）
限られたリソースをトレードオフする事
リソース使用率
スループット
システム応答時間
表の一部のみで統計をとる（サンプリング
BERNOULI
行単位で細かく
SYSTEM
ページ単位で雑
頻繁に使用される列にのみ対してRUNSTATSを実行
RUNSTATSの実行時間は行数に比例する
REORGを実行した後
更新、削除が多く実施され表のデータの20％以上が入れ替わった場合
新しくインデックスを作成したとき
表のデータを大きく入れ替えたとき
詳細な統計情報の収集、アクセスプランの精度に直結するがコストがかかる
列が文字列の場合
LIKE統計を実施
通常は前方一致の統計しか取得しない
データに偏りがある場合
DISTRIBUTIONオプションを使用すると、データの偏りも含めて統計をとる
通常は、データの分散を計算していない
統計情報をシステムカタログ表に格納
SYSSTAT.INDEXES
SYSSTAT.COLUMS
SYSSTAT.COLDIST
SYSSTAT.TABLES
4.アクセスプランの決定
3.コストの見積もり
2.複数のアクセスプランを作成
1.SQLの書き換え
クラスターインデックス
Subtopic
INSERT時の断片化を防ぐもの
PCTFREE
予め余分にページサイズをとっておく事で、増大しても再編成が必要としない様にする
データページ内にどの程度余白を残すか
インプレースで実施
インデックスの再編成が別に必要
ログの使用料が増加する
一時停止、再開が可能
REORG中の更新が可能
一時領域がいらず、同一内に20％空きがあれば十分
自身の表領域内で再編成をする
シャドーコピーで実施
一時領域にコピーしながら再編成をする
デメリット
途中で再編成を中止できない。
REORG中の表は更新できない
表サイズの２倍程度の一時領域が必要
メリット
LOBの再編成が可能
高速処理
インデックスも同時再編成
用意された式で再編成が必要かチェックされる
データ間の隙間をつめる
定期的にデータを並び替える
アーカイブログ
ログファイルを上書きしないで貯めこむ
循環ロギング
ログファイルを上書きして再使用する
LOGSECOND
２次ログ
LOGPRIMARYが足らなくなると、LOGFILSIZ*LOGSECONDを確保
LOGPRIMARY
1次ログ
最初に(LOGFILSIZ*LOGPRIMARY)が確保
LOGFILSIZ
ログファイル１つのサイズ。（4kb単位)
特殊な設定を行うパラメータ
通常はプロファイルレジストリーで設定する
OS環境変数で設定する
ＤＢＭ構成パラメータ
DBCFGの上位パラメータに位置し、インスタンス全体の設定を行う
DBごとに設定でき、チューニング項目が最も多い
DBパスとストレージパス
ストレージパス
データが格納される物理パス
DBパス
DB2の設定情報を格納するだけで、サイズは小さくアクセス頻度も少ないのであまり意識しない
デフォルトページサイズ
4,8,16,32KBの中から選択
ページサイズが適切でないと
バッファプールの使用率低下
不要なディスクI/O
余分なデータ取得
DB2のデータ操作時の最小読み書き単位
文字の並び順
文字列自体の並び順。通常デフォルトのまま
DBの文字コード
文字コードの変換時のオーバヘッド
文字コードによって必要なバイト数が違う
通常のコマンドで"db2 コマンド"として投入する
DB2の操作用コマンドで全てdb2から始まる
CONNECT RESETコマンド
DBの接続解除後にファイルの続きを実行する
TERMINATEコマンド
接続解除の時点でファイル実行が終了
RUNSTATSコマンド
REORGコマンド
参照整合性制約（外部キー）
２つの表で整合性をとるための制約
プライマリーキー制約
主キー
必ずインデックスが設定される
チェック制約
与えられた条件に一致するデータしか投入できない
LOADコマンド
大量のデータをがっさり取り込む（ログなし)
IMPORTコマンド
大量のデータをがっさり取り込む。（ログあり）
INSER文
データを１件ずつ投入
db2startコマンド
インスタンス起動
db2idropコマンド
インスタンスの削除
db2listコマンド
インスタンス一覧の取得
DB2独自のユーザで、以下実行用ユーザ
ユーザ定義関数(UDF)
ストアドプロシージャ
影響度を最小限にするため
通常のDBユーザ
OS側のユーザを作成し、OS側出認証し、それに対してユーザ権限を与える
DB２自体は、ユーザの認証を外部に移譲している
ログパス
ディレクトリ上のトランザクションログ
ログバッファー
一時的なメモリ領域
ロガー
エージェントからSQL更新処理を受け取り、ロガーに伝え、ログバッファーに書き出しCOMMITするタイミングでログパスに書きだす
表スペースはコンテナーと呼ばれるディスク領域の集まり
データ、表は表スペースに作成される
IOクリーナ
バッファー上で更新されたが、データが更新されていないものをディスクに書きだす
IOサーバ
エージェントからの要求に対し、ディスク装置にアクセスしバッファーにコピーする
また、ディスクから直接データを読み込む事をせず、全てバッファープールを介して行われる
ディスクキャッシュで、データは一時的にバッファープールで操作され、後でディスク装置に書きだされる
基本的に１エージェントに対し１コネクション
発行されたSQLを受け取り、解析・実行し結果をDB2クライアントに返す
複数のDBを管理するグループ
高度なDB操作を柔軟かつ簡単に記述できる言語
ログに処理を書き込む事で障害時にデータを失わない機能
データアクセスの高速性を保証する
メモリによく使用するデータを格納してディスクI/Oを減らす
インデックスを作り少ない手順で目的のデータにアクセスする
データ操作の全部成功か全部失敗かを保証する機能
複数で操作している時にデータの整合性を確保するための専有機能
