生成 db2exfmt 輸出： 

db2exfmt -d DUMMYDB -g TIC -w -1 -n % -s % -# 0 -o test_dummydb_exfmt.txt 

檢查 test_dummydb_exfmt.txt 的內容并查看訪問計劃： 

Access Plan: 
----------- 
 Total Cost:   25.8843 
 Query Degree:  1 

              Rows  
             RETURN  
             (   1)  
              Cost  
               I/O  
                 
                4  
             MSJOIN 
             (   2)  
             25.8843  
                2  
          /-----+-----\ 
        1                4  
     TBSCAN           TBSCAN  
     (   3)           (   5)  
     12.913           12.9682  
        1                1  
                          
        8               35  
 TABLE: SKAPOOR   TABLE: SKAPOOR   
       ORG             STAFF  

您在測試中獲得了一個不同于生產中的訪問計劃。本例中，顯然我們在測試系統上已經將 DFT_QUERYOPT（默認的查詢優化）從 5 修改為 3。因此，您看到的是 Merge Join 計劃，而非 Hash Join 計劃，以及有一點點區別的總成本（Total Cost）。 
因為這些計劃不匹配（假設您不確定為什么），所以要檢查 db2exfmt 輸出中的配置。見 表 2。 
正如您可以看到的，測試（TEST）和生產（PRODUCTION）之間的惟一區別就是優化級別（Optimization Level），我們特意將之從 5 修改為 3，只是為了顯示在測試環境中復制生產訪問計劃為何會不成功。 
本例中，您將使用下列 UPDATE 語句將 DFT_QUERYOPT 更新為 5： 

UPDATE DB CFG FOR SAMPLE USING dft_queryopt 5 

然后，停止并重新連接數據庫。再次對 DUMMYDB 發出 query.sql，并使用 db2exfmt 命令生成訪問計劃。這次，您將看到相同的訪問計劃。否則，就進一步確保本文中所討論的所有優化器相關的參數都是相同的。 
示例 2： 
該示例顯示了 db2look 命令中 -m 選項的重要性。前面用 -m 選項收集的統計數據在測試和生產中應該相同。本例中，我們將看到沒有正確更新統計數據時計劃是如何變化的。  
數據庫管理器配置、數據庫配置和 db2set 注冊表變量與上面 示例 1 中的相同。這里的模式名是 SKAPOOR。用您的表的模式替換它。數據庫是相同的，與 示例 1 中一樣是 SAMPLE 和 DUMMY。這里所使用的平臺和 db2level 是 AIX 5.1 和 DB2 UDB ESE V8.2，Fix pack 8，單分區。 
在 sample 數據庫上執行下列命令： 

db2 "connect to sample" 
db2 "create index name_ind on staff (name,id)" 
db2 "runstats on table skapoor.staff with distribution and indexes all" 
db2 "set current explain mode explain" 
db2 "select name from staff where id=10 order by name" 
db2 "set current explain mode no" 
db2 "terminate" 

使用 db2exfmt 生成訪問計劃。您將看到下面的訪問計劃：  

Access Plan: 
----------- 
        Total Cost:             0.111065 
        Query Degree:           1 

      Rows 
     RETURN 
     (   1) 
      Cost 
       I/O 
         
        1 
     IXSCAN 
     (   2) 
    0.111065 
        0 
         
       35 
 INDEX: SKAPOOR 
    NAME_IND 

從 sample 數據庫中收集 db2look 信息： 

db2look -d sample -l -o storage.out 
db2look -d sample -e -a -m -t STAFF -o db2look.out 
db2look -d sample -f -fd -o config.out 

修改這些文件以使您連接 dummy 數據庫，而非之前在上面 示例 1 中所連接的 sample 數據庫。  
手工修改統計數據之一。在 db2look.out 文件中搜索下列語句（請注意，模式名、TABSCHEMA 和 INDSCHEMA 可能與您的具體情況不同）： 

UPDATE SYSSTAT.INDEXES 
SET NLEAF=1, 
    NLEVELS=1, 
    FIRSTKEYCARD=35, 
    FIRST2KEYCARD=35, 
    FIRST3KEYCARD=-1, 
    FIRST4KEYCARD=-1, 
    FULLKEYCARD=35, 
    CLUSTERFACTOR=-1.000000, 
    CLUSTERRATIO=100, 
    SEQUENTIAL_PAGES=0, 
    DENSITY=0, 
    AVERAGE_SEQUENCE_GAP=0.000000, 
    AVERAGE_SEQUENCE_FETCH_GAP=0.000000, 
    AVERAGE_SEQUENCE_PAGES=0.000000, 
    AVERAGE_SEQUENCE_FETCH_PAGES=0.000000, 
    AVERAGE_RANDOM_PAGES=1.000000, 
    AVERAGE_RANDOM_FETCH_PAGES=0.000000, 
    NUMRIDS=35, 
    NUMRIDS_DELETED=0, 
    NUM_EMPTY_LEAFS=0 
