DB2 パフォーマンス チューニング ロードマップ --LOG INTRODUCTION_PHP 教程

DB2 パフォーマンス チューニング ロードマップ -- ログの紹介

この記事の内容は、レポートを整理する際の DB2 STAT LOG AVITIVITY の部分を補足するもので、主に DB2 LOG 機能、オーバーヘッド、関連するコンポーネント、およびコンポーネント間の作業について紹介します。このメカニズムが DB2 ログ (IBM が提供する既存の DB2 ログ ユーティリティ) をどのように利用するか。最後に、DB2 ログのロジックを知覚的に理解します。

• 1 ログの概要
  • DB2 ログの基礎
    • ログの目的:
    • なぜロギングが必要なのか
    • 完璧な世界
    • ログ作業メカニズムの概要
• 2 ログの理解
  • ログの実装
    • 1 ログデータ共有が関与する場合の RBA
    • 2-LRSN
    • 3 ログ ページ データ セット
      • アクティブ ログ データ セットの要素:
      • BSDS – ブート ストラップ データ セット
      • SYSLGRNX-DLD
      • アーカイブ ログ データセットの要素S
  • ログの構造
    • 何がログに記録されますか?
      • URの情報
      • ページセット情報
      • システムチェックポイントのリカバリ情報
      • UNDO/REDOログの例
      • ログの補償
      • リカバリ情報の例
      • システムチェックポイントの詳細
      いつログを記録するか
    ログの使用法
  • DB2の開始
    • オブジェクトのリカバリ
    • レプリケーション
    • SOX準拠
    • ヘルスチェック
    ログユーティリティ、ログの操作
  • DSN1LOGP
    • DSNJU004、DSNJU003
    • DSNJU004
      • DSNJU003 (別名、変更ログ インベントリ)
      DSNJLOGF
    • RECOVER BSDS
    • #RECOVER BSDS
  ログ関連データセット
• ログ ページ形式

1 ログの概要

DB2 ログの基礎

ログの目的:

DB2 ログには 2 つの主な機能があります: リカバリ単位の再適用またはバックアウト、および障害発生時に DB2 を一貫性のある状態に再構築することです

ログが必要な理由

1. オーバーヘッド
2. パフォーマンス、DASD、管理、クリーンアップのコストがかかります
3. 事故が発生した場合の保証です
   1. ロールバックする必要はありません
   2. リカバリする必要はありません
   3. プログラムエラーはありません
   4. いいえハードウェアエラー
   5. パワーの失敗はありませんハリケンス、テロ攻撃、詐欺はありません。各コンポーネントの使用法
   6. アクティブ ログ
   DB2 が現在のログ情報を置く場所
ログ バッファ

DASD への外部化の前にログ情報が保持される場所

ブートストラップ データセット現在のアクティブ ログ データセットとアーカイブ ログ データセットに関する情報を保持する

アーカイブログ
これらは、「古い」アクティブなログ データセットのコピーです

SYSLGRNX
DB2 は、オブジェクトが（おそらく）いつ更新されたかを追跡します

1. 
   2 ログの理解
2. ログの実装
   1 LOG RBA
BYTE ADDRESSABLE(RBA=相対バイト アドレス)
3. RBA START=0X00000000000
   RBA END=0XFFFFFFFFFFF
