How to get Materialized View to ignore unused columns in source table

Question

When updating a column in a source table, records are generated in the corresponding materialized view log table. This happens even if the column being updated is not used in any MV that references the source table. That could be OK, so long as those updates are ignored. However they are not ignored, so when the MV is fast refreshed, I find it can take over a minute, even though no changes are required or made. Is there some way of configuring the materialized view log such that the materialized view refresh ignores these updates ?
So for examle if I have table TEST:
CREATE table test (
d_id NUMBER(10) PRIMARY KEY,
d_name VARCHAR2(100),
d_desc VARCHAR2(256)
This has an MV log MLOG$_TEST:
CREATE MATERIALIZED VIEW LOG ON TEST with rowid, sequence, primary key;
CREATE MATERIALIZED VIEW test_mv
refresh fast on demand
as
select d_id, d_name
from test;
INSERT 200,000 records
exec dbms_mview.refresh('TEST_MV','f');
update test set d_desc = upper(d_desc) ;
exec dbms_mview.refresh('TEST_MV','f'); -- This takes 37 seconds, yet no changes are required.
Oracle 10g/11g

Answer 1

I would love to hear a positive answer to this question - I have the exact same issue :-)
In the "old" days (version 8 I think it was) populating the materialized view logs was done by Oracle auto-creating triggers on the base table. A "trick" could then make that trigger become "FOR UPDATE OF <used_column_list>". Now-a-days it has been internalized so such "triggers" are not visible and modifiable by us mere mortals.
I have not found a way to explicitly tell Oracle "only populate MV log for updates of these columns." I think the underlying reason is that the MV log potentially could be used for several different materialized views at possibly several different target databases. So to be safe that the MV log can be used for any MV created in the future - Oracle always populates MV log at any update (I think.)
One way around the problem is to migrate to STREAMS replication rather than materialized views - but it seems to me like swatting a fly with a bowling ball...
One thing to be aware of: Once the MV log has been "bloated" with a lot of unneccessary logging, you may perhaps see that all your FAST REFRESHes afterwards becomes slow - even after the one that checked all the 200000 unneccessary updates. We have seen that it can happen that Oracle decides on full table scanning the MV log when it does a fast refresh - which usually makes sense. But after a "bloat" has happened, the high water mark of the MV log is now unnaturally high, which can make the full table scan slow by scanning a lot of empty blocks.
We have a nightly job that checks each MV log if it is empty. If it is empty, it locks the MV log and locks the base table, checks for emptiness again, and truncates the MV log if it is still empty, before finally unlocking the tables. That way if an update during the day has happened to bloat the MV log, all the empty space in the MV log will be reclaimed at night.
But I hope someone can answer both you and me with a better solution ;-)