Skip to main content

No subqueries allowed in materialized view? No problem!

Have you ever run into the following error when trying to create a materialized view?
ORA-22818: subquery expressions not allowed here
Yes, it is true: you cannot have a scalar subquery in the SQL statement used to create your materialized view. Here's an example of what won't work (note: I am not claiming this query makes any sense):
CREATE MATERIALIZED VIEW hr_demo_mv
AS
     SELECT employee_id,
            (SELECT MAX (hire_date)
               FROM employees ce) maxhd
       FROM employees t
/

ORA-22818: subquery expressions not allowed here
22818. 00000 -  "subquery expressions not allowed here"
*Cause:    An attempt was made to use a subquery expression where these
           are not supported.
*Action:   Rewrite the statement without the subquery expression.
Rewrite my query without the subquery expression? But I just spent an hour putting it all together. Works great. Gives me exactly the results I want and need. Rewrite it? ARGH.

Calm yourself. While it is true that you will need to "rewrite the statement" that you provide in your CREATE MATERIALIZED VIEW statement, you will not have to abandon your subqueries and all your hard work.

All you have to do is create a view with the subqueries, and then create your materialized view based on the view:
CREATE VIEW hr_demo_v
AS
     SELECT employee_id,
            (SELECT MAX (hire_date)
               FROM employees ce) maxhd
       FROM employees t
/

View HR_DEMO_V created.

CREATE MATERIALIZED VIEW hr_demo_mv
AS
     SELECT * FROM hr_demo_v
/

Materialized view HR_DEMO_MV created.
I recommend this approach (the materialized view is "nothing more" than a select from a view), even if your materialized view query does not contain a subquery or anything else that would preclude the materialized view from being created.

By taking this approach, you can change the contents of the materialized view with the next refresh by doing nothing more than changing the query (instead of dropping and re-creating the materialized view).
Labels:

Comments

  1. Erik van RoonAugust 10, 2017 at 1:26 PM

    That is pretty cool. Thanks!

    And it's so simple it makes me feel stupid for not thinking of this myself. Thanks for that too ;-)

    I am definitely going to use this, starting tomorrow morning.

    ReplyDelete
  2. iudithAugust 11, 2017 at 12:23 AM

    Hello Steven, All,

    When using the approach of basing a naterialized view on a view instead of directly on the base tables,
    you should be aware that this automatically makes the materialized view to be considered COMPLEX,
    and thus NOT fast refreshable.

    This is true even for very simple views, like for example a view that selects all the columns of a single table.

    That is, if the table has a materialized view log defined, then a materialized view based directly on the table
    will be fast-refreshable, while a materialized view based on a view that selects from the table will NOT be fast-refreshable.

    This behavior may be relevant or not, based, of course, on the specifics and performance requirements of your application.


    Thanks a lot & Best Regards,
    Iudith

    ReplyDelete
    Replies
    1. Steven FeuersteinAugust 11, 2017 at 3:53 AM

      Thanks for pointing that out, Iudith.

      Delete
    2. AnonymousJanuary 2, 2018 at 5:07 PM

      Hi everyone, following-up on this thread:

      I just learned about Materialized View today and encountered the same issue in this post. As Steven suggested, I built the MV above a View. But @iudith mentioned that this won't enable the fast-refresh. My questions are:
      1. By default, how is MV refreshed by the system? Is it by period of time or something else?
      2. Since the fast-refresh is not possible, is there a way to regularly update the MV? I will appreciate it if someone can refer me to a good tutorial for beginner about this. The Oracle Docs is a bit overwhelming ...

      Danny

      Delete
    3. Steven FeuersteinJanuary 2, 2018 at 5:10 PM

      Danny, check out Tim Hall's article on materialized views.

      https://oracle-base.com/articles/misc/materialized-views

      On the Oracle Dev Gym (devgym.oracle.com) we use DBMS_SCHEDULER to run jobs daily and weekly to refresh materialized views.

      Delete
  3. AnonymousAugust 11, 2017 at 4:41 AM

    ok, this query doesn't make any sense, however, the "GROUP BY"-part of it doesn't even make any sense at all.
    It should be left away because it might be confusing

    ReplyDelete
    Replies
    1. Steven FeuersteinAugust 11, 2017 at 4:47 AM

      Ha! Excellent point. That was left over from an earlier iteration of the query. I will remove it.

      Delete
  4. AnonymousJanuary 25, 2018 at 8:33 AM

    I just wonder how annoying it might get later on, when you figure out, that changing of query actually does not work in changing of your MV_ contents, and it also stops to refresh.

    Or that when you add column into view query, this will not automatically add column into MV_ ...

    ReplyDelete
  5. AnonymousMarch 15, 2018 at 4:34 AM

    This comment has been removed by a blog administrator.

    ReplyDelete
  6. AnonymousApril 12, 2018 at 12:59 AM

    That's exactly what I needed. It works perfectly!

    ReplyDelete
  7. AnonymousJuly 2, 2019 at 6:07 PM

    This just pushed the error farther down - I'm working in peoplesoft and got the same error when I tried to build the materialized view from the view with subqueries as suggested above - "Warning: named view in FROM list not supported for this type MV" and "Warning: named view in FROM list not supported for this type MV"

    ReplyDelete
  8. modawanatyFebruary 17, 2020 at 1:34 AM

    Thank you Steven this workaround was a great help.

    ReplyDelete
  9. RodneyNovember 2, 2020 at 12:56 PM

    Hi Steven - Just wanted to say many thanks for this!! I spent a few days toiling with a materialized view trying to re-write it. Then I also got this idea to make part of the materialized view simply into a view.

    I didnt have any proof, or a comfort level doing it but after reading your blog I'm more confident that this is the best that can be done :)

    ReplyDelete
    Replies
    1. StevenNovember 2, 2020 at 1:18 PM

      Glad to hear it, Rodney! Thanks for sharing your experience.

      Delete