RBA ログ レコードを一意に定義します
4. 2 データ共有時 -LRSN
   

   
   LRSN=ログ シーケンス範囲番号 (シスプレックス ソース クロックに基づいて変更されたタイムスタンプです)

   3 ログ ページ データ セット

   ログ出力バッファ
   アクティブ ログ
   アーカイブ ログ
   
   
   いつDB2 は最後のアクティブ データ セットに移動し、最初のアクティブ ログ データ セットにラップします

   アクティブ ログ データ セットの数
   1. アクティブ ログ データ セットのサイズ
   2. シングルまたはデュアル アクティブ ログ
   3. パフォーマンス傍観:
   4. 高速 DASD
      1. ストリッピングを検討してください
      2. DB2 ZPARM OUTBUFFER+ LOGAPSTG
   BSDS – ブート ストラップ データ セット?名前：catalog.BSDS01とcatalog.BSDS02

   ? 2 つの同一のデータセットでなければなりませんか?記録された最高の RBA が含まれていますか?アクティブなログの説明 (RBA の開始と終了、およびステータス) が含まれます
   ?アーカイブログの説明が含まれていますか?データセット名
   ?ボリューム名
   ? RBA範囲
   ?その他の必要なシステム情報が含まれていますか?システムチェックポイント履歴、BP 説明、CCSID 情報など
   SYSLGRNX-DLD
   ?ディレクトリ内のテーブルなのでユーザー アクセスは利用できません
   ?テーブルスペースまたはパーティションが更新のためにオープンまたはクローズされるときの RBA が含まれますか?この情報は DB2 ログにもあることに注意してください
   ? SYSLGRNGX は、スキャンする必要があるログ データの量を制限することでリカバリを高速化するために DB2 によって使用されます
   ? MODIFY ユーティリティは、この情報を SYSCOPY 行とともに削除します

   SYSLGRNGX is key to speeding up log processing during recovery Contains RBAs when tablespaces are open for update. Log ranges out ranges cannot contain updates for this tablespace and therefore we needed during the recovery process.SYSLGRNGX is also updated by running the Modify Recovery utility 

   アーカイブ ログ データセットの要素
   1. 常に 1 つのアクティブ ログに対して 2 つのファイルを作成します
      それは非同期プロセスです
      VCAT.ARCHLOGN.BNNNNNN

      CONTAINDS THE BSDS INFORMATION BEFORE ARCHIVE IS WRITTEN FIRST LOG BEING ARCHIVED,IS STILL KNOWN AS ACTIVE LOG IN BSDS 

      VCAT.ARCHIVEN.ANNNNNN

      CONTAINS THE ACTUAL LOG FOR LOG RBA RANGE OF THAN LOG DATA SETSUPDATES BSDS WHEN COMPLETE 

   2. DB2 ZPARMS ARCHPFX1+ARCHPFX2+TSTAMP=はい|いいえ|EXT
      VCAT.ARCHIVEN .DXXXXX.TXXXXX.BNNNNNNNN
   3. アーカイブ時:
      アクティブログがいっぱい
      切り捨て:アーカイブログコマンドまたはエラー

   ログ構造

   何が記録されていますか?URの情報
   1. 開始/終了情報ATION
   2. UNDO/ REDOステートメントと補正ログの記録
   3. コミットロールバック処理

   ---

   ページセット情報
   1. ページセットを開く/閉じる
   2. 保留ステータス情報(コピー、チェック、再編成)
   3. 開始/停止情報(どのモードで実行するかを含む)
   4. 関与テーブルの DBD INFORECOVERY 情報:

      SYSIBM.SYSUTILX SYSIBM.DBD01 SYSIBM.SYSCOPY 

      システム チェックポイントSUNDO/REDO ログの例

   UPDATE T
   SET COL='BBB'
   WHERE ID=1
   LRH004A002F 0E8 00006 CEA48CC9 0006CEA4 8D590526 0006CEA4 8D59C7C0
   AF504B23 0000

   *LG** 80010C00 02000000 02000006 CEA4049E 2B02 0000 00120101 00030900 000600C2 C2C200C1 C1C1 

   C2C2C2 ='BBB'
   C1C1C1='AAA'
   URID(0006CEA48CC9)UR の RBA がログで開始されました
   010C=DBID
   0002==ページセット OBID
   000000 02=ページ ID

   ログの例
   

   
   この例の場合、現在の値は BBB で、更新後は AAA になるはずですが、何らかの理由で ROLLBACK が発生します。その場合、DB2 はこの更新を元に戻す必要があります。この取り消し自体もログに記録されます。これらのログ レコードは、補償ログ レコードと呼ばれます。
   

   SUBTYPE(UPDATE IN-PLACE IN A DATA PAGE) CLR(YES)*LG** 80010C00 02000000 02000006 CEA550BF AB00 0000 00120101 00030900 000600C2 C2C200C1 C1C1 

   CLR(YES) は、補償ログ レコードであることを示します

   RECOVERY INFORMATION EXAMPLE

   DB2 writes “syscopy” information for certain system tables to the log instead of writing it to syscopy. The reason is simple. In case of a
   disaster recovery, we need to recover the system in precise steps.Meaning that certain system tables have to be recovered before we can recover sysibm.syscopy. Therefore the backup information of those objects is written to the log.

   SYSTEM CHECKPOINTS DETAIL

   SYSTEM CHECKPOINT (snapshot of activity on system)

   1. WHAT IS IN SYSTEM CHECKPOINT
      1. Entry per active thread (amongst other status inflight/in commit etc)
      2. Entry per open page set (including exception status)
      3. Page externalization
   2. How often should one be taken ?
      1. Every 3-5 minutes (many sites are at 15-20 minutes)
      2. CHKFREQ : V9 : # LOG records or # seconds

          V10: Minimum of # LOG records and # seconds 

   3. Important for (re)start up performance
      ? Start up ALWAYS from LAST CHECKPOINT
   WHEN IS LOGGING

   As the work is being done
   ? In Log output buffer (OUTBUFF)
   ? Regularly flushed to Active Log Dataset
   Sequentially first active copy1 then active copy2 (DB2 V10 应该是双写)
   
   ? At Commit
   ? At Rollback
   ? Log Write threshold (WRTHRSH 20 pages without commit)
   ? Archive log command
   ? System Checkpoint
   ? Log Write Ahead Force

   LOG USAGE

   Start DB2

   4 phases :

   1. Log initialization
      Read/compare BSDS
      Find current active log dataset and end of log
   2. Current status rebuild
      Read last system checpoint
   3. Forward log recovery
      Do all work for INCOMMIT and INDOUBT threads
   4. Backward log recovery
      Do all work for INABORT and INFLIGHT threads
   5. ALWAYS start from LAST SYSTEM CHECKPOINT
      Amount of work varies (ab)normal shutdowN
   Recovery of objects

   DB2 新增了一个参数BACKOUT(YES),这个参数应该不是太常用，更多的情况应该是使用imgcopy+log的方式去追，即point-in-time,这里不进行介绍。

   REPLICATION

   これは現在 IDC で非常に人気のあるトピックであり、mysql でサポートされている mysql のマスタースレーブ方式など、DBMS のプラットフォーム版でも実装されています。それ自体であり、新しいソフトウェアは必要ありませんが、単一スレッドで処理されるため、多くのベンダーがスレーブでの同時実行をサポートする拡張バージョンを提供しています。 zos 上の QREP+MQ を使用して実装され、異種データベースをサポートし、遅延は数分以内に制御できます。 RPT=2MIN、RTO=2HOUR、

   SOX コンプライアンス

   これは内部監査と外部監査に関するものです。比較的言えば、監査 LOG 手法の使用コストは比較的高く、代替ソフトウェアが存在します。

   ヘルスチェック

   ベストプラクティスでは、システムの現在の動作に基づいて、ACTIVE LOG と ACHIVE LOG が異常に実行されているかどうかを確認します。

   ログユーティリティ、ログを操作する

   これは現在のプラットフォームに欠けているものであるはずですが、私は無知です。

   DSN1LOGP

   ? DB2 ログを読み取り可能な出力にフォーマットします
   ? 詳細または要約 (SUMMARY(YES/NO/ONLY))
   ? ページセットのステータスを含めます (DATAONLY(YES/NO)
   ? SYSCOPY 情報を含めます (SYSCOPY(YES/NO))
   ? 範囲を制限します (例: URID、DBID、)
   ? ログ データ セット名、ログ範囲、ボリュームなど
   ?
   条件付き再起動履歴

   ? バックアップ システム履歴

   ? LTIME 列以外の時間値に注意してください
   ?ログ インベントリの変更)
   ? DB2 がダウンしているときにのみ実行されますか? 慎重に使用してください!? アクティブなログとアーカイブ ログを追加/削除しますか? 条件付き再起動レコード (CRESTART) を作成しますか? ? STARTRBA
   ? ENDRBA
   ? STARTRBA=ENDRBA
   ? ほとんどの場合、新しいアクティブなログ データセットを事前にフォーマットしますか?RECOVER BSDS#RECOVER BSDS

   ? 起動するには 2 つの同一の BSDS が必要ですか? DSNJ126I I/O ERROR FORCED SINGLE BSDS
   ? コマンドを実行しないでください? !
   ? 起動時に 1 つの BSDS が壊れた場合はどうなりますか?
   ? DB2 が起動しない場合は? LOG 構成が複雑なので、必要に応じて後ほど追記します。
   1 BYTE=8BITS
   1 NIBBLE=4BITS
   ログページサイズ=4KB
   ログページ利用可能スペース=4075

   ログページ制御間隔

   サイズ:ページの最後の21/X'15'バイト

   使用法:CI ログページについて説明します

   ページの開始 RAB です

   ログ RBA には RBA はありません-----ページの開始 RBA にレコードのページへのオフセットを加えたものです

   1 ログ記録はおそらくスパンでログページを記録する可能性があります
   この記事の内容はすべて、インターネットのみ、参考と学習のため、著作権上の問題がある場合は、この記事をご自身で削除してください。よろしくお願いします。
   
   
   
   
   
   http://www.bkjia.com/PHPjc/1097746.html
   
   www.bkjia.com
   
   tru​​e
   

   http://www.bkjia.com/PHPjc/1097746.html

   技術記事

   DB2 パフォーマンス チューニング ロードマップ -- ログの概要 この記事の内容は、レポートを整理する際の DB2 STAT LOG AVITIVITY の部分を補足するもので、主に DB2 LOG 機能、オーバーヘッドなどについて紹介します。