ORA-12034 Materialized View Log Younger Than Last Refresh

Metalink Note 204127.1

Diagnosing ORA-12034 Materialized View Log Younger Than Last Refresh [ID 204127.1]
	Modified 25-JUN-2010     Type TROUBLESHOOTING     Status PUBLISHED

In this Document
  Purpose
  Last Review Date
  Instructions for the Reader
  Troubleshooting Details
  References

---

Applies to:

Oracle Server - Enterprise Edition - Version: 8.1.5.0 to 11.2.0.1 - Release: 8.1.5 to 11.2
Oracle Server - Enterprise Edition - Version: 8.1.5.0 to 11.2.0.1   [Release: 8.1.5 to 11.2]
Information in this document applies to any platform.
Checked for relevance on 24-Oct-2007.
Checked for relevance on 12-Mar-2010

Purpose

This troubleshooting guide is intended to introduce the reader to the reasons and ORA-12034 can be raised when refreshing a materialized view, and to present the most common causes of the error.  It also gives solutions for many of these problems and some troubleshooting queries.

Last Review Date

October 24, 2007

Instructions for the Reader

A Troubleshooting Guide is provided to assist in debugging a specific issue. When possible, diagnostic tools are included in the document to assist in troubleshooting.

Troubleshooting Details

1. Error Definition and Description

Error Definition

Oracle 8i and below: ORA-12034: "snapshot log on "%s"."%s" younger than last refresh"
Oracle 9i and above: ORA-12034: "materialized view log on "%s"."%s" younger than last refresh"

Cause: The materialized view log was younger than the last refresh.
Action: A complete refresh is required before the next fast refresh.

Note: A complete refresh can be done using the command:

execute dbms_mview.refresh('"CORP"."NM_SV_RANGE"','C');

Like the error text above indicates, ORA-12034 is a timing issue that occurs when performing a fast refresh of a materialized view. To troubleshoot it, it's important to get some background information regarding the refresh mechanism.

When a materialized view log is created for a master table, and a materialized view has been created with the REFRESH FAST option, the following timestamps will be used when validating log age.

At the materialized view site:

- Information about the last refresh time for each materialized view. The last refresh time is recorded as the timestamp when the last refresh completed successfully.

At the master table site:

- Information about the last refresh time for every materialized view using a materialized view log on that site.

The timestamps at the master site are used for two purposes:

- To maintain information concerning which rows are needed to fast refresh each individual registered materialized view.
- To maintain information concerning which rows can be purged from the materialized view log.

When a fast refresh starts, the last refresh timestamp from the materialized view site for the refreshing materialized view is compared to the oldest timestamp of ANY materialized view using the same materialized view log as the one currently being refreshed. If the oldest timestamp is newer than the materialized view site timestamp, ORA-12034 is raised. By doing this it is ensured that all changed rows since the last refresh will be refreshed, and if this can't be ensured, a complete refresh is forced. There's no exception to this behavior, and violating this main rule will result ORA-12034.



2. Potential Causes of ORA-12034

There are a number of potential reasons that the last refresh time for a materialized view at the materialized view site can be older than the oldest timestamp at the master site. These are described below.

2.1 Dropping / recreating the materialized view log on the master table.

If a materialized view was created at time T1 and materialized view log was created at time T2, we can't ensure that all changes made between T1 and T2 will be in the materialized view after fast refresh. Therefore complete refresh is mandatory.


2.2 Creating the materialized view before the materialized view log.

The explanation here is the same as in Section 2.1.


2.3 The previous refresh for the materialized view did not complete successfully.

When a refresh starts, the last refresh time of the materialized view is set to '01-JAN-1950'. This guarantees that if the refresh fails for any reason, then an ORA-12034 error will be signaled and a complete refresh will be forced. When the refresh succeeds, this date is updated to the proper time. If it doesn't get updated because of some failure during the refresh, the next time the refresh runs, '01-JAN-1950' is used to validate the log age.


2.4 Creating a materialized view takes longer than the time it takes all other materialized views currently using the materialized view log to refresh.

If there are other materialized views using the materialized view log on the master table, and all of these other materialized views start their refreshes AFTER the new materialized view creation has started but complete their refreshes BEFORE the new materialized view creation has completed, then fast refreshes will fail with ORA-12034. Materialized view registration is based on the starting time of the creation, but as the last step of the operation. If that start time is older than the oldest timestamp currently registered, the new materialized view will not be registered. A complete refresh is required to register the materialized view, but it may not avoid the ORA-12034 error the next time a fast refresh is attempted.

There are three ways to resolve this problem:

- Stop the refresh of at least one other materialized view that is using the materialized view log before
creating the new one.
- In production system the previous option might not be possible. For this situation, a temporary materialized view can be created which uses the same log. If this temporary materialized view is not refreshed while the new materialized view is created, the new materialized view creation can complete successfully.
- Use deployment templates to create the materialized view environment at materialized view sites. This problem will not occur if deployment templates are used. See the Advanced Replication documentation for information about deployment templates.


2.5 Certain DDL changes to the master table have been performed.

DDL changes that modify the master table data are not recorded in the materialized view log (truncate, alter partition, drop partition, truncate partition, etc).

Truncation of a materialized view master table should be made specifying the 'purge materialized view log' clause to force a complete refresh, otherwise the data will be inconsistent between the master table and the materialized view. However, specifying this clause will cause the ORA-12034 error if an attempt is made to fast refresh before complete refreshing. This is Oracle's way of forcing the complete refresh. See Note 179469.1 for a more detailed description of this.

