Materialized view is empty after 5 minutes

After successful usage in our dev environment, I went to migrate a snapshot to QA only to find that after about 5 minutes, it was empty. Here are all the facts/symptoms I could think of, I was wondering if anyone could shed some light - I'm stumped.
- on creation, ddl runs < 1 second with these options
TABLESPACE BPF_DATA
NOCACHE
LOGGING
NOPARALLEL
BUILD IMMEDIATE
REFRESH FORCE ON DEMAND
WITH PRIMARY KEY
- the tables selected include a remote query
- rows exist for about 5 mins
- after about 5 mins (give or take 1 minute), status goes to needs_compile, all rows disappear (the weirdest part)
- We discovered this after attempting to run dbms_mview.refresh, and it was taking forever
- no dml being done on 4 underlying tables
- 4 separate test snapshots were created as "select * from" underlying tables, none went to needs_compile
- doco says it's expected behaviour when applying dml to underlying tables (regarding statuses), except we don't apply any dml, and rows shouldn't disappear
- if I do actually apply some dml, the relevant test snapshot has different staleness/after_fast_refresh settings, more inline with expected behaviour
- doesn't happen in dev environment
- I could find no metalink entries regarding problem
Any ideas?

Hi,
This_date is just the date time that the job was started by the job process, it's OK if this_date is a little bit greater than next_date, because very rarely do jobs start exactly at their scheduled time, depends on jobqueue_interval and how many job processes are free at that time. It just means that the date time it started was slightly later than the date time that it was asked to be run at.
However the fact that total_time is resetting is odd. This should accumulate (it does on all jobs that I've seen, I've just checked my own little bevy of dba jobs). Are you sure the failures column isn't increasing?
And you don't need the DBA to tell you what's in the alert log, do you have the CREATE ANY DIRECTORY privilige?
Chris

Similar Messages

MATERIALIZED VIEW BECOMES INVALID AFTER REFRESH

Hello All,
I have wierd problem ,
In my enviroinment we have a MATERIALIZED VIEW ,which is refreshed by a sheduled DBMS_SNAPSHOT.REFRESH Job post the refresh it becomes invalid and every time we have to compile it manually ,Could anybody help with a solution .Thanks a lot in Advance .
DETAILS :
======
VERSION:Oracle9i Enterprise Edition Release 9.2.0.6.0 - 64bit Production
HOST: IBM AIX

Is the MV part of a refresh group?
Post the command and parameters used by the scheduled job to do the refresh as well as the parameters you use when you do it manually.

Result of materialized views

Hi,
I have created a materialized view, making a complete refresh ervery day at 1am.
It's possible that a query on this mview at refresh time will be empty will the query execute before and after the refresh wont be empty.
(The refresh will take about 60 Minutes to complete.)
Thanks.
regards,
Rainers

When you do a complete refresh a materialized view, Oracle deletes the old data and inserts the new data in a single transaction. Queries will never see the materialized view as empty-- the will see the old data until the refresh finishes, at which point they will see the new data.
Justin
Distributed Database Consulting, Inc.
http://www.ddbcinc.com/askDDBC

Erro perforing Fast Refresh of Materialized View.

Hi Experts,
We are facing serious problem while refreshing materialized views using fast refresh option in ORACLE..
For the very first time we are performing Complete refresh of data from DB1 to DB2 for few tables.Ongoing we are performing Fast Refresh.
Sometimes the fast refresh works fine without any error and sometimes it fails with the below error.
ERROR at line 1:
ORA-32320: REFRESH FAST of "CIR"."C_BO_COMM" unsupported after cointainer table
PMOPs
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 803
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 860
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 841
ORA-06512: at line 1we came to know the folowing.
// *Cause:
A Partition Maintenance Operation (PMOP) has been performed on the materialized view,
and no materialized view supportsfast refersh after container table PMOPs.
// *Action:
               Use REFRESH COMPLETE.
     Note:
               you can determine why your materialized view does not support fast refresh after PMOPs using
               the DBMS_MVIEW.EXPLAIN_MVIEW() API.Please let u know what action to be taken to avoid this.
