DB2 パフォーマンス チューニング ロードマップ --DIVE INTO LOCK_PHP 教程

DB2 パフォーマンス チューニング ロードマップ -- DIVE INTO LOCK

この章では、DB2 ログの関連内容の整理に基づいて、ロックの内容を整理します。ログと比較して、ロックの内容はアプリケーションに関連しており、これには関連性が高くなります。内容はあらゆる面でより複雑です。 DBMS とファイル システムの本質的な違いは、DBMS システムによってサポートされるトランザクションにあります。 ログの導入が永続性を確保することである場合、LOCK の導入はトランザクションのシリアル化を確保し、トランザクションの同時実行性を解決し、リソースの RACE CONDITION を実現することです。異なるトランザクション シナリオでは、異なる同時実行要件が定義されます。この目的のために、DBMS ごとに異なるロック メカニズムが導入されます。 DB2 のシリアル化メカニズムは、主に LOCK、LATCH、CLAIM/DRAIM によって実装され、OBJECT、SIZE、MODE、DURATION、PARTICIPANTS、PARAMETER LOCATIONS などの、特定の LOCK 関連属性と LOCK 属性のアプリケーションへの影響が紹介されています。 DBMS クラスター (DB2 の DATA SHARING GROUP および ORACLE の ORACEL RAC) が導入されたとき、異なるメンバー間のデータの一貫性を処理するために、DB2 はグローバル LOCK 競合検出を実装するために PHYSICAL LOCK と CF LOCK STRTURE を導入しました。単一の SUBSYSTEM では、主な競合は TIMEOUT と DEADLOCK です。DATASHARING GROUP では、新しい CONTENTION、XES CONTENTION、FALSE CONTENTION、および GLOBAL LOCK CONTENTION が導入されています。 LOCK の導入により、必然的に新しい OVERHEAD が発生します。DB2 は、主に IRLM、XES、CF などを介してロック リソース要求を処理します。アドレス空間ロック要求に加えて、アプリケーション自体の不合理な設計や特定のシナリオにより、多くのオーバーヘッドが発生します。これらの問題を効果的に回避するには、システムの運用保守担当者と開発者の共同の努力が必要です。
この記事の内容は、DBMS LOCK に関する私の個人的な理解レベルに基づいており、内容を整理する際の知識の広さと深さだけでなく、すべてさらなる検討が必要です。
このブログは書いてから大枠が完成するまでに2週間近くかかりましたが、今まで書いたブログの中で一番長いはずですが、それでも確認するたびに新たにやらなければいけないことが出てきます。追記、今後も私なりの理解を追記していきます。

• ロックの概要
  • なぜロックなのか? DB2 シリアル化メカニズム
    • データの整合性とデータベースの同時実行性
      • トランザクションが同時に実行されるときに見られる現象
      • 更新の喪失
      • ダーティリード
      • 反復不可能な読み取り
      • ファントム
  • ロックプロパティ
    • ロックオブジェクト所有者
    • ロック参加者
    • ロックサイズ
    • ロックモード
    • ロック期間
    • ロックリクエストとリリース
    • ロックと転送分離レベル
    • ロックパラメータの場所
      • DDL
      • DML
      • プリコンパイラのロックパラメータ
      • バインドロックパラメータ
      • Zparm ロックパラメータ
  • CLAIM と DRAIN
  • LATCH
  • 高度なトピック
    • L-LOCK(明示的な階層ロック)EHL
    • 物理ロック
    • 保持されたロック日付ロック)
      • 保持されたロックの影響
    • ロックスコープ:
      • ローカルロック
      • グローバルロック
      • グローバルロック通信
        • ページセットPロックネゴシエーション
    • CFロック構造
      • 変更されたリソースL IST(MRL)
      • ロックテーブル
      • XCF
      • XES
        • XES競合
        • 誤った競合
        • グローバル競合
        • データ共有アクティビティレポート
      • ロック構造の不足アクション
  • の種類ロックの問題
    • 問題があることを確認するにはどうすればよいですか
    • 同時実行性の問題の分析 -- TOOLBOXS
      • DB2 コマンドと EXPLAIN
      • DB2 TRACES
    • 例:単純なデッドロック シナリオの分析と解決策
      • DBD がロックされています

