db2 dba,如何解释db2的业务价值

但是，如果谈话的对方是管理层的成员，那么会怎么样?公司管理者们关心的主要问题是收入的增长、成本控制、产品质量和产品投入市场的时间。一般来说，这些人并不关心锁的粒度、服务器内存管理和 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 adv**or(db2 for luw 中内置的自治特性之一)，效率得到了极大提高。design adv**or 会分析与 db2 工作负载相关联的 sql 语句，并为改进应用程序性能提出建议。我们的基于 aix 的企业数据仓库(edw)使用带 dpf 功能的 db2，design adv**or 对这个数据库提出了修改某些表索引的建议，其效果让我们非常满意。最后，还有协作方面的好处。checkfree 的 it 基础设施有意地设计成包含多个**(我们常常说的一句话是，“使用正确的工具完成工作”)。在我们最大的部门中，核心业务应用程序运行在一个大型机 parallel sysplex 上。这个部门的操作数据存储(ods)运行在一个单独的 system z 服务器上。我们的 edw 运行在 ibm pseries 服务器集群上，crm 应用程序运行在一个单独的 sun solar** 服务器上。这些系统有什么共同点?它们都是基于 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 **ailability d**aster recovery(hadr)，它可以维护 db2 for luw 数据库的一个拷贝(使用单独的服务器和硬盘存储)，这个拷贝与主数据库保持精确的同步。hadr 的实现方法是，不断地将事务日志记录发送给备用服务器，备用服务器实时地处理这些记录。这种方**让备用数据库与主数据库同步，而且更新过的页面的内存页面缓冲区也与主服务器上的缓冲区保持一致。因此，在主系统发生故障时，备用系统会非常快速地接管(通常只需要几秒)，而且不会丢失已经提交的数据库更新。hadr 还可以按照异步**运行，这种**适合长距离数据更新复制，在可以接受少量数据损失的情况下，这可以提供灾难恢复功能。hadr 也可以减少有计划的服务中断时间，因为它使 db2 for luw 的维护几乎不需要维护时间窗。为使用 hadr 实现这种效果，dba 应该临时终止从主服务器到备用服务器的日志记录流，在备用服务器上应用并激活软件补丁，重新启动日志的传输，恢复同步(这个“追赶期”通常非常短);然后，通过一次用户发起的接管，交换主服务器和备用服务器的角色(这个过程应该只需要花几秒时间)。在此之后，重复前面的步骤，在 hadr 配置中原来的主服务器(现在的备用服务器)上应用并激活软件补丁。敏捷性 vs.对新的需求做出快速响应 db2 能够帮助组织对挑战和机遇做出快速响应，因为它能够提供多个访问 db2 数据库中的数据的路径。您希望从 j**a 应用程序访问数据吗?没问题：db2 提供了 jdbc 驱动程序并支持 sqlj，因此能够在 j**a 应用程序中使用嵌入的预绑定的 sql 语句。数据请求来自 windows 系统上运行的.net 应用服务器吗?db2 提供了 ado.net 驱动程序，并与 microsoft 的 v**ual studio 应用程序开发工具集成。您希望使用服务器端 sql 吗?db2 存储过程可以用几种编程语言来编写(包括 j**a)，也可以采用 sql 存储过程的形式。在大型机环境中广泛使用的 cics 和 ims transaction manager 程序可以提供更多的... 20210311