DB2 DBA，如何解釋DB2的業務價值

許多技術人員可以輕鬆地討論 DB2 技術的細節，很自信地談論查詢並行化、資料壓縮、WebSphere MQ 整合、大對象管理、JDBC 和 ADO.Net 驅動程式、大型主機 Parallel Sysplex 上的資料共用、DB2 for Linux, Unix, and Windows(LUW)多維叢集等等話題。但是，如果談話的對方是管理層的成員，那麼會怎麼樣?公司管理者們關心的主要問題是收入的增長、成本控制、產品品質和產品投入市場的時間。一般來說，這些人並不關心鎖的粒度、伺服器記憶體管理和 SQL 陳述式最佳化這樣的技術問題。他們並不關心 DB2 技術本身的特色(儘管 DB2 技術是很酷的)，而是關心 DB2 對於實現組織目標能夠有哪些作用。本文將協助使用 DB2 的人從業務價值的角度討論 DB2 技術。

許多技術人員可以輕鬆地討論 DB2 技術的細節，很自信地談論查詢並行化、資料壓縮、WebSphere MQ 整合、大對象管理、JDBC 和 ADO.Net 驅動程式、大型主機 Parallel Sysplex 上的資料共用、DB2 for Linux, Unix, and Windows(LUW)多維叢集等等話題。但是，如果談話的對方是管理層的成員，那麼會怎麼樣?公司管理者們關心的主要問題是收入的增長、成本控制、產品品質和產品投入市場的時間。一般來說，這些人並不關心鎖的粒度、伺服器記憶體管理和 SQL 陳述式最佳化這樣的技術問題。他們並不關心 DB2 技術本身的特色(儘管 DB2 技術是很酷的)，而是關心 DB2 對於實現組織目標能夠有哪些作用。日常使用 DB2 的任何人都應該能夠從業務價值的角度討論 DB2 技術。

通過我在 CheckFree Corp. 的經驗，我總結出了一個關鍵領域列表，在這些領域中 DB2 技術可以提供業務人員能夠感受到的價值。

延展性 vs. 隨著業務增長

單伺服器 DB2 系統(無論是運行在大型主機上，還是運行在高端 Linux、Unix 或 Windows 伺服器上)可以為 OLTP、業務智能(BI)或組合工作負載提供巨大的輸送量。輸送量大主要是由於 DB2 利用了 64 位元伺服器記憶體定址、新穎的 I/O 最佳化特性(比如列表預擷取)、預最佳化的 SQL(DB2 專業人員將其稱為靜態 SQL)以及進階工作負載管理功能。但是，在擴張迅速的業務環境中，資料訪問請求量會快速增長，單伺服器系統的能力可能不足以處理未來的請求量。業務領導肯定不希望業務的增長受到資料服務器延展性的限制。這就是規模擴充(scale-out)的重要之處，而延展性正是 DB2 真正佔據優勢的領域。

在這個上下文中，“規模擴充” 這個詞指的是能夠將針對單一邏輯映像資料庫的工作負載分散到多個物理伺服器上。有兩個 DB2 規模擴充解決方案：大型主機叢集(稱為 Parallel Sysplex)上的資料共用和在 Linux、Unix 或 Windows 伺服器叢集上實現的 Data Partitioning Feature(DPF)。這兩種技術都是在行業中領先的技術。DB2 for z/OS 資料共用能夠支援企業從最多 32 個 DB2 子系統對一個共用資料庫進行並發讀/寫訪問(這些子系統可以運行在許多大型主機系統上，也可以運行在少量物理伺服器上，每個伺服器上有多個 DB2 子系統)。這個解決方案不是市場上惟一的共用資料 DBMS 規模擴充解決方案，但是其他任何技術都無法提供 DB2 for z/OS 資料共用組這樣好的 CPU 效率(真正並發的節點間讀/寫資料訪問的 CPU 開銷非常低)。

帶 DPF 功能的 DB2 能夠在 Linux、Unix 或 Windows 環境中提供無以倫比的規模擴充能力。可以在一個 DB2 DPF 系統中配置數以百計的伺服器;每個伺服器提供對單一邏輯映像資料庫的一個物理子集的訪問(一個散列演算法將給定的資料庫表的行分散到 DBA 指定的節點上)。市場上也有其他的非共用(shared-nothing) DBMS 規模擴充解決方案，但是其他解決方案都無法像帶 DPF 功能的 DB2 那樣兼具易用性和靈活性，因為 DPF 功能是嵌入在 DB2 for LUW 資料服務引擎中的。

對於共用資料和非共用 DBMS 體繫結構孰優孰劣的問題，人們還在爭論;但是，這兩種 DB2 解決方案對於底層伺服器平台都是非常合適的。DB2 for z/OS 資料共用的 CPU 開銷非常低，這是因為它使用的函數以最佳化的方式分散在整個 Parallel Sysplex 軟體結構中：z/OS 作業系統、DB2 DBMS、Coupling Facility Control Code(它管理全域鎖和資料緩衝所用的共用記憶體結構)以及 CICS 交易管理員或 DB2 Connect 分布式客戶機網關(如果配置中有這些組件的話)。這種最佳化是可行的，因為 DB2 for z/OS 資料共用只需要使用一個作業系統和一個晶片集(IBM System z 微處理器)。在 DB2 for LUW 環境中不可能進行這樣的功能分布，因為這樣的環境需要支援多個作業系統和多個伺服器硬體平台;因此，DB2 for LUW 規模擴充解決方案基於最佳的非共用叢集技術。無論採用哪種方式，組織都會得到所希望的效果：DBMS 不會阻礙業務的增長。

效率 vs. 降低總體擁有成本

在評估各種資料服務解決方案的相關費用時，人們往往關注獲得硬體和軟體許可證的費用。軟體和硬體的價格固然重要，但是在與 DBMS 相關的總擁有成本(TCO)中這隻占很少的一部分。影響成本的其他因素包括：

管理資料庫系統所需的人數;

使用硬體資源(CPU 和硬碟儲存)的效率;

技術的培訓費用;

讓企業中的不同資料庫系統一起工作的難度;

先說說 DB2 for z/OS，因為某些範圍內它可以替代非常昂貴的基於大型主機的解決方案。下面一些因素可以影響 System z 平台上的成本控制：

規模經濟

在 DB2 for z/OS 系統上，可以處理非常大的工作負載;即使一連幾小時處於 90% 以上的利用率，資料服務大型主機也能夠順利地運行。隨著交易處理量的增長，平台的單個事務成本會顯著降低。

性價比趨勢

儘管 System z 平台是一種相當昂貴的系統(因為它提供了尖端的硬體和軟體技術)，但是在過去幾年中，單位計算能力(通常用每秒百萬指令數或 MIPS 來衡量)的成本已經下降了。無論是來自 IBM 還是其他廠商的大型主機軟體，其價格也比以前更有競爭力了。

可管理性

組織可以在大型主機 DB2 系統上處理非常大的工作負載，而不需要大量的技術服務人員。DB2 for z/OS 系統程式員和 DBA 具有令人吃驚的生產效率的原因之一是，許多公司提供了豐富的大型主機 DB2 工具;與之相關的另一個好處是，DB2 for z/OS 會產生豐富的跟蹤資料，前面提到的工具可以對這些資料進行格式化，而且成本往往非常低。DB2 for z/OS 技術服務人員還可以獲益於某些平台特性，比如系統管理的儲存，這個特效能夠讓 z/OS 作業系統在硬碟子系統中放置表和索引資料集(資料庫越大，系統管理的儲存的人員效率優勢就越顯著)。