Oracle 物化视图性能问题!

我已经在UAT服务器上创建了一个MV，并且使用了一个查询来创建MV视图，该查询具有与PROD的远程连接，并且仅选择对这些表的权限
它在每个表中有数百万行约10 lakhs，但在计算后，查询的输出仅为139-150行。没有MViews的单独查询要60
秒，但是当我使用创建物化视图时，NOCOMPRESS NOLOGGING立即使用索引刷新强制按需下一个null使用默认值
使用强制约束的本地回滚段禁用查询重写，因为 “查询” mview创建发生在一小时内，并且在刷新时间之后
是20-30分钟？这肯定是不可接受的，因为此数据被用于仪表板，延迟3分钟，MV应该需要时间来刷新!
我没有特权可以检查prod DB，但是在UAT上我有足够的访问权限!我已经尝试了很多选择，但是没有用，所以请帮助
我知道什么是解决方案，如果没有解决方案，这背后的原因是什么？另外，当我的mview刷新时，它会显示在解释计划中
“将/* 绕过 _ 递归 _ 检查 */插入abc”。请帮帮我!

我真的被困在这里，并努力解决它或找到可以向相关团队解释的原因!请帮忙!
1.我尝试使用相同的查询创建表，并且花了不到一分钟的时间。
2.插入语句同样也可以正常工作。
3.我也尝试了使用atomic_refresh = false的MV视图刷新选项，但它不起作用，实际上无济于事!

如果您有任何需要的信息，请告诉我!

注意: 我的mv视图查询使用来自UAT的带有db链接的prod表 (大约4个表)。Prod服务器有一个单独的用户，该用户在下面给出了表格权限

从abc @ prod中选择count(*);
-800000
从abc1 @ prod中选择count(*);
-700000
从abc2 @ prod中选择count(*);
-200000

要快速更新MV，您需要快速刷新。

要启用此功能，您必须在查询中的所有表上都实体化了视图日志。

这些是礼物吗？如果是，您是否检查过查询是否可以快速刷新？

正如我在本视频中讨论的那样，并非所有查询都是可刷新的:



如果出于任何原因无法快速刷新，则可以通过跟踪此过程来调查刷新时间如此长的原因:

exec dbms_monitor.session_trace_enable ( null, null, true, true );
exec dbms_mview.refresh ( 'your_mv' );
exec dbms_monitor.session_trace_disable;

然后查看跟踪文件，看看所有的时间都在哪里。