Oracle materialized view creation reports ORA-00942 error resolution

In the Oracle 10 Gb database, a materialized view is modified with a simple condition clause, deleted and rebuilt, but the creation fails, reporting that the ORA-00942 table or view does not exist.

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.
 
Let's first introduce the statements for creating materialized views, as shown below:
Create materialized view V_TABLENAME
REFRESH COMPLETE ON DEMAND
Start with TO_DATE ('28-05-2013 16:55:32 ', 'dd-MM-YYYY HH24: MI: ss') next sysdate + 1
AS
Select wid as wid, KCM as KCM, jxbh as jxbh, kknf as kknf, kkkxqm as kkxqm, xq as xq, js as js, zs as zs, JSGH AS JSGH
FROM USR_GXSJ.V_TABLENAME @ dblink_name
Where
(KKNF = '000000' and kkxqm = '1') OR (KKNF = '000000' AND kkkxqm = '2 ');
 
ORA-00942: table or view does not exist
ORA-06512: at "SYS. DBMS_SNAPSHOT_UTL", line 960
ORA-06512: at line 1
 
In metalink of Oracle, a document named Create Materialized View Results in: Ora-942 [ID 364632.1] explains that it is 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:
User_a-table owner and Materialized View log owner;
User_ B-has view on a table in user_a's schema: view1
User_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: Bugs 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_TABLENAME
REFRESH COMPLETE ON DEMAND
Start with TO_DATE ('28-05-2013 16:55:32 ', 'dd-MM-YYYY HH24: MI: ss') next sysdate + 1
AS
Select wid as wid, KCM as KCM, jxbh as jxbh, kknf as kknf, kkkxqm as kkxqm, xq as xq, js as js, zs as zs, JSGH AS JSGH
FROM (select * from USR_GXSJ.V_TABLENAME @ dblink_name)
Where
(KKNF = '000000' and kkxqm = '1') OR (KKNF = '000000' AND kkkxqm = '2 ');

This is a tragedy, because we didn't understand why ???
 
Later, we found that this was not the most tragic one. When we added work records, we moved over the previous records.
 
Last year's record
Modify the view V_TABLENAME. An error is returned.
Ora 00942 table or view does not exist
Ora 06512 at SYS. DBMC_SNAPSHOT_UTL, line 960
If the dba permission is granted, the same error is reported. Find a solution ....
.....
In the beginning, it is a bug. It is still wrong after the patch is installed.
Error encountered during internal execution of the 10046 event Analysis Statement
An error occurred while verifying the primary key field of the base table.
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 happened before. We fell twice in a pit and hoped that it would be no third time.