程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> DB2數據庫 >> DB2教程 >> 正確數據,正確位置,正確時間

正確數據,正確位置,正確時間

編輯:DB2教程

到目前為止,DBAs 在其數據庫依賴什麼類型的存儲上很少有發言權:它們只是簡單地要求一個給定大小的空間,然後存儲管理員會提供這個空間。

然而,現在對 DBAs 來說,考慮它們應該使用何種存儲是很重要的。存儲已經不單單是 “存儲” 了。它們有高速,低速和中速之分,而且每種類型都適用於不同用途。

這個挑戰就在於決定在什麼地方存儲數據來獲得投資最佳回報(ROI)。本文將會探討如何創建一個分層方法來使用 IBM DB2 for z/OS 進行存儲,實現在正確的時間從正確的位置獲取正確的數據,以此來達到提高性能的優化,減少擁有者的總成本(TCO)這一終極目標。

磁盤存儲分層:選擇,選擇

DB2 DBA 之前從未碰到過如此多價格不同,性能各異的存儲選擇。在高端部分中,能夠輕松支持每秒鐘 5,000 次 I/O 操作(IOPS)的隨機 I/O 訪問模式固態驅動(SSDs)對需要 I/O 密集型的應用是很有吸引力的選擇。不過,它們也相當昂貴。

從其他范圍的終端來講,Serial ATA(SATA)驅動可以大至 2TB,但是通常只能交付大約 75 IOPS。它們在連續工作負載時會有良好的表現,但在隨機 I/O 訪問模式下就不盡然。

在這兩個極端之間,就是我們通常使用的光纖通道(FC)驅動,它多年來一直是企業存儲陣列的中堅力量。FC 驅動在合理的響應時間內(少於 5 毫秒)交付 180 IOPS。FC 驅動能力快速增長,但是看起來已經達到速度/響應的停滯階段。

不過,獨立的設備只是這個等式的一部分。所有種類的驅動按照其交付的性價比,在企業存儲陣列中排列。例如,RAID 1O(條帶鏡像)性能更佳,但比 RAID-5 更昂貴。類似地,RAID-5(條帶單奇偶)在某些性能上優於 RAID-6(條帶雙奇偶),不過 RAID-6 對數據丟失有更好的保護。

這些類型的存儲有一部分或者全部都對您可用,或者您可能還有其他的變化。無論您處在什麼環境下,通過定義您的層次來開始您的分層計劃。高成本,高性能存儲是您的黃金層,隨後是較便宜和響應較慢的白銀層和青銅層。

選層的挑戰

如果定義存儲層是相對較為簡單的,那麼在這些層上放置正確的數據就沒有那麼簡單了。這個決定可以從項目的主要參數開始:數據庫是否對該項業務至關重要?性能需求是怎樣的?可用性需求是怎樣的?

從這些問題來看,這個資格就變得更復雜了。在一個單獨的 DB2 系統中,不是所有的數據都一樣;或許在一個數據庫裡將各部分數據存儲在各個層上的方法行得通。甚至在生產數據中,某些表很少被訪問,而另一些則不斷被訪問。最後還有一個變數,訪問配置文件會隨時間而有所變化(見圖 1)。

您還需要考慮構成您存儲工作負載的 I/O 特性。它是隨機的還是連續的?是讀還是寫?讀和寫的比率是多少?I/Os 是大還是小?搞清楚您的工作負載會讓您做出最恰當的存儲分層選擇。

圖 1. 數據訪問模式,從創建到部署,通常描述為信息生命周期。

正確數據,正確位置,正確時間

查看原圖(大圖)

描述工作負載

從不同的時間和不同的存儲角度來看,工作負載有不同的強度。除了強度以外,工作負載的類型對哪個存儲層才是最優部署也有一定影響。所有 I/Os 都不一樣!

請考慮一個寫操作:大多數企業存儲陣列緩存一個入站的寫操作,然後立即向主機返回一個通道終端/設備終端確認。這個過程通常被稱為直接訪問存儲設備(DASD)快速寫。隨後,這個寫操作被降級到物理存儲。在這種情況下,什麼是底層存儲是否真的很重要?讓情況進一步復雜的是,DB2 緩沖設備的寫操作通常和事務工作負載異步,因此也在優先級上低於,例如,同步讀操作。

連續讀操作的工作負載,例如表空間掃描所帶來的,也非常有意思。當 DB2 處理一個需要表空間掃描的計劃時,它會執行一個預抓取動作,這個動作和預讀 I/Os 是異步的。當這個存儲陣列檢測到這個連續動作時,它也通過將表格數據讀到陣列上的緩存設備來執行預抓取。這個動作將磁盤放入到一種流模式,盡管來自其他 I/O 的中斷請求相同的物理存儲媒體。

在流模式中,轉動中的磁盤,即使不優於,也不會遜於固態磁盤。對這種類型的 DB2 工作負載,黃金層也許不是最佳選擇。事實上,將數據移動到黃金層並不能改善性能,反而可能會占用可以用於其他 I/O 動作的寶貴空間。

