DB2高效的智能应用案例

即使您的团队中都是非常有才华的应用程序开发人员,他们仍会做一些错事,这会减少他们为公司提供的价值。我经常看到的一个最显著的例子是:使用应用程序代码去完成 DB2 可以更高效完成的工作。

  在 20 世纪 80 年代 IBM 推出全新的 DB2 时,大量的应用程序开发人员都在学习如何使用 SQL(顺便说一下,这也是 IBM 发明的)进行编程。虽然掌握这门语言需要时间,但现在 DB2 已经推出 27 年了,仍由程序员使用应用程序代码来连接表,而不是充分利用 SQL 的面向集合的特性。换言之,他们在用应用程序代码去完成 DB2 应该做的事。在这篇专栏中,我将尝试介绍一些案例,让 DB2 去执行它可以替您执行的工作。

  让程序员的时间更有价值

  没有人喜欢看到开发小组总是在做重复的事。如果程序员编写有用例程的方式无法让其他程序员轻松发现该例程的功能,或者无法轻松地使用它,那么所导致的结果肯定是做了不必要的重复劳动,因为其他人最终会在其程序中从头编写相同的逻辑。这还会导致在某种程度上延长应用程序的维护时间,从而导致可用来开发新应用程序的时间缩短,因为您必须在不同的程序中更新类似的功能。

  DB2 对此可提供很大的帮助。有多种方法将逻辑置于 DB2 级别的应用程序中,让访问数据库的所有程序都可使用该逻辑。例如,为了响应在表中插入、删除或更新行,可使用触发器 让某个操作自动执行(几乎所有的操作都可以使用 SQL 表达)。您可使用触发器确保某个雇员的薪水位于允许的范围内,方法是在更新后的薪水超出该范围外时发出一个错误。触发器还能调用 DB2 中已存储的过程和用户定义的函数,这些过程和函数是以DB2对象的形式封装逻辑的一种方法。如果更新 PARTS 表中的行后库存的商品数低于某个指定的阈值,那么触发器就会调用某个已存储的过程,再次定购目录中的该商品。

  在 DB2 数据库中实现的以数据为中心的逻辑越多,程序员就可以将更多的精力放在编写能直接满足公司各种商业需求的代码上。如果您认为某些与数据有关的逻辑能在企业中广泛应用,那么可以同 DB2 DBA 谈谈,将这些逻辑部署在应用系统的数据库层中,最终可让公司中的所有程序员更高效、更高产地工作。

  面向未来的应用程序

  随着时间的流逝,数据库也发生了改变。通常数据库变得更大了,并且数据库中存储的数据的特征也发生了改变。例如,过去表中内容基本上只有一列,而现在可能变得包含大量重复的值。用户希望在经历这些改变后,应用程序执行任务时仍保持一致性,但如果程序员在做 DB2 应该去做的工作,那么这种一致性实现起来就很困难。

  举个例子:用应用程序代码来连接表。这意味着程序员要确定数据访问路径。问题马上就来了:如何知道程序员是否作出了正确的决定?在表 A 上编写一个游标,获取合格的行,并在表 B 中寻找匹配的内容,实际上这些就是我们所谓的嵌套循环连接。如何知道嵌套循环方法是连接这些表的正确方法?合并连接是否是正确方法,混合连接 (DB2 for z/OS) 或哈希连接(DB2 for Linux、UNIX 和 Windows)又怎样呢?

  DB2 执行表连接工作时,SQL Optimizer 会根据 DB2 目录中存储的统计信息来确定成本最低的结果集生成方式。DB2 Optimizer 能够出色地完成本职工作,因为自从 IBM 发明基于成本的 SQL 语句优化后的 30 年中,一直在对 DB2 Optimizer 进行改进。

  数据库逐渐发生变化时,就会出现第二个问题。也许数据库变得非常大,查询得到的结果集比以前大很多,并且其他表连接方法的性能要比最初选择的方法要好。如果由 DB2 负责处理连接工作,那么 DB2 Optimizer 会自动调整访问路径。如果用应用程序代码完成连接工作,则会出现性能下降,从而导致需要重写程序。

  类似的是,用编程方式进行连接会让数据库变得无法维护,或者维护工作变得很复杂。假设某个通过程序代码执行的表连接工作主要取决于具体索引是否存在。如果表中累积了太多的索引,致使插入和删除操作的成本过高,则需要删除这些索引(在数据库中这随时都会出现这种情况)。如果由 DB2 负责处理连接工作,它可切换到不同的连接方法并实现可接受的性能。但是需要重写硬编码的连接。您无法更改硬编码程序中的连接方法(除了重写程序),所以用编程方式实现的连接可能让 DBA 无法进行实际的数据库更改,而这些更改会减少关键数据更改操作的执行时间。

  底线是:让 DB2 完成尽可能多的工作,将访问路径选择处理工作留给 DB2 去完成。这样,当数据库随着时间的流逝而不断改变时,有助于保持应用程序的性能不变。总之,您要考虑到您的公司已经为 DB2 中内置的复杂 SQL 优化技术付过费了。

  提高应用程序的 cpu 工作效率

  程序发出一个 SQL 语句之后,该语句必须从程序到达 DB2,执行完该语句后,必须将控制权归还给应用程序代码。数据在程序与 DB2 之间的来回旅行可不是免费的。减少应用程序代码中的 SLQ 语句数目,就会减少来回穿过 ―应用程序-DB2‖ 边界的 累积开销。让传输到 DB2 的信息变得更少,这样完成工作会实现显著的性能提高,此处的重点是不要关注于单个工作单元,而是关注总体的工作负载。每个交易所用的 CPU 时间虽然只有很小的差别,但在每秒执行数万个交易时,或者批处理工作要使用输入文件中的数万个记录时,累积的差别会非常显著。

  要想从 CPU 效率的角度真正实现高性能,开发人员需要跟上并准备好利用各种全新的 DB2 特性和功能,减少应用程序与 DB2 之间的通信。例如,可以考虑使用 MERGE 语句,通过使用该语句,可根据一组输入记录来更改表、与输入记录匹配时更新目标表的数据、不匹配时则在表中插入新的行。这样做可以节省 CPU 使用时间,因为老方法是针对目标表执行 SELECT 操作,查看是否存在与输入记录匹配的行,然后执行 UPDATE(如果有匹配行)或 INSERT(如果没有匹配行)。类似的是,与一次插入一行相比,使用多行 INSERT(有时称为块 INSERT)将多个新行插入表中(使用一个 INSERT)也可以节省 CPU 使用时间。寻找可用更少 SQL 语句就能完成数据检索和更改的方式,这样就可以减少 DB2上的负载。济南网站开发(www.mwinds.net)

  让 DB2 帮您完成工作

  让 DB2 完成使用 SQL 可以完成的所有工作,这才是最正确的方式。记住,一些逻辑实现 SQL 工作(例如创建触发器)是 DBA 所熟悉的,所以您可以在需要时向 DBA 求助。DB2 数据库中内置了易用且可重用的功能,随着数据库的更改的增加,可以用更一致的方式维护应用程序性能,并且程序的 CPU 使用效率会更高,这些都会让您的公司受益匪浅。不要再费劲地编程了。程序本身就是智能的。

 

posted @ 2012-03-01 05:29  晨风互动  阅读(263)  评论(0编辑  收藏  举报
济南网站建设