Peoplesoft查询 - 性能

我遇到PeopleSoft查询（使用Oracle后端数据库）的问题：当涉及多个记录的相当复杂的查询由用户设置时，PS执行强制连接的安全记录，从而生成SQL像这样：Peoplesoft查询 - 性能

选择....从
ps_job一个，PS_EMPL_SRCQRY A1，ps_table2 b，ps_sec_rcd2 B1，ps_table3 C，ps_sec_rcd3 C1
其中（...安全连接A-> A1，B- > b1，c-> c1 ...）和（... a，b和c ...的连接）和
a.setid_dept ='XYZ';

（假设最后一个条件有很高的选择性，并且对列的索引）显然，由于是创造了巨大的加入的条件下，排列第一，写入临时段，并当最后一个条件最终被应用时，只有一小部分被选中。以这种方式制定的查询很可能达到APPSRV的预设超时，甚至是QRYSRV的预设超时。当手动编写查询时，我宁愿将最有选择性的条件移到开始位置，从而将正在处理的数据量限制到相当的水平。
关于如何使PS表现如此的任何想法？事实上，已经重写“甲骨文风格的” SQL到ANSI SQL似乎加快了查询 - 然而，PS写甲骨文样式的查询......

在此先感谢
DBA

来源

2010-03-17 DBa

请添加不良执行查询的计划。 – 2010-03-19 22:15:08

这里有几个笛卡尔连接，索引被FTS部分绕过......通常，这样的计划被显示为“不这样做的一种方式”。它会真的超过可用的字符限制。 – DBa 2010-04-12 15:01:08

全表扫描可能没问题。如果您访问的记录超过一半，则几乎总是好的。合并连接笛卡儿几乎总是不好的。我会先看看那些，看看你能做些什么（索引，额外的连接标准，改变表格顺序）以便首先解决这些问题。 – 2010-05-05 16:14:23

我所知道的唯一的解决方法强制它按照它应该的方式进行连接，而不是它的方式（并且避免可怕的Merge Join Cartesian）是创建一个正确执行连接的视图。

使用正确的字段创建记录。
使其键入SQL视图。
粘贴到您现在可以使用的SQL中。
将其添加到查询安全树中。
刷新安全缓存。

来源

2010-03-19 22:17:42

这将不幸意味着为每个复杂的用户查询创建一个视图 - 这是绝对不受欢迎的。 – DBa 2010-04-12 14:58:59

解决此问题的其他方法：将其设置为“进程查询”。这将删除行级别的安全问题，只要没有它的查询结果可以公开就可以解决问题。 – 2012-08-09 20:01:53

除了格兰特的建议之外，另一种方法是在表上创建用户查询和执行正常连接的视图。

对于上述您将不得不 - 1.为查询中将使用的每个记录创建视图。 2.将查看添加到查询安全树。 3.使用PS查询中的视图。这将对视图执行正常的连接，并且连接中不会有安全记录。

为了对数据执行用户级安全性，您可以拥有另一个安全性视图并将其加入到最终查询中，并在where子句中检查当前登录用户的条件。

这样您将有固定数量的视图来创建，而不是每个用户查询的视图。

来源

2012-05-12 09:46:38 navi

Peoplesoft查询 - 性能

回答

相关问题