DB2 DBA，如何解释DB2的业务价值

核心提示：许多技术人员可以轻松地讨论 DB2 技术的细节，很自信地谈论查询并行化、数据压缩、WebSphere MQ 集成、大对象管理、JDBC 和 ADO.Net 驱动程序、大型机 Parallel Sysplex 上的数据共享、DB2 for Linux, Unix, and Windows(LUW)多维集群等等话题，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 操作系统在硬盘子系统中放置表和索引数据集(数据库越大，系统管理的存储的人员效率优势就越显著)。