What is the proper procedure for fixing materialized view replication?

Question

Oracle 10 Standard:

I have a number of materialized views built on pre-built tables.
These are fast refreshed from a remote database over a link from one master db.
They've generally been working fine, but sometimes the view needs re-creating when a database server is bounced.

Comparing the remote (replicated) table with the master table now shows there are a few records missing in the replicated table. Re-creating the materialized view doesn't fix this (or manually refreshing it). There are no errors shown with the jobs that fast refresh these.

What is the procedure to fix this? Do I need to drop & regenerate the materialized view log on the master table?

Additional information:

Ok, dropping and recreating the materialized view log did not fix this.

I suppose I can just copy the records manually, but I thought there'd be a more generic way to fix. If complete refresh is the answer, I understand that it truncates the table first which is something I'd really like to avoid if possible.

As requested, here is the script that creates the materialized view:

CREATE MATERIALIZED VIEW AUTO_EVENT_DEFN 
ON PREBUILT TABLE
USING INDEX 
TABLESPACE DATA1 
PCTFREE 10 
INITRANS 2 
STORAGE 
( 
  INITIAL 81920 
  NEXT 1048576 
  MINEXTENTS 1 
  MAXEXTENTS UNLIMITED 
  BUFFER_POOL DEFAULT 
) 
REFRESH 
NEXT SYSDATE + 1/(24*60)   
FAST 
WITH PRIMARY KEY 
USING DEFAULT LOCAL ROLLBACK SEGMENT 
DISABLE QUERY REWRITE AS 
select   aed_rid, name, description, max_check_freq_sec, max_result_freq_sec, header, footer, subject, html_format, 
report_group, trigger_event, max_lines, html_base_size, ins_or_update, active, valid, defn_type, cust_req, last_modified, 
modified_by, sum_cols, report_delay_secs, process_queue, sql_string, report_security, results_type, multi_loc 
from auto_event_defn@kitlive;

Answer 1

And this is exactly what happens when you create materialized views on a prebuilt table that is already stale.

Recreating the mview the same way will not solve this, why would it? You still use the same incomplete prebuilt table.

Recreating mview logs has nothing to do with it. If you recreate mview logs now, that does not include data that was modified in the past.

Yes, the solution is complete refresh, and that does not necessarily truncate the table.

REFRESH Procedures

DBMS_MVIEW.REFRESH has a parameter called atomic_refresh which defaults to true.

A complete refresh with atomic_refresh set to true refreshes all mviews given as parameter in a single transaction. It is achieved by DELETE-ing the rows from the mview.

A complete refresh with atomic_refresh set to false refreshes all mviews given as parameter in seperate transactions. It is achieved by TRUNCATE-ing the mviews (which is much quicker than DELETE).

So specify atomic_refresh => true, and the mview will not be truncated.