oracle materialized view 清除,Oracle 11g Broken Materialized视图：停止刷新而不删除视图或刷新视图？(Oracle 11g Broken Mate...

Oracle 11g Broken Materialized视图：停止刷新而不删除视图或刷新视图？(Oracle 11g Broken Materialized view: Stop refresh without dropping view or refreshing view?)

所以我有一个物质化的观点(我知道......)：

CREATE MATERIALIZED VIEW vw_my_view_here

REFRESH COMPLETE START WITH SYSDATE NEXT SYSDATE + 1/24 AS

/*huge-ass select statement here*/

UNION ALL

/*huge-ass select statement here*/

UNION ALL

/*huge-ass select statement here*/

UNION ALL

/*huge-ass select statement here*/

这在我们的系统中存在了一段时间而没有引起问题。 其中一个选择查询被破坏(以某种方式 - 基础表中的模式更改)并且已经连续24小时运行并消耗所有的盒子资源。 这是盒子上其他东西的问题。

我无法删除或修改视图 - 因为它完全没有记录(我知道......)而且我需要先找出谁消耗它，它是如何填充的等等。

我试图杀死正在处理查询的进程，但似乎另一个查询会立即被解雇。

如何在没有1)删除视图的情况下停止物化视图，以及(2)不刷新视图(因为这需要24小时以上和我们所有的盒子资源)。

我试过跑步

alter materialized view view_name refresh on demand;

但它似乎只是无休止地运行，对原始的大规模查询没有影响。

有任何想法吗？

So I've got a materalized view (I know...) :

CREATE MATERIALIZED VIEW vw_my_view_here

REFRESH COMPLETE START WITH SYSDATE NEXT SYSDATE + 1/24 AS

/*huge-ass select statement here*/

UNION ALL

/*huge-ass select statement here*/

UNION ALL

/*huge-ass select statement here*/

UNION ALL

/*huge-ass select statement here*/

This has been present in our system for some time without causing issues. One of these select queries is broken (somehow - presumibly schema changes in the underlying tables) and has taken to running for 24 hours straight and consuming all of the boxes resources. This is a problem for the other things on the box.

I can't drop or modify the view - as it's completely undocumented (I know...) and I need to figure out who consumes it, how it's populated, etc. first.

I tried killing the process that's handling the query, but it seems another query is fired straight away afterwards.

