Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> c.d.o.server -> ORA-600 on Materialized View re-creation
I've opened a TAR for this issue, and have been searching everywhere I
can think - Metalink, other forums - but thought I'd poll the
community as well, for possible insights.
Replicating tables from 10.2.0.3 on Windows to 9.2.0.6 on AIX.
Attempting replication with snapshot logs (on the 10.2.0.3 db) and materialized views (on the 9.2.0.6 db).
Creation of the materialized view works the first time. I attempt to delete the materialized view and create it again with the same CREATE statement, and I get the ORA-600 error.
I delete the mview, delete the MVLOG from the source, recreate the
MVLOG, attempt to recreate the
materialized view, and I get the ORA-600 error:
ORA-01001: invalid cursor
ORA-00600: internal error code, arguments: [21051], [], [], [], [],
[], [], []
Process:
1) Create tablespace for mv logs on the source (10.2.0.3) db
2) Create tablespace for mviews on the target (9.2.0.6) db, and one for indexes.
3) Create db link from target to source. Db link credentials have DBA priveleges on the source database. Db link uses the same ID as is used to create the mv logs.
4) Create the MV LOG on the source. Sample Statement:
CREATE MATERIALIZED VIEW LOG ON SCHEMA1.TBLGROUP TABLESPACE MV_LOGS_1
WITH PRIMARY KEY INCLUDING NEW VALUES;
Result - no errors - materialized view log created.
5) Create the MView on the target. Sample Statement:
CREATE MATERIALIZED VIEW TBLGROUP TABLESPACE TABLES_REPL BUILD
IMMEDIATE USING INDEX TABLESPACE INDEXES_REPL REFRESH FORCE ON DEMAND
WITH PRIMARY KEY AS SELECT * FROM
SCHEMA1.TBLGROUP_at_DBLINK;
Result - no errors - materialized view created.
6) Refresh. Sample Statement:
EXECUTE DBMS_MVIEW.REFRESH('TBLGROUP','?');
Result - no errors - PL/SQL procedure successfully completed.
7) Drop MView.
8) Recreate MView - ORA-600 reappears.
I attempt to drop the MV Log as well, and recreate both. ORA-600 appears when I try to create the MView.
This is quite consistent. This process works perfectly well on two 10.2.0.3 Windows servers, sitting on the same segment. Received on Mon Apr 02 2007 - 14:59:35 CDT