許多技術人員可以輕松地討論 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 操作系統在硬盤子系統中放置表和索引數據集(數據庫越大，系統管理的存儲的人員效率優勢就越顯著)。
數據存儲的空間效率高
DB2 for z/OS 服務器硬件可以幫助進行數據壓縮，這可以將表空間存儲的硬盤空間需求降低 50%以上(我們在 CheckFree 常常觀察到 70% 或更好的壓縮效果，因為我們的表往往具有很長的行;長行的壓縮率一般好於短行)。由於 DB2 9 中的改進，在 Linux、Unix 和 Windows 服務器上數據壓縮效果也很好了。
自治是什麼意思?這個詞是指 DB2 能夠自行完成以前需要 DBA 執行的大量工作。我們在 CheckFree 發現，通過使用 DB2 Design Advisor(DB2 for LUW 中內置的自治特性之一)，效率得到了極大提高。Design Advisor 會分析與 DB2 工作負載相關聯的 SQL 語句，並為改進應用程序性能提出建議。我們的基於 AIX 的企業數據倉庫(EDW)使用帶 DPF 功能的 DB2，Design Advisor 對這個數據庫提出了修改某些表索引的建議，其效果讓我們非常滿意。
最後，還有協作方面的好處。CheckFree 的 IT 基礎設施有意地設計成包含多個平台(我們常常說的一句話是，“使用正確的工具完成工作”)。在我們最大的部門中，核心業務應用程序運行在一個大型機 parallel sysplex 上。這個部門的操作數據存儲(ODS)運行在一個單獨的 System z 服務器上。我們的 EDW 運行在 IBM pSerIEs 服務器集群上，CRM 應用程序運行在一個單獨的 Sun Solaris 服務器上。這些系統有什麼共同點?它們都是基於 DB2 的。DBMS 具有共同的 “基因”，這會簡化平台之間的數據轉移，並增強人員配置的靈活性。最近，我們的大型機 DB2 團隊中 DBA 人員過剩(盡管這些系統已經增長了，這是一種便於管理的環境)，而快速增長的 EDW 需要更多的 DBA 人力資源。我們讓一位 DB2 for z/OS DBA 轉入了 DB2 for LUW 團隊，他很快就適應了新的崗位。DB2 for z/OS 和 DB2 for LUW 之間存在 DBA 能夠察覺到的差異嗎?確實有差異，但是與 DB2 for z/OS 和在分布式系統服務器上運行的非 DB2 DBMS 之間的差異相比，這些差異是很小的。
高可用性 vs. 拿起電話話筒就能聽到撥號音
在 CheckFree，我們一直在為應用程序的可用性而努力。我們希望應用程序的可用性像電話撥號音那樣持續不斷，當您拿起電話話筒時，就一定會聽到撥號音。DB2 能夠提供這樣的可用性。單服務器 DB2 系統已經能夠提供極其出色的可用性;多服務器配置甚至能夠進一步提高可用性標准。
前面作為規模擴展解決方案提到了 parallel sysplex 上的 DB2 for z/OS 數據共享，這種技術也能夠在兩個方面提高可用性：
減小服務意外中斷的影響
如果數據共享組中的一個 DB2 子系統失敗了(無論是由於服務器、操作系統還是 DB2 故障)，那麼並不需要等待替代服務器接管這個子系統的數據庫連接。組中的其他成員已經能夠訪問數據庫，工作負載會自動地從失敗的子系統轉移到其他 DB2 系統上。失敗並非毫無影響，因為在失敗的 DB2 子系統重新啟動之前，這個成員上運行的程序正在更新的數據庫頁面是不可訪問的;但是，在通常情況下，處於這種狀態的數據庫頁面所占的百分比非常小，子系統的恢復是自動的(如果 “主” 服務器和操作系統仍然可用，那麼會 “就地” 恢復;否則，在 sysplex 中的另一個服務器上恢復)而且很快(在我們的環境中大約需要 90 秒)。與單獨的系統環境相比，數據共享組中的 DB2 失敗的影響要小得多。幾個月前，我們的生產數據共享組中發生了一次 DB2 for z/OS 故障，但是客戶都沒有察覺到。
幾乎完全消除有計劃的服務中斷
因為數據共享為所有 DB2 成員提供對數據庫中所有數據的讀/寫訪問，所以可以讓一個 DB2 子系統臨時停止運行，對它進行軟件維護，然後讓它重新運行，這個過程不會中斷應用程序的處理(當一個 DB2 成員停止運行時，應用程序通信量會轉給組中的其他成員)。這種功能讓我們能夠自由地對數據共享組進行維護，而不需要指定維護時間窗。
DB2 對於業務的意義
如果需要用業務人員能夠理解的方式討論 DB2，那麼可以試試下面這些詞匯。
可伸縮性：DB2 可以隨著業務而增長，而不是限制業務的發展;
效率：DB2 可以降低數據服務平台的總擁有成本(TCO)，而數據服務平台是組織的應用程序的基礎。降低 TCO 就相當於增加收入;
服務質量：DB2 技術可以減少有計劃的應用程序系統中斷，還可以縮小意外服務中斷的影響和范圍。因此，能夠提高服務質量和客戶忠誠度;
敏捷性：DB2 為訪問和管理傳統數據和非結構化數據提供了眾多可選方法;這種靈活性可以幫助組織對市場機遇做出快速響應。
對於 LUW 環境，DB2 提供了一個多服務器解決方案，這個方案能夠提供更高的可用性，但它使用的是在非大型機環境中更有意義的非共享體系結構。這個解決方案稱為 High Availability Disaster Recovery(HADR)，它可以維護 DB2 for LUW 數據庫的一個拷貝(使用單獨的服務器和硬盤存儲)，這個拷貝與主數據庫保持精確的同步。HADR 的實現方法是，不斷地將事務日志記錄發送給備用服務器，備用服務器實時地處理這些記錄。這種方法會讓備用數據庫與主數據庫同步，而且更新過的頁面的內存頁面緩沖區也與主服務器上的緩沖區保持一致。因此，在主系統發生故障時，備用系統會非常快速地接管(通常只需要幾秒)，而且不會丟失已經提交的數據庫更新。HADR 還可以按照異步模式運行，這種模式適合長距離數據更新復制，在可以接受少量數據損失的情況下，這可以提供災難恢復功能。
HADR 也可以減少有計劃的服務中斷時間，因為它使 DB2 for LUW 的維護幾乎不需要維護時間窗。為使用 HADR 實現這種效果，DBA 應該臨時終止從主服務器到備用服務器的日志記錄流，在備用服務器上應用並激活軟件補丁，重新啟動日志的傳輸，恢復同步(這個 “追趕期” 通常非常短);然後，通過一次用戶發起的接管，交換主服務器和備用服務器的角色(這個過程應該只需要花幾秒時間)。在此之後，重復前面的步驟，在 HADR 配置中原來的主服務器(現在的備用服務器)上應用並激活軟件補丁。
敏捷性 vs. 對新的需求做出快速響應
DB2 能夠幫助組織對挑戰和機遇做出快速響應，因為它能夠提供多個訪問 DB2 數據庫中的數據的路徑。您希望從 Java 應用程序訪問數據嗎?沒問題：DB2 提供了 JDBC 驅動程序並支持 SQLJ，因此能夠在 Java 應用程序中使用嵌入的預綁定的 SQL 語句。數據請求來自 Windows 系統上運行的 .Net 應用服務器嗎?DB2 提供了 ADO.Net 驅動程序，並與 Microsoft 的 Visual Studio 應用程序開發工具集成。您希望使用服務器端 SQL 嗎?DB2 存儲過程可以用幾種編程語言來編寫(包括 Java)，也可以采用 SQL 存儲過程的形式。在大型機環境中廣泛使用的 CICS 和 IMS Transaction Manager 程序可以提供更多的服務器端 SQL 方式。對於文件處理這樣的任務，批處理程序具有很高的效率。
通過 DB2 與 IBM WebSphere MQ(一種消息排隊和傳遞技術)的集成，應用程序開發的靈活性會得到進一步增強。將 MQ 插入基於 DB2 的基礎結構中是一種增強系統彈性的好方法：如果應用程序的 “處理消息” 的組件不可用(由於故障或有計劃的停機)，那麼從客戶機系統收到的消息就會累積在隊列中，當不可用的應用程序組件再次聯機時，它會繼續從隊列中獲取消息。從發送消息的用戶或客戶機應用程序的角度來看，並沒有出現服務中斷。MQ 隊列還有助於控制大幅度變化的工作負載量，其作用就像是汽車引擎散熱器的附屬水箱：消息處理應用程序可以按照自己的節奏處理消息;如果消息到達的速度超過了處理消息的速度，那麼消息就會累積在隊列中，而不會造成 “目標” 服務器過載。DB2 和 MQ 組合的優點還包括：協調的提交和回退(如果程序在 DB2 表中插入一行並在 MQ 隊列中放一個消息，那麼當這個程序失敗時，DB2 和 MQ 更改會回退到最近的提交點);DB2 函數支持程序使用 SQL 語句與 MQ 交互;MQ 實用程序與 DB2 實用程序非常相似，因此 DB2/MQ 的交叉培訓非常容易。
數據級別上的靈活性怎麼樣呢?DB2 可以存儲和管理傳統的文本和數字數據，還可以非常高效地管理大對象(LOB)，比如文檔、圖像和音頻文件。DB2 9 引入了先進的 XML 數據存儲特性，在存儲 XML 文檔時可以保留數據元素的結構特性，還可以使用 SQL 或 XQuery 高效地訪問數據。當然，可以在 DBMS 之外存儲 LOB 和 XML 文檔;但是，將這些數據類型存儲在 DB2 中，就可以為集成數據管理、安全性以及備份和恢復提供一個現成的解決方案。其結果是，管理和保護數據所需的時間更少了，可以留出更多的時間來開發使用數據的應用程序。
技術的最終目的
我很喜歡談論在各個平台上 DB2 中使用的高級技術。但是，技術必須能夠幫助我的公司實現業務目標;否則，就是浪費資金。大多數業務人員對 IT 產品的要求只有幾點：產品必須能夠工作(可靠性)，它們不能限制公司在市場上的作為(增長和創新)。DB2 在 CheckFree 的各個平台和應用環境中表現出了這些品質。業務人員需要的就是這些;技術人員請務必注意這一點。