Post a Comment

Popular posts from this blog

Why DBMS_OUTPUT.PUT_LINE should not be in your application code

A database developer recently came across my  Bulletproof PL/SQL  presentation, which includes this slide. That first item in the list caught his attention: Never put calls to DBMS_OUTPUT.PUT_LINE in your application code. So he sent me an email asking why I would say that. Well, I suppose that is the problem with publishing slide decks. All the explanatory verbiage is missing. I suppose maybe I should do a video. :-) But in the meantime, allow me to explain. First, what does DBMS_OUTPUT.PUT_LINE do? It writes text out to a buffer, and when your current PL/SQL block terminates, the buffer is displayed on your screen. [Note: there can be more to it than that. For example, you could in your own code call DBMS_OUTPUT.GET_LINE(S) to get the contents of the buffer and do something with it, but I will keep things simple right now.] Second, if I am telling you not to use this built-in, how could text from your program be displayed on your screen? Not without a lot o...
4 comments
Read more

The future of Oracle PL/SQL: some thoughts on Sten Vesterli's thoughts

Sten Vesterli published a very thought-provoking post on his blog: Please stop reading this post, and read that one. When you are done, come on back here for my thoughts on Sten's thoughts. OK. You read it. Here we go. First, thanks, Sten, for being such an interesting, wise, sometimes provocative voice in our community. Next, Sten writes: Now, on the one hand, I certainly agree that the vast majority of young developers are currently caught up in the modern version of a Gold Rush, which is: "Build an app using JavaScript, pay no attention to that database behind the curtain." But I can assure you that I still do meet young PL/SQL programmers, regularly, when I am at conferences and doing onsite presentations at companies. So, young person who writes PL/SQL: do not be afraid! You are not alone! And you are super-smart to have made the choice you did. :-) Next, Sten offers this advice to managers: I agree that PL/SQL is a "spec...
46 comments
Read more

Table Functions, Part 1: Introduction and Exploration

Please do feel encouraged to read this and my other posts on table functions, but you will learn much more about table functions by taking my Get Started with PL/SQL Table Functions class at the Oracle Dev Gym. Videos, tutorials and quizzes - then print a certificate when you are done! Table functions - functions that can be called in the FROM clause of a query from inside the TABLE operator - are fascinating and incredibly helpful constructs. So I've decided to write a series of blog posts on them: how to build them, how to use them, issues you might run into. Of course, I am not the first to do so. I encourage to check out the  documentation , as well as excellent posts from Adrian Billington (search for "table functions") and Tim Hall . Adrian and Tim mostly focus on pipelined table functions, a specialized variant of table functions designed to improve performance and reduce PGA consumption. I will take a look at pipelined table functions in the latter part...
31 comments
Read more