DB2 UDB for Windows 的用户将会十分欣赏 Stinger 中针对安全性所做的修改。例如，Stinger 现在将支持 DB2 UDB 之前不允许您在用户名中所使用的某些字符。

　　更重要的是，DB2 UDB 支持 Windows 本地系统帐户（Local System Account，LSA），并将之指定为系统管理员。在访问 DB2 UDB 时，该功能将支持在该帐户下运行 DB2 UDB 应用程序（包括 DAS 调度器），而不必指定或创建一个外部用户帐户。

　　最后，Stinger 将支持包含两部分的用户名。这将允许 DB2 UDB 理解 <domainname>\\<username> 格式以进行身份验证。以前，如果在多个域的环境中操作 DB2 UDB，就必须将递给 DB2 UDB 进行身份验证的用户名广播给所有的域服务器，以找到该用户名是在何处定义的。这样做会在连接时导致性能问题，并且可能引发授权冲突。而所有这些问题均在 Stinger 中得到了解决。

　　Stinger 还可以对在客户机和服务器之间传输的数据进行加密。其实现将以 56 位的加密开始，以保持 DB2 UDB 家族到 DB2 UDB for z/OS® 平台的兼容性。Stinger 还在进行公共标准认证测试，并附带了新的安全手册，其中包含了所有的相关概念。

　　可管理性和自主性

　　Stinger 版本在可管理性和自主性方面新增了许多功能。这些功能的主要目标是在任务的部署中加入更多的自动操作，并提高可管理性，从而释放熟练的数据库管理员（DBA）资源，以便他们能够集中关注关键业务问题和进一步降低 DB2 UDB 解决方案的总体拥有成本（TCO）。

　　Stinger 包含自动化的基于策略的监控，可以提醒您需要或执行自动维护操作，如备份（顺便提一下，Stinger 中的自我调优和在线备份都将包含日志文件）、表的统计收集（通过抽样进行，且对用户和应用程序是完全透明的）和在线表重组。

　　图 9. 配置自动维护

 

　　Configure Automatic Maintenance 向导允许您为指定的数据库定义空周期或较低的活动级别；选择 DB2 UDB 自动处理事件时使用的支持维护程序，选择当维护失败时（或是当 DB2 UDB 确定需要进行维护，而您不希望 DB2 UDB 马上执行维护程序的情况下）需要通知的一组 Staff 和 Power 用户。

　　图 10. Control Center 角色：基本、高级和定制

 

　　Control Center 也得到了极大的增强，其运行速度更快了。它具有不同的角色（基本、高级和定制），并且在主窗口窗格中显示了一个内置的显示板。比如在选择数据库时， Control Center 将在该仪表板中高亮显示表空间容器信息和数据库的健康状况，而无需下钻或扩展菜单。

　　图 11. 数据库显示板

 

　　为了进一步促进“lights-out”管理，Stinger 还包括一个增强的内存模型，可抢先其他堆保存内存中的偏移，以进行健康管理。

　　得到了较大增强的顾问（Advisor）有助于进行健康报警，而且可以节省更多实用程序（给 BACKUP 和 REBALANCE 添加了 RUNSTATS）。

　　Stinger 还首次包含了一些自动进行模式演变的步骤，当中的功能简化了对于模式的修改，例如重新定义列名、删除列、增加列的大小以及修改默认的列值。

　　DB2 UDB Design Advisor 向导也得到了增强，除了具有索引建议，还包括对于物化查询表（MQT）、数据库分区环境中分区键的选择和多维群集（MDC）的候选方案的建议。这些顾问考虑了一个工作负载，并推荐一个支持该工作负载的模式。

　　图 12. Stinger 的 Design Advisor

 

　　图 13 展示了 Design Advisor 等工具可能产生的结果。在内部实验的测试中，Design Advisor 可以将未调优的 DB2 UDB 数据库性能提高 84%！（当然，结果将会变化，而该测试是通过执行包含 1 TB 数据的 TPC-H 查询完成的。数据库服务器是一个带有 4 个逻辑分区运行 AIX® 的 8 路服务器）。为了取得这些性能增强，该顾问推荐创建 20 个新索引、一个 6 维的 MDC 表、4 个新的分区键和 2 个物化查询表。

　　图 13. 性能提高

 

　　高可用性

Stinger 所提供的一些新功能增强了 DB2 UDB OnDemand 数据库在业务操作连续性或灾难恢复服务方面的弹性。

　　Stinger 中针对高可用性的最强功能就是高可用性灾难恢复（HADR）。该实现是基于 Informix® 的 HDR 实现的。HADR 是一个易于使用的数据复制功能，为部分和整个站点故障提供高可用性（HA）解决方案。