How can I stop the materialized view without 1) dropping the view and (2) without refreshing the view (because that's taking 24+ hours and all of our box resources).

I've tried running

alter materialized view view_name refresh on demand;

but it seems to just run endlessly with no effect on the original massive query.

Any ideas?

原文：https://stackoverflow.com/questions/40484564

更新时间：2019-11-15 20:11

最满意答案

此子句仅设置默认刷新选项。 有关实际实现刷新的说明，请参阅Oracle Database Advanced Replication和Oracle Database Data Warehousing Guide。

因此，您的alter materialized view语句本身不会刷新。 它只是等待当前排除的刷新完成才能更新该视图的数据字典。 一旦当前刷新完成(或终止)， alter将完成并阻止进一步自动刷新。

This clause only sets the default refresh options. For instructions on actually implementing the refresh, refer to Oracle Database Advanced Replication and Oracle Database Data Warehousing Guide.

So your alter materialized view statement is not doing a refresh itself. It is just waiting for the currently-excuting refresh to complete before it can update the data dictionary for that view. Once the current refresh completes (or is terminated) the alter will complete and prevent further automatic refreshes from being started.

2016-11-08

相关问答

你可以吗？ 当然。 这是调整流程的最有效方法吗？ 可能不会。 执行增量刷新而不是完全刷新将允许您仅移动通过数据库链接实际更改的数据，并且可能会显着降低索引维护的成本。 另外，如果您正在进行非原子刷新，则意味着Oracle在后台执行直接路径加载。 这意味着索引维护已经推迟到将数据加载到表中之后，这限制了删除和重新创建索引的潜在好处。 如果您决定每次都手动删除并重新创建索引，则必须确保在添加或删除新索引时保持最新状态。 当一些开发人员想要添加或删除索引时，这是一个相对容易忽视的维护麻烦。 Can yo

...

您不需要在线重新定义或任何聪明; 你要做的是通过ON PREBUILT TABLE子句内置的： ON PREBUILT TABLE子句允许您将现有表注册为预初始化的物化视图。 此子句对于在数据仓库环境中注册大型实例化视图特别有用。 该表必须具有相同的名称，并且与生成的实例化视图位于相同的模式中。 如果删除了物化视图，则预先存在的表将恢复为其作为表的标识。 所以你可以这样做： CREATE MATERIALIZED VIEW SCI_FI_MOVIE

(SCI_FI_MOVIE_ID, NAME,

...

我们发现的事情似乎阻止了MV的刷新：1.对基表的DDL进行更改2.如果MV跨越数据库链接，则通过链接获取数据时出现问题(例如，我们有一个数据库这里和一个远程如果在刷新期间两个数据库之间的连接失败，则刷新失败) 在＃1的情况下，刷新失败并且再也不能再次运行，我们必须重新创建MV。 在＃2的情况下，它不清楚刷新是否会再次增加。 快速刷新MV对我们来说已证明是不可靠的，因此我们在Windows调度程序中创建了一项工作来启动刷新。 Things we've found seem to stop an MV

...

我想如果你完全消除“exec”它可能会更好。 “exec”是一个SQL * Plus命令。 我试试： CREATE OR REPLACE PROCEDURE REFRESH_MV AS

BEGIN

DBMS_MVIEW.REFRESH('my_mat_view_mv','C');

END REFRESH_MV;

I think if you just eliminate the "exec" altogether it might work better. "exec" is a SQL

...

好的，可能有很多原因。 你没有在11g中重新创建MV。 您无法刷新MV来创建它。 您没有为MV所在的架构重新创建同义词(公共或私有)。 您没有在另一个模式中重新创建对MV的授权，因此请创建它们。 您可以尝试使用DBMS_MVIEW而不是DBMS_SNAPSHOT。 exec dbms_mview.refresh('Table1');

OK, there may be many reasons for this. You didn't recreate the MV yet in 11g. You

...

关键是物化视图中的ORDER BY毫无意义。 在封面下，物化视图实际上只是一个表，它在基于它的表更新时自动更新。 但作为一张桌子意味着无法保证订购。 即使初始MV以所需顺序存储，也不能保证在应用更新后它将保持不变。 确保以正确顺序获得结果的唯一方法是在从MV中选择时使用显式ORDER BY。 您可以在视图(不是物化视图)中包含ORDER BY，并且在使用该视图时将应用ORDER BY：从视图中选择，然后不需要任何ORDER BY。 但这是一个非常糟糕的做法。 这意味着应用程序可能在不知不觉中依赖于

...

我冒着'重新格式化'您的查询的自由(顺便说一句：我认为那里有一些复制粘贴错误，有些部分在最后看起来会翻倍) '布局'对实际执行时间没有影响，但它使我更容易理解你在做什么(仅仅因为我习惯了我自己的风格，我并不是说它更好，而是简单我习惯了) 无论如何，如果我理解正确并且没有弄乱括号，那么这应该等同于你的查询： SELECT *

FROM documents this_

INNER JOIN document_treenodes treenodes14_

ON treenode

...

简单的降落物化视图.. PRESEVE TABLE将做到这一点 simple DROP MATERIALIZED VIEW .. PRESERVE TABLE will do it

更改刷新设置的文档说： 此子句仅设置默认刷新选项。 有关实际实现刷新的说明，请参阅Oracle Database Advanced Replication和Oracle Database Data Warehousing Guide。 因此，您的alter materialized view语句本身不会刷新。 它只是等待当前排除的刷新完成才能更新该视图的数据字典。 一旦当前刷新完成(或终止)， alter将完成并阻止进一步自动刷新。 The documentation for altering t

...

JSapkota提到的Oracle Issue / Doc ID 757537.1明确指出，这不是错误，而是正确/预期的行为： mview的STALENESS，引用PL / SQL函数设置为UNKOWN，因为无法确定PL / SQL函数的变化。 根据设计和代码，当前行为是正确的。 我想使用DETERMINISTIC函数而不是默认范围可能会阻止它。 The Oracle Issue/Doc ID 757537.1 mentioned by JSapkota states clearly, that

...