Skip to Main Content

Oracle Database Discussions

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.

Materialized View Refresh fails for a MView including a Lateral Join with ORA-31933 and ORA-00942

Martin PreissJun 13 2019 — edited Jun 19 2019

Hello,

today I encountered a rather strange error in the context of an mview refresh: one of our development teams did create a rather complex view and wanted to get a corresponding Materialized View. The initial creation worked as expected, but a following refresh failed with an unexpected ORA-00942 error. I was able to reproduce the effect in the following small test case:

-- 12.2.0.1 SE

create table t(

   col1 number

, col2 varchar2(4000)

);

insert into t(col1, col2) values(1, '[{"type":1,"target":42}]');

insert into t(col1, col2) values(2, '[{"type":1,"target":42},{"type":2,"target":43}]');

create materialized view t_mv

as

select t.col1, t.col2, r.val

  from t,

  LATERAL (SELECT MIN(val) AS val

             FROM JSON_TABLE ( t.col2, '$[*].target'

                               COLUMNS (val NUMBER PATH '$')

                              )

           ) r;

SQL> create materialized view t_mv

  2  as

  3  select t.col1, t.col2, r.val

  4    from t,

  5    LATERAL (SELECT MIN(val) AS val

  6               FROM JSON_TABLE ( t.col2, '$[*].target'

  7                                 COLUMNS (val NUMBER PATH '$')

  8                                )

  9             ) r;

Materialized view created.

SQL> exec dbms_mview.refresh('t_mv')

BEGIN dbms_mview.refresh('t_mv'); END;

*

ERROR at line 1:

ORA-00942: table or view does not exist

ORA-06512: at "SYS.DBMS_SNAPSHOT_KKXRCA", line 2952

ORA-06512: at "SYS.DBMS_SNAPSHOT_KKXRCA", line 2370

ORA-06512: at "SYS.DBMS_SNAPSHOT_KKXRCA", line 85

ORA-06512: at "SYS.DBMS_SNAPSHOT_KKXRCA", line 245

ORA-06512: at "SYS.DBMS_SNAPSHOT_KKXRCA", line 2352

ORA-06512: at "SYS.DBMS_SNAPSHOT_KKXRCA", line 2908

ORA-06512: at "SYS.DBMS_SNAPSHOT_KKXRCA", line 3191

ORA-06512: at "SYS.DBMS_SNAPSHOT_KKXRCA", line 3221

ORA-06512: at "SYS.DBMS_SNAPSHOT", line 15

ORA-06512: at line 1

I know: the pseudo-JSON column col2 is missing its check constraint - and I would not claim that the use of the lateral join (or the JSON) is actually a good idea, but still the result surprises me: the MView is created and returns the expected result, but a subsequent refresh fails with an ORA-942 - though there is only one table included into the definition. So I created a SQL trace and found there the following information:

kkzfThrowError:  error_pos = kkzfGetNumRows:OCIStmtPrepare2 errcode = 942  msgbuf =ORA-00942: table or view does not exist

kkzfPrintError: error = 31933 btm = 0  emsglen = 137

ORA-31933: error occurred during refresh statistics processing at kkzfGetNumRows:OCIStmtPrepare2

ORA-00942: table or view does not exist

kkzfSetupStatsCtxDrv:1: stats is disabled on error 31933

kkzfSetupStatsCtxDrv:1: error = 31933 is cleared

kkzdQueryObjNumByName:------ORA-1403 data not found ---

kkzdQueryObjNumByName:usrid= 104, oname=VW_LAT_9DCD9C42

kkzdQueryObjNumByName:---------------------------------

So it seems the internally the Oracle tried to gather stats on VW_LAT_9DCD9C42 - which is in my opinion a lateral view as mentioned in https://jonathanlewis.wordpress.com/2011/02/27/internal-views/. I see a similar VT_LAT entry when I create a plan for the query used in the mview definition:

--------------------------------------------------------------------------------------------

| Id  | Operation                | Name            | Rows  | Bytes | Cost (%CPU)| Time     |

--------------------------------------------------------------------------------------------

|   0 | SELECT STATEMENT         |                 |     2 |  5034 |    60   (0)| 00:00:01 |

|   1 |  NESTED LOOPS            |                 |     2 |  5034 |    60   (0)| 00:00:01 |

|   2 |   TABLE ACCESS FULL      | T               |     2 |  4030 |     2   (0)| 00:00:01 |

|   3 |   VIEW                   | VW_LAT_A18161FF |     1 |   502 |    29   (0)| 00:00:01 |

|   4 |    SORT AGGREGATE        |                 |     1 |     2 |            |          |

|   5 |     JSONTABLE EVALUATION |                 |       |       |            |          |

--------------------------------------------------------------------------------------------

So my question is: has anyone seen a similar behaviour? I could not find much about ORA-31933 in MOS (and ORA-942 was also not extremly helpful for different reasons). And could you think of a way to avoid the internal statistics gathering to get the mview refresh working? Ok, actually two questions...

