在将项目代码从oracle 12 c迁移到19 c时，我们面临着视图的并行提示问题。当我们使用下面的代码时，并行度工作正常
SELECT /*+ PARALLEL(8) */ 1 FROM View;字符串
但是，当我们在select语句中显式地给予视图列名时，并行提示不起作用
SELECT /*+ PARALLEL(8) */ id,name FROM View型
它在oracle 12 c中工作正常，但在oracle 19 c中不工作。如何解决这个问题？
- 管道行函数调用
第一个月
--函数声明
FUNCTION P_FILE
(
P_SOURCE IN SYS_REFCURSOR,
p_filename IN VARCHAR2,
p_directory IN VARCHAR2
)
RETURN v_return_pipe
PIPELINED DETERMINISTIC
PARALLEL_ENABLE (PARTITION p_source BY ANY)AS型
PRAGMA AUTONOMOUS_TRANSACTION
2条答案
按热度按时间lrl1mhuk1#
您的查询 is 在可能的情况下使用并行性，即在
T_...的两次全表扫描中您可以看到PX BLOCK ITERATOR操作作为这些表扫描的直接父操作，TQ列显示PX团队分配。但是，您随后使用
COUNT将第一个聚合为一行。然后在另一个查询块中使用结果，但根据定义，聚合后只有1行，PX在该执行分支的其余部分被禁用。出于很好的原因-当只有一行要处理时，它没有任何用处。行输出除了流到客户端之外没有别的事情要做，无论如何都必须是串行的。下一个查询块从
dual中拉取，这意味着同样只有1行。这里没有并行性。下一个查询块再次从
T_....中拉取，并使用并行扫描。最后一个块再次从dual中拉取1行。并行性在这里没有什么要做的。
我看不出Oracle在这里是如何实现员工并行的问题。它在唯一可以做到的地方这样做。事实是，它这样做只是因为您暗示了它并请求了并行。在这里这样做可能是错误的。因为您没有对这些表扫描的下游数据做任何事情（至少在视图本身），在这个查询中的任何地方都没有并行性的好处。你的瓶颈将是通过网络连续地将结果获取到客户端，并在那里消费/显示它们，而不是数据库正在做的任何事情。在这方面抛出并行性只会导致其他进程无法使用的空闲但已分配的PX从机。此外，即使您正在执行连接和排序以及其他可以从并行性中受益的操作，您的统计数据也会说，您的查询中唯一的表，
T_...只有13 K行。这不足以证明并行查询的启动时间。我会删除提示，让它串行运行。数据库版本的更改对执行计划进行全面更改是很正常的。有时会有帮助，有时会有伤害，有时您无法判断，但可以通过重大升级进行某种更改。这并不意味着它做错了什么。
在一天结束的时候，重要的不是我们是否理解或同意我们在计划中看到的内容，而是它是否实际上执行得可以接受。如果它运行得很快，就不应该花时间去试图弄清楚为什么Oracle做出了它所做的决定。只关注运行得太慢而不能满足他们需求的查询，然后深入研究计划，根据您对数据的了解，了解它犯了什么错误（如果有的话）。在这种情况下，并行性不是其中之一。
ctrmrzij2#
并行提示正在工作。你仍然有“PX发送”=>“PX协调员”在第二个执行计划，只是有点低。
我不知道这个视图里面是什么，但是出于某种原因，Oracle决定并行处理SQL的一部分，然后对并行工作进程产生的结果顺序地应用SORT => UNION ALL。