Solution to ORA-00942 error reported by Oracle materialized view Creation

Oracle materialized view creation report ORA-00942 error solution in Oracle10g Database, a materialized view made a simple Condition Clause modification, delete and re-build, but, it is not created successfully, reported ORA-00942 table or view does not exist error. This is a strange question. Do I think this is a bug first? I found metalink of oracle and found similar bugs, but the solution is not suitable. So I analyzed and solved it myself, and found a pitfall followed by a pitfall. Well, I'll first introduce the statement for creating MATERIALIZED views, as shown below: CREATE MATERIALIZED VIEW V_TABLENAMEREFRESH COMPLETE ON DEMANDSTART WITH TO_DATE ('28-05-2013 16:55:32 ', 'dd-MM-YYYY HH24: MI: ss') next sysdate + 1 asselect wid as wid, KCM as KCM, jxbh as jxbh, kkknf AS kkknf, kkxqm as kkkxqm, xq as xq, js as js, zs as zs, jsgh as jsghfrom USR_GXSJ.V_TABLENAME @ dblink_name where (KKNF = '000000' and kkxqm = '1') OR (KKNF = '000000' and kkxqm = '2'); O RA-00942: table or view does not existORA-06512: at "SYS. DBMS_SNAPSHOT_UTL ", line 960ORA-06512: at line 1 in metalink in Oracle, a file named Create Materialized View Results in: Ora-942 [ID 364632.1] explains this as a bug. Symptoms Creating a Materialized view based on a view existing on the remote database results in the following errors: ORA-00942: table or view does not exist ORA-06512: at "SYS. DBMS_SNAPSHOT_UTL ", line 1543 ORA-02063: preceding 2 lines from remote db Significantly, the database link on the local side connects to user_c schema on the remote database. on the remote database the configuration is: use R_a-table owner and Materialized View log owner; user_ B-has view on a table in user_a's schema: view1user_c-has select privs on view in user_ B's schema. changes This issue occurs when the remote database is 10.2.The problem did not occur with 9.2.X Cause This issue is addressed in: Bug 5015547. solution In order to determine that it is this issue, create the database link to user_ B schema. This can serve as a workaround and confirmation that this is likely: Bug 5015547 Apply patch for Bug 5015547 to 10.2.0.X if it is thought you are experiencing this issue. in this document, the solution proposed by Oracle is to change dblink to the same access user, which is not tested here because it is not in line with our application architecture plan. No, so I had to analyze it myself and search for previous cases on the Internet. First, check the permissions to see if the authorization line is not available. Do not authorize USR_GXSJ.V_TABLENAME. Do not authorize the table in USR_GXSJ.V_TABLENAME. Later, I found a person on the Internet who gave a solution to this problem and used the data source USR_GXSJ.V_TABLENAME @ dblink_name to use select * from USR_GXSJ.V_TABLENAME @ dblink_name for nesting. You can test it according to the method. Create materialized view V_TABLENAMEREFRESH complete on demandstart with TO_DATE ('28-05-2013 16:55:32 ', 'dd-MM-YYYY HH24: MI: ss') next sysdate + 1 asselect wid as wid, KCM as KCM, jxbh as jxbh, kkknf as kknf, kkxqm as kkxqm, xq as xq, js as js, zs as zs, jsgh as jsghfrom (select * from example @ dblink_name) where (KKNF = '000000' and kkxqm = '1') OR (KKNF = '000000' AND kkkxqm = '2'); this is a tragedy because Why ??? Later, we found that this was not the most tragic one. When we added work records, we moved over the previous records. When the view V_TABLENAME was modified last year, the ora 00942 table or view does not existora 06512 at SYS error was reported. DBMC_SNAPSHOT_UTL, line 960 gave dba permissions, or reported the same error. Find a solution ......... In the beginning, it is a bug. It is still wrong after the patch is installed. The specific error encountered during internal execution of the 10046 event analysis statement is that the primary key field of the basic table is re-verified. In our materialized view step, we did not specify whether to use rowid or primary key to traverse data. Primary key is used by default. According to the record prompt, we added the with rowid clause and created successfully. It turns out that this problem has happened before. We fell twice in a pit and hoped that it would be no third time ....