Good afternoon,
I have 3 databases; the SIDs are config, prod1 and prod2.
I am using Materialized Views to replicate data on 11 tables in the config database onto the other two databases. The Materialized Views are currently refreshing every five seconds but it would be ideal if they were updated on commit.
I came across this website that explains that when replicating from a remote database that on commit is not supported.
This is what I was expecting to work
CREATE MATERIALIZED VIEW "schema"."table" USING INDEX REFRESH FORCE ON COMMIT AS select column1 from schema.table#config;
The method "refresh fast on demand with primary key" is suggested in the link but obviously this is on demand. I am wondering what ideas anyone may have in order to get a refresh-on-commit environment running if possible?
Thanks
You can't create a materialized view refreshed on commit from a remote table. From the documentation:
Restrictions on Refreshing ON COMMIT
This clause is not supported for materialized views containing object types or Oracle-supplied types.
This clause is not supported for materialized views with remote tables.
The reason is that the database link is defined in the "child" database, not in the "parent" database. Therefore, the parent database can't possibly trigger or modify anything in the child database on its own.
If you want a 100% real-time copy of a table, I suggest a view.
If you want to replicate the data on commit, you could modify your DML procedures so that they update the children remote tables at the same time.
Related
I want to ask you if there is a solution to auto-synchronize a table ,e.g., every one minute based on view created in oracle.
This view is using data from another table. I've created a trigger but I noticed a big slowness in database whenever a user update a column or insert a row.
Furthermore, I've tested to create a job schedule on the specified table (Which I wanted to be synchronized with the view), however we don't have the privilege to do this.
Is there any other way to keep data updated between the table and the view ?
PS : I'm using toad for oracle V 12.9.0.71
A materialized view in Oracle is a database object that contains the results of a query. They are local copies of data located remotely, or are used to create summary tables based on aggregations of a table's data. Materialized views, which store data based on remote tables, are also known as snapshots.
Example:
SQL> CREATE MATERIALIZED VIEW mv_emp_pk
REFRESH FAST START WITH SYSDATE
NEXT SYSDATE + 1/48
WITH PRIMARY KEY
AS SELECT * FROM emp#remote_db;
You can use cronjob or dbms_jobs to schedule a snapshot.
Initial Note: Created Model by choosing to Import the Data Dictionary using one of my Connections and then choosing the Schema and lastly the Tables for which I want to model.
After making changes within Oracle SQL Developer Data Modeler how can I commit the changes made in the newly created relational model back to the database.
I can manually parse thru the generated DDL but that seems like unnecessary work. I attempted to use the 'Synchronize with Data Dictionary' option however when I went back to my tables within my schema they were not altered/updated in any way. No Primary Keys... Foreign Keys, Indexes or any other of the DDL actions I created in the model were seen in my database. What am I missing here?
I really thought the Synchronize options where what I should be using.
We will never commit changes to the database.
You'll do the compare, review the delta DDL, and then if you think it's good - load it up in SQLcl, SQL Developer, or SQLPlus to run.
It's not that we don't trust you to do the review part first, but also, it'd be just too easy to muck up a database if you hit the wrong button. Especially as some table structural changes could result in data loss.
We have a legacy app that I am rewriting in .net. All of our databases are oracle and make use of database links. Is there any way for Entity Framework 6 to generate models based on tables located on a different database?
Currently the legacy app gets data from table like this
SELECT * FROM emp#foo2;
where its db connection is to database foo that has a database link to the database foo2.
I would like to reproduce this using EF6. So far all I have found regarding this is this question.
You can do two things that EF 4 or higher will work with:
CREATE VIEW EMP as SELECT * FROM emp#foo2;
CREATE MATERIALIZED VIEW EMP as SELECT * FROM emp#foo2;
LOBS are not accessible across a database link without some contorted PL/SQL processing to read the LOB piece by piece.
I believe fast refresh does not work across database links so you must consider the size of the table on the linked database. If you are refreshing a million rows you may find the time to do this is an issue. Most large tables are full of tombstone data that never changes so a timestamp column with the last modified date could help you create a package that only picks out the changed data.
If you are doing complicated joins for either ensure that Oracle considers the column that would be the primary key as not null.
You can add a primary key on views and materialized view but it must be disabled. See here for details.
Good day,
Is it technically possible to create a materialized view against a another view in the master database (as opposed to a solid table)?
My DBA advises that oracle does not allow creation of materialized view logs against a view. IMO a view is pretty much the same as a table, so it ought to be possible.
Has anyone ever done this successfully (Oracle 11g).
The documentation is pretty clear about this:
Restrictions on Master Tables of Materialized View Logs
The following restrictions apply to master tables of materialized view logs:
You cannot create a materialized view log for a temporary table or for a view.
You cannot create a materialized view log for a master table with a virtual column.
A view is not pretty much the same as a table. It's a stored query, so it has no storage and DML is only possible through instead-of triggers. It doesn't have the basis for noticing an underlying data change.
Just thinking about it, in order to support a view log - even for a simple single-table view - an update to the view's base table would have to check if there were any views; check if any of those had materialized view logs; and then work out if the change needed to be logged - which would mean executing each view's query and looking at the entire result set. Imagine doing that for every change to the underlying table. And then imagine a more complicated view query, with aggregates or multiple tables, etc.
You'd effectively be materialising the view query to decide whether was a change that needed to be logged, to update an actual materialized view. This is partly what actual materialized views do - stop you having to repeatedly re-execute an expensive view query by tracking changes on the master table(s).
You have to create the materialized view logs on the (normal) view's base tables.
I would like to create a cached copy of a table via dblink in oracle. The story is the following:
I have two tables (employee, work) which are joined via a third table (emloyee_work) in a remote database. The reason for that is to decouple the connection between the two entities so that they are not able to be connected directly.
To handle the data easily we have a view that connects the tables via the join table. One can argue that this is the same as having the join table in the same database as the other two but that in not the point right now.
On a new site, the db link latency is very high which causes a major drop in performance since for every select the view is built and a select is executed for each employee through the db link.
The structure has relative high read count and low write count.
The question is whether there is a possibility to "mirror" or copy the remote join table to the local database? This copy should be temporary and should not be persisted.
This way the view would be executed on the local copy.
EDIT: Oracle version is 11gR2
You could use refreshed on demand materialized views.
See also this link where they talk about implementing a materialized view over a dblink.
Since you are using Oracle 11g, you may create an ad-hoc, RAM-based Materialized View.