選擇某種類型 I/O 動作的正確層可能並不直觀,一個工作負載的經驗性測量可以幫助選擇更優化的分層部署。

選擇每層的最佳工作負載

決定哪些數據屬於哪層的最好方法就是通過分析表空間的資源管理工具(RMF)設備來決定 I/O 特性。例如,當查找可能適合 SSDs 的數據時,檢查系統管理工具(SMF)42 個子類型 6 條記錄是很有指導性的,這些信息顯示了高 DISCONNECT 時間的表空間。高 DISC 時間通常是一個指標,它指示在 DB2 同步讀操作的存儲控制緩存中該頁是否讀取。在區間內有高平均 DISCK 時間的數據集通常可能是移動到 SSDs 的候選項。

但是即使您識別了有高 DISCK 時間的數據集(即,那個正在使存儲緩存 “遺失”),有最高丟失率的數據集往往是最大的數據集,因為它們不能輕易存儲在存儲緩存中。您所需要的是理解您的數據集的 “丟失密度”。這個丟失密度就是您每取表空間存儲的一千兆字節有多少緩存丟失。您可以使用 DCOLLECTK 和 SMF 記錄,通過一些巧妙的電子表格工作來計算這個值。

SMF 報告中其他的十進制能夠標明 I/O 動作最少的數據集。這些數據集可以是存儲青銅層的候選項,尤其是如果這些數據集很大。

雖然本文中不會深入說明此類分析的所有細節,但可以歸納出一些基本規則:

隨機讀 I/O 動作是 SSDs 的最佳工作負載,尤其是那些造成很多存儲緩存丟失的動作。

高度連續的動作最適用於 FC 或者 SATA 驅動。

高寫動作最適用於不使用奇偶保護的 FC 驅動。如果存儲控制器是緩存限制的,高寫動作可以在 SSDs 中直接寫入,因為寫操作可以降級到磁盤,這比用 FC 或者 SATA 驅動要更快。

低 I/O 動作最適用於 SATA 驅動。

使用 DFSMS 來創建一個手動存儲分層策略

理想情況下,存儲機制和數據庫會自動合作,識別各種數據的最佳層,然後將數據移動到該層 — 但是我們還不在那裡。

同時,您可以使用 IBM Data Facility Storage Management Subsystem(DFSMS)來部署一套初級的手動分層方法。通過構建包含類似性能特性容量的存儲組,您就可以使用和存儲類設置聯合的 Automatic Class Selection(ACS),將 DB2 表空間指引到最適合的層。

這基本上有三個原因:第一,數據集放置的控制發生在分配時間(數據集創建時)。這並不考慮數據生命周期。當數據不再被頻繁訪問,變為低執行層候選項時會怎樣?第二,這假設您事先知道表空間性能需求。如果那些需求事先並不知道,而且表空間無意中放置在錯誤的層上要怎麼辦?您要怎麼移動它?第三,或許只有部分表空間很 “熱”,而其余部分相反,那麼它應該存在於多個層上。

一個存儲分層解決方案

當了解到表空間擁有持續、確定的性能需求時,就可以采用靜態存儲分層技術,或者使用 DFSMS。總體目標就是匹配存儲層、性能和數據 I/O 特性。圖 2 描述了一個簡單的靜態分層解決方案,它可以通過使用 Storage Management Subsystem(SMS)存儲組來實現。實際上,因為數據訪問模式的易變性,分層模式並非如此簡單。

圖 2. 使用 SMS 存儲組的靜態分層將數據特性匹配到存儲層。

正確數據,正確位置,正確時間

查看原圖(大圖)

各層間的數據移動

在任何分層模式中,有多種方法無需影響數據庫可用性,就能透明地將數據從一層移動到另一層:

DB2 Reorg 工具: 使用在線重組將一個表空間從一個磁盤移動到另一個磁盤是簡單且有效的。雖然控制其移動位置並非易事,但是可以使用保證空間或者修改 ACS 路徑來實現。

DB2 分區: 謹慎選擇分區鍵允許 DBA 使用下列數據集移動工具,將一個表空間的 DB2 分區從存儲的一個層滾動到另一層。

第三方工具:這包括 IBM Softek TDMF、IBM Softek zDMF、EMC z/OS Migrator、EMC Virtual LUN Migrator、EMC FAST、Hitachi TIEred Storage Manager,FDRPAS 和 FDRMOVE。請注意當您使用這些工具時,必須根據是否需要在數據集級別或者卷級別移動數據,DB2 表空間或者卷是否被積極使用,來驗證哪個工具是您需要的。

存儲分層:走向自動化

DB2 for z/OS 的存儲分層毫無疑問可以改善 ROI,增進性能優化,盡管這對 DBAs 管理整個策略來說是個負擔。DBAs 需要智能存儲系統,該系統可以根據用戶提供的策略設置,在數據庫環境下自動執行,在優化存儲層上放置表空間級別(或者更低級別的粒度)的數據。同時,它還是一個良好實踐 — 以及潛在的贏利點 — 使您能夠熟悉您所要求或者分配給您的存儲特性,並考慮它的最佳使用方法。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved