DB2性能優化之設計DB2配置數據庫很好用！

在這裡我們主要向大家講述的是DB2性能優化之設計DB2配置數據庫的正確操作步驟，在實際操作中有很多數據庫設計與配置選項時直接影響查詢DB2數據庫的性能。對數據庫設計的更多建議參考“ Planning your Physical Database Design ”最佳實踐文章。

使用約束來提高查詢優化

考慮定義的唯一性，檢查並參考一致性約束。這些約束提供了語義信息，允許 DB2 優化器重寫查詢來評估連接，通過連接來降低聚合和 FETCH FIRST N ROWS，去掉不必要的 DISTINCT 選項被和一些其它的DB2性能優化。

當應用程序可以保證它自己的關系時，信息約束也可以被用來檢查並參考一致性約束。相同的優化也是可以的。當更新(插入或刪除)行的時候，來自數據庫管理器的強制約束可能導致很高的系統開銷，尤其在更新很多有一致性約束的行的時候。如果一個應用程序在更新一行之前已經驗證的信息，這樣使用信息約束比起正常的約束更有效

例如，考慮 2 個表 DAILY_SALES 和 CUSTOMER 。在 CUSTOMER 表中的每一行都有一個唯一的客戶鍵值(CUST_KEY)。 DAILY_SALES 包含一個 CUST_KEY 列並且每一行都引用一個 CUSTOMER 表中的客戶鍵。可以創建一個參考一致性約束來防止在 CUSTOMER 和 DAILY_SALES 之間發生 1:N 的關系。

如果應用程序要強制約束這個關系，可以創建一個信息化的約束。那麼下面的查詢避免了在 CUSTOMER 和 DAILY_SALES 之間進行連接，因為沒有從 CUSTOMER 獲取任何列，而且來自於 DAILY_SALES 的每一行都可以在 CUSTOMER 裡面找到與之匹配的行，所以查詢優化器將自動刪除連接

SELECT AMT_SOLD, SALE PRICE, PROD_DESC   
FROM DAILY_SALES, PRODUCT, CUSTOMER   
WHERE   
DAILY_SALES.PROD_KEY = PRODUCT.PRODKEY AND   
DAILY_SALES.CUST_KEY = CUSTOMER.CUST_KEY   

應用程序必須執行信息約束，否則查詢可能返回不正確的結果。在上面的例子中，如果行存在於 DAILY_SALES 中，在 CUSTOMER 表中卻找不到相應的客戶鍵，那麼上面的查詢返回的行可能不正確。

在復雜查詢中使用 REOPT 綁定選項和輸入變量

在一個在線事務處理(OLTP)環境的中輸入變量有較好的語句准備時間是關鍵，在這樣的環境中語句往往比較簡單而且查詢計劃選擇也很簡單。使用不同的輸入變量多次運行相同的語句可以復用在動態語句高速緩存中編譯了的訪問片段，避免了由於隨時更改輸入值而造成昂貴的 SQL 語句編譯開銷。

然而，輸入變量對復雜的查詢負載也會造成問題，它們的查詢計劃選擇非常復雜，因此優化器需要更多的信息來做出好的決定。而且，語句編譯時間通常是總運行時間中的一個很小組成部分。因為 BI 查詢通常不會重復，所以並沒有從動態語句高速緩存上得到好處。

如果在一個復雜查詢工作負載中需要使用輸入變量，請考慮使用 REOPT(ALWAYS) BIND 選項。當輸入變量值是已知的，REOPT BIND 選項從 PREPARE 到 OPEN 或執行過程中推遲了語句編譯。變量值被傳遞到 SQL 編譯器中，這樣優化器可以使用這些便利來計算一個更精確的選擇評估。 REOPT(ALWAYS) 表示所有執行語句都應該被預編譯。

REOPT(ALWAYS) 也可以被用於涉及特殊寄存器的復雜查詢，比如 "WHERE TRANS_DATE = CURRENT DATE - 30 DAYS" 。如果輸入變量對 OLTP 工作負載造成較差的訪問計劃選擇，並且 REOPT(ALWAYS) 選項因為語句編譯造成過多的開銷，那麼考慮對挑選過的查詢使用 REOPT(ONCE) 。 REOPT(ONCE) 推遲語句的編譯直到首個數據變量被綁定。

使用這個首個輸入變量值編譯並優化 SQL 語句。後續使用不同的值來運行的語句將重用基於第一個輸入編譯的查詢片段。這是一個好方法 , 如果首個輸入變量代表了後續的輸入值，並且在輸入值未知的情況下比起優化器使用不同的值進行評估，它提供個了一個更好的查詢訪問計劃 .

有很多方法來指定 REOPT：

