導讀：對於一個應用程序的性能來說，其中數據庫的性能是一個重要因素。由於應用程序及其相關的數據總會隨著時間的推移而發生變化，因此必須不斷地對數據庫進行調優從而使其保持最佳水准。然而，花在調優上的努力應該在一個合理的范圍之內。調優應該有一個度，超過了這個度的一切努力只能產生負面影響。如果應用程序的性能還不能令人滿意，那麼就應該考慮其他的變通辦法，比如將該應用程序移到更快的平台上。下文就以講解DB2數據庫初始調優和設計方面為例為大家講解數據庫的調優。
本文中提到的命令和語法是基於 DB2 UDB V7 的，如果您使用的是 DB2 UDB V8，可能會稍有差異。
數據庫設計方面的考慮
數據庫調優始於設計階段。假設硬件的選擇是基於其他方面的考慮的，那麼第一個要決定的就是存儲架構。DB2 所使用的驅動器越多、越快，則潛在的性能將越好。對於表空間(tablespaces )和其他對象(日志，備份文件，等等)的位置應該小心仔細地加以規劃。尤其重要的是，要盡量保證日志和備份處在不同的驅動器上，這樣做不但是為了性能，也是為了便於恢復。
表空間設計是整個數據庫設計中的一個重要部分。通過創建不止一個的用戶表空間可以增強性能。在下面三種情況下，使用多個表空間就很有用：
控制 I/O，如果這些表空間可以位於不同的驅動器上的話。
使用不同的頁面大小(pagesize)。
控制緩沖池。
在大多數情況下，隔離的表空間是為索引和大型對象而創建的。以相同的頁面大小創建多於一個的表空間並沒有什麼好處。
比起系統管理的表空間來，數據庫管理(Database-managed)的表空間(尤其是在原始設備上)能夠提供更好的性能。在決定頁面大小時要記住，DB2 在一頁上最多只能放 255 行，剩余的空間將不被使用。例如，如果平均行長度是 50 字節，那麼一頁最多使用的空間是 50*255=12750 字節。如果將該表放在頁面大小為 16K 或者 32K 的表空間中，那麼有些頁就會被浪費。反之，如果有些表有更長的行，或者有很多的列，(具體的限制參見 SQL 參考手冊中 CREATE TABLE 語句)，那麼頁面大小就需要大於 4K。如果要以一種連續的方式(例如，群集表)來訪問數據，那麼采用更大的頁面大小可以獲得更好的性能，相反，如果對數據的訪問采用的是隨機方式，那麼最好使用盡可能小的頁面大小。
每個表空間都與具有相同頁面大小的一個緩沖池相關聯(一個緩沖池可以與不止一個的表空間相關聯)。在使用多個緩沖池的時候要謹慎。由於可用的存儲是有限的，為某個緩沖池分配過多的空間勢必減少其他緩沖池的寬度，從而導致整體性能的降低。緩沖池調優最好是在檢測數據庫性能和基准的基礎上進行。DB2 善於動態地管理可用空間，因此，在大多數情況下使用最少數量的緩沖池可以得到較好的性能。
長期以來，表設計的重要性就在於標准化。無冗余數據占據著最少的空間，並且具有最好的完整性。然而，無冗余數據並不能提供最好的性能。為了消除一點點的冗余，需要創建額外的表，這使得查詢時需要額外地結合這額外創建的表，從而增加查詢的復雜性。在平衡這兩方面的需求時，需要有正確的判斷。通常，通過生成冗余數據可以增加性能，但是這要采取一種受約束的方式，即冗余數據所采取的形式必須是索引和匯總表。如果要經常訪問匯總數據，那麼後者可以明顯增加性能。對刷新頻率的評估應該以信息需要保持的新鮮程度為依據。
索引是性能調優中最重要的方面之一。通常，對表的訪問都是基於一些標准的。根據組成這些標准的一些列構建索引，可以動態地減少查詢相關的開銷。對於在線維護的不穩定的表應該創建少量的索引(一個或兩個)，而對於大型的歷史性的表，由於需要通過多種方式進行查詢，則需要創建很多的索引。一條索引中的列數應該盡量地少，除非很多查詢都可以通過一個“index only”搜索來完成。為了這個目的， INCLUDE 選項允許將其他字段附加到索引上，其開銷則小於完全索引方式。可以選擇一個表的某一索引作為群集索引，或者在 REORGANIZE 命令中指定該索引。表數據將保持由該索引指定的順序。當大量的查詢基於該索引訪問大量的行時，這種做法很有用。索引通常被放在它們自己的表空間中，擁有它們自己的緩沖池，以防止數據頁數量很多時會將索引頁擠出。
應用程序設計方面的考慮
應用程序設計同樣會影響到數據庫。首要的一步就是要確保應用程序只要求數據庫管理器做必需的工作。例如，通過使用 SELECT * 來請求所有的列在一定程度上可以使得程序的速度加快，但是這樣做卻降低了性能，因為需要額外的數據移動，而且阻止了“index only”掃描。在查詢中包括不必要的子句，例如 ORDER BY 或者 DISTINCT ，就是請求數據庫管理器做額外工作的一個例子。如果列的順序對應用程序的運行沒有影響，那麼就可以省下排序所花的時間。
控制鎖(locking)特性對於增加數據庫的吞吐量非常重要。即使是對於只讀事務，提交也具有極大的重要性，因為對於這樣的事務同樣也要使用鎖。選擇正確的隔離級別非常重要。應該使用盡可能低的隔離級別，只要在這種級別上應用程序能夠運行就行了。對於鎖來說，使用可重復讀隔離級別是極其昂貴的，並且也減少了並發性。只要不打算對結果集進行更新，那麼就應該包括 FOR READ ONLY 子句。這樣就可以保證獨占的鎖不被獲得。 FOR UPDATE 子句將消除對重新獲得更高級別鎖的需求。在某些環境下，在查詢之前通過應用程序獲得一個表鎖可以防止獲取很多的行鎖，從而防止了對鎖的逐步升級。
查詢優化是另一個可以節省大量資源的方面。優化的級別可以通過數據庫配置參數 dft_queryopt 進行設置。並且，在靜態 SQL 中可以通過 PREP 和 BIND 命令進行重設，在動態 SQL 中可以通過 SET CURRENT QUERY OPTIMIZATION 語句進行重設。對於復雜的查詢，可能需要第 5 級或者更高的級別。可以使用 db2batch 工具來評測花在編譯和執行 SQL 語句上的時間。至於結果，要記住，靜態 SQL 語句通常是編譯一次，執行多次;對於動態 SQL 也是一樣，因為結果要緩存。
初始調優
在創建了數據庫和表空間之後，可以使用 Performance Wizard 來設置初始數據庫配置。選擇數據庫以及“Configure Performance Using Wizard”選項。這將允許更快地裝載數據。在創建了數據對象之後，就應該裝載數據。
調優的第一步就是使用 RUNSTATS 命令收集統計信息。為了獲得整套的統計信息，應該指定“WITH DISTRIBUTION AND INDEXES ALL”選項。 RUNSTATS 應該是數據庫維護的一個常規的部分。應該根據數據庫的更新率有規律地(每日，每周，每月)調用 RUNSTATS 。如果對數據作了大的更改(裝載或者刪除了大量的行)，也應運行 RUNSTATS 命令。統計信息可用於決定對於一個查詢來說哪一個訪問計劃是最有效的。在執行了 RUNSTATS 命令之後，受到影響的包應該重新綁定。
在此之後應該再次執行 Performance Wizard，這一次是為了指定要填充的數據庫。Performance Wizard 將更改某些數據庫配置參數。如果正確地解決了這些問題，那麼由 Performance Wizard 產生的值通常會比較理想。Performance Wizard 使您可以在第一屏恢復先前的配置(如果有的話)。您應該認真閱讀窗口中的解說。最後一屏將顯示老的和新的數據庫配置，並對所有的更改用粗體進行高亮顯示。
如果在測試時性能不令人滿意，那麼就應該使用 Database System Monitor(參見 System Monitor Guide and Reference以了解細節)，或者將問題的源頭縮小至幾個事務，來查探這一問題的起因。對於特定的查詢，解釋工具(參見 Administration Guide 以了解細節)提供了有關性能問題可能的起因的有價值的信息。根據這些信息，可以對索引結構或者數據庫參數作出更改。
結束語
先前的討論強調了調優時需要考慮的的一些主要方面。調優是一個反復的過程。隨著時間的推移，數據庫中的數據以及應用程序需要更改。這時，為了適應新的需要，應該對性能進行檢測並對數據庫作出更改。對數據庫的配置參數或者其他方面所做的更改要有基准，要打破常規。在某些時候，有些更改看上去是對的，實際上卻會對數據庫產生負面的影響。希望大家通過上文的學習，都能夠很好的掌握關於DB2數據庫初始調優和設計方面的知識。