WHERE INDNAME = ’NAME_IND’ AND INDSCHEMA = ’SKAPOOR ’ 
      AND TABNAME = ’STAFF’ AND TABSCHEMA = ’SKAPOOR ’; 

現在，將 FIRSTKEYCARD、FIRST2KEYCARD、FULLKEYCARD 和 NUMRIDS 從 35 修改為 37�，F在保存 db2look.out 文件并運行這 3 個文件： 

db2 -tvf config.out > config_output.out 
db2 -tvf storage.out > storage_output.out 
db2 terminate 
db2stop 
db2start 
db2 -tvf db2look.out > db2look_output.out 

檢查前兩個文件 config_output.out 和 storage_output.out 的內容，以確保它們運行成功�，F在，檢查 db2look_output.out 文件的內容。您將看到下列更新語句失敗了： 

UPDATE SYSSTAT.INDEXES SET NLEAF=1, NLEVELS=1, FIRSTKEYCARD=37, FIRST2KEYCARD=37 
, FIRST3KEYCARD=-1, FIRST4KEYCARD=-1, FULLKEYCARD=37, CLUSTERFACTOR=-1.000000, C 
LUSTERRATIO=100, SEQUENTIAL_PAGES=0, DENSITY=0, AVERAGE_SEQUENCE_GAP=0.000000, A 
VERAGE_SEQUENCE_FETCH_GAP=0.000000, AVERAGE_SEQUENCE_PAGES=0.000000, AVERAGE_SEQ 
UENCE_FETCH_PAGES=0.000000, AVERAGE_RANDOM_PAGES=1.000000, AVERAGE_RANDOM_FETCH_ 
PAGES=0.000000, NUMRIDS=37, NUMRIDS_DELETED=0, NUM_EMPTY_LEAFS=0 WHERE INDNAME = 
 ’NAME_IND’ AND INDSCHEMA = ’SKAPOOR ’ AND TABNAME = ’STAFF’ AND TABSCHEMA = ’SK 
APOOR ’ 
DB21034E  The command was processed as an SQL statement because it was not a 
valid Command Line Processor command.  During SQL processing it returned: 
SQL1227N  The catalog statistic "37" for column "FULLKEYCARD" is out of range 
for its target column, has an invalid format, or is inconsistent in relation 
to some other statistic. Reason Code = "8".  SQLSTATE=23521 

正如您可以看到的，上面用于索引 NAME_IND 的 UPDATE 語句失敗了，因為 FULLKEYCARD 大于表的基數（CARD）。正如通過 db2look.out 文件中的下列更新語句可以看到的，CARD 是 35： 

UPDATE SYSSTAT.TABLES 
SET CARD=35, 
    NPAGES=1, 
    FPAGES=1, 
    OVERFLOW=0, 
    ACTIVE_BLOCKS=0 
WHERE TABNAME = ’STAFF’ AND TABSCHEMA = ’SKAPOOR ’; 

現在，再次以解釋模式運行相同的查詢： 

db2 "select name from staff where id=10 order by name" 

并生成訪問計劃。您將看到它是不同的： 

Access Plan: 
----------- 
        Total Cost:             12.972 
        Query Degree:           1 

      Rows 
     RETURN 
     (   1) 
      Cost 
       I/O 
         
        1 
     TBSCAN 
     (   2) 
     12.972 
        1 
         
        1 
     SORT 
     (   3) 
     12.9708 
        1 
         
        1 
     TBSCAN 
     (   4) 
     12.9682 
        1 
         
       35 
 TABLE: SKAPOOR 
      STAFF 

該示例顯示，如果在表上發生 WRITE 活動時運行 RUNSTATS，統計數據就可能與本示例中的不一致。因此，用于更新統計數據的 UPDATE 語句可能失敗并產生 SQL1227N 錯誤消息。所有的 UPDATE 語句都運行成功十分重要，如果存在不一致性，就應該進行修理并重新運行。本例中，解決方案是將 KEYCARDS 和 NUMRIDS 從 37 重新修改為 35。