Note that for Partition Maintenance Operations (PMOPS) such as alter partition, drop partition, truncate partition, etc, if the materialized view is distributed (i.e. the master table and the materialized view are located on different databases) then an ORA-12034 error is expected after PMOPS to force a complete refresh. Improvements in the PCT (Partition Change Tracking) mechanism since Oracle server version 9i have allowed most local refreshes to use fast PCT refresh and therefore allow a fast refresh to occur even after PMOPS (avoiding the ORA-12034 error and complete refresh). PCT is not supported over database links.


2.6 Master table reorganization.

As explained in Note 254593.1, an ORA-12034 will be raised when attempting to refresh a ROWID-based materialized view after its master table has been reorganized. The master table reorganization process generates new ROWIDs which cannot be mapped to those stored for the materialized view. Therefore a complete refresh is forced via the ORA-12034.


2.7 Materialized view registration failed at the master site.

The contents of the materialized view log(s) depend on other materialized view refreshes. Therefore if the materialized view was not registered successfully, the contents of the master table materialized view log(s) might not include all the changes needed. A complete refresh will register the materialized view if it is not already registered.


2.8 Incorrect conversion of a materialized view log from ROWID to primary key.

When converting a materialized view log from ROWID to primary key type, certain steps have to be performed in order to maintain the fast refresh capability. See Note 254593.1 for details.


2.9 Point in Time Recovery (PITR) performed on a materialized view site.

PITR or incomplete recovery can result in the timestamps at the materialized view site being older than those maintained at the master table site. Materialized view fast refresh first identifies the changes that occurred in the master table since the most recent refresh of the materialized view and then applies them to the materialized view. Fast refresh is therefore not applicable after a PITR on the materialized view site. The materialized view log is younger than the last fast refresh so the materialized view requires a complete refresh to resynchronize the materialized view logs and materialized view with the master table.


2.10 Cloning of materialized view database.

If the materialized view database is cloned and renamed on the same network as the master table database, and the materialized views are dropped on the clone, then refresh of the materialized views on the original materialized view database can begin failing with ORA-12034. This is because dropping the materialized view on the cloned site caused the materialized view to become unregistered on the master site, and a complete refresh is necessary. After a cloning a materialized view site, the database link to the master site should be dropped prior to dropping any materialized views. See Note 287105.1 for more information.


2.11 Manual deletion of sys.slog$ entry for the materialized view.

One of the tables that maintains information for each registered materialized view at the master table site is called sys.slog$. If the sys.slog$ entry for a materialized view is removed, whether by accident or due to a bug, then a fast refresh for the materialized view can fail with ORA-12034. See Note 3669454.8 for one way this can occur.

Normally a complete refresh is adequate to replace the entry in sys.slog$ and allow fast refreshes to continue after the successful complete refresh. However, if there are refreshes of other materialized views occurring simultaneously with the complete refresh of the materialized view for which the sys.slog$ entry was removed, under certain conditions subsequent fast refreshes of this materialized view can fail with ORA-12034. In this case it will be necessary to complete refresh the materialized view again.




3. Diagnostic Queries

To identify which of the above causes has been encountered, run the following queries. If the cause is not apparent please supply the output to Oracle Support Services.

AT THE MASTER SITE :

alter session set nls_date_format = 'DD-MON-YY HH24:MI:SS';

column Owner format a14
column Tablename format a14
column Logname format a10
column Youngest format a10
column "Last Refreshed" format a10
column "Last Refreshed" heading "Last|Refreshed"
column "MView ID" format 99999
column "MView ID" heading "Mview|ID"
column Oldest_ROWID format a10
column Oldest_PK format a10

select m.mowner Owner,
m.master Tablename,
m.log Logname,
m.youngest Youngest,
s.snapid "MView ID",
s.snaptime "Last Refreshed",
oldest_pk Oldest_PK
from sys.mlog$ m, sys.slog$ s
WHERE s.mowner (+) = m.mowner
and s.master (+) = m.master;

AT THE MASTER SITE (for ROWID Materialized View Logs) :

select m.mowner Owner,
m.master Tablename,
m.log Logname,
m.youngest Youngest,
s.snapid "MView ID",
s.snaptime "Last Refreshed",
oldest Oldest_ROWID
from sys.mlog$ m, sys.slog$ s
WHERE s.mowner (+) = m.mowner
and s.master (+) = m.master;

AT THE MATERIALIZED VIEW SITE :  

alter session set nls_date_format = 'DD-MON-YY HH24:MI:SS';

column Owner format a14
column master_owner format a14

select distinct owner,
name mview,
master_owner master_owner,
last_refresh
from dba_mview_refresh_times;

set long 4000
alter session set nls_date_format='DD-MON-YYYY HH24:MI:SS';
select query, rewrite_enabled, refresh_mode rmode, refresh_method rmethod,
last_refresh_date, last_refresh_type rtype, staleness, compile_state,
build_mode bmode, fast_refreshable ref_fast
from dba_mviews where mview_name = '';

where is replaced by the name of the problem materialized view.

Please note the above queries must be run while connected as a user with DBA (select any table) privileges and only work with Oracle 8.0.x and above.

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/22198259/viewspace-667528/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/22198259/viewspace-667528/