通过StarSQL访问DB2 - 效率。输出参数或选择查询

时间:2011-09-06 18:17:14

标签: c# db2 mainframe

我正在研究一些代码,这些代码查询在一个漂亮的旧MainFrame上运行的旧DB2数据库。 Query必须用StarSQL编写。这样做的目的是大大减少MIP对通过Command.Text传入的当前查询的使用。

对于那些不知道的人,你会根据大型机上的CPU使用率(MIP)收取费用(很多!),因此你希望事情尽可能高效地运行。你真的不想说“Select * From TableA”并将其作为CommandType.Text传递给数据库,因为它需要编译该语句然后返回结果。您需要将其保存为一个过程(已经编译过)并删除*以获得所需的确切列。

所以,我的问题。我自己无法回答这个问题,因为我们的MainFrame大师正在度假......

我有一个返回~30列的过程。通过Select查询返回它们或将它们作为输出参数返回会更有效。这是通过存储过程。

我并不担心C#代码的长度,但是它会破坏大型机的效率。

我需要考虑以下事项:

SELECT PHNS.CLNT_INTERNL_KY as CLNT_INTRNL_KY

使用额外的CPU使用率将该列名应用于该列,但使用游标将其保存为输出参数会更有效吗?

如果您需要任何其他信息,请与我们联系。

干杯,

(标签上有“star”标签,但是我不是1500分......)

1 个答案:

答案 0 :(得分:2)

许多查询API不允许使用存储过程,但是如果您有该选项,则使用存储过程可以通过在编译时而不是在每次执行期间解析和优化查询一次来节省一些CPU时间。如果没有,您仍然可以从动态SQL语句的缓存中受益。动态语句的访问计划临时存储在包缓存中,因此如果很快遇到相同的逐字节相同语句(包括参数标记和文字值),DB2将重用包缓存中的访问计划而不是从头开始优化它。

使用存储过程可以为使用不同文字值的频繁运行的语句节省大量编译时间。如果输入参数是可选的或可能有很大差异(例如灵活搜索),则存储过程可能会在编译时产生不合需要的访问计划,因为它不知道将在运行时填充哪些参数。在这些情况下,存储过程可能需要在运行时通过REOPT策略重新优化查询,但这种方法显然会消除预编译的节省。

我建议使用DB2的EXPLAIN工具来确定查询工作负载中的实际成本(编译与扫描与排序)。如果查询扫描大量行,则评估每行的CPU成本可能会快速超过优化动态查询的开销。发出SELECT *的查询通常会阻止优化器利用可以用较少的I / O操作满足相同查询的索引。在WHERE子句中过滤和连接谓词(或缺少它们)也可以阻止优化器选择索引。