Please note that this error is not repeated always. Some times REFRESH FAST is happening and some times it is throwing error.
Appreicate your earliest reply.
Thank you.
Edited by: User71408 on Sep 4, 2008 11:40 PM
Edited by: User71408 on Sep 4, 2008 11:43 PM
Edited by: User71408 on Sep 5, 2008 12:38 AM

9i doesn't support fast refresh after truncate. Read the metalink note 275325.1
You should be sure no truncate has been executed, or use complete refresh.
Nicolas.

How to create one procedure which can drop and create materialized view

Hi,
I want to create one pl/sql procedure which can first drop materialized view CATEGORY_PK and after that create same materialized view CATEGORY_PK.
programme is as follows:
DROP MATERIALIZED VIEW CATEGORY_PK;
CREATE MATERIALIZED VIEW CATEGORY_PK REFRESH FORCE WITH PRIMARY KEY AS
SELECT cav1.ownerid AS categoryid, p.uuid AS productid ,p.domainID AS productdomainid,pav.stringvalue AS NAME
     ,pav2.stringvalue AS ID, pav3.stringvalue AS SHORT
FROM product p, product_av pav, catalogcategory_av cav1, catalogcategory_av cav2,product_av pav2,product_av pav3
WHERE
cav1.NAME = 'PRODUCT_BINDING_ATTRIBUTE' AND
cav2.NAME = 'PRODUCT_BINDING_VALUE' AND
cav1.ownerid = cav2.ownerid AND
p.uuid = pav.ownerid AND
          p.uuid = pav2.ownerid AND
          p.uuid = pav3.ownerid AND
pav.NAME = cav1.stringvalue AND
          pav2.NAME = cav1.stringvalue AND
          pav2.NAME = cav1.stringvalue AND
pav.stringvalue = cav2.stringvalue AND
          pav2.stringvalue = cav2.stringvalue AND
          pav3.stringvalue = cav2.stringvalue
UNION
SELECT catalogcategoryid AS categoryid, productid, repdomainid AS productdomainid,pav1.stringvalue AS NAME
     ,pav2.stringvalue AS ID, pav3.stringvalue AS SHORT
FROM productcategoryassignment ,product_av pav1,product_av pav2,product_av pav3
     WHERE pav1.ownerid=productid
     AND pav2.ownerid=productid
     AND pav3.ownerid=productid
     AND pav1.NAME='name'
     AND pav2.NAME='productID'
     AND pav3.NAME='shortDescription';

user498566 wrote:
I want to create one pl/sql procedure which can first drop materialized view CATEGORY_PK and after that create same materialized view CATEGORY_PK.That sounds like a waste of time and resources. What do you hope to achieve by this? A refresh? If so, a simple refresh of the old materialized view will do.
If you truly want to continue this road, you'll have to use the EXECUTE IMMEDIATE command to execute DDL commands from within PL/SQL.
Regards,
Rob.

Monitoring materialized view replication

Hi.
I have set up a materialized view replication (FAST with 5 minutes interval for refresh). Sometimes the child node can't reach the master node. Where can I monitor this behaviour? I found views (deftran, deferror,...) - but there is nothing in it. The information that the master isn't reachable is written into the child's alert file but for a normal user this isn't enough.
So where can I look into for errors?
Thanks
Markus

You could use dba_snapshot_refresh_times to find last refresh time of your snapshots.
If this is not enough you must write you own procedure that check if master is reacheable or not. And write this info to table. Run this procedure as a job.

Materialized view acting weirdly

Hi everyone,
I have a weird behavior with a materialized view.
Let's suppose, I have a base table defined as
CREATE TABLE TEST
NAME VARCHAR2(100)
)And a MView defined on that table. If I
alter table TEST modify column name varchar2(255)and I dbms_mview.refresh my view, the datatype in the mview is not updated. Can anyone tell me why? It's basically a view, why isn't it refresh?
Thanks for your advice,

Sorry to bother you again,
But why do you say I don't need to refresh the datatypes?
I mean, if I create a materialized view on a base table with a field of varchar2(10). Then, later, I put a size of 100. When the materialized view will refresh after the size has grown, I guess the data will be truncated to 10. And I don't want that. So, somehow, I need to refresh the datatypes.
If the only way to do that is deleting an then recreating the mview, it's ok for me :-)
Thanks,

