REORGCHK コマンド

以下の権限のいずれか。

• SYSADM、SCHEMAADM、 または DBADM 権限
• 表に対する CONTROL 特権

CURRENT STATISTICS オプションを指定していなければ、 REORGCHK はデフォルトのオプションだけを使用してすべての列から統計を収集します。 特に、列グループは収集されません。 さらに、LIKE 統計が以前に収集されている場合、それらは REORGCHK によっては収集されません。 収集される統計は、カタログ表に現在保管されている統計の種類によって異なります。

• いずれかの索引のカタログ内に詳細索引統計が存在する場合、 すべての索引の表統計および詳細索引統計が収集されます (サンプリングは行われません)。
• 詳細索引統計が収集されない場合、 すべての索引の表統計および通常の索引統計が収集されます。
• 分散統計が検出された場合、その表についての分散統計が収集されます。 分散統計が収集された場合、 頻度および変位値の数はデータベース構成パラメーターの設定値によって異なります。

REORGCHK は、8 つの異なる公式から得た統計を計算し、 表またはその索引の再編成によってパフォーマンスが低下するか、または改善できるのかを判別します。 表が ( NPARTITIONS * 1 エクステント・サイズ) より小か等しいページを使用する場合、各公式に基づいて、表の再編成が推奨されなくなります。 具体的には、以下のようになります。

• 非パーティション表 ( NPARTITIONS =1 ) の場合、しきい値は以下のようになります。

  (FPAGES <= 1 extent size)

• パーティション表では、以下のようになります。

  (FPAGES <= NPARTITIONS * 1 extent size)

• 複数パーティションのデータベースでは、表のデータベース・パーティション・グループのデータベース・パーティションの数を考慮した後、表の再編成が推奨されないこのしきい値を次のように変更します。

  FPAGES <=  'number of database partitions in a database partition group
         of the  table' * NPARTITIONS * 1 extent size

REORGCHK は、次の公式を使用して、行の物理的なロケーションおよび表のサイズを分析します。

• 公式 F1:

  100*OVERFLOW/CARD < 5

  表のオーバーフロー行の合計数は、行の合計数の 5% 以下でなければなりません。 オーバーフロー行は、行が更新されて、 新しい行のバイト数が古い行 (VARCHAR フィールド) のそれより大きくなる場合、 または列が既存の表に追加される場合に作成されます。 ただし、固定長の列の場合でも、表で圧縮が行われると、オーバーフローが生じることがあります。

• 公式 F2:
  通常の表では、以下のようになります。

  100*TSIZE / ((100-TPCTFREE)/100 * (FPAGES-NPARTITIONS) * (TABLEPAGESIZE-68)) > 70

  バイト単位の表のサイズ (TSIZE) は、表に割り当てられた合計スペースの 70 % を超えていなければなりません (フリー・スペースは 30% 以下でなければなりません)。 表に割り当てられる合計スペースは、 表データが存在する表スペースのページ・サイズによって決まります (オーバーヘッド分の 68 バイトを差し引きます)。 データ・オブジェクト内で割り当てられる最終ページは、通常はいっぱいにならないため、各パーティションごとに FPAGES から 1 を引きます (これは、FPAGES-NPARTITIONS と同じです)。 表の圧縮が使用されている場合は、ディクショナリーの推定サイズを計算に入れるために FPAGES が調整されます。

  REGULAR 表スペース内の通常の表は、1 データ・ページ当たり 255 行までに制限されています。 大きいページ・サイズと短い表の行を使用する場合、行がそのページに保管される方法によって、データ・ページ・スペースが無駄になる場合があります。 この場合、公式 F2 では 70 より小さい値が取得されることがあります。 しかし、この表の再編成では、255 行の制限のためにデータ・ページ・スペースが回収されない場合があります。 無駄なスペースを使用したい場合、より小さいページ・サイズを使用するか、またはご使用の REGULAR 表スペースを LARGE 表スペースに変換し、その後表を再編成する必要があります。 これは、LARGE 表スペース内にある表には影響を与えません。

  MDC 表では、以下のようになります。

  100*TSIZE / ((ACTBLK-FULLKEYCARD) * EXTENTSIZE * (TABLEPAGESIZE-68)) > 70

  FULLKEYCARD は、MDC 表の複合ディメンション索引のカーディナリティーを示します。 エクステント・サイズは、ブロックごとのページ数です。 バイト単位の表サイズが、必要最低限のブロック数を差し引いた後の残りのブロックの 70 パーセントを超えているかどうかが、公式でチェックされます。

