分布式應用是這樣的：它分布在整個企業的一個或多個硬件平臺，這些環境通常是與數據庫服務器相分離的。而DBA的工作就是監視這些環境并配置和優化數據庫服務器以滿足多種需求。大數據的出現加劇了DBA的問題，因為現在多個分布式應用需要訪問一個非常龐大的數據存儲。那么在DB2的環境下，有哪些可用調優的方法呢?我們將在本文中進行詳細介紹。

DBA必須首先解決常見的應用性能瓶頸。如果數據可用性或性能已經很差，那么面向高性能訪問大數據就會出現問題。這里是一份常見的調優問題列表，DBA要確保數據庫存在這些流程以減輕這些潛在的問題。

過度加鎖

在DB2環境中有兩個流程級別可以“存儲”數據：SQL流程和數據庫工具。SQL流程包括應用程序發布靜態SQL語句和動態發布的SQL語句。SQL會發布針對數據的鎖，并且這些鎖通常會避免數據正在被讀取的時候并發更新。此外，加鎖會避免諸如Load之類的工具加載數據，這會導致取代或是覆蓋正在被讀取的數據。

工具會發布針對數據的聲明。一條聲明類似于數據庫鎖，是因為它可以通過實體來保留數據以供訪問并避免某些并發的SQL訪問。一般來說，加鎖會強制聲明去等待，而聲明會強制SQL操作去等待。這就允許數據庫管理系統可以管理多個諸如Load或是Image Copy之類的并發工具，而不用受到SQL語句的干擾。

最常見的加鎖問題是SQL語句鎖定太多的數據。一條SQL語句讀取一條記錄通常會在此SQL語句執行期間鎖定多條記錄為只讀。這種行為在多個地方是受控的，包括語法，數據庫定義，以及通過應用程序提交語句的用法。

DBA應該審查SQL語句加鎖行為來確保鎖定最小量的數據。了解鎖定對象的大小和應用是如何訪問數據的。長期運行的應用程序可能會長時間鎖定數據，從而降低了數據可用性。考慮記錄級別的鎖定來最小化SQL的影響，盡管這可能會導致用于管理加鎖的CPU時間有所上升。

應用程序提交邏輯同樣應該加以審查，提交會釋放鎖定并允許數據訪問。

此外，DBA應該審查應用程序和工具的調度。例如，驗證諸如Image Copy這類工具在應用程序做數據庫更新的時候沒有在并發運行。

數據訪問模式的糟糕設計

如果表中某個記錄集訪問頻繁，那么它們便可成為一個“熱點”。比如一個按訂單號排序的訂單表。最近的訂單會在它們處理的時候更加活躍。由于多個應用程序和工具訪問少量記錄，那么數據訪問的影響就會集中在數據庫中的一個小范圍內。當某些事務鎖定或聲明數據時，而其他應用程序或工具試圖對它們進行訪問，這通常就會導致性能問題。

這樣的熱點可以在數據庫設計階段加以預測。DBA可以在數據庫中嵌入空白空間來分散數據，這樣就降低了在一個物理點活動的集中程度。其他選項包括分配記錄到整個數據庫的方法。在我們以上的訂單表例子中，DBA可能會實現以地理位置進行排序而非按訂單號排序的表。這樣，新訂單就不會彼此相鄰，而是分布于整個物理表。

大數據應用調優

大數據通常意味著一個需要高速數據分析軟件的大型數據存儲。很多時候這些大數據部署與企業數據倉庫共存。這意味著DBA人員必須與數據倉庫人員進行協作以保證良好的性能。下面提到的一些點需要我們充分考慮：

存儲于非常大的DB2表中的大數據可能會有特殊的恢復需求。考慮一個要每天進行分析的事務數據的大型存儲。業務管理者可能會認為此分析對日常生產至關重要，從而指定此數據為關鍵任務。如果發生故障，這些數據要怎樣才能恢復呢?對于一個數據倉庫最佳的做法就是指定數據在恢復上為低優先級的。

存儲在DB2表中的大數據可能需要DBA去降低或是最小化數據上索引的數量。雖然通常來說可以添加多個索引到一個表來改善查詢性能，而對于非常大的表其索引也會很大。磁盤存儲限制可能會阻止DBA創建某些索引。此外，更多的索引會減緩數據插入性能，同樣還會讓任何數據庫恢復過程運行更長的時間。

置于一個專門的軟硬件一體化設備中的大數據必須經常由數據倉庫表同時進行訪問。這通常是利用SQL連接語句加以實現的。DBA必須協調大數據設備的加載和數據倉庫的ETL流程以確保所有數據在查詢階段是可用的。

數據倉庫訪問優化

最后一點也是最重要的。數據倉庫的ETL流程有其自身獨特的性能問題。數據提取流程通常會作為多個并行數據查詢流程加以執行。數據倉庫團隊可能會使用高速網絡來加速這一流程。由于可操作數據可能不是以易于分析的形式呈現的，因此數據轉換需要編程技能。常見問題有空值，缺失或未知數據，甚至是諸如日期值為 “99/99/9999”的無效數據。

最后，加載流程通常包括多個針對倉庫表并發加載的工具。加載通常是長期運行和資源密集型的。

由于分布式應用試圖訪問大數據，它們也不可避免的會訪問數據倉庫數據。再次，DBA必須將此過程與數據倉庫ETL過程加以協調。

常見的方法是架設有兩個分區的表，活動和非活動分區。目標表物理上被分為數據集和分區。一個分區被指定為活動分區，而一個控制表或參數被設置用來指示哪個分區是活動的。分布式查詢現在可能訪問活動的數據，允許加載流程把數據加載到非活動分區。一旦加載完畢，活動和非活動標記就會切換。

分布式處理和大數據

優化分布式訪問性能的一個最佳實踐是使用資源約束分析。DBA會在收集性能數據的時候監視諸如磁盤子系統和CPU之類的資源。甚至查詢和工作運行時間也可以被當做是資源。當DBA發現某項資源受限時，他們會平衡其他資源以進行彌補。

例如，考慮一個被多個分布式應用經常查詢的大數據存儲。DBA可能會確定運行時間(資源#1)太長。一項資源均衡操作可能會添加更多的索引到表中。這樣便在加速了查詢時間的同時使用了磁盤存儲空間(資源#2)。

其他均衡操作包括刪除索引，為DB2分配額外內存，增加DB2的排序工作區，查詢調優，等等。這些以及其他方法都是記錄在DB2性能手冊中的。

總結

大數據可能意味著大的性能問題，并且通過分布式應用程序進行訪問會將這些問題進一步復雜化。DBA可以通過考慮以下方面來主動了解這些問題：

數據庫設計選項(活動/非活動分區，索引選擇，分散數據到整個物理數據集);

利用Explain優化分布式查詢;

協調大數據訪問和數據倉庫訪問;

執行資源約束分析。

分布式應用程序對于DBA來說可能會是個挑戰。通過解決當前以及潛在的數據可用性問題作為開始，尤其是那些企業數據倉庫中的問題。一旦這些擔憂得以緩解，那么DBA就可以開始管理對大數據的分布式數據訪問。