Query against materialized view awful after refresh of Mview

We have a materialized view defined to refresh complete daily at 5am. YOu can run queries against the MV alone or joining it to other tables. Results come back in 2 or 3 seconds. Once the MView refreshes at 5am - those same queries now take 15 minutes or even more sometimes to complete. WHY IS THIS HAPPENING?? Help anyone?

okay this is better... sorry...
this is the GOOD EXPLAIN PLAN:
PLAN_TABLE_OUTPUT                                                                                                                                                                                                                                                                      
| Id  | Operation                         |  Name             | Rows  | Bytes | Cost  |                                                                                                                                                                                                
|   0 | SELECT STATEMENT                  |                   |     1 |   127 |  1665 |                                                                                                                                                                                                
|   1 |  SORT AGGREGATE                   |                   |     1 |   127 |       |                                                                                                                                                                                                
|   2 |   NESTED LOOPS                    |                   |     1 |   127 |  1665 |                                                                                                                                                                                                
|   3 |    NESTED LOOPS                   |                   |     1 |   113 |  1664 |                                                                                                                                                                                                
|   4 |     NESTED LOOPS                  |                   |     1 |    99 |  1663 |                                                                                                                                                                                                
|   5 |      NESTED LOOPS                 |                   |     1 |    88 |  1662 |                                                                                                                                                                                                
|*  6 |       HASH JOIN ANTI              |                   |     1 |    70 |  1661 |                                                                                                                                                                                                
|*  7 |        TABLE ACCESS BY INDEX ROWID| CONTACT           |  3815 |   201K|  1534 |                                                                                                                                                                                                
|   8 |         AND-EQUAL                 |                   |       |       |       |                                                                                                                                                                                                
|*  9 |          INDEX RANGE SCAN         | IDX_CNT__C_STATE  |       |       |       |                                                                                                                                                                                                
|* 10 |          INDEX RANGE SCAN         | IDX_CNT__STATUS   |       |       |       |                                                                                                                                                                                                
|  11 |        INDEX FAST FULL SCAN       | PK_RPP            | 69277 |  1082K|   120 |                                                                                                                                                                                                
|* 12 |       TABLE ACCESS BY INDEX ROWID | REP_PROFILE       |     1 |    18 |     1 |                                                                                                                                                                                                
|* 13 |        INDEX UNIQUE SCAN          | PK_C19            |     1 |       |       |                                                                                                                                                                                                
|* 14 |      INDEX UNIQUE SCAN            | PK_B01            |     1 |    11 |       |                                                                                                                                                                                                
|* 15 |     INDEX UNIQUE SCAN             | PK_B02            |     1 |    14 |       |                                                                                                                                                                                                
|* 16 |    INDEX UNIQUE SCAN              | PK_RCN            |     1 |    14 |       |                                                                                                                                                                                                
Predicate Information (identified by operation id):                                                                                                                                                                                                                                    
   6 - access("B"."CONTACT_ID"="RPP"."PARTNERSHIP_ID")                                                                                                                                                                                                                                 
   7 - filter("B"."C_STATE"='GA' AND "B"."C_LAST"<>'Name Unknown' AND                                                                                                                                                                                                                  
              "B"."STATUS"='Confirmed')                                                                                                                                                                                                                                                
   9 - access("B"."C_STATE"='GA')                                                                                                                                                                                                                                                      
  10 - access("B"."STATUS"='Confirmed')                                                                                                                                                                                                                                                
  12 - filter("C19"."TERR1"='46')                                                                                                                                                                                                                                                      
  13 - access("B"."CONTACT_ID"="C19"."CONTACT_ID")                                                                                                                                                                                                                                     
  14 - access("B"."FIRM_ID"="B01"."FIRM_ID")                                                                                                                                                                                                                                           
  15 - access("B"."OFFICE_ID"="B02"."OFFICE_ID")                                                                                                                                                                                                                                       
  16 - access("B"."CONTACT_ID"="RCN"."CONTACT_ID")                                                                                                                                                                                                                                     
Note: cpu costing is off                                                                                                                                                                                                                                                               
38 rows selected.

