最近发再一个MVLOG大到13G了。

刷新变得异常的慢，删除重新建立方才解决问题。
After I recreated the MV log, I manually ran the reporter partition maintenance - it finished in about 3 minutes.

I found this from an Oracle Note:179469.1 : " If the master table is partitioned, the truncate partition and drop partition operations will also cause the materialized view log to be purged."

The extreme size of the reporter MV log was causing errors on the partition maintenance because the truncate and drop partition statements were trying to purge data from the 13 GB mv log which was taking WAY too long.

refrence:

Subject:	Diagnosing ORA-12004 Refresh Fast Cannot be Used
	Doc ID:	Note:179469.1	Type:	TROUBLESHOOTING
	Last Revision Date:	27-NOV-2007	Status:	PUBLISHED

Overview
========

The purpose of this article is to provide a step by step guide to diagnosing
the following error message, when users are attempting to refresh read only
or updatable materialized views / snapshots :

  ORA-12004: "REFRESH FAST cannot be used for snapshot ..." (in v8.x)
  ORA-12004: "REFRESH FAST cannot be used for materialized view ..." (in v9.x)

   Cause: The materialized view log does not exist or cannot be used.
  Action: Use just REFRESH, which will reinstantiate the entire table.
          If a materialized view log exists and the form of the materialized
          view allows the use of a materialized view log, REFRESH FAST will
          be available starting the next time the materialized view is
          refreshed.

Article Contents
----------------

1. Possible Causes

  1.1 Materialized view does not exist
  1.2 Incorrect Privileges or Database Links
  1.3 Fast refreshable materialized views cannot contain complex queries
  1.4 Rollback / Undo segment space
  1.5 Primary Key and ROWID materialized view logs 
  1.6 Master table truncation
  1.7 Materialized view log contains data prior to last refresh
  1.8 Materialized view uses synonyms or views
  1.9 Special Cases

2. Diagnostic Information

  2.1 Diagnostic Script & Sample Output
  2.2 Using DBMS_VIEW.EXPLAIN_MVIEW to determine if a mv is fast refreshable

3. References

------------------------------------------------------------------------------

1. Possible Causes
================== 

If you have a problem refreshing a materialized view or a materialized view 
group, initially you need to identify if it's a problem associated with an 
automatic refresh or if it's reproducible in a manual refresh too. 

If an automatic refresh fails the errors causing Oracle to consider a job
broken are recorded in a trace file. Prior to Oracle9 the name of materialized
view trace is of the form SNPn, in Oracle9 the name of the materialized view
trace file is of the form Jn, where n is operating system specific.

