Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> materialized views and ORDER BY

materialized views and ORDER BY

From: Greg Norris <spikey.mcmarbles_at_gmail.com>
Date: Wed, 25 Apr 2007 11:10:49 -0500
Message-ID: <d4beff360704250910t19bc51ebl41494eb60a2be7c2@mail.gmail.com>


I have a developer who's complaining that the ORDER BY clause is being dropped from his materialized views, thus requiring him to recreate them several times a day. I've told him I'm virtually certain this is by design, so that the MV behavior doesn't change depending upon the refresh method, but have so far been unable to find it explicitly documented... can anyone point me to a definitive statement?

Here's a quick test case (some of the more trivial output has been trimmed for brevity), to clarify what I'm babbling about...

SQL> create table test (
  2 col1 number(2)
  3 );

Table created.

SQL> insert into test values (1);
SQL> insert into test values (3);
SQL> insert into test values (9);
SQL> insert into test values (4);
SQL> insert into test values (7);
SQL> insert into test values (2);
SQL> insert into test values (5);
SQL> insert into test values (6);
SQL> insert into test values (8);
SQL> insert into test values (10);
SQL> commit;

Commit complete.

SQL> select * from test;

      COL1


         1
         3
         9
         4
         7
         2
         5
         6
         8
        10

10 rows selected.

SQL> create materialized view test_mv

  2     refresh complete with rowid
  3     as select * from test order by 1;

Materialized view created.

SQL> select * from test_mv;

      COL1


         1
         2
         3
         4
         5
         6
         7
         8
         9
        10

10 rows selected.

SQL> select query from user_mviews where mview_name = 'TEST_MV';

QUERY



SELECT "TEST"."COL1" "COL1" FROM "TEST" "TEST" SQL> exec dbms_mview.refresh('TEST_MV')

PL/SQL procedure successfully completed.

SQL> select * from test_mv;

      COL1


         1
         3
         9
         4
         7
         2
         5
         6
         8
        10

10 rows selected.

As you can see, Oracle appears to use the query AS-IS for the initial creation (provided that you don't specify BUILD DEFERRED), so it does get the requested ordering once... future refreshes will completely ignore the ORDER BY, however, as it's been dropped from the query.

In real life, the query in question is a fairly involved beastie which involves several join/union/grouping operations, and everything "always worked correctly" in the past. The database was recently upgraded from 8.1.7.4 to 10.2.0.3, however, so I'm pretty sure this is really a case of "what do you mean GROUP BY doesn't sort?!?" in disguise. I've suggested a couple of workarounds already, so what I really need is to convince them that this behavior is by design and thus we can't "fix" the materialized view directly.

No need to even mention that developers shouldn't have the ability to (re)create objects in the first place... completely out of my control in this case.

Thanx!

--

"I'm too sexy for my code." -Awk Sed Fred

--

http://www.freelists.org/webpage/oracle-l Received on Wed Apr 25 2007 - 11:10:49 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US