Similar Messages

  • Query against materialized view from stored procedure brings back empty row

    I have a stored procedure that runs a query against a materialized view. When I run the query outside the SP it works just fine. When I change the MV to a table name, the SP works. When I change it back to the MV i get an empty row. Any ideas? The code is below:
    PROCEDURE getAuth     (p_naid        IN  NUMBER,
                             p_scope       IN VARCHAR2,
                             o_xml_data    OUT SYS_REFCURSOR
                             ) IS
      BEGIN
        IF p_scope = 'Approved' THEN
          OPEN o_xml_data FOR
            SELECT naid,
                   p_naid,
                   auth_type,
                   xml_data
            FROM some_mv
            WHERE naid = p_naid;   
          RETURN;
          CLOSE o_xml_data;
    ... the rest of the procedure ...

    does procedure contain EXCEPTION handler?
    if so, then remove, delete & eliminate EXCEPTION handler (at least during testing & debugging)

  • Select query in materialized view with two dblinks

    Hi All,
    We have oracle 10g On windows.
    We are trying to create materialized view. Scenario is we have base table on other database and we are creating mview on different database.
    Basa database have two schema's and i am selecting records from that two schema's using two private db links.
    But when i am tryin gto create mview its not getting created. After 15 hrs. its still showing creation command and not finished.
    Query is :-
    Is it good practice to have two db links in select query of materialized view.

    Billy  Verreynne  wrote:
    Chanchal Wankhade wrote:
    Is it good practice to have two db links in select query of materialized view.Same db link being used twice, or two different db links?
    If the former, you ideally want the local Oracle db to send the join to the remote database, and for the remote database to drive the join between those 2 tables. There is a hint (<i>driving_site</i>) that can be used - or the join query can be defined on the remote database as a view, and the local materialised view can then use that remote view.
    If you have 2 different db links and joining across these - usually a bad idea to perform distributed database joins. There are lots of limitations as to how the tables can be joined. Worse case, full table scans of both remote tables, pulling all the rows from the 2 remote database tables to the local database, and joining these on the local database.
    I have seen some severe performance issues in the past as a result of distributed joins. I'll rather use 2 materialised views for pulling both distributed tables's data locally, and then do the join on local data (using indexes, partition pruning, etc)Hi Billy,
    My scenario is i have two database database A and database B. Database A is having two schema's SCOTT AND HR. SCOTT schema have select privileges on HR schema.
    DB LINK is between Database B to Database A. name is db.link.B.A.oracle.com.
    What if i priovide while creating materialized view, the schema name before the table name in database B for this particuler table so it will pick up the table from that schema using same DB LINK(db.link.B.A.oracle.com.) that i am using to fetch records from SCOTT schema.
    Above schnario is like two base schema's and one db link using two schema.

  • Query on Materialized view and materialized view log

    I am creating a materialized view something like this.but getting following error:
    ERROR at line 1:
    ORA-12032: cannot use rowid column from materialized view log on "SCOTT"."EMP"
    SQL> create snapshot log on scott.emp;
    Materialized view log created.
    SQL> create materialized view scott_emp refresh fast on demand as select deptno,sum(sal) sum_sal from scott.emp group by deptno;
    ERROR at line 1:
    ORA-12032: cannot use rowid column from materialized view log on "SCOTT"."EMP"
    Note when i have my query in materialized view as "select * from emp;" in place of
    "select deptno,sum(sal) sum_sal from scott.emp group by deptno;" This code works fine.
    How do i have a materialized with with a group by clause.
    Thanks in Advance

    Got the answer myself.
    I wasnt adding all the required columns.
    CREATE MATERIALIZED VIEW LOG ON scott.emp
    WITH SEQUENCE, ROWID (<all the required columns>)
    INCLUDING NEW VALUES;
    Anyways,
    Thanks guys...

  • Materialized view not properly refreshing

    Hi,
    As materialized view is not refreshing properly. we compare the sum of hashcode materialized view with the sum of hash code of the base view or table the materialized view is defined. If it's found equal then materialized view got refreshed succesfully else not.
    But in below example the column value is interchanged in between the row eventhough hashcode is same.
    Is there any other way to find the materialized view got refreshed successfully or not.
    SQL> create table temp as select object_name, subobject_name from user_objects where rownum<3;
    Table created
    SQL> select * from temp;
    OBJECT_NAME SUBOBJECT_NAME
    ATP_BN_I_1
    ATP_START_END_DATE_I_2
    SQL> create materialized view mv1 as select * from temp;
    Materialized view created
    SQL> select * from mv1;
    OBJECT_NAME SUBOBJECT_NAME
    ATP_BN_I_1
    ATP_START_END_DATE_I_2
    SQL> select sum(nvl(ora_hash("OBJECT_NAME"||"SUBOBJECT_NAME"),0)) from temp;
    SUM(NVL(ORA_HASH("OBJECT_NAME"
    4852176374
    SQL> select sum(nvl(ora_hash("OBJECT_NAME"||"SUBOBJECT_NAME"),0)) from MV1;
    SUM(NVL(ORA_HASH("OBJECT_NAME"
    4852176374
    SQL> UPDATE TEMP SET OBJECT_NAME=SUBOBJECT_NAME,SUBOBJECT_NAME=OBJECT_NAME;
    2 rows updated
    SQL> COMMIT;
    Commit complete
    SQL> select * from mv1;
    OBJECT_NAME SUBOBJECT_NAME
    ATP_BN_I_1
    ATP_START_END_DATE_I_2
    SQL> select * from temp;
    OBJECT_NAME SUBOBJECT_NAME
    ATP_BN_I_1
    ATP_START_END_DATE_I_2
    SQL> select sum(nvl(ora_hash("OBJECT_NAME"||"SUBOBJECT_NAME"),0)) from MV1;
    SUM(NVL(ORA_HASH("OBJECT_NAME"
    4852176374
    SQL> select sum(nvl(ora_hash("object_name"||"subobject_name"),0)) from temp;
    select sum(nvl(ora_hash("object_name"||"subobject_name"),0)) from temp
    ORA-00904: "subobject_name": invalid identifier
    SQL> select sum(nvl(ora_hash("OBJECT_NAME"||"SUBOBJECT_NAME"),0)) from temp;
    SUM(NVL(ORA_HASH("OBJECT_NAME"
    4852176374
    Any help really appreciated.
    Thanks in advance.

    unique wrote:
    Is there any other way to find the materialized view got refreshed successfully or not.You can look at the last_refresh_date and staleness columns of all_mviews: http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/statviews_1105.htm#REFRN20139
    Or maybe use the all_mview_refresh_times view: http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/statviews_1104.htm#sthref1068
    Regards,
    Rob.

  • How to get a materialized view get to refresh itself after the job is "broken"

    we created a materialized view sometime ago with the following statement:
    create materialized view SXV_PUB_EMPLOYEE_CERT_ALL_M
    refresh complete on demand
    start with to_date('30-08-2009 04:00:00', 'dd-mm-yyyy hh24:mi:ss') next trunc(sysdate) + (28/24)
    as
    select  sxv_emp_cert_all.*
    from    sxv_employee_certification_all sxv_emp_cert_all;
    this week we found out it had not been refresh for about a month
    In dba_jobs the column broken was 'Y', next_date time something like 01-01-4000 and failures 16
    when I ran it manually by executing
    BEGIN DBMS_MVIEW.REFRESH('SXV_PUB_EMPLOYEE_CERT_ALL_M', 'C'); END;
    I found that one of the columns was too small (probably a columns of one of the underlying tables had been extended since the creation of the materialized view)
    After fixing this I ussied yesterday (on 29-8-2013) the statement :
    alter materialized view SXV_PUB_EMPLOYEE_CERT_ALL_M
    refresh complete on demand
    start with to_date('30-08-2009 04:00:00', 'dd-mm-yyyy hh24:mi:ss') next trunc(sysdate) + (28/24)
    after this the table dba_jobs showed me 30-08-2013 04:00:00 as next date
    I was expecting it to run this night at 04:00, but it didn't
    the last_date column value was still from about a month ago, the column broken still shows 'Y'
    and the next date 30-08-2013 04:00:00 (while it should been set to 31-08-2013 01:00:00
    Rrunning
    BEGIN DBMS_MVIEW.REFRESH('SXV_PUB_EMPLOYEE_CERT_ALL_M', 'C'); END;
    gave no errors this time
    and in User_Mview_Analysis the last_refresh_date column showed the date/time I had executed it
    Any idea how to get the job "unbroken" again so that the view refreshes itself every night?
    the database is Oracle Database 10g Release 10.2.0.4.0
    regards,
    Remco

    thanx for all your helpful and correct answers . but eventually I found it myself
    exec dbms_job.broken(<jobnumber>, false);

  • Refresh FAST for Materialized View failed after Partition Operation

    Dear all,
    I have created a Materialized View having a simple join between a Dimension and Fact Table of a Datawarehouse. The MV is REFRESH FAST ON DEMAND.
    However, when a Partition Maintenance Operation (PMOP) was performed on the Master Tables, the MV failed to Refresh giving a ORA-32313 error.
    As suggested on one of the troubleshooting websites, we did a complete refresh of the MV and fixed it temporarily. However, I would like to know the exact cause for this and would like to have a permanent fix for the same.
    Can the DBA for this Database provide me the answers or are there some standard troubleshooting steps for the same?
    Please let me know.
    Best,
    Ketan

    Hello Maurice,
    Here are the answers to your questions.
    1) Database is Oracle 9i.
    2) We have a stored procedure to refresh the MV. The command is dbms_mview.refresh('SALES_FACT_MV','f'). It was working fine daily. Only after a PMOP was done on the Master Tables, it failed to refresh. We have also created indexes on some columns of the MV for performance improvement. We are getting a very good improvement.
    3) We have MV logs for both Master Tables to store the incremental values.
    4) We are not able to get the output from DBMS_MVIEW.EXPLAIN_MVIEW since this can be done only by the DBA. WIll update you once I have the info.
    5) Same as Point 2.
    Let me know if you need any further info.
    Thanks, Ketan

  • Issue with materialized view and fast refresh between Oracle 10g and 11g

    Hi all,
    I've hit a problem when trying to create a fast-refreshable materialized view.
    I've got two databases, one 10.2.0.10, another 11.2.0.1.0, running on 32-bit Windows. Both are enterprise edition, and I'm trying to pull data from the 10g one into the 11g one. I can happily query across the database link from 11g to 10g, and can use complete refresh with no problem except the time it takes.
    On the 10g side, I've got tables with primary keys and m.v. logs created, the logs being of this form ...
    CREATE MATERIALIZED VIEW LOG ON table WITH PRIMARY KEY INCLUDING NEW VALUES
    On the 11g side, when I try to create an m.v. against that ...
    CREATE MATERIALIZED VIEW mv_table REFRESH FAST WITH PRIMARY KEY AS SELECT col1, col2 FROM table@dblink;
    ... I get an ORA-12028 error (materialized view type is not supported by master site).
    After running the EXPLAIN_MVIEW procedure it shows this;
    REFRESH_FAST_AFTER_INSERT not supported for this type mv by Oracle version at master site
    A colleague has managed to build a fast-refresh m.v. from the same source database, but pulling to a different one than I'm using; his target is also 10g, like the (common) source, so I've no idea why I'm getting the 'not supported' message whilst he isn't.
    I've been able, on previous projects, to do exactly what I'm trying to achieve but on those someone with more knowledge than me has configured the database!
    I'm now stumped. I'm also no DBA but despite that it's been left to me to install the new 11g database on the 32-bit Windows server from scratch, so there are probably a couple of things I'm missing. It's probably something really obvious but I don't really know where to look now.
    If anyone can give me any pointers at all, I'd be really grateful. This question is also duplicated in the Replication forum but hasn't had any replies as yet, so I'm reproducing it here in hope!
    Thanks in advance,
    Steve

    Hi Steve,
    You should have a look at metalink, Doc ID 1059547.1
    If that does not help, there may be something else in Mater note ID 1353040.1
    Best regards
    Peter

  • Creating a Materialized View Log After the Data has been instered

    Hi,
    I am trying to create a method of replication from Oracle to MySQL using the Materialized View Log table.
    This has been done before and works quite well, the only problem is that I am trying to impliment the log after the table has been created and populated and wish to push all the existing data through the log file...
    Does anyone know if it is possible to refresh the Materialized View Log and not a Materialized View.
    The way the replication is intended to work is:
    Oracle> Data inserted into table
    Oracle> writes the vector data to the MVL
    Script> Monitors the MVL and can see the changes being made to the Oracle Table
    Script> Updates MySQL with the data and removes the rows from the MVL
    MySQL is then used with other unix systems
    Currently we export the data from the table using Triggers and a cronjob running every x minute to check for changes in the TriggerTables
    Many thanks for your time on this, I have been checking for almost a whole working day and not found the answer to this problem.

    Thats what I thought, the MVL will only read data that has changed since it was created and wont have the option to load in all the data as though it was made before the table was created.
    From what I have read, the MVL is quicker than a Trigger and I have some free code that prooved to work from a MVL using it as a reference to know what records to update. There is not that much to a MVL, a record ID and type of update, New, Update or Delete.
    I think what I will have to do is work on a the same principle for the MVL but use a Trigger as this way we can do a full reload if required at any point.
    Many thanks for your help.

  • Help with sql query on materialized view logs

    I am in need of a query to find out what tablespace and snap shot site a long list of materialized view logs are associated with.
    something like below except tablespace and snap_shot_site are not an option for this table.
    select log_owner, master, log_table, tablespace, snap_shot_site from dba_mview_logs;

    What is the refresh method set as?
    Could you paste the full MV log creation script and the corresponding MV creation script.

  • Query on Materialized View Logs

    We need a denormalised data step-up, we decided on implementing Materialized Views and started working on them. I have created Materialized View log on a table using below mentioned syntax
    CREATE MATERIALIZED VIEW LOG ON <table_name> WITH ROWID
    I have tested it and its working fine.A Strange error I am facing is, after an hour or so the materialised view gets corrupted and applicatin users gets an error saying error with the materialised view log.
    The log entry in the data dictionary gets deleted. Later I have to execute DROP on the log to completely remove it.
    I am confused how this can happen.

    What is the refresh method set as?
    Could you paste the full MV log creation script and the corresponding MV creation script.

  • Query on Materialized View created on Prebuilt Table

    Hi,
    I am trying to explain the scenario below on Materialized View which I want to setup for our database.
    I have created a materialized view on prebuilt table on target side on primary key. Now for purging history data from target side which are more than 5 years old I have executed the following steps:
    1. Dropped the materialized view which was created previously on prebuilt table in target side.
    2. Deleted the data from that target table which are more than 5 years old.
    3. Now created the materialized view again on the prebuilt table.
    Now, the problem which I am facing is that - if any changes happens in the source side during the above 3 steps on the target side those changed records were not captured even after successfully building materialized view again in the target side (i.e. after completing step-3 of above the intermediate changed records were not captured).
    Can you please let me know exactly what I am doing wrong here and how can I achieve my intended result.
    Regards,
    Koushik

    See matelink for doc id *252246.1*. The document id says: A materialized view was defined on a Table A. This table had a referential constraint defined against another table, Table B. This constraint was defined as 'ON DELETE CASCADE'. An 'ON DELETE CASCADE' constraint is not allowed on views but as the constraint was created on the table underlying the materialized view, Table A, it could be created although it would behave as a constraint on the view. The constraint existed for performance reasons, which is permitted, and was disabled when created but a general script had been run to enable all constraints. When a delete was performed on Table B the error above was reported although there was no view created on Table B.

  • Query on materialized view

    Hi,
    Materialized view can't be renamed, so how can I reduce the downtime for any new column addition in the materialized view.
    Regards,
    Koushik

    Agree with your reply.
    I like to do the following steps assuming there is already a materialized view created on a base table :
    1. Add any new column to the base table.
    2. Drop and recreate the mlog table.
    3. execute the statement "alter materialized view <mv_name> consider fresh" to simulate the error "ORA-12034: snapshot log on "<schema>"."<mv_name>" younger than last refresh"
    4. Create a new MV with the additional columns and with a different name.
    5. Drop the existing(old) MV.
    6. Rename the new MV with the name of the old one.
    Now this renaming is not possible. Is there any alternative way do the thing whatever I am trying to do by the above steps.
    Can you please also tell me what is use of "ENABLE QUERY REWRITE" option during creation of a materialized view.
    Thanks & Regards,
    Koushik

  • Materialized view - parameter and refresh

    Hi,
    We are creating a Materialized view that has 2 rows for a CCID, one for this year and one for previous year with balances in 12 buckets.
    We have 2 questions:
    1. Can a materialized view be created with a parameter? or it can only take hard coded values?
    2. Can we refresh a part of materialized view, lets say we want to refresh the balances only for this year?
    Thanks

    user12182208 wrote:
    Hi,
    We are creating a Materialized view that has 2 rows for a CCID, one for this year and one for previous year with balances in 12 buckets.
    We have 2 questions:
    1. Can a materialized view be created with a parameter? or it can only take hard coded values? Typically, you want a materialized view to contain a complete set of aggregate data ... so, no, parameters don't really make sense (also, the results are pre-computed unlike a regular VIEW which is just a stored query. With a MV the data is actually computed on creation unless you defer it, and takes up physical storage).
    >
    2. Can we refresh a part of materialized view, lets say we want to refresh the balances only for this year?
    You can (depending on your Oracle Version and complexity of your materialized view) create a materialized view that does fast refreshes. If for some reason it was pertinent for you to achieve what you've asked, you could make 2 MV's and then a view that does a UNION ALL of them (the MV's would not contain overlaps), then you would just refresh the 1 MV, seems odd to me to want to do this though.
    Thanks

  • Materialized View creation with REFRESH FAST

    Hello ,
    Please see below case,
    TABLE A1(partitioned range+list)
    COLUMN C1  -- Primary key
    COLUMN C2  -- NUMBER
    TABLE D1
    COLUMN C1 -- PRIMARY KEY
    created MV log as below
    CREATE MATERIALIzED VIEW LOG ON A1 WITH ROWID,PRIMARY KEY INCLUDING NEW VALUES;
    CREATE MATERIALIzED VIEW LOG ON D1 WITH ROWID,PRIMARY KEY INCLUDING NEW VALUES;
    Trying to create MV like below:
    CREATE MATERILIZED VIEW mv1test
                                    REFRESH FAST ON COMMIT
    AS
    Select
    FROM A1,
                            D1
                    WHERE A1.C1 = D1.CI
    AND A1.C2 IS NOT NULL;
    It gives below error message:
    ORA-12052: cannot fast refresh materialized view schema.mv1test
    12052. 00000 -  "cannot fast refresh materialized view %s.%s"
    *Cause:    Either ROWIDs of certain tables were missing in the definition or
               the inner table of an outer join did not have UNIQUE constraints on
               join columns.
    *Action:   Specify the FORCE or COMPLETE option. If this error is got
               during creation, the materialized view definition may have be
               changed. Refer to the documentation on materialized views.
    However ,as discussed in earlier thread i checked all general restrictions of the 'Refresh fast' approach for join.
    Restrictions on Fast Refresh on Materialized Views with Joins Only
    Defining queries for materialized views with joins only and no aggregates have the following restrictions on fast refresh:
    1) They cannot have GROUPBY clauses or aggregates.
    2) Rowids of all the tables in the FROM list must appear in the SELECT list of the query.
    3)Materialized view logs must exist with rowids for all the base tables in the FROM list of the query.
    4)You cannot create a fast refreshable materialized view from multiple tables with simple joins that include an object type column in the SELECTstatement.
    As per above restrictions ,
    1) Group by clause is not present
    2)i do not understand 2nd point , i have added a1.rowid  and d1.rowid in  select statement of MV, but got same error.
    3) observed same as 2nd point.
    4)we have CLOB column in select list. Tried removing this column but got same error.
    Please do let me know any workaround on this.
    Thanks in advanced ..
    PM

    Basic Materialized Views show how to analyse MVs using dbms_mview. I'm not sure about creating MVs on partitioned tables, that partition maintenance might cause problems

Maybe you are looking for