It not hard to find a workaround for the problem (since the object is only refreshed on demand, and it should be no problem to create an intermediate table with CTAS and base the mview refresh on this table instead of using the query), but I would be happy to avoid additional complexity.

Regards

Martin Preiss

This post has been answered by AndrewSayer on Jun 17 2019
Jump to Answer

Comments

mariam.kupa

Hello,

I have seen the same problem when using fast refresh materialized view that uses mview log also.

Do an explicit  select privilege for the mlog:

grant select on mlog$_<master_table> to <mview_schema>

https://deeparaja.wordpress.com/2012/07/17/materialized-view-fast-refresh-fails-with-ora-12018-ora-00942/

Martin Preiss

thank you for the answer and the link: but in my case the owner of table and mview is the same and the ora-942 is not related to the accessed table, but to an internal object and furthermore a transient object, that cannot be found in the dictionary at all (so the ora-942 makes sense - but not the idea to gather statistics for this object at all).

BobLilly

Hi Martin,

Have you tried the OPT_PARAM('optimizer_dynamic_sampling', '0') hint?

Regards,

Bob

AndrewSayer
Answer

I can replicate on my 12.2 instance, it looks like there's a problem with the lateral view existing in the execution plan. I can't see a no lateral view hint, and I couldn't see anything in the plan outline that looks relevant but you can hint to use an older optimizer environment, 11.1.0.7 did the trick for me (although it was the first I chose).

create materialized view t_mv

as

select /*+OPTIMIZER_FEATURES_ENABLE('11.1.0.7')*/t.col1, t.col2, r.val

  from t,

  LATERAL (SELECT MIN(val) AS val

            FROM JSON_TABLE ( t.col2, '$[*].target'

                              COLUMNS (val NUMBER PATH '$')

                              )

          ) r;

exec dbms_mview.refresh('t_mv','c')

PL/SQL procedure successfully completed.

I suggest you raise an SR as this could effect a lot of other things, and should be relatively painless as you've got an easily reproducible test case

Marked as Answer by Martin Preiss · Sep 27 2020
Donatello Settembrino

trying on a 12.2 with SYS user (disabling query rewrite) it seems to work correctly without modifying OFE

SQL> select user from dual;

USER

------

SYS

SQL> create materialized view t_mv

  2  disable query rewrite

  3  as

  4  select t.col1, t.col2, r.val

  5    from t,

  6    LATERAL (SELECT MIN(val) AS val

  7              FROM JSON_TABLE ( t.col2, '$[*].target'

  8                                COLUMNS (val NUMBER PATH '$')

  9                                )

10            ) r;

Creata vista materializzata.

SQL> exec dbms_mview.refresh('T_MV');

Procedura PL/SQL completata correttamente.

Mustafa KALAYCI

Hi Martin,

I have the same result but if you change the query as a subquery it works. of course mv does not support scalar subqueries so I created a view to achive that:

create or replace view v_x as

select t.col1, t.col2, (SELECT min(val) AS val

                         FROM JSON_TABLE ( t.col2, '$[*].target'

                                           COLUMNS (val NUMBER PATH '$')

                                          )

                       ) as val

from t;

drop materialized view t_mv;

create materialized view t_mv

as

select * from v_x;

exec dbms_mview.refresh('t_mv');

it works and when I checked the execution plan of the view I can see that VW_LAT*** view. I hope that gives some idea.

Martin Preiss

Hi Andrew,

thank you for the hint: I didn't consider this option since the lateral join was a 12c addition (if I recall  this right). This should work in the given context.

Regards

Martin

Martin Preiss

Hi Donatello,

SYS is special: I would not be surprised to see different strategies, when SYS is concerned.

Regards

Martin

Martin Preiss

Hi Mustafa,

thank you for adding this solution, which would also be a valid option.

Regards

Martin

Donatello Settembrino

in fact, I did not indicate it as a solution but it seemed "strange" to me that without changing the behavior of the optimizer (OFE) it would still work under SYS user.

Regards

Martin Preiss

strange indeed, but SYS tends to include strange effects.

AndrewSayer

Dom Brooks wrote:

Would be interesting to know what fix is responsible

https://blog.dbi-services.com/ofe-optimizer-features-enable/

https://blog.tanelpoder.com/posts/scripts-for-drilling-down-into-unknown-optimizer-changes/

I tried the obvious parameter (with lateral in the name) but it wasn't that. I started writing some scripts a while ago to brute force these things with explain plan, but only managed to get as far as it cycling through fix controls (and can confirm there's no fix control in it). Mauro Pagano's Pathfinder (which my scripts mimic) does include hidden parameters but it has to execute the SQL each time and needs to be run as SYS (which doesn't seem to have the problem) https://mauro-pagano.com/category/pathfinder/ . Might be worth kicking off overnight and checking the results in the morning.

1 - 13

Post Details

Added on Jun 13 2019
13 comments
12,903 views