4

I have a huge materailized view that I have to adjust. It's a simple adjustment as I'm just adding an NVL function to the select statement.

I.e. Original...

Select this,
       that.....

I.e. Modified 

Select NVL(this, orThat) as this,
       NVL(That, orThis) as that

The query takes 26 seconds to run, but due to the amount of rows retrieved (2.3 million) it is dead slow. It ran for almost 5 days straight and then I stopped it.

This is a problem, especially since I need to deliver this to a client, and they can't run a script for 5+ days to create a MV.

Question: Is there any way to speed up the altering/recreation of a MV? Would it be faster if I altered the MV or would it be around the same as dropping and recreating?

Oracle version = 10g

contactmatt
  • 18,116
  • 40
  • 128
  • 186
  • you'll need to test that, but chances are recreating it will be faster (you're touching all the rows, that's pretty hell). – Mat May 18 '11 at 14:41
  • 2
    "the query takes 26 seconds to run"...you mean it STARTS returning rows after 26 seconds. Try that query using /*+ ALL_ROWS */ hint – tbone May 18 '11 at 16:29

2 Answers2

9

You can't alter the definition of the query for a materialized view - you have to drop and recreate it. That said, you can try this approach, it could be faster than recreating the entire MV:

  1. Drop the materialized view, using PRESERVE TABLE.
  2. Update the data in the table that used to be the MV to reflect the new column definitions.
  3. Recreate the materialized view using the ON PREBUILT TABLE clause.

If you have indexes on the view, it may be helpful to disable and rebuild them.

DCookie
  • 42,630
  • 11
  • 83
  • 92
1

5+ days to build a 2-3 million row MV? Thats waaaaay out of whack, too much to be just poor SQL. My guess is that you may be blocked by some other process(?). Not sure, but check this from a different session after you launch your MV rebuild:

select s1.username || '@' || s1.machine
  || ' ( SID=' || s1.sid || ' )  is blocking '
  || s2.username || '@' || s2.machine || ' ( SID=' || s2.sid || ' ) ' AS blocking_status
  from v$lock l1, v$session s1, v$lock l2, v$session s2
  where s1.sid=l1.sid and s2.sid=l2.sid
  and l1.BLOCK=1 and l2.request > 0
  and l1.id1 = l2.id1
  and l2.id2 = l2.id2 ;

Just a guess. If you use Toad you can get this info as well (via Database->monitor->session browser). This will also show you Long Ops progress (table scans, etc).

Edit: Oh, btw, build the MV using nologging, should help a bit overall once you determine that you don't have issues stated above.

tbone
  • 15,107
  • 3
  • 33
  • 40
  • If you're doing a complete refresh, it will do a truncate...insert/*+append*/. With nologging specified, it can bypass redo generation for the table (but will still generate some for indexes). This will greatly reduce (but not eliminate) redo, and you should see a performance boost (in the complete rebuild) from it. – tbone May 26 '11 at 11:30