　　图 14. 高可用性灾难恢复

 

　　HADR 基本上是一种日志传送（DB2 UDB 目前所支持的），但它是从日志缓冲区而非固化的磁盘日志中进行提取；该方法提供了各种尺寸来满足您的解决方案中的高可用性需求。

　　比如，Stinger 中的 HADR 功能允许您选择三种级别的数据保护：

• Synchronous（同步）（零数据丢失）- 主服务器进行提交之前，要先将日志数据写入备用服务器中的稳定存储器。而备用服务器直到从主服务器收到消息，得知它磁盘上具有相同的日志，才写入该日志。同时，主服务器在得知备用服务器已经写入了日志之后，才继续进行下一次日志刷新。最终，当日志数据同时存在于主服务器和备用服务器的 磁盘上时，COMMIT 操作才成功，从而确保了零数据丢失。
• Near synchronous（准同步）- 该模式下，要保证将日志数据成功送至备用站点，但是当主服务器上的提交操作成功时，可能还未将该数据写入稳定存储器。主服务器的日志写入和对于备用服务器的发送在主服务器上是并行执行的。该模式下，当日志数据存在于主服务器的 磁盘上，且备用服务器已经 收到了日志数据时，提交（commit）就成功了。该模式可能会导致数据丢失，但是这只有碰巧在两个服务器上同时执行极其相似的操作时才会发生。
• Asynchronous（异步）- 该模式在防止数据丢失方面提供最小保护。异步的 HADR 设置只保证将日志数据传递到 TCP/IP 栈，以及成功返回对套接字发送的调用。这里值得注意的是，套接字发送的调用返回并不能确认备用服务器已经成功接收它。因此，如果连接断了，备用服务器可能还未接收到主服务器发送的全部数据。该模式下有一些保护机制，如 TCP/IP 套接子要保证传送次序，因此只要一直存在套接字，备用服务器就不会看到数据包的丢失或次序颠倒。该模式下，主服务器的日志写入和对于备用服务器的发送在主服务器上是并行执行的；当日志数据存在于主服务器的 磁盘上，且已经 发送给备用服务器时，COMMIT 操作就成功了。

　　图 15. HADR 的状态

 

　　所有推动 DB2 UDB 产品的新功能都具有“易于使用”的一致特点，HADR 也不例外。整个 HADR 场景都可以通过图形向导来设置和管理（例如，在出现站点故障之后，让主服务器和备用服务器重新同步）。

　　图 16. Configure database logging 向导

 

　　HADR 还允许您进行滚动升级（例如，升级您的 DB2 UDB 或操作系统版本），且不会遭到中断。

　　Client Reroute 是 Stinger 中的另一新功能，用于处理 DB2 UDB 中的任何灾难恢复模式，而不仅仅是 HADR。在主数据库遭遇中断的应用程序不会将该问题暴露给终端用户，而是切换至备用服务器并重新发出连接。签订了严格的服务级协定（SLA）的 DBA 将会十分喜爱这项新功能。

　　DB2 UDB Stinger 中的其他功能

　　除了本文中所介绍的，Stinger 中还有一大批功能。下面所列举的一些功能必定会吸引您的目光：

1. 基于队列的复制，通过 WebSphere MQ® 获得高可用、执行快速的复制模式。
2. 新的 DB2 Geodetic Extender（Informix Geodetic DataBlade 的 DB2 UDB 实现）进一步扩展了 DB2 UDB 的“位置感知”功能。这个扩展器（extender）增添了比用 DB2 Spatial Extender 获得的传统纬度/经度投影更丰富的位置语义。
3. 新的 DB2 UDB 通用驱动程序（极大地增加了 SQLJ 支持）与 J2EE 1.4 和 JDBC 3.0 相兼容。
4. 支持 2.6 Linux 内核，从而允许在任何地方运行支持 64 位 Linux 的 DB2 UDB。
5. 许多与 Informix 相兼容的功能，如各种 OLTP 性能增强、Informix 4GL 到 IBM EGL 的转换工具和工具箱，等等。
6. 随时随地获得随需应变（OnDemand）的信息，MobilityOnDemand 功能将 DB2 UDB 服务器授权给了 DB2 Everyplace（这不是 Stinger 的新功能，但是没有什么意义，因为 DB2 UDB v8.1.4 中已经添加了该授权）。

　　我希望本文能让您了解一下我们这些 IBM 数据库开发小组的成员所完成的工作。建议您注册和下载一份 Stinger 的副本，并亲身体验当中所有的神奇功能。（