Materialized View big and empty after full refresh

Background:
Database 10.2.0.4 running on Windows 2003 Server R2 SP2.
Materialized view MV_A, selects from 3 base tables, 2 of which are partitioned, fast refresh on demand, approx 33 million rows. Initially populated with a complete refresh of 31 million rows about 2 months ago, and fast refreshed every 10 seconds since then.
Problem: Performed a partition split on one of the base tables and received this error on the next fast refresh:
ORA-32313: REFRESH FAST of "CUR"."MV_A" unsupported after PMOPs
Docs say a complete refresh is required.
So, created a new copy of the materialized view "MV_B", same storage params, same mview SELECT, same schema.
Did a complete refresh, the extents grew to the expected 10GB combined size. The DBMS_MVIEW.REFRESH reported 'PL/SQL procedure successfully completed' but the MVIEW is empty.
23:01:26 SQL> exec DBMS_MVIEW.REFRESH('MV_B','C','',FALSE,FALSE,0,0,0,TRUE) /* Complete */;
PL/SQL procedure successfully completed.
07:56:46 SQL> commit;
Commit complete.
08:17:51 SQL> select count(*) from mv_b;
COUNT(*)
0
08:19:39 SQL>
Since the MVIEW table MV_B added 10 GB worth of extents during the refresh, it appears that the rows were inserted but then for some reason were rolled back. Nothing unusual in the alert.log. If I execute the MVIEW select statement by itself in SQLPlus, yes, I do get rows back.
The tablespaces housing the MVIEW table as well as the temporary and undo tablespaces are set to autoextend/unlimited to make sure they are not an issue.
Next I dropped and recreated the materialized view MV_B, identical except an added condition to the WHERE clause so that the number of rows returned is only 7 million instead of 33 million and that works fine - a complete refresh populates it and subsequent fast refreshes work correctly.
I'm stumped. Any ideas? Could we be running out of some memory resource that when exhausted, is not trapped properly by Oracle as an error?
- Tom

Is the MV and the source tables on the same database? If this is a remote MV, then check the source site if there are any issues (TEMP, UNDO space issues).

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.

MLOGS not purge after a fast refresh (Materialized view) ...

Hi,
I have a database on my own site (Quebec) that has 36 materialized views refresh by a master table site that is physically at Montreal. The MVIEWs are refreshed every day of the week (monday to friday) at 7h00 until 19h00. We use the "fast refresh" technic to refresh the materialized views.
Last weekend, I transfered this database on a new server. So, I created a new SID (I rename the old SID "ORCL" by "ATQP") and I created this instance with a DB_BLOCK_SIZE of 16k rather than 8k. It's the only difference between the two instances (the old one and the new one). I also created the owner schema "ATQP" and I made an Export on the old server followed by an Import of the schema that owned the Materialized views (not a Full import) on the new server. The export was made many hours (saturday morning) after the last refresh of the week (friday, at 19h00) on the old server.
After the successul import on my new server, I'm looking for the information about the creation of the MVIEW. Everything seems OK. I can see that the last refresh date indicated "2008-02-22 19:00" (date / time of the last refresh of the week). I made a quick test on a small MVIEW (a fast refresh) and it worked, no error.
Yesterday morning, the DBA of the master table site mentionned us that the DELETE on the MLOGS didn't work on the master site. The refresh was made successfully but the MLOGS continue to grow up, again and again ... On my database, I'm looking in the SYS.SNAP$ table and I saw that the SNAPTIME date is '1950-01-01 12:00' rather than '2008-02-25 19:00'. In the SYS.SNAP_REFTIME, the SNAPTIME is OK but the LOADERTIME column contains the same strange date '1950-01-01 12:00'.
I made a quick check on my old server and the SYS.SNAP$ table is empty !!! I think it's normal because the last refresh on this node was made last friday night and I made the transfert last saturday (I shutdown the old database after).
I know how to solve the problem, by recreate the MVIEW, but it causes a big problem for us. We are in PRODUCTION and we don't want to refresh many millions of records. I think it will take a couple of days to refresh all the materialized views of my schema. And it doesn't sound good by the master table site management team ...
The master table site "rush" us to solve the problem before the weekend. They don't want that we overcharge the network link between them and us by refreshing those MVIEWS.
So, is it possible to make something simple to resynchronized the SNAPTIME date without refreshing completely all the materialized views ?
If the master site table recreate the MLOG (purge manually), is it possible that it will solve our problem ?
Is it also possible to recreate the MVIEW without refreshing the data (specify to Oracle to recreate the MVIEW but indicate that the table associated already exist) ?
All of my materialized view are up to date concerning the data. I don't want to refresh all of it.
Thank's in advance ...