Check if a manual refresh works.

  - Connect as the materialized view (snapshot) owner or refresh group owner.
  - To refresh a single materialized view:

        exec DBMS_SNAPSHOT.REFRESH (´<snapshot name>', ´F'); 
    or
        exec DBMS_MVIEW.REFRESH ('<mview name>','F');

  - To refresh the refresh group :

        exec DBMS_REFRESH.REFRESH (´<refresh_group_name>');

If the fast manual refresh works, it means the problem lies in the automatic 
refresh. Check the user that executes this job has the correct privileges.

If ORA-12004 occurs this is the full stack:

  ORA-12004: REFRESH FAST cannot be used for snapshot "OWNER"."SNAPSHOT_NAME"
  ORA-06512: at "SYS.DBMS_SNAPSHOT", line 610
  ORA-06512: at "SYS.DBMS_SNAPSHOT", line667
  ORA-06512: at "SYS.DBMS_IREFRESH", line 577
  ORA-06512: at "SYS.DBMS_REFRESH", line 211
  ORA-06512: at line 1

This error can be reported for several reasons:


1.1 Materialized View Log cannot be retrieved
---------------------------------------------

A fast refresh of a materialized view / snapshot can only be performed when
the master table has a materialized view log. If the materialized view contains
a subquery, each table referenced in the subquery should have a materialized
view log. If the materialized view log name doesn't exist on master site fast
refreshes fail with ORA-12004.

In some releases the fast refresh fails with ORA-12031: cannot use primary
key columns from snapshot log on "OWNER"."TABLE", if the snapshot log doesn't
exist on master site.

To verify the existence of the materialized view log, execute at master site:

  select master from user_snapshot_logs;

1.2 Incorrect Privileges or Database Links
------------------------------------------

For a materialized view / snapshot refresh to complete successfully the user
that executes the refresh must have the correct privileges at the materialized
view site and the user their link connects to must have the correct privileges
at the master site. Remember that when the refresh runs as part of a database
job (DBMS_JOB) the refresh runs with the privileges of the jobs LOG_USER at
the snapshot site.

The account that a database link uses to access to the remote database defines
the security context under which Oracle creates and subsequently refreshes a
snapshot. A snapshot must use a database link that includes an embedded user
name and password in its definition. You cannot use a public database link when
creating a snapshot. Refer to the following article for additional information:

Note 121716.1 Troubleshooting Database Links in a Replicated Environment

Typically a single user is responsible for configuring, propagating deferred
transactions and pulling down changes to the snapshot from the associated
master table or master materialized views but you can have different users
performing these functions. For example, materialized views may be created by
a user and refreshed by another user. In addition you also need to determine
which type of security model you will implement: trusted or untrusted. Refer
to the following for additional information:

Note 120093.1 Initial steps required to a create Snapshot Replication 
                  environment v8.1

  Replication Management API Reference. Appendix A: Security Options.

Check if the user that does the refresh is the owner of the snapshot. If the 
refresher is not the owner certain privileges must be granted either explicitly
or through a role: ALTER ANY SNAPSHOT or ALTER ANY MATERIALIZED VIEW.

NOTE: The DBA privilege will not give you the proper privileges you need. 

In addition SELECT object privileges at the master site and on the snapshot log
(untrusted model) or SELECT ANY TABLE system privilege (trusted model), must be
granted to the user at the master or materialized view site to which the user
at the materialized view site connects through a database link.

1.3 Fast refreshable materialized views cannot contain complex queries
----------------------------------------------------------------------

Complex materialized views do not support fast refresh.

If the defining query of a materialized view has been defined as a complex
query (i.e. not a simple query or not a valid subset subquery) then the
materialized view will not be fast refreshable.

Please see the following reference for more information by version concerning what 
constitutes a complex query:

Note 179466.1 Diagnosing ORA-12015 fast refresh materialized view / 
complex queries

1.4 Rollback / Undo segment space
---------------------------------

If ORA-12004 occurs during a materialized view / snapshot refresh, it may
be because you have run out of rollback segment space while the refresh was
trying to maintain the snapshot log.

Fast refreshes of large tables or materialized view logs can make significant
demands on rollback segment space at both the materialized view and master
sites. Check the alert log for any rollback or other errors relating to
resources on both the materialized view and master sites.

From Oracle8 onwards the create and alter snapshot syntax allows you to
specify the rollback segment that will be used at the master site during
a snapshot refresh. The DBMS_REFRESH.REFRESH procedure also allows you to
define the rollback segment that will be used at the materialized view site
during the refresh.

1.5 Primary Key and ROWID materialized view logs 
------------------------------------------------

Prior to Oracle8, when a snapshot was created it would use ROWID's from the
master site to handle fast refreshes. Where as from Oracle8 onwards the
default mechanism for fast refreshing snapshots is WITH PRIMARY KEY. To handle
environments that include Oracle7 which only uses ROWIDs or master tables that
do not have primary keys, Oracle allows snapshots and snapshots logs can be
defined WITH ROWID.

MIXED ENVIRONMENT where your Master Site is Oracle8 and your Snapshot Site is
Oracle7, verify that the snapshot log you created on the Oracle8 Master Site
was created with the ROWID option. In the same way when you have an Oracle7
snapshot, you have to explicitly create the snapshot log WITH ROWID on Oracle8.
If it was created with Primary Key, which is default, you will still receive
an ORA-12004.

At the master site check the log type with :

   SQL> select master, rowids, primary_key from user_snapshot_logs
        where master = '<master_table>';

   MASTER       ROWIDS  PRIMARY_KEY
   ------------ ------- ------------
   master_table NO      YES

If the log does not include ROWIDs you can drop and recreate the snapshot log
(although a complete refresh will be required after this action), alternatively
alter the snapshot log to also log ROWIDs with:

   SQL> alter snapshot log on t1 add rowid;

   SQL> select master, rowids, primary_key from user_snapshot_logs
        where master= '<master_table>';


   MASTER       ROWIDS  PRIMARY_KEY
   ----------   ------- ---------------------
   master_table YES     YES

After migration to Oracle8 all ROWID snapshots must be complete refreshed, if
they are not the next fast refresh will fail with ORA-12004. The following
articles address issues relating to migration:

Note 254593.1 Differences Between Rowid & Primary Key Materialized Views
Note 66465.1  Using offline instantiation to avoid a full Snapshot
                  refresh after Oracle8 Migration

1.6 Master table truncation
---------------------------

In Oracle7 truncating a snapshots master table causes the snapshot log to
be truncated. After log truncation the next snapshot refresh has to be a
complete refresh, attempts to fast refresh return ORA-12004.

From Oracle8 onwards the following statements all cause the materialized view
log to be truncated, as long as the log is defined WITH ROWID, only:

  TRUNCATE TABLE <schema_name>.<table_name>;
  TRUNCATE TABLE <schema_name>.<table_name> PURGE MATERIALIZED VIEW LOG;

From Oracle8 onwards the following statement is required to force the log to
be purged if the materialized view log has been defined with either PRIMARY
KEY or PRIMARY KEY & ROWID:

  TRUNCATE TABLE <schema_name>.<table_name> PURGE MATERIALIZED VIEW LOG;

If the master table is partitioned, the truncate partition and drop partition
operations will also cause the materialized view log to be purged.

Depending on the order that the above actions where performed and the releases
involved you may encounter ORA-12004 or ORA-12034 on a fast refresh at the
snapshot site. To investigate the if this is a likely cause, check the snapshot
log and the sys.slog$ tables:

  SQL> select count(*) from mlog$_<master_table>;

  SQL> select * from sys.slog$ where master = '<master_table>';

The SYS.SLOG$ table holds a record of fast refreshable snapshots, the entry
in this table is removed to force a complete refresh.

Care should be taken when truncating tables that have dependant snapshots. If
the snapshot log is not also purged, the next fast refresh will not fail and
data at the snapshots site will differ from the master site. Unfortunately
TRUNCATE TABLE .... defaults to preserve the contents of the log. You should
only preserve the contents of the snapshot log if you are performing master
table reorganisation with dbms_mview.begin_table_reorganization. 

1.7 Materialized view log contains data prior to last refresh
-------------------------------------------------------------

For a snapshot to be able to fast-refresh the snapshot's identifier (or
creation date) must be present in slog$ at master site and the snapshot's
last refresh time must be later than the oldest entry in the snapshot log.
We need to compare the master sites snapshot log to the snapshot for the 
timestamps to determine the "age" of the snapshot log.

