Peoplesoft 查询 - 性能答案

【问题标题】：Peoplesoft queries - performancePeoplesoft 查询 - 性能
【发布时间】：2010-03-17 16:11:51
【问题描述】：

我遇到了 PeopleSoft 查询的问题（使用 Oracle 后端数据库）：当一个涉及多个记录的相当复杂的查询被用户触发时，PS 会强制连接安全记录，从而生成如下 SQL：

选择 .... 来自
ps_job a, PS_EMPL_SRCQRY a1, ps_table2 b, ps_sec_rcd2 b1, ps_table3 c, ps_sec_rcd3 c1
其中 (...security join a->a1, b->b1, c->c1...) and (...joins of a, b and c...) and
a.setid_dept = 'XYZ';

（假设最后一个条件具有高选择性并且列上有索引）显然，由于条件的安排，首先创建了一个巨大的连接，写入临时段，当最后应用最后一个条件时，只选择了一个小的子集。以这种方式制定的查询很可能会达到 APPSRV 甚至 QRYSRV 的预设超时。在手动编写查询时，我宁愿将最具选择性的条件移到开头，从而将正在处理的数据量限制在相当大的水平。
关于如何使 PS 表现得像这样的任何想法？实际上，已经将“Oracle 风格”的 SQL 重写为 ANSI SQL 似乎加速了查询 - 但是，PS 编写了 Oracle 风格的查询......

提前致谢
DBa

【问题讨论】：

请添加执行不良查询的计划。
那里有几个笛卡尔连接，索引被部分绕过以支持 FTS...通常，这样的计划显示为“不这样做的方法”。而且它真的会超过可用的字符数限制。
全表扫描可能没问题。如果您要访问超过一半的记录，那几乎总是好的。合并连接笛卡尔几乎总是不好的。我会先看看这些，然后看看你能做些什么（索引、附加连接条件、更改表顺序）来首先解决这些问题。
在像 ps_job 这样的表上执行 FTS 几乎总是很糟糕，因为行长（166 列）。不幸的是，PeopleSoft 中的查询管理器以非常糟糕的方式强制加入安全记录 - 是否有可能影响这种行为？

标签： oracle peoplesoft

【解决方案1】：

除了 Grant 所建议的之外，另一种方法是在表上创建用户将查询并执行正常连接的视图。

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

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

这样您就可以创建固定数量的视图，而不是为每个用户查询创建一个视图。

【讨论】：

【解决方案2】：

我所知道的唯一解决方法是强制它以应有的方式进行连接，而不是按照它的方式（并避免可怕的合并连接笛卡尔）是创建一个正确执行连接的视图。

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

【讨论】：

不幸的是，这意味着为每个复杂的用户查询创建一个视图——这绝对是不受欢迎的。
解决此问题的其他方法：将其设置为“进程查询”。这将消除绕过问题的行级安全性，只要没有它的查询结果可以公开。