生成 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 ummy 數據庫,而不是之前在上面示例1中所連接的sample數據庫。