At the master site the SYS.MLOG$ table keeps track of the least recent (OLDEST
or OLDEST_PK column) and most recent (YOUNGEST) refresh times for a particular
master table, SLOG$ table keeps track of the snapshots for a particular master
table based Last refresh time SLOG$.SNAPTIME matches the corresponding column
in SNAP_REFTIME$ at the snapshot site.

ORA-12004 appears when:

  mlog$.oldest at master site > snap_reftime$.snaptime at snapshot site.

Due to Bug 557451 The last_refresh field in the view DBA_SNAPSHOTS was being
created using the snaptime field in sys.snap$. This column is now obsolete and
as a result doesn't get updated after the refresh. Fix was to use last_refresh
from dba_snapshot_refresh_times (snaptime from sys.snap_reftime$).

1.8 Materialized View References Synonyms or Views
------------------------------------------------------------

Fast refreshable materialized views can be created based on master tables and 
master materialized views only. Materialized views based on a synonym or a view 
must be complete refreshed.  This actually is a consequence of the cause 
discussed in Section 1.3.  From 8.1.6 onwards, use of a synonym or a view in 
place of a direct reference to a master table renders the materialized view 
complex, and thus it cannot be fast refreshed.  This can be seen if a direct 
attempt is made to create the materialized view as fast refreshable when it 
references synonyms or views.  The creation will fail with the following error:

	ORA-12015: cannot create a fast refresh snapshot from a complex query

