今天，实时数据对于业务来说至关重要。一个公司必须要以信息为基础来做出正确的决策，并且赶在竞争对手前发布新产品和新服务。这对于IT部门的挑战不仅仅是要跟上节奏，更重要的是领导业务需求的创新过程。

　　业务性能管理研究所(bpminstitute.org)最近的一项调查表明，对整体业务影响最大的是来源于IT部门的快速，灵活和及时响应的应用传递。但是调查也显示，只有11%的调查者感觉他们的IT部门的变化过程可以跟的上业务需求。

　　响应业务需求的能力来源于一个灵活的基础。“Viper 2”(下一代 DB2 9.5版本的开发名称)就为您提供了这样的基础。

　　敏捷XML开发

　　使用DB2 9，IBM创建了一个新的混合数据服务器，可以同时管理关系型和XML数据存储。DB2 Viper2 扩展了这一“纯XML”能力来加速应用传递。

　　XML是为敏捷性而设计的。它的自描述元素，平台无关性，和方便的扩展性是一些让它更加适合动态业务应用的属性。新的DB2 Viper 2特性增强了其敏捷性。

　　XML提供了快速传送数据的能力(它流行的原因);XSLT是最流行的转变XML的方式。DB2 Viper 2内建了对XSLT的支持。新的XSLTRANSFORM程序转换数据库中的XML文档为HTML，普通文本或者其他形式。

　　XML流行的另外一个原因是能够快速的改变XML记录。DB2可以让你实时更新XML模式，而不用失去对已有XML文档的访问。XML定义一般是存储在XML模式里。DB2 Viper2 介绍了模式演变，提供了验证已有的和新的XML文档到一个已注册的模式的演化版本的能力。UPDATE XMLSCHEMA命令和XSR_UPDATE存储的过程让你修改已经在XML模式库中注册的XML模式，无须重新有效化已有的XML文档。

　　减少系统停机时间

　　高可用性灾难恢复(HADR)已经在DB2 8.2版本中实现并可为Linux，Unix和Windows所用了。DB2 HADR维护了一个备用数据库来复制主DB2服务器的更新。如果主DB2服务器停止了工作，这个备用服务器可以通过接管命令将主服务器的负载全部接管。为了增强DB2高可用性的功能，DB2 Viper2 AIX和Linux发行版本包含了Tivoli系统自动化(TSA)。TSA通过检测失效来提供了自动的DB2失效恢复，并且自动签署结果命令。如图1所示。你可以使用DB2 Viper2中包含的DB2安装器或者Tivoli脚本安装，更新和卸载TSA。

图1

　　每个DB2的版本都包含了帮助降低费用的改进;即将发布的版本也不例外。DB2 Viper2通过规则的移动老文件来自动减少备份，负载拷贝，和记录文件的存储消耗量。在DB2 9中，DB2数据服务器以规则的方式移动这些文件;DB2数据库管理器超过num_db_backups规定和旧于rec_his_retentn定义的日期的历史文件记录。Viper2 版本包含了新的配置参数auto_del_rec_obj;当这个参数为ON，数据服务器删除备份，负载拷贝和剪除任何历史文件的记录文件。

　　对于数据仓库，DB2 Viper2包含了增强功能来提高总体得分布式数据库可用性。当在Viper 2版本中的某个分离的数据库中的catalog节点进行备份时，你可以指定哪个分区包含进这个备份。这些分区将会同时被备份。

　　为了辅助恢复，你可以使用 END_OF_BACKUP语句来在一个分离的数据库中回滚到最小恢复时间，也就是在回滚中发现数据库可用的最近的一个时间点。这个特性减少了需要手动决定可用点的时间，提高了恢复的速度。

　　为离线数据重分配的窗口缩减的增强也提高了DB2分布式数据库的可用性，保证了数据仓库可用且可被业务访问。性能提升将会以一系列的DB2 Viper2的FixPak出现。

　　管理和安全

　　信息的随处可访问的趋势，也带来了数据偷窃和失去安全控制的风险。原先只对内部员工开放的数据现在对所有业务伙伴和客户开放了，那么也更易受到非授权访问的攻击。信息安全小组面临着在内外夹攻的形势下保护关键企业数据的挑战(公司财务，信用卡，个人身份，个人健康和知识产权信息)。

　　DB2 Viper2审计功能的增强通过提供需要审计的敏感信息的多粒度提高了审计性能。DB2 Viper2也提供了保护审计信息用于未来报告和检查的审计档案。在DB2mag.com的“Analyzing Audit Data in Viper 2”文章中有详细介绍。

　　三层应用已经在近年来得到了广泛应用，特别是在基于Web的技术和J2EE平台中。三层应用模型被诸如WebSphere应用服务器(WAS)等产品所支持——扩展了已有的两层客户机/服务器结构，增加了客户程序(WAS)和数据库(DB2)中的中间层。

　　在三层应用模型中，中间层认证用户和管理跟数据库之间的交互。当一个用户被中间层认证后，所有对数据服务器的访问使用一个单独的用户ID和密码来访问数据库。因为数据服务器保证了数据库在中间层访问用户ID的权限，每个应用程序的用户分享中间层的同一认证。这限制了审计只报告中间层用户ID而不是在请求数据的真正的终端用户。

图2

