I have to maintain history into target table for each and every change made into source table.
Have you tried associating a Materialized View to your table to track?
You can use the Materialized view log. All changes will be saved there:
https://oracle-base.com/articles/misc/materialized-views
Related
I am trying to understand but its not obvious to me in the documentation of Azure SQL DW, if you materialize a view and any of the base tables of the view is being updated with data or data is deleted / truncated, will this affect what is accessible in the materialized view or will what was created in the materialized view at execution persist?
A Materialized View persists the data returned from the view definition query and automatically gets updated as data changes in the underlying tables.
I tried All the operation you mentioned in Question on the base table of materialized view It is updating the view according to the changes perform on base table materialized view without restrictions.
Sample data
Created Materialized view on table
Updated data in base table and performed select operation on view
Deleted data from base table and performed select operation on view
Inserted data in base table and performed select operation on view
After every update on base table Materialized view is getting updated automatically.
When you create a view, the column structure of the view is created and stored, and thus you can see it in object explorer:
When you alter the source data tables, sometimes things go wacky, because the view may have been built with "Select *" yet the schema created for you has the old information without the additional columns.
Does SQL Server have an easy way to rebuild the view schemas?
Do not use SELECT * in views. I say this as someone who has spent much too much time (in the past) debugging views that had this "feature".
When you do create a view in a production system, create it with SCHEMABINDING:
SCHEMABINDING
Binds the view to the schema of the underlying table or tables. When SCHEMABINDING is specified, the base table or tables cannot be modified in a way that would affect the view definition. The view definition itself must first be modified or dropped to remove dependencies on the table that is to be modified.
Although this adds an extra step when trying to modify tables, the increased resilience of the system is worth it.
I have three sites,one site contians the employees table, while the other sites have materialized view of employees table .
This is how i created the materialized views on the other sites.
CREATE MATERIALIZED VIEW employeesMV
REFRESH FAST
FOR UPDATE
AS
SELECT * FROM manager.employees#managerlink;
so i just want to know how to update the master table employees after i make changes such as (insert or update) on the materialized view.
Thank you in advance.
By default, materialized view can't be updated. However, if you use FOR UPDATE clause, you can do it, but those changes aren't reflected in MV's source table. Moreover, as soon as you refresh the MV, changes you've made will be lost.
Advanced replication covers it, but Oracle says that it is deprecated in 12cR1.
There's a walkthrough on Vinayaga Consultancy's blog, Updatable Materialized View, based on Oracle 11.2 (source) and 10.2 (target database) so - have a look. It isn't that trivial at all.
I have a table T_SG_LTA_TRANSACTION_TYPE in source database.
I want to move it into a target database.
I have created a materialized view log in source database.
CREATE MATERIALIZED VIEW LOG ON T_SG_LTA_TRANSACTION_TYPE WITH PRIMARY KEY, ROWID;
Then I created materialized view in target database with following query.
CREATE MATERIALIZED VIEW T_SG_LTA_TRANSACTION_TYPE
ON PREBUILT TABLE
REFRESH FAST ON DEMAND
FOR UPDATE
AS
SELECT TRANSACTION_ID,
TRANSACTION_DESCRIPTION,
FILE_TYPE_ID
FROM T_SG_LTA_TRANSACTION_TYPE#EBAODWH_SRC_1_GS_AIG;
But when I refresh materialized view , I am unable to load the data which is already present in T_SG_LTA_TRANSACTION_TYPE(SOURCE DB).
BEGIN
DBMS_MVIEW.refresh('T_SG_LTA_TRANSACTION_TYPE');
END;
The data which is updated in source table after creation of materialized view, is only loading to materialized view . But I want to get whole data from source table(modified and unmodified) into materialized view. And I need this unmodified data only once when mview is created. Please suggest the solution. Thanks in advance.
You seem to be using the ON PREBUILT TABLE clause incorrectly:
The ON PREBUILT TABLE clause lets you register an existing table as a preinitialized materialized view.
And
Caution:
This clause assumes that the table object reflects the materialization of a subquery. Oracle strongly recommends that you ensure that this assumption is true in order to ensure that the materialized view correctly reflects the data in its master tables.
You're essentially saying that T_SG_LTA_TRANSACTION_TYPE already exists on the target database - not the source - and contains the current state of the source table; which, since you're missing data, is not true.
When you refresh Oracle is only looking for changes since the view was created, as it's supposed to; it relies on the MV log to identify what has changed.
Drop the MV in the target database, without the preserve table clause, and then recreate it without the on prebuilt table clause.
Make sure you're dropping the right thing in the right database/schema, of course...
It isn't clear if the (empty) table already existed in your target DB before you started; or you've run this a couple of times and dropped the MV with preserve table - and either the source was empty last time, or you truncated the target table afterwards - or perhaps you tried to export/import the initial state but just got the metadata and not the data. If the table you said existed on the target DB did not, in fact, exist then Oracle would have thrown an ORA-12059 exception when you tried to create the MV. I suspect you'd created an empty table and then tried to convert it to an MV, but if you do that it won't get any data from the source DB, as you've seen.
I would like to use a materialized view that refreshes ON COMMIT. My backing view joins two tables in the local database and one table in a remote database via DB Link. How can I have the view refresh only when changes are made to one of the two local tables?
Are there any other ways to solve this problem? Can I have the materialized view just join the two local tables and put NULLS for the columns from the remote database, and then have a trigger on insert/update to the materialized view that would fill in those fields? Or do updates to a materialized view propagate back to the source tables?
I'm doing something like this:
SELECT LOC1.ID, LOC1.NAME, LOC2.PRICING_TYPE, REM1.PURCHASING_ID
FROM LOCAL_TABLE_A LOC1, LOCAL_TABLE_B LOC2, REMOTE_TABLE#SOMEDB.WORLD REM1
WHERE LOC1.ID = LOC2.MASTER_ID
AND LOC1.REM_ID = REM1.ID
AND LOC2.YEAR = REM1.YEAR
The REMOTE_TABLE is only a lookup table for information related to the two local tables. It should not drive anything here, and I only want the materialized view to update if LOCAL_TABLE_A OR LOCAL_TABLE_B CHANGE.
You could use an intermediate Materialized View for the remote table. This MV would be created in your local DB with REFRESH ON DEMAND so that you can refresh it manually. Your MV would use the local table in place of the remote table.