It is also highly recommended to create materialized views with fully qualified 
references to the master tables, i.e. so that they refer to 
"owner"."mastertable".


1.9 Special Case
----------------

If you are sure your environment is set up correctly, but you are still getting
ORA-12004 then you may be encountering the following scenario:

After you have created a materialized view environment with one or more
materialized view sites, you may need to add new materialized view sites. You 
may encounter problems when you try to fast refresh the materialized views you 
create at a new materialized view site if both of the following conditions are 
true: 

- Materialized views at the new materialized view site and existing materialized
  views at other materialized view sites are based on the same master table or
  master materialized view. 

- Existing materialized views can be refreshed while you create the new 
  materialized views at the new materialized view site.

The problem arises when the materialized view logs for the masters are
purged before a new materialized view can perform its first fast refresh.
If this happens and you try to fast refresh the materialized views at the
new materialized view site, then you may encounter ORA-12004 or ORA-12034.

It is due to the column OLDEST_PK (or OLDEST column for ROWID) in the
SYS.MLOG$ table getting a timestamp which is more recent than the creation
time of the snapshot. And, as column SNAPTIME in SYS.SNAP_REFTIME$ is more
recent than the OLDEST column, it assumes that the snapshot log is created
later than the snapshot has been created.

If you receive these errors, then the only solution is to perform a complete 
refresh of the new materialized view. 

To avoid this problem, choose one of the following options: 

a) Use deployment templates to create the materialized view environment 
   at materialized view sites. You will not encounter this problem if you
   use deployment templates. 

b) Create a dummy materialized view at the new materialized view site before
   you create your production materialized views. The dummy materialized view
   ensures that the materialized view log will not be purged while your
   production materialized views are being created.

If you choose to create a dummy materialized view at the materialized view
site, complete the following steps: 

1) Create a dummy materialized view called dummy_mview based on the master 
   table or master materialized view. For example, to create a dummy
   materialized view based on a master table named sales, issue the following
   statement at the new materialized view site: 

     CREATE MATERIALIZED VIEW dummy_mview REFRESH FAST AS 
       SELECT * FROM [e-mail] WHERE 1=0; 

2) Create your production materialized views at the new materialized view 
   site. 

3) Perform a fast refresh of your production materialized views at the new 
   materialized view site. 

4) Drop the dummy materialized view.

The following also cover this issue:

  - Oracle9i Replication. Chapter 4, "Deployment Templates Concepts and 
    Architecture" for information about deployment templates.

  - Note 204127.1 Diagnosing ORA-12034 Materialized View Log Younger
                    than Last Refresh


2. Diagnostic Information
=========================

2.1 Diagnostic Script & Sample Output
-------------------------------------

Use the following script to diagnose the ORA-12004 error, if you are unable
to isolate the problem, supply the output from this script to Oracle Support
Services.

SET term on;
PROMPT
PROMPT  QUERY TO EXECUTE AT MASTER SITE
PROMPT  --------------------------------

