Replication :: MV Views To Snapshot Data Pros And Cons
Nov 4, 2012
I have 3 reporting tables with 2.2 million records each being rebuilt nightly. The data is used online 24/7 by users and thus, snapshot tables are being built from the refreshed reporting tables. The current method to do this:
delete from snapshot table;
insert into snapshot table (select * from report table);
<repeat for other 2 tables>
commit;
This seems to me to be resource intense on the system even though the table is defined with nologging option.
Is it better to create a MV (select only with refresh complete on demand)? The query is very simple without joins so it at first seems like overkill. However, I am also seeing that dbms_mview.refresh allows for an atomic option. Thus, if 1 of the 3 MVs fails during refresh all 3 rollback, which is a nice feature.
Are there better ways to replicate a snapshot table that I've missed? Is a delete and insert strategy a bad idea?
I am moving an Oracle DB (10.2.0.1) to a new server, by creating a blank DB and importing the data by user. I chose to create the new database with Flash Recovery activated (I haven't previously used this), but I'm having a nightmare when importing the data.
I encountered issues with the DB_RECOVERY_FILE_DEST_SIZE which I resolved by increasing the size of this parameter.
Next the import crawled along because of redo.log file errors "Checkpoint cannot complete". I'm assuming that I need to add redo.log files to accommodate this?
i am trying to identify the pro's/con's of using multiple ASM Diskgroup. I understand oracle recommends/best practice is to have 2 DG (one data and one flash) and you can place multiple copies of control files/online redo logs(and thats the way i want to go). But would that same be true if i use different set of DISK. For example we have multiple RAID 10 devices and multiple of SSD devices for us that we can use for this ASM instance. And i was thinking to create 2 more Disk group (call it DG_SYS1 and DG_SYS2) and use that to put my online redo logs, control file and temp and system table space there. i understand in a standalone system(where regular file system is being used), they(online redo/ control file) are usually on there own drives, but with ASM when i am already using external RAID 10 config + ASM striping i assume the IO would faster or am i better of using the SSD that i can have for my redo/control? What would be the pro's/cons of it (besides managing multiple DG)..
Materialized views are normally used for summarized data access.
CREATE MATERIALIZED VIEW mv_snapshot_A REFRESH FAST START WITH SYSDATE NEXT SYSDATE + 20/1440 WITH PRIMARY KEY AS SELECT * FROM A;
This does not seem to be the case here as the materialized view seems to be just a full select. The overhead of the snapshot logs are concerning for this core table. Can we turn off logging in 10g ? the materialized view is defined as fast refresh/ build immediate .
The main requirement here is to keep the snapshot every 15 minutes so that the users can see the updated information ( the flow of data from one location to other).
User get the location wise count of data and can go further in details like in which location wise system wise data count. As the base table is volatile the materialized view is used so that the moment the user clicks for location wise details the data is static for 15 min and user don't get confused.
I need to know that what is best approach for replication. Materialized View or Streaming. We have to replicate a subset of database at different nodes.
1. I have created a materialized view with following syntax in 11g R1 database.
CREATE MATERIALIZED VIEW fr_emp_bonus_record_vw BUILD IMMEDIATE REFRESH COMPLETE START WITH SYSDATE NEXT SYSDATE+1/48 ENABLE QUERY REWRITE AS SELECT person_id, <columns>
This MV will have around 300K records and this MV will be used in other queries based on person_id. So I have created an index on mv.person_id with following syntax. I have chosen REFRESH COMPLETE, I am assuming that, Oracle truncates this table and recreates it. When it recreates this MV, does it analyze automatically or do I need to do it manually.
CREATE UNIQUE INDEX mv_u1 ON mv(person_id);
2. It takes around 2 minutes to populate 300K. While it is populating the data, if somebody accessing this view or query where this view is being used, are they going to get any error?
There is a database db1 which has user U1 in in it contains T1 as table.
Likely,
There is also another database db2 which also has a user named U2 containing table T2 in it.
Now
I want to use the concept of JOINS and Join Table T1 of database named DB1 and Table T2 of database named DB2 and access from database named DB3 using Materialized View Concept.
what shall i do to access tables of DB1 and DB2 from database DB3 using Materialized View.
I have a view with complex query that have grouping and aggregations in sub-queries.
Now we would like to change it to a materialized view. However, materialized view does not support GROUP BY clause in sub-query. The solution is to create several view for the sub-queries and then create a materialized view based on it. It seems it can work, but I guest every time complete refresh is required.
I have a database link between 2 databases and that works fine. Now the tables of one database are having thier materialized views in the other. The materialized views are not getting refreshed. They hang when i try refreshing them. I have tried everything said on the forums. I changed the job_queue_processes. Also changed the query_reqrite_enabled to true. Still it won't work.
CREATE Materialized View log on t1 with rowid; CREATE Materialized View log on t2 with rowid; CREATE Materialized View log on t3 with rowid; CREATE Materialized View MV_test BUILD IMMEDIATE FAST REFRESH ON COMMIT [code].......
I have created a Materialized View by joining the above 3 tables. The Materialized View logs with ROWID has been created on each of the 3 base tables. One of the base tables has around 160 million rows and i expect the Materialized View to have the same number of rows.
The Materialized View has been built for FAST REFRESH on COMMIT. The SELECT list of the CREATE Materialized View statement includes all the ROWIDS from each base tables for doing the fast refresh.
The DBMS_MVIEW explain view shows that the view is capable of doing fast refresh on any DML. The Materialized View took 3 hrs to get built. I have also created indexes on all the three rowid columns (t1rowid,t2rowid,t3rowid) on the Materialized View.
Now, When i do any update on one of the base table and do a commit,
UPDATE t1 set value=500 where tx_id='1234';
The commit is taking around around 15 minutes. I have generated the trace and had a look at it, and it shows that, to refresh the Materialized View, ORACLE is first deleting that record from the Materialized View and then inserting the new record from the base table to the Materialized View. This delete done by oracle is being done on the basis of the rowid of the updated record stored on the Materialized View log,
However its not using the index created on the t1rowid of the Materialized View and doing a full scan of the MV and hence the delete is taking a lot of time. The delete statement is using a hint NO_MERGE and HASH_SJ which is causing it to do the full table scan of the MV. why is ORACLE not using the index on the t1rowid column of the MV to do this delete?
Also to do the insert in the MV, its selecting the new changed value from the base tables t1,t2 and t2. Here again its doing a full table scan of the base table t1, rather then using the rowid directly or the index coulmn.which is taking a lot of time.
I have a Problem regarding Data Replication, I am using Standard Version of Oracle 9i,I am having 5 remote servers , I am replicating the data from all of these servers using Materialized views on a Centralized server , I have created 5 schema for them, there is a application which is Consolidating the Data from all the locations.
When I create materialized views from these Materialized views I am facing problems to Fast refresh them as I am using "Union All" to combine data of all Users (Error is ora -12004) . I would like to know that is there any other way to do this, also I have tried all the ways to solve the problem of Ora-12004.
while replicating the master site via materialized views, in mViewGroups i issued:
BEGIN DBMS_REFRESH.MAKE ( name => 'mvadmin.hamza_refg', list => '', next_date => SYSDATE, interval => 'SYSDATE + 1/1440', -- for test purpose i used such a small interval implicit_destroy => FALSE, rollback_seg => '', push_deferred_rpc => TRUE, refresh_after_errors => FALSE); END;
in my previous attempt it worked all fine... i had a change in senerio, so i did my replication again from scractch using the same old spool in a new installation but even after 3 tries on replicating from scratch my objects are not getting refreshed automatically. even when i attempt to refresh the group it does not work. it works only when i refresh each of the participating object of the group manually.
We have some materialized views in our environment which refreshes after every 1 hour. In the same environment, we have some big processes and we do not want the performance of these big processes to get affected because of refreshing these materialized views.
if there is a way to pause the refreshing of materialized views before running the big processes and later after the big processes are completed, then resume the refreshing of the materialized views?
One way I can think of is to drop the materialized views and create the materialized views back.
CREATE MATERIALIZED VIEW LOG ON ABC; CREATE MATERIALIZED VIEW MV_ABC REFRESH FAST START WITH SYSDATE NEXT SYSDATE+20/(24*60) FOR UPDATE AS SELECT * FROM ABC WHERE TMSTP> SYSDATE-1;
It is working fine. Appended the Query with WHERE clause in MV_ABC MVIEWS.
DROP MATERIALIZED VIEW LOG ON ABC; DROP MATERIALIZED VIEW MV_ABC; CREATE MATERIALIZED VIEW LOG ON ABC; CREATE MATERIALIZED VIEW MV_ABC REFRESH FAST START WITH SYSDATE NEXT SYSDATE+20/(24*60) FOR UPDATE AS SELECT * FROM ABC WHERE TMSTP> SYSDATE-1;
ORA-12013: updatable materialized VIEWS must be simple enough TO DO fast refresh
(Oracle 11gR1 OEL 5)Is there any possibility to convert snapshot database (standby) directly to Primary. Instead of manual switchover I want to do this
I have checked that snapshot creates a guaranteed restoration point which reverts back changes in Standby.
We are planning to consolidate our Oracle Production DB into one server. We are basically a windows shop. Is it feasible to run 8 production Oracle DB in one windows server. All the DB are not really transaction intensive DB. 2 DB in the size of 300GB and others all DB falls under average size of 40GB.
I can take care of the HD slicing so Oracle does not enter into IO bottleneck. We are planning to go for external NAS or SAN for storage.
My main concern is on processor usage. The processor we are thinking about is Intel Xeon Quad Core x 2nos. Will there be a processor bottleneck or is there way in Oracle to assign processor usage(I belive there is no much tweaking options here)
I have a created a materialized view which is based on a view on remote database. Now how do I refresh the view.
Materialized view is created by
CREATE MATERIALIZED VIEW mv_employee_name AS SELECT EMPLID, EMPL_NAME FROM VEMPDATA@REMOTEDB WHERE REGION = 'US';
I am wondering how the refersh happens or how do I specify the refresh clause.REFRESH FAST option is looking for VIEW LOG on the master table but in this case its a remote view, so I cannot create any object on remote db.
I am removing sal column from table tab_emp; i want to check whether any materialized view or view using this column by querying using data dictionary :- if i use like condition against query column of all_mviews it is throwing error sicne it is long data type. is there a way to search it without creating any function and use it in a query.
If flashback is enable in physical standby database 1. If we failover at 11AM can I flash back NEW primary database to 6 AM ? 2. if I convert physically standby database to snapshot standby database at 11AM , Can I flashback snapshot standby database to 6 AM and do some works on it (DML operations) then converting the snapshot standby database into physical standby database ?
I've got a Source Data in complex relational formFor reporting purposes, a simpler, less normalized data model is neededThere are two Target views from the Source Data: one of them with full access to all datathe second one with access only to a subset of the data (same columns, but not all the records)For both target groups, a separate schema shall be available, each containing only relevant dataToday, these schemas are physically located on the same DB instance and host as the source dataA daily refresh is sufficientA later relocation of the reporting schemes to other DB instances shall be possible without major changes neededOracle 10g should be used I tried to accomplish this using Materialized Views (Materialized seems better since there will be sometime a need to have all the apropriate data somewhere else, geographically, AND it provides Complete Refresh from the Source), but there is a problem: when creating the MV there is a possibility to type 'SELECT *' - but after execution it changes into real columns names. It is important because later after adding a new column into Source Data it WILL NOT appear in MV after refresh.
I also thought about Data Guard, Streams and RAC, but I think only in the Materialized Views you may choose the data to show (rows, columns).
