问题判断、性能和安全性 —— pureQuery 为何对 DBA 如此重要
作为一名数据库管理员，您有时会受到开发人员的制约。您可能已经发现 SQL 性能不稳定，但是又无法识别是哪个 .NET 应用程序提交了造成问题的 SQL。因为 .NET 应用程序通常在一个通用包标识符之下运行。
让我们通过示例进行演示。如果您是一名在 z/OS® 系统上管理 DB2 的 DBA，那么您可能对下面的 Tivoli® OMEGAMON® XE Performance Expert for DB2 监控屏幕相当熟悉（图 1）：
图 1. Tivoli OMEGAMON。哪个应用程序正在使用 SYSxxx00 包？
由于几乎所有的动态 SQL 应用程序都使用 “SYSxxx00” 这样的包，因此确定具体的程序相当困难。在确定造成问题的查询时，您怎么知道应该先查看哪个应用程序呢？如果 .NET 开发人员没有预先考虑这点或者未按最佳实践编写程序，那么将 SQL 与发起它的源应用程序关联在一起是不是更好呢？通过客户机优化，作为 DBA，您可以决定将具体的包名与具体的应用程序关系在一起，从而显著改善在此环境中跟踪问题的能力。
许多人都钟情于静态 SQL，特别是当他们需要为 CPU 使用买单时，其中的一个关键原因就是它可以减少 CPU 使用。使用动态 SQL 时，访问计划、来回发送准备消息等操作确实会带来显著的开销。虽然 pureQuery 客户机优化特性不会将拙劣编写的 SQL 转换为 road runner，但它消除了这方面的开销，因此可以减少 DB2 CPU 使用，有时尤为显著。
为了演示这一点，IBM 开展了一些实验测试，它使用 IRWW 基准测试工具测量静态 SQL 相对动态 SQL 为 .NET 应用程序带来的收益。下图（图 2）显示，在这个特定的环境中，实验室通过使用静态 SQL 能够显著减少 CPU 使用。当 DB2 经过适当优化后，实验人员甚至得到了非常优秀的结果，并且能获得 100% 的语句缓存命中率。有关此性能研究的更多信息，请阅读 “More pureQuery Performance: Now with .NET applications accessing DB2 for z/OS”（参见 参考资料）。
图 2. 基于 .NET 的 IRWW 基准测试：每事务的平均 CPU 使用（值越低越好）
此外，由于访问计划是提前制订的（在绑定时），因此您的应用程序更易于提供一致、稳定的性能。
最后，从安全的角度来说，静态执行 SQL 能够更好地控制所执行的 SQL，并能帮助减少 SQL 注入的风险，而这正是动态 SQL 面临的安全风险。这是因为使用静态包时，您只需要授权用户执行这个包，这表示他们只能执行包中的 SQL。使用动态 SQL 时，您需要提供对底层数据对象的访问。
通过 pureQuery 客户机优化，您可以让现有 .NET 应用程序转换为使用静态 SQL（不需要修改任何源代码！）。有关这方面的更多信息，请继续阅读。
| 