PROMPT
COLUMN MASTER HEADING 'Master Table' FORMAT A15
COLUMN MOWNER HEADING 'Owner' FORMAT A6
COLUMN LOG    HEADING 'MVIEW Log' FORMAT A15
COLUMN LAST_REFRESH_TIME  HEADING 'Last Refresh Time|Snaptime' FORMAT A20
COLUMN OLDEST_PK HEADING 'Maximum age of PK |in the log |OLDEST' FORMAT A20
COLUMN OLDEST HEADING 'Maximum age ROWID|in the log|OLDEST' FORMAT A20

PROMPT  FOR PRIMARY KEY SNAPSHOT LOGS. OLDEST_PK IS USED INSTEAD OF OLDEST.

SELECT m.mowner, m.master, m.log,
substr(to_char(s.snaptime,'MON/dd/yyyy hh24:mi:ss'),1,20) Last_Refresh_Time,
substr(to_char(oldest_pk,'MON/dd/yyyy hh24:mi:ss'),1,20) oldest_pk
from sys.mlog$ m, sys.slog$ s
WHERE s.mowner (+) = m.mowner
and s.master (+) = m.master;


PROMPT  FOR ROWID SNAPSHOTS. OLDEST IS USED INSTEAD OF OLDEST_PK.

SELECT m.mowner, m.master, m.log,
substr(to_char(s.snaptime,'MON/dd/yyyy hh24:mi:ss'),1,20) Last_Refresh_Time,
substr(to_char(oldest,'MON/dd/yyyy hh24:mi:ss'),1,20) oldest
from sys.mlog$ m, sys.slog$ s
WHERE s.mowner (+) = m.mowner
and s.master (+) = m.master;


PROMPT
PROMPT  QUERY TO EXECUTE AT SNAPSHOT SITE
PROMPT  ----------------------------------

PROMPT

COLUMN SNAPSHOT HEADING 'Snapshot' FORMAT A15
COLUMN OWNER HEADING 'Snapshot|Owner' FORMAT A8
COLUMN MASTER_OWNER HEADING 'Master|Owner' FORMAT A6
COLUMN LAST_REFRESH HEADING 'Snapshot/Mview|Last Refresh' FORMAT A20
select  substr(owner,1,10) owner, substr(name,1,15) snapshot  ,
substr(master_owner,1,10) master_owner, 
substr(to_char(last_refresh,'MON/dd/yyyy hh24:mi:ss'),1,20) last_refresh
from dba_snapshot_refresh_times;

PROMPT When mlog$.oldest <= dba_snapshot_refresh_times.last_refresh, you can do 
PROMPT a fast refresh.
PROMPT When mlog$.oldest > dba_snapshot_refresh_times.last_refresh, the meaning 
PROMPT is that you CANNOT do a  fast refresh.
PROMPT


Sample output:

In an environment with a master table TEST and two snapshot sites. When
you create the snapshot log MLOG$.OLDEST_PK has the creation date and 
SLOG$.SNAPTIME is null because it has not been refreshed.

                                                            Maximum age of PK
                                       Last Refresh Time    in the log
Owner  Master Table    MVIEW Log       Snaptime             OLDEST
------ --------------- --------------- -------------------- --------------------
SYSTEM TESTS           MLOG$_TESTS                          FEB/05/2002 11:50:09


After creating the snapshot at master site:

                                                            Maximum age of PK
                                       Last Refresh Time    in the log
Owner  Master Table    MVIEW Log       Snaptime             OLDEST
------ --------------- --------------- -------------------- --------------------

SYSTEM TESTS           MLOG$_TESTS     FEB/05/2002 11:56:41 FEB/05/2002 11:56:41


At snapshot site:

Snapshot                 Master Snapshot/Mview
Owner    Snapshot        Owner  Last Refresh
-------- --------------- ------ --------------------
SYSTEM   TESTS           SYSTEM FEB/05/2002 11:56:41


If we create a 2nd snapshot in another snapshot site:

