Originally posted by slimdave what're the issues with rowid, Julian?
In order to implement fast refreshes, all tables that form part of the replicated group, should have Primary keys defined.
Fast refreshes should be implemented as far as possible to reduce network traffic.
Use the rowid of rows and not the primary key;
Define primary keys for these tables;
Use complete refreshes.
Each of these has disadvantages:
§ Use rowid only for backward compatibility to Oracle 7 databases,
§ There is NO guarantee that the ROWID of a particular ROW will be the same from one day to the next. Oracle does not provide you that guarantee,
§ Move table will change rowid,
§ Export/import will change rowid,
§ If there are no unique columns for a specific table, then it will not be possible to define a primary key,
§ Complete refreshes are heavy on the network and should be avoided as far as possible.
Oracle Certified Master
Oracle Certified Professional 6i,8i,9i,10g,11g
that all sounds very fair. it comes down to really needing to use pk's for fast refresh, and refresh on commit. there are obviously a few decisons to be made by Manjunath on these issues, but if a complete refresh on demand suits his environment for functional reasons or through technical restrictions then rowid would seem to be his only choice.
I have quite a few refresh complete on demand MV's -- for query rewrite aggregations on DW fact tables they are a kind of necessary evil, before Partition Change Tracking is introduced in 9i
My environment is not of replication. I am utilizing the features of MVs, to reduce the workload in one of our modules. I have decided to go ahead using 'ROWID', and 'REFRESH ON DEMAND' for now.