對 C/C++ 應用程序中的嵌入式 SQL，使用 REOPT BIND 選項。這個 BIND 選項影響靜態和動態 SQL 的再DB2性能優化行為。

對 CLP 包，用 REOPT 綁定參數重新綁定 CLP 包。例如，使用 CS 隔離級別和 REOPT ALWAYS 來重新綁定 CLP 包，詳細命令：

rebind nullid.SQLC2G13 reopt always;  

對使用傳統 JDBC 驅動的 CLI 應用程序或 JDBC 應用程序，在 db2cli.ini 中設置 REOPT 關鍵字。選項的值是：

2 - NONE

3 - ONCE

4 - ALWAYS

對於使用 JCC 通用驅動的 JDBC 應用程序，使用下面的方法之一：

使用 SQLATTR_REOPT 連接或語句屬性。

使用 SQL_ATTR_CURRENT_PACKAGE_SET 連接或語句屬性來制定 NULLID、NULLIDR1 或 NULLIDRA 包集合。 NULLIDR1 和 NULLIDRA 是保留的包集合名稱。一旦使用就分別隱含了 REOPT ONCE 和 REOPT ALWAYS 。這些包集合需要於那個下面命令顯示的創建： db2 bind db2clipk.bnd collection NULLIDR1;

db2 bind db2clipk.bnd collection NULLIDRA;  

對 SQL PL 存儲過程使用下面的方法之一：

使用 SET_ROUTINE_OPTS 存儲過程來為在當前會話中創建 SQL PL 存儲過程設置綁定選項，例如調用 sysproc.set_routine_opts( ‘ reopt always ’ )

使用 DB2_SQLROUTINE_PREPOPTS 注冊表變量在實例級別設置 SQL PL 存儲過程選項。值設置為使用 SET_ROUTINE_OPTS 存儲過程將覆蓋 DB2_SQLROUTINE_PREPOPTS 指定的值

你可也能使用優化配置來為靜態語句和動態語句設置 REOPT，如下面例子顯示的：

<STMTPROFILE ID="REOPT example "> <STMTKEY> 
<![CDATA[select acct_no from customer where name = ? ]]> 
</STMTKEY> 
<OPTGUIDELINES> 
<REOPT VALUE='ALWAYS'/> 
</OPTGUIDELINES> 
</STMTPROFILE> 

為你的工作負載選擇最佳的優化級別

設置優化級別可以獲得顯式指定優化技術的好處，尤其出於下面的原因：

為了管理非常小的數據庫或者非常簡單的查詢語句

為了在你的數據庫服務器編譯時進行內存限制

為了減少查詢編譯時間，比如 PREPARE

大多數語句可以通過使用第 5 級優化得到充分的優化和合理的資源，這也是默認的查詢優化級別。在一個給定的優化級別，查詢編譯時間和資源消耗是主要受查詢復雜度的影響，尤其是連接以及子查詢的數目。不過，編譯時間和資源的使用同樣受到執行優化的影響。

查詢優化級別 1，2，3，5 和 7 適用於一般用途。只有你需要進一步減少查詢優化時間而且在你知道 SQL 語句非常簡單的情況下才考慮級別 0 。

Tip：要分析一個運行很長時間的查詢，對查詢運行 db2batch 來找出花了多少時間在編譯上在運行上花費了多少時間。如果編譯需要更多的時間，降低優化級別。如果執行需要更多的時間那麼就考慮更高的優化級別

當你選擇了一個優化級別，考慮下面的一般准則：

從使用默認查詢優化級別開始，級別 5

要使用默認級別之外的級別，首先嘗試級別 1，2 或 3 。級別 0，1 和 2 使用貪婪連接枚舉運算法則。

如果你有很多表以及在同一列上有大量的連接謂詞，在關心編譯時間的情況下使用DB2性能優化級別 1 或 2 。

對只有不到一秒的運行時間的查詢使用一個低的優化級別(0 或 1)。比如查詢往往有下面的特點：

只訪問一個或很少的表

只獲取一行或者幾行

使用完全唯一的索引

在線事務處理(OLTP)事務是這種類型訪問的很好例子

對長時間運行(超過 30 秒)的語句使用高一些的優化級別(3，5 或 7)。

優化級別 3 及其以上使用動態編程連接枚舉算法。這個算法考慮更多的可選計劃，並且可能招致比 0，1，和 2 更多的編譯時間，尤其在表的數目增加後。

只有在你對一個查詢有特別的優化需求時才使用優化級別 9 。

復雜查詢需要不同數量的優化來選擇最佳訪問計劃。對有下面特征的查詢，請考慮使用更高的DB2性能優化級別,

以上的相關內容就是對的介紹，望你能有所收獲。