　　尽管三层应用模型有很多优点，它也引发了安全考虑，诸如失去用户身份。中间层用户ID将会用于所有数据库连接;IT安全最好的实践偏向于使用真正访问的用户的身份，以便用于控制目的。因为中间层用户ID并不是真正最终用户的ID，它并不提供大多数公司需要的审计和用户统计性。

　　另外一个问题是对于特权的过分给予。中间层的认证ID必须拥有所有必要的特权来执行所有的来自用户的请求，经常是来自所有的应用程序。这就使得用户拥有所有的不必要的访问权限来访问所有信息。当前的业务需要第三层使用的认证ID必须安全的持有，并且给予尽量少的用户。如果中间层认证ID被攻破了，所有资源都暴露了。

　　这些安全考虑突出了需要将初始用户ID交付给数据服务器的需要，来进行审计和访问控制。考虑到这些，DB2 Viper2版本引进了“被信任的上下文”。安全管理员(拥有SECADM权限)可以创建一个数据库中被信任的上下文对象，该对象定义了一个数据库和中间层的信任关系。连接属性和DB2服务器中定义的被信任的上下文属性相符合时，数据库连接被认为是一个被信任的连接。信任关系基于下列属性集：

• 系统认证ID，代表建立数据库连接的用户
• IP地址(域名)，代表数据库连接建立的主机
• 数据流加密，代表在数据库服务器和数据库客户端的数据通信的加密设置(如果有)

　　中间层可以接着建立一个明确的被信任的数据库连接，使得它可以使用或不使用认证来转换连接上的当前用户ID到一个不同的用户ID。另外，被信任的上下文提供了另外一个优点：当特权被授予一个数据库用户时进行控制的能力。安全管理员能够授予一个或者更多的特权给一个数据库角色，并且赋予这个角色以一个被信任的上下文对象。只有符合被信任上下文定义的被信任数据库连接(明确的或者不明确的)能够利用该角色关联的特权。

　　DB2 Viper2增加的另外一个新的安全对象是数据库角色。数据库角色降低了简单管理数据库特权的风险。一个数据库角色是一个包含一个或多个特权或者数据库授权的对象。用户，组，PUBLIC或者其他角色可以成为该角色的成员。角色经常建立来复制组织的结构;比如，你可以创建数据库里的角色来映射组织里的工作职能。安全管理员能够通过简单增加成员到一个合适的角色来控制数据库访问，而不是为每一个用户定义完全访问。

　　工作负载管理

　　DB2 Viper2的性能提升关注于使得访问和刷新大量数据能够达到最大性能。在过去，所有在数据服务器中执行的交易被认为具有同等重要性;意味着最高优先权，高性能，和低延迟。在整个系统中达到这样的高性能要求业务不断进行升级。减少费用而不放弃敏捷性的压力促进了企业认识到所有的交易并不平等。通过根据业务优先级的资源平衡，它们可以减少消耗并且持续提供高性能。

　　DB2 Viper2集成了一个新的工作负载管理特性的集合来识别，管理和监控数据服务器负载。通过联系工作负载定义和服务等级，每个独立的工作负载可以被使用主动或被动模型来进行优先区分。这保证了业务能够将目标和IT应用保持一致(图3)。

图3

　　使用DB2工作负载管理特性，你能够通过使用工作负载定义来自动划分工作到可管理的和逻辑的组，将工作负载分配给各个服务等级，分配资源给每个服务等级。你可以获取详细工作负载的描述和性能信息来帮助改进你的工作负载和服务等级定义。

　　你也可以通过费用，时间和并发的阀值来使用新的工作负载管理特性来控制执行。这些阀值使得你控制无效的查询，帮助你满足服务等级协定(SLA)目标。使用阀值，系统能自动对坏情况进行反应或者在其发生前进行预测。当你控制长时间运行的复杂查询时，你可以保持业务的平滑运行。你可以将各个阶段的处理情况及时的反映给用户。

　　在AIX系统中，你可以将DB2服务等级和AIX工作负载管理器(WLM)服务等级联系起来。比如，AIX WLM能够动态的调整CPU时间或者使用其它服务等级中剩下的CPU时间。

　　增强的统计功能

　　查询性能的一个关键元素是当查询优化时具有实时统计能力。DB2 8.2 引入了一个自动统计集合，能够监控表和进行所需的统计。当背景进程选择了什么时候统计时，它被预先定义的维护阶段限制了。这样就会导致在数据改变和新统计结果采集之间的一个时间缺口。DB2 Viper2的实时统计填补了这个缺口。当你提交一个查询，优化器决定了是否受影响的统计是精确的。如果没有统计或者查询并不是如优化器预测的那样进行，统计将被更新以提高下次查询的性能，而不需要等待一个维护窗口。

　　乐观锁机制

　　DBA经常将优化重点放在数据库响应时间上，而没有考虑到是否问题出在并发上。Viper2版本引入了“乐观锁”，一个不在选择和升级或者删除一行时保持行锁的技术。程序乐观的假设未上锁的行并不可能会在更新或者删除操作前改变。如果行变化了，更新或者删除将会失败;程序逻辑通过诸如重试的方式处理这样的失败。乐观锁的使用将会提升并发性能，因为程序可以同时读写一行。但是，你的程序将会需要重试机制来处理读和升级或者删除的行改变。在三层环境中，交易通常不会对数据库交互进行修正;不能使用锁，因为锁不能在业务交易中维持。这就使得乐观锁成为在不牺牲数据完整性的情况下减少锁竞争的绝佳方式。

评论 (0) All

登陆 还没注册？