• 公式 F3:

  100*NPAGES/FPAGES > 80

  まったく行を含まないページ数は、ページ合計数の 20% より少ない値にします (行が削除された後では、ページは空になります)。 前述のように、(FPAGES <= NPARTITIONS * 1 extent size) の場合は表の再編成は推奨されません。 したがって、F3は計算されません。 非区画表の場合は、 NPARTITIONS = 1。 複数区画データベースでは、この条件をFPAGES = 'number of database partitions in a database partition group of the table' * NPARTITIONS * 1 extent sizeに変わります。

  MDC 表または ITC 表の場合、この公式は、ページではなく、使用済みのブロックのパーセンテージを示します。この公式は次のとおりです。

  100 * activeblocks / 
     (
        (fpages_adjust / tExtentSize) -
        (numberOfTablePartitions * numberOfDatabasePartitions)
     )

REORGCHK は、次の公式を使用して、索引および表データに対する索引のリレーションシップを分析します。

• 公式 F4:
  • 非パーティション表では、以下のようになります。

    CLUSTERRATIO or normalized CLUSTERFACTOR > 80

    グローバル CLUSTERFACTOR および CLUSTERRATIO では、索引キーと分散キーの相関関係が考慮に入れられます。 クラスタリング索引比率は、80% より大きくします。 複数の索引が 1 つの表に定義される場合は、これらの索引のいくつかは、 低いクラスター比率を持っています (索引順序は、表の順序と同じではありません)。 これを避けることはできません。 表を再編成する際に、必ず最も重要な索引を指定してください。 そのクラスター比率は、通常、数の多い複写キーおよび数の多い項目を含む索引には最適ではありません。

  • パーティション表では、以下のようになります。

    AVGPARTITION_CLUSTERRATIO or normalized AVGPARTITION _CLUSTERFACTOR > 80

    AVGPARTITION_CLUSTERFACTOR および AVGPARITITON_CLUSTERRATIO 値は、索引キーから見て、データ・パーティションの中でデータがどの程度クラスタリングされているかを反映します。 パーティション表は特定の索引キーに関して各データ・パーティションの中で完全にクラスタリングすることが可能ですが、それでも CLUSTERFACTOR および CLUSTERRATIO の値は低くなります。なぜなら、索引キーは表パーティション・キーの接頭部ではないからです。 最も重要な索引キーを表パーティション・キーの接頭部として使用して、表および索引を設計してください。 それに加えて、オプティマイザーは複数のデータ・パーティションを対象とした照会に関する決定を下すにあたり、グローバルなクラスタリング度を表す値を使用するため、クラスタリングの再編成を実行しつつも、キーが適切でない場合はオプティマイザーがクラスタリング索引を選択しないようにすることができます。

  注:

  • 先読みプリフェッチが有効になっている場合、公式 F4 は、REORG コマンドを実行するかどうかの良い指標とはならない可能性があります。 REORG コマンドを実行するかどうかは、照会パフォーマンスに応じて決定するのがより適切です。
  • 索引キー列のランダム順序付けの場合、CLUSTERRATIO は低くなります。 索引キー列のランダム順序付けでは索引キーを順不同に並べ、データ順に挿入するため、この数値は低くなります。 ランダム順序付けをクラスタリング索引として使用することはできません。 これらの理由により、REORGCHK の公式 F4 の結果には常に、索引をランダム順にする場合、再編成は必要でないことが示されます。 REORGCHK_IX_STATS ストアード・プロシージャーを使用する場合も同様です。
