A. 如何使用虚拟化软件实现双活灾备系统
灾备双活如何实现数据同步？
问题1：金融系统中同城灾备如何实现数据实时同步（两地是异构存储），请软件推荐和方法？
问题2：如果是远距离（1000KM）异地灾备双活，如何较好的实现数据同步？
希望获得：具体解决, 注意事项, 实例参考
问题1：金融系统中同城灾备如何实现数据实时同步（两地是异构存储），请软件推荐和方法
问题2：如果是远距离（1000KM）异地灾备双活，如何较好的实现数据同步？
A1：数据实时同步复制有两种大的分类：
1）存储复制 - 即使异构存储也能，只不过效果差点。利用虚拟化网关集群设备（比如VPLEX）。但是有一个缺点，存储层面的块儿复制，解决不了逻辑校验的问题，有可能同步过去的块儿数据，数据库无法识别。
2）数据库层面的复制，Oracle、db2都有。是基于日志的复制，数据复制量很小。很安全。但是灾难时刻拉起数据库的时间也不是很理想。有条件的做一下自动化开发。
wangj0923技术经理 , 工行
存储复制最大的问题是，复制过去的磁盘对数据库来讲突然下宕后挂上的，有可能不识别，即便识别了，也要进行一致性校验，那个时间是无法忍受的。
数据库复制的问题是同步模式对主库的影响较大，备库出问题容易hang主库，而异步模式无法确保RPO为零。
需要各种技术组合起来用。
shenxzh系统工程师 , Nanjing Securities
同城灾备，如果是ORACLE数据库，可以使用远距离RAC，实现同城双活数据中心（通过ORACLE ASM实现异构存储双活，或者存储虚拟设备VPLEX,SVC等）
远距离异地灾备，最好使用主备模式，采用dataguard利用异步模式（或采用12C的far sync功能），保证数据安全
else_xie系统运维工程师 , PICC
cz_doctor、xk2008赞同了此回答
首先要确定，实现要异地实时同步，生产环境答应吗？
另外带宽，速度的压力，成本投入能答应吗？
每一个数据的修改交互，都需要问1000KM外的，是否OK了。然后才下一步？那多累的，估计某些应用可以，同步数据少的，对业务性能不敏感的。
现在很多存储的复制技术，异步效果也趋于同步效果，只要业务压力在可接受范围内，就能及时传送数据过去，只要自己明白，如果遇到业务高峰时，是要承受数据传输滞后比较明显的结果而已。
另外，对复制同步的数据，如果不是在线进行使用的，要定期的验证检查，反正数据已经是“带病”的，还一直在同步，哪天真的要用，才发现，那就迟了。
zhoujia8218(提问者)
你的这些反问点，都是我要关注的和不明确的地方，谢谢提醒
nitkey系统架构师 , ECT
xiaoyaozi赞同了此回答
问题1：异构存储要实现同城实时同步有几种实现方式：1.存储前面加一层虚拟网关，通过虚拟网关来实现两个存储的数据同步；2.操作系统层面，通过LVM或者veritas的卷管理软件实现；3.通过应用层自己实现数据同步，比如ORACLE的DG，DB2的HADR。同城实时同步一般对架构环境的要求都较高，如果再加上是异构存储，要特别注意两个存储的性能是否匹配，否则会出现短板
问题2:1000KM以上我认为基本上只有靠存储的异步复制，通过数据库的复制方式在远距离的案例上不是太多。
孔再华数据库运维工程师 , 中国民生银行
同城灾备可以做到对等双活。相当于双中心不差别提供服务。数据库技术有DB2 GDPC和Oracle Extended RAC。DB2 GDPC集群底层通过GPFS集群文件系统完成数据同步，支持异构的存储。
远距离灾备如果需要双活肯定是有很大限制的。首先数据不可能实时同步，代价太大。因此对一致性要求高的系统几乎不可能。但是如果使用异步的方式，例如DB2的HADR技术，或者是CDC等数据逻辑同步技术，能够做到同步数据，但是灾备服务器只能用来做查询分析等作用。
zhoujia8218(提问者)
CDC远距离复制时有没有需要注意的吗？我们只用过同城的，远距离的没有尝试过
B. 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 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 的各个平台和应用环境中表现出了这些品质。业务人员需要的就是这些;技术人员请务必注意这一点。
C. 大话存储的目录
第1章 盘古开天--存储系统的前世今生 1
1.1 存储历史. 2
1.2 信息. 数据和数据存储 5
1.2.1 信息 5
1.2.2 什么是数据 7
1.2.3 数据存储 7
1.3 用计算机来处理信息. 保存数据 8
第2章 IO大法--走进计算机IO世界 11
2.1 IO的通路--总线 12
2.2 计算机内部通信 13
2.2.1 IO总线可以看作网络么 14
2.2.2 CPU. 内存和磁盘之间通过网络来通信 15
2.3 网中之网 17
第3章 磁盘大挪移--磁盘原理与技术详解 19
3.1 硬盘结构 20
3.1.1 盘片上的数据组织 22
3.1.2 硬盘控制电路简介 28
3.1.3 磁盘的IO单位 29
3.2 磁盘的通俗演绎 30
3.3 磁盘相关高层技术 32
3.3.1 磁盘中的队列技术 32
3.3.2 无序传输技术 33
3.3.3 几种可控磁头扫描方式评论 34
3.3.4 关于磁盘缓存 36
3.3.5 影响磁盘性能的因素 36
3.4 硬盘接口技术 37
3.4.1 IDE硬盘接口 37
3.4.2 SATA硬盘接口 40
3.5 SCSI硬盘接口 43
3.6 磁盘控制器. 驱动器控制电路和磁盘控制器驱动程序 50
3.6.1 磁盘控制器 50
3.6.2 驱动器控制电路 51
3.6.3 磁盘控制器驱动程序 51
3.7 内部传输速率和外部传输速率 53
3.7.1 内部传输速率 53
3.7.2 外部传输速率 54
3.8 并行传输和串行传输 54
3.8.1 并行传输 54
3.8.2 串行传输 55
3.9 磁盘的IOPS和传输带宽(吞吐量) 56
3.9.1 IOPS 56
3.9.2 传输带宽 57
3.10 小结：网中有网, 网中之网 58
第4章 七星北斗--大话/详解七种RAID 59
4.1 大话七种RAID武器 60
4.1.1 RAID 0阵式 60
4.1.2 RAID 1阵式 62
4.1.3 RAID 2阵式 64
4.1.4 RAID 3阵式 67
4.1.5 RAID 4阵式 71
4.1.6 RAID 5阵式 72
4.1.7 RAID 6阵式 76
4.2 七种RAID技术详解 78
4.2.1 RAID 0技术详析 80
4.2.2 RAID 1技术详析 82
4.2.3 RAID 2技术详析 83
4.2.4 RAID 3技术详析 85
4.2.5 RAID 4技术详析 87
4.2.6 RAID 5技术详析 90
4.2.7 RAID 6技术详析 93
第5章 降龙传说--RAID. 虚拟磁盘. 卷和文件系统实战 95
5.1 操作系统中RAID的实现和配置 96
5.1.1 Windows Server 2003高级磁盘管理 96
5.1.2 Linux下软RAID配置示例 105
5.2 RAID卡 107
5.3 磁盘阵列 119
5.4 实现更高级的RAID 119
5.4.1 RAID 50 119
5.4.2 RAID 10和RAID 01 120
5.5 虚拟磁盘 120
5.5.1 RAID组的再划分 121
5.5.2 同一通道存在多种类型的RAID组 121
5.5.3 操作系统如何看待逻辑磁盘 122
5.5.4 RAID控制器如何管理逻辑磁盘 122
5.6 卷管理层 123
5.6.1 有了逻辑盘就万事大吉 124
5.6.2 卷管理层 125
5.6.3 Linux下配置LVM实例 126
5.6.4 卷管理软件的实现 128
5.6.5 低级VM和高级VM 130
5.6.6 VxVM卷管理软件配置简介 131
5.7 大话文件系统 134
5.7.1 成何体统--没有规矩的仓库 134
5.7.2 慧眼识人--交给下一代去设计 135
5.7.3 无孔不入--不浪费一点空间 136
5.7.4 一箭双雕--一张图解决两个难题 137
5.7.5 宽容似海--设计也要像心胸一样宽 139
5.7.6 老将出马--权威发布 139
5.7.7 一统江湖--所有操作系统都在用 140
5.8 文件系统中的IO方式 140
第6章 阵列之行--大话磁盘阵列 143
6.1 初露端倪--外置磁盘柜应用探索 144
6.2 精益求精--结合RAID卡实现外置磁盘阵列 145
6.3 独立宣言--独立的外部磁盘阵列 147
6.4 双龙戏珠--双控制器的高安全性磁盘阵列 149
6.5 龙头凤尾--连接多个扩展柜 150
6.6 锦上添花--完整功能的模块化磁盘阵列 152
6.7 一脉相承--主机和磁盘阵列本是一家 153
6.8 天罗地网--SAN(Storage Area Network)存储区域网络 154
第7章 熟读宝典--系统与系统之间的语言OSI 155
7.1 人类模型与计算机模型的对比剖析 156
7.1.1 人类模型 156
7.1.2 计算机模型 157
7.1.3 个体间交流是群体进化的动力 158
7.2 系统与系统之间的语言--OSI初步 158
7.3 OSI模型的七个层次 159
7.3.1 应用层 160
7.3.2 表示层 160
7.3.3 会话层 160
7.3.4 传输层 160
7.3.5 网络层 161
7.3.6 数据链路层 162
7.3.7 物理层 165
7.4 OSI与网络 166
第8章 勇破难关--Fibre Channel协议详解 169
8.1 FC网络--极佳的候选角色 170
8.1.1 物理层 170
8.1.2 链路层 171
8.1.3 网络层 172
8.1.4 传输层 178
8.1.5 上三层 179
8.1.6 小结 179
8.2 FC协议中的七种端口类型 180
8.2.1 N端口和F端口 180
8.2.2 L端口 180
8.2.3 NL端口和FL端口 181
8.2.4 E端口 183
8.2.5 G端口 183
8.3 FC适配器 184
8.4 改造盘阵前端通路--SCSI迁移到FC 185
8.5 引入FC之后 186
第9章 天翻地覆--FC协议的巨大力量 191
9.1 FC交换网络替代并行SCSI总线的必然性 192
9.1.1 面向连接与面向无连接 192
9.1.2 串行和并行 193
9.2 不甘示弱--后端也升级换代为FC 193
9.3 FC革命--完整的盘阵解决方案 195
9.3.1 FC磁盘接口结构.. 195
9.3.2 一个磁盘同时连入两个控制器的Loop中 196
9.3.3 共享环路还是交换--SBOD芯片级详解 197
9.4 中高端磁盘阵列整体架构简析 208
9.4.1 IBM DS4800控制器架构简析 209
9.4.2 NetApp FAS系列磁盘阵列控制器简析 212
9.4.3 IBM DS8000简介 213
9.4.4 富士通ETERNUS6000磁盘阵列控制器结构简析 214
9.4.5 EMC公司CX及DMX系列盘阵介绍 216
9.4.6 HDS公司USP系列盘阵介绍 217
9.5 磁盘阵列配置实践 218
9.5.1 基于IBM的DS4500盘阵的配置实例 218
9.5.2 基于EMC的CX700磁盘阵列配置实例 227
9.6 小结 230
第10章 三足鼎立--DAS, SAN和NAS 233
10.1 NAS也疯狂 234
10.1.1 另辟蹊径--乱弹NAS的起家 234
10.1.2 双管齐下--两种方式访问的后端存储网络 237
10.1.3 万物归一--网络文件系统 238
10.1.4 美其名曰--NAS(Network Attached Storage网络附加存储) 246
10.2 龙争虎斗--NAS与SAN之争 247
10.3 三足鼎立--DAS. SAN和NAS 250
10.4 最终幻想--将文件系统语言承载于FC网络传输 251
10.5 长路漫漫--系统架构进化过程 251
10.5.1 第一阶段：全整合阶段 252
10.5.2 第二阶段：磁盘外置阶段 252
10.5.3 第三阶段：外部独立磁盘阵列阶段 252
10.5.4 第四阶段：网络化独立磁盘阵列阶段 253
10.5.5 第五阶段：瘦服务器主机. 独立NAS阶段 253
10.5.6 第六阶段：全分离式架构 253
10.5.7 第七阶段：能量积聚, 混沌阶段 254
10.5.8 第八阶段：收缩阶段 254
10.5.9 第九阶段：强烈坍缩阶段 255
10.6 泰山北斗--NetApp的NAS产品 255
10.6.1 WAFL配合RAID 4 256
10.6.2 Data ONTAP利用了数据库管理系统的设计 257
10.6.3 利用NVRAM来记录操作日志 257
10.6.4 WAFL从不覆写数据 258
10.7 初露锋芒--BlueArc公司的NAS产品 258
第11章 大师之作--大话以太网和TCP/IP协议 261
11.1 共享总线式以太网 262
11.1.1 连起来 262
11.1.2 找目标 262
11.1.3 发数据 263
11.2 网桥式以太网 264
11.3 交换式以太网 265
11.4 TCP/IP协议 266
11.4.1 TCP/IP协议中的IP 266
11.4.2 IP的另外一个作用 267
11.4.3 TCP/IP协议中的TCP和UDP 268
11.5 TCP/IP和以太网的关系 271
第12章 异军突起--存储网络的新军IP SAN 273
12.1 横眉冷对--TCP/IP与FC 274
12.2 自叹不如--为何不是以太网+TCP/IP 274
12.3 天生我才必有用--攻陷Disk SAN阵地 275
12.4 ISCSI交互过程简析 275
12.4.1 实例一：初始化磁盘过程 276
12.4.2 实例二：新建一个文本文档 278
12.4.3 实例三：文件系统位图 281
12.5 ISCSI磁盘阵列 283
12.6 IP SAN 284
12.7 增强以太网和TCP/IP的性能 285
12.8 FC SAN节节败退 286
12.9 ISCSI配置应用实例 287
12.9.1 第一步：在存储设备上创建LUN 287
12.9.2 第二步：在主机端挂载LUN 289
12.10 小结 292
第13章 握手言和--IP与FC融合的结果 293
13.1 FC的窘境 294
13.2 协议融合的迫切性 295
13.3 网络通信协议的四级结构 299
13.4 协议融合的三种方式 300
13.5 Tunnel和Map融合方式各论 301
13.5.1 Tunnel方式 302
13.5.2 Map方式 303
13.6 FC与IP协议之间的融合 305
13.7 无处不在的协议融合 306
13.8 交叉融合 306
13.9 IFCP和FCIP的具体实现 307
13.10 局部隔离/全局共享的存储网络 309
13.11 多协议混杂的存储网络 310
第14章 变幻莫测--虚拟化 313
14.1 操作系统对硬件的虚拟化 314
14.2 计算机存储子系统的虚拟化 316
14.3 带内虚拟化和带外虚拟化 319
14.4 硬网络与软网络 323
14.5 用多台独立的计算机模拟成一台虚拟计算机 323
14.6 用一台独立的计算机模拟出多台虚拟计算机 324
14.7 用磁盘阵列来虚拟磁带库 324
14.7.1 NetApp VTL700配置使用实例 325
第15章 众志成城--存储群集 337
15.1 群集概述 338
15.1.1 高可用性群集(HAC) 338
15.1.2 负载均衡群集(LBC) 338
15.1.3 高性能群集(HPC) 338
15.2 群集的适用范围 339
15.3 系统路径上的群集各论 339
15.3.1 硬件层面的群集 339
15.3.2 软件层面的群集 341
15.4 实例：Microsoft MSCS软件实现应用群集 341
15.4.1 在Microsoft Windows Server 2003上安装MSCS 342
15.4.2 配置心跳网络 344
15.4.3 测试安装 344
15.4.4 测试故障转移 345
15.5 实例：SQL Server群集安装配置 345
15.5.1 安装SQL Server 345
15.5.2 验证SQL 数据库群集功能 348
15.6 小结：世界本身就是一个群集 351
第16章 未雨绸缪--数据保护和备份技术 353
16.1 数据保护 354
16.1.1 数据保护的方法 354
16.2 高级数据保护方法 355
16.2.1 远程文件复制 355
16.2.2 远程磁盘(卷)镜像 356
16.2.3 块(快)照数据保护 356
16.2.4 Continuous Data Protect(CDP, 连续数据保护) 363
16.3 数据备份系统的基本要件 367
16.3.1 备份目的 368
16.3.2 备份通路 371
16.3.3 备份引擎 373
16.3.4 三种备份方式 377
16.3.5 数据备份系统案例一 378
16.3.6 数据备份系统案例二 379
16.3.7 NetBackup配置指南 380
16.3.8 配置DB2数据库备份 392
第17章 愚公移山--大话数据容灾 399
17.1 容灾概述 400
17.2 生产资料容灾--原始数据的容灾 401
17.2.1 通过主机软件实现前端专用网络或者前端公用网络同步 402
17.2.2 案例：DB2数据的HADR组件容灾 405
17.2.3 通过主机软件实现后端专用网络同步 411
17.2.4 通过数据存储设备软件实现专用网络同步 415
17.2.5 案例：IBM公司Remote Mirror容灾实施 416
17.2.6 小结 421
17.3 容灾中数据的同步复制和异步复制 421
17.3.1 同步复制例解 421
17.3.2 异步复制例解 423
17.4 生产者的容灾--服务器应用程序的容灾 424
17.4.1 生产者容灾概述 424
17.4.2 案例一：基于Symantec公司的应用容灾产品VCS 428
17.4.3 案例二：基于Symantec公司的应用容灾产品VCS 431
附录 五百年后--系统架构将
走向何方 435
后记
D. 如何最有效地使用DB2 HADR备用数据库
说明：
下面的代码演示了如何利用日志还原功能，将主数据库中的数据变化及时反馈到备用数据库中
备用数据库的数据可以随时用于查询，但不能被更新（备用数据库只读）。
--*/
--首先,创建一个演示用的数据库(主数据库)
CREATE DATABASE Db_test
ON
( NAME = Db_test_DATA,
FILENAME = 'c:\Db_test.mdf' )
LOG ON
( NAME = Db_test_LOG,
FILENAME = 'c:\Db_test.ldf')
GO
--对数据库进行备份
BACKUP DATABASE Db_test TO DISK='c:\test_data.bak' WITH FORMAT
GO
--把数据库还原成备用数据库(演示主数据库与这个备用数据库之间的同步)
RESTORE DATABASE Db_test_bak FROM DISK='c:\test_data.bak'
WITH REPLACE,STANDBY='c:\db_test_bak.ldf'
,MOVE 'Db_test_DATA' TO 'c:\Db_test_data.mdf'
,MOVE 'Db_test_LOG' TO 'c:\Db_test_log.ldf'
GO
--启动 SQL Agent 服务
EXEC master..xp_cmdshell 'net start sqlserveragent',no_output
GO
--创建主服务器数据训与备用服务器数据库之间同步的作业
DECLARE @jogid uniqueidentifier
EXEC msdb..sp_add_job
@job_id = @jogid OUTPUT,
@job_name = N'数据同步处理'
--创建同步处理步骤
EXEC msdb..sp_add_jobstep
@job_id = @jogid,
@step_name = N'数据同步',
@subsystem = 'TSQL',
@command = N'
--主数据库中进行日志备份
BACKUP LOG Db_test TO DISK=''c:\test_log.bak'' WITH FORMAT
--备用数据库中还原主数据库的日志备份(应用主数据库中的最新变化
--实际应该时主数据库备份与备用数据库的还原作业应该分别在主服务器和备用服务器上建立，并且备份文件应该放在主服务器和备用都能访问的共享目录中
RESTORE LOG Db_test_bak FROM DISK=''c:\test_log.bak'' WITH STANDBY=''c:\test_log.ldf''',
@retry_attempts = 5,
@retry_interval = 5
--创建调度(每分钟执行一次)
EXEC msdb..sp_add_jobschele
@job_id = @jogid,
@name = N'时间安排',
@freq_type=4,
@freq_interval=1,
@freq_subday_type=0x4,
@freq_subday_interval=1,
@freq_recurrence_factor=1
-- 添加目标服务器
EXEC msdb.dbo.sp_add_jobserver
@job_id = @jogid,
@server_name = N'(local)'
GO
--通过上述处理,主数据库与备用数据库之间的同步关系已经设置完成
--下面开始测试是否能实现同步
--在主数据库中创建一个测试用的表
CREATE TABLE Db_test.dbo.TB_test(ID int)
GO
--等待1分钟30秒（由于同步的时间间隔设置为1分钟,所以要延时才能看到效果）
WAITFOR DELAY '00:01:30'
GO
--查询一下备用数据库,看看同步是否成功
SELECT * FROM Db_test_bak.dbo.TB_test
/*--结果:
ID
-----------
（所影响的行数为 0 行）
--*/
--测试成功
GO
--最后删除所有的测试
DROP DATABASE Db_test,Db_test_bak
EXEC msdb..sp_delete_job @job_name=N'数据同步处理'
GO
/*===========================================================*/
/*--服务器档机处理说明
使用这种方式建立的数据库同步，当主数据库不可用时（例如，主数据库损坏或者停机检修）
可以使用以下两种方法使备用数据库可用。
--*/
--1. 如果主数据库损坏，无法备份出最新的日志，可以直接使用下面的语句使备用数据库可读写（丢失最近一次日志还原后的所有数据）。
RESTORE LOG Db_test_bak WITH RECOVERY
--2. 如果主数据库可以备份出最新日志，则可以使用下面的语句。
--先备份主数据库的最新的事务日志
BACKUP LOG Db_test TO DISK=''c:\test_log.bak'' WITH FORMAT
--再在备用数据库中恢复最新的事务日志，并且使备用数据库可读写（升级为主数据库）
RESTORE LOG Db_test_bak FROM DISK='c:\test_log.bak'
E. unix环境高级编 v节点是存放在内存中的吗
但是，如果谈话的对方是管理层的成员，那么会怎么样?公司管理者们关心的主要问题是收入的增长、成本控制、产品质量和产品投入市场的时间。一般来说，这些人并不关心锁的粒度、服务器内存管理和 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 的各个平台和应用环境中表现出了这些品质。业务人员需要的就是这些;技术人员请务必注意这一点。