ロックの概要

なぜロックするのか

データの整合性とデータベースの同時実行性

DBMS 領域と文書系の最重要領域:DBMS サポート事

DBMS :データの整合性を損なうことなく、複数のユーザーがデータベースに同時にアクセスできるようにします。あトランザクション (または作業単位) は、通常はアプリケーション プロセス内で単一の単位としてグループ化された 1 つ以上の SQL 操作の回復可能なシーケンスです。
DB2 がデータの一貫性を保つために使用するメカニズムの 1 つがトランザクションです。トランザクション (別名作業単位) は、通常はアプリケーション プロセス内で単一の単位としてグループ化された 1 つ以上の SQL 操作の回復可能なシーケンスです。単一トランザクションの開始と終了によって、データベース内のデータの一貫性のポイントが定義されます。トランザクション内で実行されたすべての SQL 操作の効果がデータベースに適用されて永続化 (コミット) されるか、実行されたすべての SQL 操作の効果が完全に「元に戻されて」破棄 (ロールバック) されます。
トランザクション時に見られる現象同時実行

ジョブの問題を解決するために、DB2 では 4 つのジョブ間隔が定義されています。

ファントム

1. 更新情報の喪失
2. 2 つのトランザクションが同じデータを読み取り、両方が読み取ったデータを更新しようとし、更新の 1 つが失われたときに発生します

Transaction 1 and Transaction 2 read the same row of data and both calculate new values for that row based upon the original values read. If Transaction 1 updates the row with its new value and Transaction 2 then updates the same row, the update operation performed by Transaction 1 is lost 

3. DIRTY READS
4. トランザクションがまだコミットされていないデータを読み取るときに発生します

Transaction 1 changes a row of data and Transaction 2 reads the changed row before Transaction 1 commits the change. If Transaction 1 rolls back the change, Transaction 2 will have read data that theoretically, never existed. 

Non-Repeatable Reads

Occurs when a transaction executes the same query multiple times and gets different results with each execution

Transaction 1 reads a row of data, then Transaction 2 modifies or deletes that row and commits the change. When Transaction 1 attempts to reread the row, it will retrieve different data values 

Phantoms

Occurs when a row of data that matches some search criteria is not seen initially

Transaction 1 retrieves a set of rows that satisfy some search criteria, then Transaction 2 inserts a new row that contains matching search criteria for Transaction 1’s query. If Transaction 1 re-executes the query that produced the original set of rows, a different set of rows will be retrieved – the new row added by Transaction 2 will now be included in the set of rows returned 

LOCK PROPERTIES

LOCK OBJECT OWNER

这里的object是指锁所施加的对象，不同的锁所能适用的对象是不同的。如PAGE LOCK的对象肯定是PAGE.
OWNER 表示谁持有锁，有的是TRAN,有的是DB2 MEMBER
LOCK PARTICIPANTS



Locking is a complex interaction of many parts.