Hi Justin,
The DBA of the master table site sent me a email about the fact he unregistered the MVIEW. He told me that the script for the unregistered worked well. He tried to purge the MLOG and he got the error ORA-23424 but I think it's normal (It's what you said yesterday about the fact that the UNREGISTER command also purge the MLOGS).
So, it seems that the MLOGS are still not purged (that's what the DBA of the master table site said). I ran the following query:
SQL> select * from [email protected];
LOG_OWNER MASTER LOG_TABLE LOG_TRIGGER ROW PRI OBJ FIL SEQ INC
ATQ ALIAS_ANILOTS MLOG$_ALIAS_ANILOTS NO YES NO YES NO YES
ATQ ALIAS_INTERVENANTS MLOG$_ALIAS_INTERVENANTS NO YES NO YES NO YES
ATQ ANILOTS MLOG$_ANILOTS NO YES NO YES NO YES
ATQ CATEGORIES MLOG$_CATEGORIES NO YES NO YES NO YES
ATQ CODES_POSTAUX MLOG$_CODES_POSTAUX NO YES NO YES NO YES
ATQ COMMANDES MLOG$_COMMANDES NO YES NO YES NO YES
ATQ COMMUNICATIONS MLOG$_COMMUNICATIONS NO YES NO YES NO YES
ATQ DEPLACEMENTS MLOG$_DEPLACEMENTS NO YES NO YES NO YES
ATQ DETAILS_STATUTS_COMMANDES MLOG$_DETAILS_STATUTS_COMM NO YES NO YES NO YES
ATQ DOMAINES MLOG$_DOMAINES NO YES NO YES NO YES
ATQ ENREGISTREMENT_LOGS MLOG$_ENREGISTREMENT_LOGS NO YES NO YES NO YES
ATQ ENREGISTREMENT_NOTES MLOG$_ENREGISTREMENT_NOTES NO YES NO YES NO YES
ATQ ESPECES MLOG$_ESPECES NO YES NO YES NO YES
ATQ EVENEMENTS MLOG$_EVENEMENTS NO YES NO YES NO YES
ATQ EVENE_DIFFERES MLOG$_EVENE_DIFFERES NO YES NO YES NO YES
ATQ IDENTIFIANTS MLOG$_IDENTIFIANTS NO YES NO YES NO YES
ATQ INTERVENANTS MLOG$_INTERVENANTS NO YES NO YES NO YES
ATQ INTERVENANTS_CLIENTS MLOG$_INTERVENANTS_CLIENTS NO YES NO YES NO YES
ATQ INTERVENANTS_SITES MLOG$_INTERVENANTS_SITES NO YES NO YES NO YES
ATQ MAX_EVENE_DIFFERES MLOG$_MAX_EVENE_DIFFERES NO YES NO YES NO YES
ATQ MESSAGES MLOG$_MESSAGES NO YES NO YES NO YES
ATQ MUNICIPALITES MLOG$_MUNICIPALITES NO YES NO YES NO YES
ATQ NEW_ANILOTS MLOG$_NEW_ANILOTS NO YES NO YES NO YES
ATQ NEW_EVENEMENTS MLOG$_NEW_EVENEMENTS NO YES NO YES NO YES
ATQ NEW_IDENTIFIANTS MLOG$_NEW_IDENTIFIANTS NO YES NO YES NO YES
ATQ NEW_SITES MLOG$_NEW_SITES NO YES NO YES NO YES
ATQ PAYS MLOG$_PAYS NO YES NO YES NO YES
ATQ PRODUCTIONS MLOG$_PRODUCTIONS NO YES NO YES NO YES
ATQ PROPRIETES_ANILOTS MLOG$_PROPRIETES_ANILOTS NO YES NO YES NO YES
ATQ PROVINCES MLOG$_PROVINCES NO YES NO YES NO YES
ATQ SITES_EXPLOITATIONS MLOG$_SITES_EXPLOITATIONS NO YES NO YES NO YES
ATQ TYPES_IDENTIFIANTS MLOG$_TYPES_IDENTIFIANTS NO YES NO YES NO YES
ATQ UTILISATEURS MLOG$_UTILISATEURS NO YES NO YES NO YES
ATQ VALEURS MLOG$_VALEURS NO YES NO YES NO YES
ATQ VALEURS_DETAILS MLOG$_VALEURS_DETAILS NO YES NO YES NO YES
ATQ VEHICULES MLOG$_VEHICULES NO YES NO YES NO YES
36 ligne(s) sélectionnée(s).
SQL>
I supposed that is the result of the MLOG of the MVIEW associated with my new server. How can I be sure that the MLOG associated with the old one are really deleted ?
Thank you

Materialized View Log not empty

Hello all
I have an oracle database (11g version), connecting via dbLink to another DB (10g version), and using it's tables as masters for fast refresh materialized views.
To make it simple: I have master DB, with master table X, and Materialized View Log MLOG$_X.
Then, I have replicate DB, with dblink pointing to Master, and Materialized View MV_X, using X.
The materialized view is refreshed fast, on demand.
The problem is, the MV log is never getting empty... how can I solve this issue?
/* code for creating MView */
CREATE MATERIALIZED VIEW "MY_USER"."SI_BANK" ("ID", "NAME", "ACRONYM")
ORGANIZATION HEAP PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
STORAGE(INITIAL 163840 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
TABLESPACE "USERS"
BUILD IMMEDIATE
USING INDEX
REFRESH FAST ON DEMAND START WITH sysdate+0 NEXT SYSDATE + 1
WITH PRIMARY KEY USING DEFAULT LOCAL ROLLBACK SEGMENT
USING ENFORCED CONSTRAINTS DISABLE QUERY REWRITE
AS SELECT ibanco id, nbanco name, nsigla acronym FROM USER.tgtbanc0@DB_LINK;
/* code for refresh group*/
BEGIN
DBMS_REFRESH.MAKE ( name => 'si2p_grp',
list => '', next_date => 'SYSDATE +1' , interval => 'SYSDATE + 1', implicit_destroy => FALSE, rollback_seg => '', push_deferred_rpc => TRUE, refresh_after_errors => FALSE);
END;
/* ADD MATERIALIZED VIEWS TO GROUP */
BEGIN
DBMS_REFRESH.ADD ( name => 'si2p_grp', list => 'SI_BANK', lax => TRUE);
END;
Thank you for any help

One MV log serve to many materialized views. Check dba_registered_mviews on master DB to see how many MViews you have build on you master table X.
After MV (materialized view) is refreshed than all data logged in MVlog for this MV are deleted. But new are recorded when DML are performed against table X.
If you can stop DML on table X for some period of time then do MV refresh and then you can see that MVlog is empty.

Materialized View to be run every 1 minute through dbms_scheduler

Hi,
I have a materialized view on 1 database which has its select statement going across a database link to numerous tables on another database.
The materialized view creates fine and when refreshed using dbms_snapshot refreshes without error.
My requirement is to automate this refresh for every minute. I have created a job through dbms_scheduler for the refresh to happen every minute but it fails with the error message
ORA-12008: error in materialized view refresh path
I have ctreated another materialized view on the database which does not go across a dblink and scheduled this though dbms_scheduler for every minute, this works fine.........
So it appears my issue is the selecting from tables across a dblink.
Does any one have any experience of this area, how to resolve this issue or maybe an alternative solution than dbms_scheduler?
Thanks in advance.
Mark.

How is your database link defined?
Is it using a fixed user? i.e create database link .... identified by xxxxx
I think it needs to be to be used in a scheduled job.
Carl

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);

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)

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.

Materialized view is empty after 5 minutes

Similar Messages

Maybe you are looking for