Snapshot                 Master Snapshot/Mview
Owner    Snapshot        Owner  Last Refresh
-------- --------------- ------ --------------------
SYSTEM   TESTS           SYSTEM FEB/05/2002 12:06:58

At master site:

                                                            Maximum age of PK
                                       Last Refresh Time    in the log
Owner  Master Table    MVIEW Log       Snaptime             OLDEST
------ --------------- --------------- -------------------- --------------------
SYSTEM TESTS           MLOG$_TESTS     FEB/05/2002 11:56:41 FEB/05/2002 11:56:41
SYSTEM TESTS           MLOG$_TESTS     FEB/05/2002 12:06:58 FEB/05/2002 11:56:41


After refreshing 1st snapshot:

At snapshot site:

Snapshot                 Master Snapshot/Mview
Owner    Snapshot        Owner  Last Refresh
-------- --------------- ------ --------------------
SYSTEM   TESTS           SYSTEM FEB/05/2002 12:14:21



And at master site:
                                                            Maximum age of PK
                                       Last Refresh Time    in the log
Owner  Master Table    MVIEW Log       Snaptime             OLDEST
------ --------------- --------------- -------------------- --------------------
SYSTEM TESTS           MLOG$_TESTS     FEB/05/2002 11:56:41 FEB/05/2002 11:56:41
SYSTEM TESTS           MLOG$_TESTS     FEB/05/2002 12:14:21 FEB/05/2002 11:56:41



After refreshing 2nd snapshots:

At snapshot site:

Snapshot                 Master Snapshot/Mview
Owner    Snapshot        Owner  Last Refresh
-------- --------------- ------ --------------------
SYSTEM   TESTS           SYSTEM FEB/05/2002 12:18:23



At master site:
                                                            Maximum age of PK
                                       Last Refresh Time    in the log
Owner  Master Table    MVIEW Log       Snaptime             OLDEST
------ --------------- --------------- -------------------- --------------------
SYSTEM TESTS           MLOG$_TESTS     FEB/05/2002 12:18:23 FEB/05/2002 12:14:21
SYSTEM TESTS           MLOG$_TESTS     FEB/05/2002 12:14:21 FEB/05/2002 12:14:21



ORA-12004 can occur if we recreate a snapshot log on the master site and do a
complete refresh of 1st snapshots then:

At master site.
                                                            Maximum age of PK
                                       Last Refresh Time    in the log
Owner  Master Table    MVIEW Log       Snaptime             OLDEST
------ --------------- --------------- -------------------- --------------------
SYSTEM TESTS           MLOG$_TESTS     FEB/05/2002 12:28:14 FEB/05/2002 12:28:14


At 2nd snapshot site, before refreshing:

Snapshot                 Master Snapshot/Mview
Owner    Snapshot        Owner  Last Refresh
-------- --------------- ------ --------------------
SYSTEM   TESTS           SYSTEM FEB/05/2002 12:14:21


In this case, the 2nd is not present in SLOG$ and OLDEST is more recent than 
last refresh snapshot time.

2.2 Using DBMS_VIEW.EXPLAIN_MVIEW to determine if a mv is fast refreshable
--------------------------------------------------------------------------

In Oracle9i the procedure dbms_mview.explain_mview enables you to determine if
a  materialized view is fast refreshable. Prior to calling EXPLAIN_MVIEW it's 
necessary to run the $ORACLE_HOME/rdbms/admin/utlxmv.sql script. This script
creates a table called MV_CAPABILITIES_TABLE.

  exec DBMS_VIEW.EXPLAIN_MVIEW (´owner.materialized_view´);

The materialized view is then analyzed and the results are written into 
MV_CAPABLITIES_TABLE.


3. References
=============

Oracle9i Replication / Oracle Database Advanced Replication (10.2)
Oracle9i Replication Management API Reference /Oracle Database Advanced Replication Management API Reference (10.2)
Oracle9i Data Warehousing Guide / Oracle Database Data Warehousing Guide (10.2)