• 公式 F5:
  • 単一データベース・パーティションの場合:

    100*(KEYS*(LEAF_RECSIZE+LEAF_RECSIZE_OVERHEAD)+(INDCARD-KEYS)*DUPKEYSIZE)
    / ((LEAF-NUM_EMPTY_LEAFS-1)* (INDEXPAGESIZE-LEAF_PAGE_OVERHEAD)) 
    > MIN(50,(100-PCTFREE))

    索引のリーフ・レベルで使用されている割り振りスペースのパーセンテージは、PCTFREE が CREATE INDEX ステートメントによって定義されている場合は、最小の 50 パーセントと 100 パーセントの PCTFREE パーセントより大きくなければなりません。 使用されるスペースがこの値より少ない場合、REORG を実行することによって索引を小さくすることができます。 索引のリーフ・ページを 1 ページより少なくすることはできないので、この公式は、LEAF>1 の場合にのみ検査されます。

  • 複数パーティション・データベース環境の場合:

    100*(KEYS*(LEAF_RECSIZE+LEAF_RECSIZE_OVERHEAD)+(INDCARD-KEYS)*DUPKEYSIZE)
    / ((LEAF-NUM_EMPTY_LEAFS-NPARTITIONS)*(INDEXPAGESIZE-LEAF_PAGE_OVERHEAD)) 
    > MIN(50,(100-PCTFREE))
    

• 公式 F6:

  (( 100-PCTFREE ) * ((FLOOR((100 - LEVEL2PCTFREE) / 100 * 
  (INDEXPAGESIZE-NLEAF_PAGE_OVERHEAD)/(NLEAF_RECSIZE+NLEAF_RECSIZE_OVERHEAD)))*
  (FLOOR((100-MIN(10, LEVEL2PCTFREE))/100*(INDEXPAGESIZE-NLEAF_PAGE_OVERHEAD)/
  (NLEAF_RECSIZE+NLEAF_RECSIZE_OVERHEAD)) ** (NLEVELS-3)) * 
  (INDEXPAGESIZE-LEAF_PAGE_OVERHEAD))/(KEYS*(LEAF_RECSIZE+LEAF_RECSIZE_OVERHEAD)+
  (INDCARD-KEYS) * DUPKEYSIZE)) < 100

  索引の再作成がツリーのレベル数を減少させるかどうかを判別するために、 この公式は現行のツリーよりも 1 つ低いレベルの索引ツリー内にあるスペースの量と 必要なスペースの量との比率を検査します。 1 つ低いレベルのツリーを作成しても PCTFREE が使用できるなら、再編成をお勧めします。 索引項目の実際の数は、NLEVELS-1 索引ツリーが処理できる項目数の (100-PCTFREE) パーセントを超えてはなりません ( NLEVELS>2の場合にのみ検査されます)。 NLEVELS = 2 の場合に索引の再編成が必要かどうかを判断するには、他の REORGCHK 公式に頼る必要があります。

  簡易な形式の場合、公式 F6 は以下の形式に書き直すことができます。

  Amount of space needed for an index if it was one level smaller
  --------------------------------------------------------------- < 1
      Amount of space needed for all the entries in the index

  左上の部分が1より大きい場合、既存のインデックスのすべてのインデックスエントリが、既存のインデックスより1レベル小さいインデックスに収まる可能性があることを意味します。 この場合、索引の REORG をお勧めします。

  NLEVELS-1 索引に必要なスペース量は、次のように計算されます。

  (The max number of leaf pages that a NLEVELS-1 index can have) * 
  (Amount of space available to store index entries per leaf page)

  ここで、

  The max number of leaf pages that a NLEVELS-1 index can have =
  (No. of entries a level 2 index page can have) *
  (No. of entries per page on levels greater than 2) **
  (No. of levels in the intended index - 2) =
  
                (100 - LEVEL2PCTFREE)         
  { FLOOR( [----------------------------]  *  
                        100                   
              
              (PageSize - Overhead)                       
  [-------------------------------------------] ) *
     (Avg. size of each nonleaf index entry)   
  
            (100 - MIN(10, LEVEL2PCTFREE))       
  FLOOR([------------------------------------] * 
                        100                      
   
            (PageSize - Overhead)                          
  [----------------------------------------------------])**                       
         (Avg. size of each nonleaf index entry)
  
  (NLEVELS-3) }
  
  
  (100 - LEVEL2PCTFREE) is the percentage of used space on level 2 of the index.
  
  Level 2 is the level immediately above the leaf level.
  
  (100 - MIN(10, LEVEL2PCTFREE)) is the percentage of used space on all levels
  above the second level.                                     
  
  NLEVELS is the number of index levels in the existing index.
  
  The amount of space available to store index entries per leaf page = 
  ((100-PCTFREE)/100 * (INDEXPAGESIZE - LEAF_PAGE_OVERHEAD)) =
  ( Used space per page * (PageSize - Overhead) )
  
  The amount of space needed for all index entries:
  KEYS * (LEAF_RECSIZE + LEAF_RECSIZE_OVERHEAD) +
  (INDCARD - KEYS) * DUPKEYSIZE

