DB2未来版“Viper 2” ——为IT敏捷加速(2)
管理和安全
信息的随处可访问的趋势，也带来了数据偷窃和失去安全控制的风险。原先只对内部员工开放的数据现在对所有业务伙伴和客户开放了，那么也更易受到非授权访问的攻击。信息安全小组面临着在内外夹攻的形势下保护关键企业数据的挑战(公司财务，信用卡，个人身份，个人健康和知识产权信息)。
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版本引入了“乐观锁”，一个不在选择和升级或者删除一行时保持行锁的技术。程序乐观的假设未上锁的行并不可能会在更新或者删除操作前改变。如果行变化了，更新或者删除将会失败;程序逻辑通过诸如重试的方式处理这样的失败。乐观锁的使用将会提升并发性能，因为程序可以同时读写一行。但是，你的程序将会需要重试机制来处理读和升级或者删除的行改变。在三层环境中，交易通常不会对数据库交互进行修正;不能使用锁，因为锁不能在业务交易中维持。这就使得乐观锁成为在不牺牲数据完整性的情况下减少锁竞争的绝佳方式。