DB２即戦略管理術

Még több ilyen

シナリオ構想力

Szerző: Heihachi Mishima

承認改善の設計を行う。

Szerző: mydesk mydesk

Ext JavaScript Library Coreメモ

Szerző: Usui Hirofumi

Forex eXchange

Szerző: syouta kazama

DB２即戦略管理術

トラブル解決

DB2異常終了場合

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

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

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

よくあるトラブル

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

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

1.容量問題

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

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

SQLステートメントの例

5.取得した情報の変換

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

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

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

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

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

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

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

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

トラブル解決の基本4step

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

原因不明の障害対処法

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

3.DB2内を切り分ける

4.DB2内部を確認

3.DB2の障害を確認

2.OSの障害を確認

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

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

とても遅い場合

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

動かない場合

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

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

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

障害発生時刻の確認

障害内容の確認

自動保守

自動保守機能の注意点

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

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

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

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

自動保守の基本

RUNSTATSの自動保守で可能な事

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

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

対象の表を絞りこむ

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

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

バックアップ実行期間

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

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

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

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

パラメータ調整

監視

DB2のリソースを監視

パフォーマンス監視

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

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

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

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

ロックウェイト

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

ソートに費やされた時間

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

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

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

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

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

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

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

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

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

SNAPDBビューから得られる値

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

COMMITの発行数

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

リソース監視

DB2のディスク監視

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

DB2のメモリ監視

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

DB2のプロセス監視

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

DB2の状態を確認

DB2確認機能

スナップショット関数

モニター表関数

オブジェクトメトリック

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

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

実行されているSQL

要求メトリック

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

AP層　DB2の監視で大事な事

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

死活監視が重要

OS層の監視で大事な事

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

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

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

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

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

死活監視

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

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

監視すべき対象とは

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

ストレージの使用率

ログファイル

CPUやメモリ使用量

プロセス

監視とは？

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

事前に障害発生を防ぐ事

物理設計

バックアップ

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

DBの設定変更

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

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

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

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

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

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

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

SET WRITE SUSPENDコマンド

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

EXPORTコマンド

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

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

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

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

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

バックアップの実行時間

BACKUPが必要な量

バックアップの保存先

DBアクセスの傾向

DBの増加量

DBの更新量

DBのサイズ

リストア

RECOVERコマンド

オフラインモードで作業

FORCE APPLICATIONSコマンド

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

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

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

DB2

インスタンス名

0

3

表スペースBACKUP

データベースBACKUP

MYDB

DB名

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

BACKUPコマンドオプション

COMPRESS

バックアップ種類

差分バックアップ

拡張用のBACKUP

INCREMENTAL DELTA コマンド(DELTA)

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

INCREMENTALコマンド(累積)

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

オフラインバックアップ

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

オンラインバックアップ

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

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

基本コマンド

LIST HISTORYコマンド

BACKUPの結果を確認

LIST UTILITIESコマンド

BKUPの進行状態の確認

BACKUP DATABASEコマンド

基本BKUPコマンド

パフォーマンスチューニング

基本的なチューニング

チューニング方法の選択

5.論理設計を変更

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

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

MQTやMDCなど

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

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

DB CFGなど

１ハードウェアの増強

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

チューニングの心得

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

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

必ず測定する

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

システム全体を考慮

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

一度に一箇所のみ調整

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

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

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

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

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

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

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

遅いとは？

特定の処理の時のみか？

いつぐらいから？

画面切り替え速度

応答速度

チューニングとは？

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

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

パフォーマンスとは？

リソース使用率

スループット

システム応答時間

アクセスプランの精度

効率的に統計をとる

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

RUNSTASの実行時間を短くする

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

BERNOULI

行単位で細かく

SYSTEM

ページ単位で雑

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

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

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

REORGを実行した後

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

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

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

統計情報の基本

統計の精度を上げるには

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

列が文字列の場合

LIKE統計を実施

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

データに偏りがある場合

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

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

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

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

インデックスの有無

SYSSTAT.INDEXES

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

SYSSTAT.COLUMS

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

SYSSTAT.COLDIST

行数

SYSSTAT.TABLES

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

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

アクセスプランの役割

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

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

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

3.コストの見積もり

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

1.SQLの書き換え

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

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

再編成でパフォーマンス

効率的な再編成

再編成を減らす

クラスターインデックス

Subtopic

INSERT時の断片化を防ぐもの

PCTFREE

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

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

INPLACEオプションなし

インプレースで実施

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

ログの使用料が増加する

一時停止、再開が可能

REORG中の更新が可能

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

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

INPLACEオプションあり

シャドーコピーで実施

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

デメリット

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

REORG中の表は更新できない

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

メリット

LOBの再編成が可能

高速処理

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

再編成が必要かどうか

REORGCHKコマンド

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

最適な再編成とは？

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

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

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

再編成

コンパクション

データ間の隙間をつめる

デフラグメンテーション

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

再編成が必要な理由

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

DB2の基本設定と操作

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

ロギング

アーカイブログ

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

循環ロギング

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

ログの最大サイズを設定

LOGSECOND

２次ログ

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

LOGPRIMARY

1次ログ

最初に(LOGFILSIZ*LOGPRIMARY)が確保

LOGFILSIZ

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

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

ログを設定する

DB構成パラメータ

レジストリー変数

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

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

OS環境変数で設定する

DBM CFG

ＤＢＭ構成パラメータ

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

DB　CFG

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

DB作成時のポイント

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

DBパスとストレージパス

ストレージパス

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

DBパス

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

デフォルトページサイズ

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

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

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

不要なディスクI/O

余分なデータ取得

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

文字の並び順

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

DBの文字コード

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

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

DB２のコマンド実行

CLPコマンド

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

システムコマンド

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

DBと表の作成

接続解除

CONNECT RESETコマンド

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

TERMINATEコマンド

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

統計情報の更新

RUNSTATSコマンド

表の再編成

REORGコマンド

制約

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

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

プライマリーキー制約

主キー

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

チェック制約

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

表にデータを入れる

LOADコマンド

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

IMPORTコマンド

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

INSER文

データを１件ずつ投入

db2startコマンド

インスタンス起動

db2idropコマンド

インスタンスの削除

db2listコマンド

インスタンス一覧の取得

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

分離ユーザ(fence User)

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

ユーザ定義関数(UDF)

ストアドプロシージャ

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

インスタンスユーザ

通常のDBユーザ

DB2の仕組み基本

DB2の内部構造

ユーザ認証と権限

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

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

トランザザクション

ログパス

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

ログバッファー

一時的なメモリ領域

ロガー

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

表スペース

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

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

IO

IOクリーナ

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

IOサーバ

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

バッファープール

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

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

エージェント

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

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

インスタンス

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

DBに求められる基本機能

SQL問い合わせ

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

耐久性

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

高速性

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

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

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

原子性

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

隔離性

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