exporting bitmap, functional and extensible indexes exporting referential integrity constraints about to export ORIG's tables via Conventional Path. exporting object type definitions for user ORIG exporting foreign function library names for user ORIG exporting pre-schema procedural objects and actions Server uses WE8ISO8859P1 character set (possible charset conversion) With the Partitioning, OLAP and Data Mining optionsĮxport done in US7ASCII character set and AL16UTF16 NCHAR character set All rights reserved.Ĭonnected to: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production Orig%ORA10GR2> select mview_name, refresh_method, refresh_mode from user_mviews Įxport: Release 10.2.0.1.0 - Production on Tue Jul 29 15:28:39 2008Ĭopyright (c) 1982, 2005, Oracle. Orig%ORA10GR2> select object_name, object_type from user_objects Orig%ORA10GR2> CREATE MATERIALIZED VIEW mv Ops$tkyte%ORA10GR2> grant all on t to other Ops$tkyte%ORA10GR2> grant all on t to orig Ops$tkyte%ORA10GR2> CREATE MATERIALIZED VIEW LOG ON t WITH PRIMARY KEY ,rowid Ops$tkyte%ORA10GR2> create table t ( x int primary key, y int ) Ops$tkyte%ORA10GR2> grant dba to other identified by other Ops$tkyte%ORA10GR2> grant dba to orig identified by orig Ops$tkyte%ORA10GR2> drop user orig cascade Ops$tkyte%ORA10GR2> drop user other cascade ?Ĭan i manually drop this "M_ROW$$" column (any issue later ?) Will this exta column cause any issue for any data maniuplation/queries/alters.
I see "M_ROW$$" extra column in each table as the first column. So in order to refresh with production data, we created another DB schema and imported the materialized view tables (regular tables) with data. So we could not refresh the data with production data as it was not allowed. Those SCHEMA tables in ST/UAT are also replicated via Read-only materialized views. We have a request to copy production data (materialized view tables data) into ST/UAT instance. and point the application to the new platform. keep doing FAST refreshes to last minute. Setup MVIEW based replication between two platform databases. Logical stand by across different platforms ? NOT SUPPORTEDģ. Export/import within an hour ? NOT EVEN CLOSEĢ. Maximum 1 hour maintenance window is allowed for switching to the new platform.ġ. * Migrating a 80GB database from Solaris-64 (SPARC) to Linux-64, a 24x7 application should be up and running during the migration process. I'm looking for a syntax that would purify (clean up MVIEW specific dictionary entires) a MVIEW into a normal table. Is it possible to convert a MVIEW back to a normal table directly (without using CTAS workaround)?. I'm aware that a normal table can be converted to a MVIEW using the "PREBUILT" keyword.
0 kommentar(er)
