Fast refersh materialized view having group by in it's select query

Hi,
Can any one please tell me from which version of Oracle we can create a fast refresh materialized materialized view having group by in it's select query.
Regards,
Koushik

i dont know from which version this feature is started but I know that
in 9i it works and we implemented for DWH projects

Similar Messages

  • Error While Creating Fast Refresh Materialized view.

    Table Scripts:
    CREATE TABLE CONTRACT_MASTER
      CONTRACT_SEQ                    NUMBER(10)    NOT NULL,
      PDN                             CHAR(5)       NOT NULL,
      APPID                           NUMBER(10)    NOT NULL,
      CONTRACT_LOB_DESC               VARCHAR2(20)  NOT NULL,
      CUSTOMER_NAME                   VARCHAR2(57)  NOT NULL,
      CONTRACT_DT                     DATE          NOT NULL,
      CONTRACT_RECD_DT                DATE          NOT NULL,
      HELD_OFFERING_DT                DATE          NOT NULL,
      DRAFT_AMT                       NUMBER(15,2)  NOT NULL,
      STATUS_DESC                                   VARCHAR2(20)  NOT NULL,
      GIF_UPLOAD_TM                                            TIMESTAMP     NOT NULL
    CREATE table CONTRACT_COMMENTS
      CONTRACT_COMMENTS_SEQ           NUMBER(10)     NOT NULL,
      APPID                           NUMBER(10)     NOT NULL,
      COMMENTS                        VARCHAR2(1000) NOT NULL,
      GIF_UPLOAD_TM                                            TIMESTAMP      NOT NULL
    Constraints on tables
    ALTER TABLE CONTRACT_MASTER ADD
      CONSTRAINT XPKCONTRACT_MASTER PRIMARY KEY (CONTRACT_SEQ) USING INDEX ;
    ALTER TABLE CONTRACT_COMMENTS ADD
      CONSTRAINT XPKCONTRACT_COMMENTS PRIMARY KEY (CONTRACT_COMMENTS_SEQ) USING INDEX ;
    alter table CONTRACT_MASTER add CONSTRAINT XUIAPPCONTRACT_MASTER UNIQUE (APPID) USING INDEX;
    CREATE INDEX XUIAPPCONTRACT_COMMENTS ON
    CONTRACT_COMMENTS(APPID) ;
    Materialized View Creation:
    CREATE MATERIALIZED VIEW LOG ON CONTRACT_MASTER WITH PRIMARY KEY,ROWID;
    CREATE MATERIALIZED VIEW LOG ON CONTRACT_COMMENTS WITH PRIMARY KEY, ROWID;
    CREATE MATERIALIZED VIEW MV_CONTRACT_COMMENTS_HELDOFFERING
    REFRESH FAST
    ENABLE QUERY REWRITE AS
    SELECT APPID,COMMENTS FROM CONTRACT_COMMENTS  WHERE APPID IN (
    SELECT APPID FROM CONTRACT_MASTER WHERE STATUS_DESC = 'Held Offering' )
    Errors generated:
    ERROR at line 4:
    ORA-12015: cannot create a fast refresh materialized view from a complex query
    _*Afer That I have changed the query but still it was not created like:*_
    CREATE  MATERIALIZED VIEW MV_CONT_COMMNTS_HELDOFFERNG
    REFRESH FAST
    ENABLE QUERY REWRITE AS
    SELECT CONTRACT_COMMENTS_SEQ,c.APPID,COMMENTS
    FROM CONTRACT_COMMENTS c,CONTRACT_MASTER  m 
    WHERE m.APPID = c.APPID and m.STATUS_DESC = 'Held Offering'
    *even though error displayed:
    SQL> CREATE  MATERIALIZED VIEW MV_CONT_COMMNTS_HELDOFFERNG*
       2  REFRESH FAST
       3  ENABLE QUERY REWRITE AS
       4  SELECT CONTRACT_COMMENTS_SEQ,c.APPID,COMMENTS
       5  FROM CONTRACT_COMMENTS c,CONTRACT_MASTER  m
       6  WHERE m.APPID = c.APPID and m.STATUS_DESC = 'Held Offering';
    FROM CONTRACT_COMMENTS c,CONTRACT_MASTER  m
    ERROR at line 5:
    ORA-12052: cannot fast refresh materialized view GSSIO.MV_CONT_COMMNTS_HELDOFFERNG
    *Again I have done "Analyzing Materialized Views for Fast Refresh" as follows:*
    1: exec dbms_mview.explain_mview('MV_CONT_COMMNTS_HELDOFFERNG');
    2: SELECT capability_name,  possible, SUBSTR(msgtxt,1,60) AS msgtxt
               FROM mv_capabilities_table
               WHERE capability_name like '%FAST%';
    Output is :
    CAPABILITY_NAME                               P              MSGTXT                                                            
    REFRESH_FAST                                   N                                                                   
    REFRESH_FAST_AFTER_INSERT            N  the SELECT list does not have the rowids of all the detail t      
    REFRESH_FAST_AFTER_ONETAB_DML   N  see the reason why REFRESH_FAST_AFTER_INSERT is disabled          
    REFRESH_FAST_AFTER_ANY_DML         N  see the reason why REFRESH_FAST_AFTER_ONETAB_DML is disabled      
    REFRESH_FAST_PCT                            N  PCT is not possible on any of the detail tables in the mater      
    Please suggest what to do to implement fast refresh materialized view for same.Edited by: dba on Sep 20, 2010 12:00 AM

    If the two MVs have to be consistent with each other as of a specific time, put them into a Refresh Group and refresh them with DBMS_MVIEW.REFRESH
    If an MV is dependent on another, use DBMS_MVIEW.REFRESH_DEPENDENT
    See the "Oracle® Database PL/SQL Packages and Types Reference" documentation pages for DBMS_MVIEW.
    Hemant K Chitale
    http://hemantoracledba.blogspot.com --- this is NOT a documentation site.
    Edited by: Hemant K Chitale on Sep 20, 2010 5:19 PM

  • 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

  • Creation of fast refresh materialized view

    Hi,
    I am creating fast refreshable materialized view.At that time i am getting error message
    ORA-12052: cannot fast refresh materialized view OPS$QDW.EMP_DEPT_MV
    I created log's also on that tables(emp,dept)
    Please Help me any body.
    I am using oracle 8.1.7.4.0
    below the scripts i created
    CREATE MATERIALIZED VIEW LOG ON emp
    tablesspace vijay_test
    WITH ROWID
    INCLUDING NEW VALUES
    CREATE MATERIALIZED VIEW LOG ON DEPT
    tablesspace vijay_test
    WITH ROWID
    INCLUDING NEW VALUES
    CREATE MATERIALIZED VIEW emp_dept_mv
    TABLESPACE vijay_test
    BUILD IMMEDIATE
    REFRESH FAST
    ENABLE QUERY REWRITE
    as
    select e.ename,e.empno,e.deptno,d.loc from emp e, dept d
    where e.deptno=d.deptno

    It will be possible to create a Materialised view with up to 20 tables, but you have to understand the restrictions on complex Materialised views with regards to fast refresh.
    To help your understanding, refer to Materialized View Concepts and Architecture
    <br>
    Oracle Database FAQs
    </br>

  • ORA-12015: cannot create a fast refresh materialized view from a complex qu

    BANNER
    Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
    PL/SQL Release 11.2.0.1.0 - Production
    CORE    11.2.0.1.0      Production
    TNS for Linux: Version 11.2.0.1.0 - Production
    NLSRTL Version 11.2.0.1.0 - ProductionI'm trying to create a fast refresh materialized view that uses a column of xmltype. The problem is I cannot create an MV log that accounts for the xmltype column. I tried excluding it and got the above error. Is there another way I can incrementally update a materialized view where I don't have to do a COMPLETE refresh or use FAST refresh?
    CREATE TABLE "DAS_DESC"."AUTHORITY_TEST"
        "NAID"      NUMBER(20,0) NOT NULL ENABLE,
        "AUTH_TYPE" VARCHAR2(40 BYTE),
        "XML_DATA" "SYS"."XMLTYPE" ,
        "TERM_NAME" VARCHAR2(4000 BYTE)
    CREATE TABLE "DAS_DESC"."AUTH_ASSC_TEST"
        "NAID"    NUMBER(20,0),
        "P_NAID" NUMBER(20,0),
        "REL_TYPE"    VARCHAR2(25 BYTE),
        "XML_DATA" "SYS"."XMLTYPE"
    CREATE
    MATERIALIZED VIEW person_mv
    AS
    SELECT  p.naid
          , p.auth_type
          , INSERTCHILDXML
              p.xml_data                 -- Parent XML Column
            , '//*[contains(local-name(), ''person'')]' --XPATH to Person
            , 'nonPreferredHeadingArray'                -- Value for new child element
            (                                                       -- Sub query for injecting new variant person array
              SELECT XMLELEMENT
                "nonPreferredHeadingArray"
              , XMLAGG -- Aggregator for Variant Persons Array
                  XMLELEMENT
                    "variantPersonName"                    -- Wrapper for each entry in array
                  , extract(a.xml_data,'*/*')
              FROM auth_assc_table -- Link table
              WHERE a.p_naid = p.naid
          ) AS XML_DATA
    FROM authority p -- Parent table
    WHERE p.auth_type = 'Person';The views are created fine and they work perfectly for what we need. The problem is the refresh when we edit the base tables. Ideally, it should take a couple seconds. Right now, it takes a couple minutes. XMLTYPE is one problem and the Complex Query exception is the other. If there is a work-around for fast refresh, please let me know. Greatly appreciated.

    jjmdb wrote:
    I'm trying to create a fast refresh materialized view that uses a column of xmltype. The problem is I cannot create an MV log that accounts for the xmltype column. I tried excluding it and got the above error. Is there another way I can incrementally update a materialized view where I don't have to do a COMPLETE refresh or use FAST refresh? Besides XMLTYPE column, your MV definition has a subquery which prevents it from being fast refreshable.
    I could not find any specific reference in documentation about restriction on XMLTYPE (or CLOB) columns but it seems logical that oracle will not be able to keep track of changes to binary data. What does DBMS_MVIEW.EXPLAIN_MVIEW generate for your MV definition? That should tell you which all conditions (for FAST REFRESH) your MV violates. Since you can not create a MV LOG to include XMLTYPE column, it will not be possible to create a FAST REFRESHABLE MV that includes the XMLTYPE column.
    I am afraid there is not much you can do here unless you are prepared to change the way data is stored in your base tables. If you can store data in base tables using standard data types instead of binary/XML storage, you might be able to create a FAST REFRESHABLE MV.

  • ORA-12015:  cannot create a fast refresh materialized view from a complex q

    Hi,
    I'm facing very strange problem. Please help me why this error is coming
    I'm creating a simple materialized view, but it is giving below error since this is simple select * from.
    CREATE MATERIALIZED VIEW EFMS.MS_TASK
    BUILD IMMEDIATE
    REFRESH FAST
    START WITH SYSDATE
    NEXT (SYSDATE + 1/24)
    WITH ROWID
    AS
    SELECT * FROM MS_TASK@efms_link;
    SELECT * FROM MS_TASK@efms_link
    ERROR at line 8:
    ORA-12015: cannot create a fast refresh materialized view from a complex query
    CREATE MATERIALIZED VIEW LOG ON MSDBO.MS_TASK
    TABLESPACE DBOR_MVLOG
    PCTUSED 0
    PCTFREE 60
    INITRANS 20
    MAXTRANS 255
    STORAGE (
    INITIAL 64K
    MINEXTENTS 1
    MAXEXTENTS UNLIMITED
    PCTINCREASE 0
    BUFFER_POOL DEFAULT
    NOCACHE
    NOLOGGING
    PARALLEL ( DEGREE 2 INSTANCES 1 )
    WITH ROWID, PRIMARY KEY
    EXCLUDING NEW VALUES;


    Not is a best practice to use 'select *'

    ORA-12015: cannot create a fast refresh materialized view from a complex query
    Cause:      Neither ROWIDs and nor primary key constraints are supported for complex queries.
    Action:      Reissue the command with the REFRESH FORCE or REFRESH COMPLETE option or create a simple materialized view.
    Then you have to change REFRESH FAST or create a primary key in MS_TASK@efms_link to avility fast refresh.
    . :-) any help with my english is wellcome :-) .

  • ORA-12015: cannot create a fast refresh materialized view from a complex

    Hi All,
    I am trying to create materialized view but i got a error ORA-12015: cannot create a fast refresh materialized view from a complex query.
    Regards,
    narayana

    Hi,
    Please see if (Note: 179466.1 - Diagnosing ORA-12015 fast refresh materialized view / complex queries) helps.
    Regards,
    Hussein

  • Fast Refresh Materialized view on a 'View'

    Hi,
    I am trying to create a materialized view with Refresh FAST option. This is based on a view. I am getting an error that there is no materialized view log on the table. But we cannot create a materialized view log on a view. Can you please let me know how to create a FAST REFRESH materialized view on a view.
    Thanks!

    Thanks Justin! Actually, I have a remote database on which I want the copy of one of our tables. We have a view on this table on the source database with meaningful names. I have created materialized view logs on the underlying table. If I am able to create a MV on the view, then I need not write that extra step to code for meaningful names. I wanted to know if a fast refresh is possible on a view (There are materialized view logs on the underlying table)?
    Thanks!

  • Alternative for OUTER Join for use in fast refresh materialized view

    Hi ,
    I have two tables as :
    CREATE TABLE TEST_SANDY1
    COL1 NUMBER
    CREATE TABLE TEST_SANDY2
    COL1 NUMBER,
    COL2 VARCHAR2(10 BYTE)
    Data for the tables are :
    INSERT INTO TEST_SANDY1 ( COL1 ) VALUES (
    1);
    INSERT INTO TEST_SANDY1 ( COL1 ) VALUES (
    2);
    INSERT INTO TEST_SANDY1 ( COL1 ) VALUES (
    3);
    COMMIT;
    INSERT INTO TEST_SANDY2 ( COL1, COL2 ) VALUES (
    1, 'a');
    INSERT INTO TEST_SANDY2 ( COL1, COL2 ) VALUES (
    2, 'b');
    INSERT INTO TEST_SANDY2 ( COL1, COL2 ) VALUES (
    4, 'd');
    COMMIT;
    Now when I run the following select statement :
    select
    b.col1
    from
    test_sandy1 a,
    test_sandy2 b
    where
    b.COL1 = a.COL1(+)
    I get :
    COL1
    1
    2
    4
    I want to build a materialized view to generate the same values but it has to be fast refresh. But since I am using outer join I am unable to create a fast refresh one.
    Can someone suggest an alternate select to create fast refresh materialized view.
    Thanks,
    Sandipan

    The select statement was not fitting my problem , so I'll change it as :
    select
    a.col1, nvl(b.col2, 'DEFAULT')
    from
    test_sandy1 a,
    test_sandy2 b
    where
    b.COL1(+) = a.COL1
    I get :
    COL1     VAL
    1     a
    2     b
    3     DEFAULT
    How do I this ?

  • How Fast is the Fast Refreshed Materialized View ?

    Hi all,
    In our Front End aplication we have two big view :
    V_ALL_TRANS -> this is UNION ALL on about 10 transaction tables
    V_SUMM_TRANS -> this query with SUM & GROUP BY on V_ALL_TRANS.
    We are having performance problem on V_SUMM_TRANS, I am thinking of making V_ALL_TRANS as materialized view.
    The requirement is : every INSERT on the transaction tables ( and some tables with INSERT & UPDATE) will "immediately reflected" in V_ALL_TRANS.
    Is this a possible approach ?
    How "immediate" the refreahed will be done by oracle ?
    Thank you very much for your help,
    xtanto

    hi,
    Of course this is a possible approach.
    I think we have a time that which we can keep with for ther refresh in materialized views.
    but using that may become yet another cause of concern because ur front end may experience performance problems if all the time refresh is going on thru materialized views.
    Maybe you can time the refreshes to happen at nigh when the user usage is very low..

  • Create Materialized View with GROUP BY

    I have a table
    treecluster NUMBER(3)
    treenumber NUMBER(3)
    treedate DATE
    nestnumber NUMBER(3)
    eggs NUMBER(3)
    nestlings NUMBER(3)
    fledglings NUMBER(3)
    nestfate VARCHAR2(10)
    nestfailurecode NUMBER(2)
    I want to group the data by treecluster, treenumber, year, and nest number and get a max eggs, nestlings, fledglings. I am doing this with the following:
    SELECT treecluster, treenumber, to_char(nestchecksdate, 'YYYY'), nestnumber,
    max(eggs), max(nestlings), max(fledglings)
    FROM nestchecks
    GROUP BY treecluster, treenumber, to_char(nestchecksdate, 'YYYY'), nestnumber;
    This works fine.
    The last record for a year has a nestfate and nestfailurecode value.
    I need to group all information and then also get the nestfate and nestfailurecode for the year. How do I go about getting this information?
    I am really trying to create a summary materialized view based on a data table so the select I am trying to craft would be a part of a create materialized view as SELECT...
    so I want to be able to group the info and add in the nestfate and failurecode in one step.
    Thanks!

    try this:
    SQL> select * from table_tree;
    TREECLUSTER TREENUMBER NESTCHECK NESTNUMBER       EGGS  NESTLINGS FLEDGLINGS NESTFATE   NESTFAILURECODE
              4        167 17-MAY-00          2          0          0
              4        167 24-MAY-00          2          3          0
              4        167 30-MAY-00          2          3          0
              4        167 12-JUN-00          2          0          1            FAILURE                  2
    select a.treecluster, a.treenumber, to_char(a.nestyear,'YYYY') nestyear,
           a.nestnumber, a.eggs, a.nestlings, a.fledglings, a.nestfate, a.nestfailurecode
    from   (select max(treecluster) treecluster, max(treenumber) treenumber,
                   max(nestchecksdate) nestyear,
                   max(nestnumber) nestnumber, max(eggs) eggs, max(nestlings) nestlings,
                   nvl(max(FLEDGLINGS),0) FLEDGLINGS, max(NESTFATE) NESTFATE,
                   max(nestfailurecode) nestfailurecode
            from table_tree) a
    TREECLUSTER TREENUMBER NEST NESTNUMBER       EGGS  NESTLINGS FLEDGLINGS NESTFATE   NESTFAILURECODE
              4        167 2000          2          3          1          0 FAILURE                  2hope this helps

  • Fast Refresh Materialized View - failure

    Okay, this issue currently has me stumped. I searched the world wide web and still cannot seem to identify the cause of this issue.
    Here is the scenario:
    I created a materialized view log for the source table (let's say table1) found at DB1.
    I then create a materialized view (fast refresh, with logging) at a remote database (let's say DB2). The query for the MV is basic: select * from schema1.table1@db1_link;
    I set the materialized view to refresh every 30 seconds (for testing purposes).
    This creates a dbms job that executes every 30 seconds. The materialized view gets created successfully. I purposely enter new data into table1. The materialized view log for table1 successfully captures these changes. However, the materialized view found at DB2 does not get refreshed (updated) successfully.
    In fact, the dbms job errors-out. It keeps failing and failing. After 16 times, it gets marked as 'broken.'
    The error message is as such:
    RDBA WARNING: ORA-12012: error on auto execute of job 1472
    RDBA WARNING: ORA-00604: error occurred at recursive SQL level 3
    RDBA WARNING: ORA-01017: invalid username/password; logon denied
    RDBA WARNING: ORA-02063: preceding line from db1
    RDBA WARNING: ORA-06512: at "SYS.DBMS_SNAPSHOT", line 820
    RDBA WARNING: ORA-06512: at "SYS.DBMS_SNAPSHOT", line 877
    RDBA WARNING: ORA-06512: at "SYS.DBMS_IREFRESH", line 683
    RDBA WARNING: ORA-06512: at "SYS.DBMS_REFRESH", line 195
    RDBA WARNING: ORA-06512: at line 1
    The strange thing is, that the error supposedly claims invalid username/password. But I've used the db links successfully before & the username/password is not invalid. Has anyone encountered this issue before?

    Justin,
    From reading earlier posts about issues with materialized views, I remember reading something about materialized views (fast refreshable) not working with sysdate. What did you mean by such a statement? (I would copy & paste it here, but I am unable to find it at the moment).
    The reason I am curious, is the fact that I am setting my MV to refresh every 30 seconds let's say (for testing). At this moment - it starts failing & failing & failing.

  • Regarding Refresh in Materialized View having Join

    Hi,
    I have created a Materialized View on Primary Key out of a join between a Dimension and Fact Table of a Datawarehouse. Each of these tables contains close to 70 million records.
    I have also created the Materialized View Logs on these two tables 'ON ROWID'.
    Also, there is no explicit 'ROW_ID' column present in both the tables. So, it is also not present in the SELECT Query.
    I used a REFRESH FAST Option and tried refreshing the View manually using the DBMS_MVIEWS Procedure. It gave an error ORA-12052 of unique constraints and missing rowids.
    Can't I use the REFRESH FAST Option if there are no ROWID columns in the Master Tables?
    Could you please let me know the resolution for this problem?
    Many Thanks, Ketan

    Post your version information and the DDL for your MV.
    No table has a ROWID column ... ROWID is a pseudocolumn.

  • Materialized views with GROUP by ROLLUP

    I am trying to created Materialized view (snapshot) using group by rollup functionality.
    The idea is to use snapshot with all subtotals already calculated in place.
    For example average group by rollup (columns of the time dimension).
    The idea is to use "query rewrite" Oracle functionality and snapshot with calculated subtotals.
    Does anybody have experiance with this method ?
    Thank you
    Michael

    The query rewrite is an internal function of Oracle. Normally, you have nothing to do than verify that the query that perform OBIEE is rewrited.
    In any other way, you can in OBIEE define that you have create an aggregate and OBIEE will (re-)write the query.
    http://www.rittmanmead.com/2007/10/26/using-the-obiee-aggregate-persistence-wizard/
    Regards
    Nico

  • 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

Maybe you are looking for