圧縮解除索引内にあるすべての索引項目に必要なスペース量は、以下のようになります。

KEYS * (LEAF_RECSIZE + LEAF_RECSIZE_OVERHEAD) +
(INDCARD - KEYS) * DUPKEYSIZE

ここで、LEAF_RECSIZE は索引キーの平均サイズです。DUPKEYSIZEはRIDのサイズです。

圧縮索引では、LEAF_RECSIZEは接頭部圧縮の影響を受けます。 DUPKEYSIZEはインデックスの重複キーのサイズ測定に対して、信頼できる方法ではありません。 圧縮索引で必要なスペース量は、圧縮解除されているすべての索引項目で必要とされるスペース量に索引圧縮比率を乗算して求めます。

(KEYS * (LEAF_RECSIZE + LEAF_RECSIZE_OVERHEAD) +
(INDCARD - KEYS) * DUPKEYSIZE) * COMPRESSION_RATIO

ここで、COMPRESSION_RATIOは索引内の索引圧縮率の見積もりです。 COMPRESSION_RATIO は、以下のようにして計算されます。

(100 - PCT_PAGES_SAVED) / 100

ここで、PCT_PAGES_SAVEDは、索引圧縮に節約されるリーフ・ページの推定パーセンテージです。 この値は、カタログから取得されます。 統計が収集されない場合、カタログ内のPCT_PAGES_SAVEDは -1、COMPRESSION_RATIOは1です。

以下に、パーティション表 MYDPARTT1 に対する表統計の出力例を示します。 この表には、デフォルト・パーティション名 PART0、PART1、および PART2 という 3 つのデータ・パーティションがあります。

Table statistics:

SCHEMA.NAME             CARD  OV  NP  FP ACTBLK  SIZE  F1  F2  F3 REORG
-----------------------------------------------------------------------
Table: USER1.MYDPARTT1
                           -   -   -   -      -     -   -   -   - ---
Table: USER1.MYDPARTT1
Data Partition:  PART0
                           -   -   -   -      -     -   -   -   - ---
Table: USER1.MYDPARTT1
Data Partition:  PART1
                           -   -   -   -      -     -   -   -   - ---
Table: USER1.MYDPARTT1
Data Partition:  PART2
                           -   -   -   -      -     -   -   -   - ---
-----------------------------------------------------------------------

以下に、パーティション表 MYDPARTT1 の索引統計の出力例を示します。 この表には、3 つのデータ・パーティション、1 つの非パーティション索引 MYNONPARTIDX1、および 1 つのパーティション索引 MYDPARTIDX1 があります。

Index statistics:

SCHEMA.NAME                INDCARD LEAF ELEAF LVLS NDEL KEYS ... F4 F5 F6 F7 F8 REORG  
------------------------------------------------------------ ... --------------------
Table: USER1.MYDPARTT1
Index: USER1.MYNONPARTIDX1
                                 -    -     -    -    -    - ...  -  -  -  -  - ----- 
Index: USER1.MYDPARTIDX1
Data Partition:   PART0
                                 -    -     -    -    -    - ...  -  -  -  -  - ----- 
Index: USER1.MYDPARTIDX1
Data Partition:   PART1
                                 -    -     -    -    -    - ...  -  -  -  -  - ----- 
Index: USER1.MYDPARTIDX1
Data Partition:   PART2
                                 -    -     -    -    -    - ...  -  -  -  -  - ----- 
------------------------------------------------------------ ... --------------------