1. DBM1, where SQL executes, is the beginning of locking.
2. The IRLM, a separate address space, is where locks are held and managed. The DBM1 AS requests locks from the IRLM. In addition to its functionality of granting and releasing locks, the IRLM is also in charge of detecting deadlock and timeout situations.
3. In a data sharing environment, there are two other ingredients in the soup. The XCF address space is where its XCF component resides. The XES does some lock management and communicates directly with the lock structure in the coupling facility

   LOCK SIZE

   访问数据的范围
   设计锁的颗粒度对系统和应用均有影响：设计时要综合考虑
   1. 锁本身也是一种资源，持有的lock size越大，锁资源消耗越小
   2. lock size的大小与对应用访问的并发（concurrent）成反比关系
   3. LOCK SIZE 带来的另外一个副作用就是当你申请的锁资源足够多，以至于超过系统设定的阀值时（NUMLKUS/NUMLKTS/LOCK MAX =0,SYSTEM,N），
      lock size： PAGE/ROW /TABLE /PARENT LOCKS:TABLESPACE /PARTITION

      Page/Row locks are not compatible with tablespace locks The solution is "Intent Locking" Regardless of the locksize, DB2 will always start with a tablespace lock 

      INTENT LOCKS:IS/IX USED whenever page or row locks are being used
      GROSS LOCKS:The gross locks (S, U, SIX and X) are tablespace locks which are used in three
      situations
   4. lock size tablespace
   5. lock table for a non-segmented tablespace
   6. 非パーティションテーブルスペースのロックエスカレーション

      ロックモード

      データアクセス方法:排他的または共有S/U/X
      X:排他的、他と共有不可
      S:共有、他のS-ロックと共有可能
      ロックモード互換性SUNNXNNN

      lockduration

      
      
      

      持有数据：コミット、コミット（保留）全体のコミット：from from：first use to：commition ormomentialiy
      1. lockrequest and leleaseデータの変更（挿入、更新、削除)、
         DB2 がすべてのロック アクションを決定します
         
      2. テーブルスペースのロック サイズ
         =>初回使用時にロックがかかります
         =>ロックはコミットまたは割り当て解除時に解放されます
         
      SQL-ステートメント「排他モードでテーブルをロック」
      3. =>最初は IX ロック (テーブルスペース上)
         =>初回使用時にロックがかかります
         =>ロックはコミットまたは割り当て解除時に解放されます
         
      ページロックと行ロック
      =>最初は IX ロック (テーブルスペース上)=>その後、必要に応じて各ページ/行で X ロックが取得されます

      =>これらの X ロックは commit

      🎜LOCK AND TRAN ISOLATION LELVEL🎜🎜每一种事务隔离级别锁所能解决的问题🎜で解放されます。
      1. Repeatable Read
         => locks all data read by DB2
         => guarantees that exact the same result set will be returned when reusing the cursor
      2. Read Stability
         => locks all data “seen” by the application
         => guarantees that at least the same result set will be returned when reusing the cursor
      3. Uncommitted Read (UR)
         Pro:
         Our read will be “cheaper”
         We are not disturbing others
         Con:
         We may read data
         which may be “un-inserted”
         which may be “un-updated”
         When you are reading live (operational) data,you can never guarantee exact results
      4. Cursor Stability (CS)
         => a lock is taken when the row is fetched
         => the lock is released when next row is fetched,
         or at end of data or at Close Cursor
         For page locks:
         => a lock is taken when the first row on the page is fetched
         => the lock is released when next page is fetched,
         or at end of data or at Close Cursor
         This means:When you have fetched a row and have not reached end of data or closed the cursor,
         you are holding an S-lock on the row or page
      5. LOCK AVOIDANCE
         Updateable

         DECLARE upd_cur CURSOR FOR SELECT data1, data2 FROM table FOR UPDATE OF colx 

         Read-Only

         DECLARE ro_cur CURSOR FOR SELECT DEPTNO, AVG(SALARY) FROM EMP GROUP BY DEPTNO 

         Ambiguous

         DECLARE amb_cur CURSOR FOR SELECT data1, data2 FROM table 

         => Use FOR READ ONLY or FOR FETCH ONLY
         If we have the following:
         
         Read-Only (or Ambiguous) Cursor
         Cursor Stability
         Currentdata No
         it is possible that we can get "Lock Avoidance“
         Lock avoidance is advantageous!
         A possible problem with Currentdata No:
         Fetch a row
         ...
         Update (or Delete) Where Key = :hostkey
         can give SQLSTATE="02000" (Not Found)

      LOCKING PARAMETERS LOCATIONS

      下面分别介绍了系统参数，应用参数如何影响LOCK行为

      DDL

      OBJECT DEFINITION,CREATE TABLESPACE:

      1. LOCKMAX (INTEGER,SYSTEM)
      2. LOCKSIZE
         DEFAULT:ANY
         OPTION:ANY,TABLESPACE,TABLE,PAGE,ROW,LOB
      3. MAXROW:INTEGER
         DEFAULT:255
         同時実行性を高めるために使用されます
         MAXROWS 1行をエミュレートするために使用されますレベルロック
         ページの p-lock 処理のコストをかけずにロック
      4. MEMBERCLUSTER:(P-LOCK)
         メンバーごとのクラスタリング
         スペースマップページの p-lock 競合を削減
         クラスタリングインデックスに従ってクラスタリングを破棄
      5. TRACKMOD (P-LOCK)
         デフォルト:いいえ
         オプション:はい/いいえ

      DML

      1. ロックテーブル
         構文:LOCK {TABLE, TABLESPACE [partno]} IN
         {排他的、共有}モード
      2. カーソル定義
         更新用
         読み取り用ONLY
         1. 結果セットが読み取り専用であることを DB2 に伝えます
         2. 位置指定された UPDATE と DELETE は許可されません
         3. カーソルに対して U または X ロックは取得されません
      3. 分離節
         WITH [UR, CS, RS, RR]
         1. 排他的ロックを使用および保持する
         2. 更新ロックを使用および保持する
         3. 共有ロックを使用および保持する

      プリコンパイラのロックパラメータ

      NOFOR オプション:NO FOR update 句は位置指定更新に必須です
      STDSQL(はい): NOFOR を意味します

      バインド ロック パラメーター

      1. CURRENTDATA
         FUNCTION:CURRENTDATA は、DB2 がロックを回避しようとするかどうかを決定するのに役立ちます
         mean:プログラム内のデータは、現在のカーソル位置のデータと等しくなければなりません
         lock aovidance
         demo:
         
         CURRENTDATA (いいえ)
         注意
      2. 隔離
      3. リリース

      Zparm ロックパラメータ

      ZPARM	意味
      URCHKTH	UR チェックポイント頻度しきい値
      URLGWTH	UR ログ書き込みしきい値
      LRDRTHLD	長時間実行リーダー
      RELCURHL	保持されているロックを解除
      EVALUNC	コミットされていないものを評価
      SKIPUNCI	コミットされていない挿入をスキップ
      RRULOCK	RR/RS用Uロック
      XLKUPDLT	X検索された U/D のロック
      NUMLKTS	テーブル(スペース)ごとのロック
      NUMLKUS	ユーザーごとのロック

      CLAIM AND DRAIN

      BETWEEN SQL AND SQL:DB2 USE LOCKS
      BETWEEN UTILITY AND SQL:DB2 USE CLAIM AND DRAIN
      BASE:
      FOR EACH OBJECT(TABLESPACE,PARTITION,TABLE,IDNEXSPACE),THERE IS A CLAIM-COUNT
      WHICH IS INCREASED 1 AT START AND DECREASE BY 1 AT COMMIT
      A utility starts with a Drain
      No new Claims are allowed (wait, maybe timeout)
      If the Claim-count >0 the utility waits (maybe timeout)
      When the Claim-count reaches zero, the utility can continue
      Two important situations:

      • UR (Uncommitted Read) takes no locks – but increases Claim-count (UR REQUEST MASS-DELETE LOCKS)
      • For Cursor With Hold the Claim-count is not reduced at Commit

        A claim is a notification to DB2 that a particular object is currently being accessed. Claims usually do not continue to exist beyond the commit point one exception being a Cursor with Hold. In order to access the DB2 object within the next unit of work, an application needs to make a new claim.Claims notify DB2 that there is current interest in or activity on a DB2 object.Even if Uncommitted Read doesn’t take any locks, a claim is taken. As long as there are any claims on a DB2 object, no drains may be taken on the object until those claims are released. 

      A drain is the action of obtaining access to a DB2 object, by:Preventing any new claims against the object.Waiting for all existing claims on the object to be released. 

      A drain on a DB2 object causes DB2 to quiesce all applications currently claiming that resource, by allowing them to reach a commit point but preventing them (or any other application process) from making a new claim.A drain lock also prevents conflicting processes from trying to drain the same object at the same time.
      Utilities detect claimers are present and wait
      Drain Write waits for all write claims to be released
      Drain All waits for claims on all classes to be released
      SHRLEVEL(CHANGE) Utilities are CLAIMers

      LATCH

      Latches – managed by DB2
      ? BM page latching for index and data pages
      ? DB2 internal latching (many latches grouped into 32 latch classes)
      ? Latches – managed by IRLM
      ? Internal IRLM serialization

      ADVANCED TOPICS

      虽然标题是advanced topics,其实涉及的内容并没有本质的区别，只不过我们在看待问题，分析问题时需要从单个DB2 SUBSYSTEM的视角上升到DBMS CLUSTER的高度，即DATA SHARING GROUP的高度。为了处理不同的member之间共享数据的COHERENCY问题，DB2引入P-LOCK,区别主要在于单个DB2 SUBSYSTEM中的LOCK owner均为tran，而P-LOCK的owner为DB2 SUBSYSTEM.因此这里的内容按照这种分类进行介绍L-LOCK,P-LOCK,RETAINED LOCK，这几种锁之间的区别需要了解。

      L-LOCK(EXPLICIT HIERARCHICAL LOCKING )EHL

      特点：

      THE KIND YOU HAVE IN BOTH DATA SHARING AND NON DATA SHARING SUBSYTEM THEN CONTROL DATA CONCRRRENCY OF ACCESS TO OBJECTS THEN CAN BE LOCAL OR GLOBAL THEY ASSOTIATED WITH PROGRAMS 

      WHY IS HIERACHICAL

      SO THE MEMBER DB2 SUBSYSTEM WILL NOT PROPAGATE L-LOCKS TO THE CF UNNECESSARILY 

      1. PARENT LOCK
         PARENT LOCK ARE TABLE SPACE LOCKS OR DATA PARTITION LOCK
         GROSS LOCKS ARE ALWAYS GLOBAL LOCKS
      2. CHILD LOCK
         PAGE /ROW LOCK
         EXCEPTION: MAYBE TABLES LOCKS IF SEGMENT TABLESPACE
         PAGE/ROW LOCK CAN BE GRANTED LOCALLY IF NOT IN INTER-DB2 R/W SHARING STATE
         ASYNCHRONOUS CHILD PROPAGATION WHEN INTER-SYTEM INTEREST FIST OCCUR
      3. L-LOCK PROPAGATION
         NOT ALL L-LOCKS ARE PROPAGATED TO THE DB2 LOCK STRUCTURE
         PARENT L-LOCKS ARE ALMOST ALWAYS PROPAGATE TO THE DB2 LOCK STRUCTURE
      4. Child Locks Propagation based on Pageset P-lock
         Now based on cached(held) state of the pageset P-lock
         If pageset P-lock negotiated from X to SIX or IX, then child L-locks propagated
         Reduced volatility
         If P-lock not held at time of child L-lock request, child lock will be propagated
         "Index-only" scan (if any locks taken) must open table space
         Parent L-lock no longer need to be held in cached state after DB2 failure
         A pageset IX L-lock no longer held as a retained X lock
         Important availability benefit in data sharing
         CHILD L-LOCKS ARE PROPAGATED TO THE DB2 LOCK STRUCTURE ONLY IF THERE IS INTER DB2 PARENT L-LOCKS CONFICT ON A DATABASES OBJECT

      PHYSICAL LOCK

      特点：
      EXCLUSIVE TO DATA SHARING
      ARE ONLY GLOBAL
      USED TO MAINTAIN DATA COHERENCY IN DATA SHARING
      ALSO USED TO MAINTAIN EDMPOOL CONSISTENCY AMONG MEMBERS
      ASSOTIATED BY(OWNED BY) DB2 MEMBERS
      P-LOCK CAN BE NEGOTIATTED BETWEEN DB2 MEMBERS
      NO TIMEOUT OR DEADLOCK DETECTION
      分类

      1. PAGE SET P-LOCK
      2. PAGE P-LOCK
      3. PAGE SET/PARTITION CASTOUT P-LOCK

      4. 
         

      5. 
         

      6. GBP STRUCTURE P-LOCK

         RETAINED LOCKS(UPDATE LOCKS)

         AIM:PROTECT UNCOMMITED DATA FROM ACCESS BY THER LOCK STRUCTURE
         UPDATE(IX,SIX,X)
         GLOBAL LOCKS ARE RETAINED AFTER FAILTURE

         IMPACT OF Retained LOCKS

         

         <img src="/static/imghw/default1.png" data-src="http://www.bkjia.com/uploads/allimg/160227/11433Q233-1.png" class="lazy"    style="max-width:90%"  style="max-width:90%" alt="">The ONLY way to clear retained locks is by estarting the failed DB2 subsystem. 

         LOCK SCOPE:

         LOCAL LOCK

      GLOBAL LOCK

      A LOCK THAT A DB2 SHARING DB2 MEMBERHAS TOMAKE KNOWN TO OTHERS MEMBERS OF THIS DATA SHARING GROUP
      THE IRLM VIA XES,PROPAGATE TO THES LOCKS TO THE STRUCTURE IN THE CF
      XCF,XES的内容在XES contention部分介绍。

      GLOBAL LOCK COMMUNICATION

      HOW ARE GLOBAL LOCK REQUESTS MADE KNOWN TO OTHER DB2 MEMBERS?

      THEY ARE PROPAGATED TO DB2 LOCK STRUCTURE 

      Page Set P-Lock Negotiation
      

      与APPLICATION LOCK不同的是，PHYSCIAL LOCK 可以做Page Set P-Lock Negotiation。
      
      上图展示了INERDB2 READ/WRITE INTEREST场景下的PAGE SET P-LOCK NEGOTIATION。所谓的negotiation就是锁请求方以及锁申请方将锁请求均DOWNGRADE，从而达到compatible的目的。需要注意的是，PAGE SET P-LOCK STATE状态的变化需要涉及IRLM以及XCF通讯机制。PAGE SET P-LOCK对GLOBAL BUFFER POOL起一种标志作用，
      对于READ的DB2 SUBSYSTEM, must register its
      interest in read pages in the GBP directory
      对于UPDATER的DB2 SUBSYSTEM,must write updated pages to the group buffer pool and register those updated pages in the GBP directory

      CF LOCK STRUCTURE

      DEVIDE INTO TWO PARTS OF CF LOCK STRUCTURE RATIO OF LAST TWO COMPONETS DEFAULT ROUGHLY 50%CAN BE ALTERED BY IRLM PARAMETER 

      

      MODIFIED RESOURCE LIST(MRL)

      OVERVIEW OF MRL STRUCTURE
      
      ACTIVEstatus of active means that the DB2 system is running.
      Retained, on the other hand, means that a DB2 and/or its associated IRLM has failed
      CONTAINS ENTRIES FOR ALL CRURENTLY HELD MODIFY LOCKS
      IN THE EVENT OF DB2 FAILTURE ENSURE THAT OTHER MEMBER OF DB2 KNOW WHICH LOCKS MUST BERETIANED
      It is essentially a list structure that lists all the update or modify locks in the data sharing group
      DISPLAY GROUP ; Display “LIST ENTRIES IN USE”

       NUMBER LIST ENTRIES : 7353, LIST ENTRIES IN USE: 1834 

      WARNING: When the LIST ENTRIES IN USE catches up to the NUMBER LIST ENTRIES, new modify lock requests will not be granted, and transactions will begin to fail with -904s.

      LOCK TABLE

      A 'POOL' OF HASH POINTERS
      CONTAINS ENTRIES FOR ALL READ AND MODIFY LOCKS
      USED FOR GLOBAL LOCK CONTENTION
      It is very difficult to keep track of how full a randomly populated table is, so the only way to track its utilization is indirectly. In DB2 data sharing, that tracking mechanism is false contention
      SIZE OF EACH INDIVIDUAL ENTRY SET BY MAXUSRS PARAMETER IN IRLMPROC OF FIRST IRLM JOIN THE GROUP
      NUMBER OF MEMBER IN THE GROUP

      XCF

      
      
      其实主要的目的就是提供INTER-SUBSYTEM之间通讯的API，主要的功能有三个：

      1. シグナリング サービスは、同じ XCF グループ (マルチシステム アプリケーションによって XCF に定義された一連の関連メンバー) のメンバー間で通信するための方法を提供します。この機能は、両者間の通信を提供することにより、並列シスプレックスの単一システム イメージの概念をサポートします。 DB2 メンバーなどのサブシステム、および各イメージ内の z/OS コンポーネントを使用すると、マルチシステム アプリケーションがグループとそのメンバーを XCF に定義できるようになり、同じ内の他のメンバーに関する情報を要求する手段も提供されます。 SETXCF コマンドを使用した XCF グループ。
      2. XCF のステータス監視サービスは、同じシスプレックス内の他の z/OS システムのステータスを監視する手段を提供します。
      XES
      3. は、CF にアクセスするためのさまざまな SUBSYSTEM API を提供します。 XES 自体は、S|X タイプという 2 つのロック タイプのみをサポートします。ただし、DB2 SUBSYTEMB 自体はさまざまなタイプのロックをサポートしているため、これらのロック タイプを CF に送信するときにどのようにマップする必要があるかという問題が発生します。DB2 V7 プロトコル レベル 1 と V8 プロトコル レベル 2 の処理はまったく異なります。もちろん、この変更の目的は、CF ロックに送信されるリクエストの数を減らし、ロックの競合を完全に検出できることを前提としてグローバル ロック検出メカニズムを最適化することです。 V7 から V8 への最適化の出発点は、XES ロック マッピングの問題をさらに解決することです。V8 から V10、さらには V11 へも基本的には変わりません。これは、V8 の最適化の重要性を示しています。

         DB2 には、データ共有の下に明示的な 3 レベルのロック構造があり、2 つのレベルのアプリケーション ロックと DB2 メンバー レベルの PAGE SET P LOCK のステータス変更は次のとおりです。

         
         
         アクション DB2メンバー関心ページの設定 P ロックSTAE CHANGEopenPP-LOCK S/ISNONE->R/O疑似OPENPP-LOCK IX/SIX/ X /UR/O->R/WPSEDUO CLOSEPP-LOCK S/ISR/W->R/OPhysical CLOSENONE R /O->なしXES 競合

         根本的な原因は、XES 自体が 2 つのロック タイプのみをサポートするように設計されていることです。
         ?XES 競合 = XES
         は S または X のみを理解するため、XES レベルのリソース競合です
         例: メンバー 1 が IX とメンバー 2 を要求していますIS の場合
         V8 での大幅な緩和

         誤った競合

         主な理由は、DB2 ロック テーブルが小さすぎるか、ハッシュ アルゴリズムが十分に離散的ではないため、同じロック テーブル ハッシュ クラスにハッシュされた異なる DB2 リソース間で競合が発生する可能性があります。この問題は CF ロック テーブルを拡大することで解決できるため、FALSE CONTENTION は CF LOCK STRUCTURE のサイズが適切かどうかをマークします。

         グローバル競合

         グローバル競合自体には、XES競合、FALSE競合、REAL競合が含まれており、このうちREAL競合は確かにリソースホットスポットなどのリソース競合であり、他の2つの競合はデータ共有のオーバーヘッドの導入によるものです

         によると上記の紹介に加えて、以下は DB2 パフォーマンス チューニング ロードマップの表示です。2 データ共有ブロックです
         
         L-LOCK (SHARING) の部分はデータ共有の度合いを示します
         P/L XES CONTENTION は P-LOCK とCF に送信する必要がある L-LOCK。それ