MLOG$ TABLES.

Hi All,
I am currently having a setup of primary database along with a logical standby.i have certain MLOG$ tables in primary as well as logical standby but I don't need the MLOG$ tables in primary.So I thought of droping it but since dataguard is enable it will drop the tables from logical standby which I don't want.i want the tables to be dropped from primary database only.Do MLOG$ tables get replicated by SQL Apply process??..if yes then how can I Achieve my goal..kindly help me out.

Use dbms_logstdby.skip() to skip some statements on particular objects.
http://docs.oracle.com/cd/B19306_01/appdev.102/b14258/d_lsbydb.htm#i997288
9.1.6 Skipping SQL Statements on a Logical Standby Database
http://docs.oracle.com/cd/B12037_01/server.101/b10823/manage_ls.htm#1025068

Similar Messages

Exclude mlog$ table during import

Hi Experts,
Could you please help me on how to exclude the materialized view log tables (mlog$ table) during data pump import.
Error:
ORA-31693: Table data object "RM_DBA"."MLOG$_ACTUAL_INCOME" failed to load/unload and is being skipped due to error:
Regards,
Boris

I found the answer here..
impdp job_name=schemaexp1 schemas=sthomas dumpfile=exp_schem.dmp logfile=imp_schema.log directory=exp_dir EXCLUDE=table:\"like \'MLOG\$\%\'\",MATERIALIZED_VIEW_LOG,MATERIALIZED_VIEW
Original Post: http://www.acehints.com/2013/09/how-to-exclude-mlog-materialized-view.html

Questions on Materialized Views and MV Log tables

Hello all,
Have a few questions with regards to Materialized View.
1) Once the Materialized View reads the records from the MLOG table the MLOG's records get purged. correct? or is it not the case? In some cases I still see (old) records in the MLOG table even after the MV refresh.
2) How does the MLOG table distinguish between a read that comes from an MV and a read that comes from a user? If I manually execute
"select * from <MLOG table>" would the MLOG table's record get purged just the same way as it does after an MV refresh?
3) One of our MV refreshes hangs intermittently. Based on the wait events I noticed that it was doing a "db file sequential read" against the master table. Finally I had to terminate the refresh. I'm not sure why it was doing sequential read on the master table when it should be reading from the MLOG table. Any ideas?
4) I've seen "db file scattered read" (full table scan) in general against tables but I was surprised to see "db file sequential read" against the table. I thought sequential read normally happens against indexes. Has anyone noticed this behaviour?
Thanks for your time.

1) Once all registered materialized views have read a particular row from a materialized view log, it is removed, yes. If there are multiple materialized views that depend on the same log, they would all need to refresh before it would be safe to remove the MV log entry. If one of the materialized views does a non-incremental refresh, there may be cases where the log doesn't get purged automatically.
2) No, your query wouldn't cause anything to be purged (though you wouldn't see anything interesting unless you happen to implement lots of code to parse the change vectors stored in the log). I don't know that the exact mechanism that Oracle uses has been published, though you could go through and trace a session to get an idea of the moving pieces. From a practical standpoint, you just need to know that when you create a fast-refreshable materialized view, it's going to register itself as being interested in particular MV logs.
3) It would depend on what is stored in the MV log. The refresh process may need to grab particular columns from the table if your log is just storing the fact that data for a particular key changed. You can specify when you create a materialized view log that you want to store particular columns or to include new values (with the INCLUDING NEW VALUES) clause. That may be beneficial (or necessary) to the fast refresh process but it would tend to increase the storage space for the materialized view log and to increase the cost of maintianing the materialized view log.
4) Sequential reads against a table are perfectly normal-- it just implies that someone is looking at a particular block in the table (i.e. looking up a row in the table by ROWID based on the ROWID in an index or in a materialized view log).
Justin

Question on Materialized View Log Table

Hello,
One of our MLOG table keeps growing without the records getting flushed out ...The Materiazed view gets refreshed successfully though...The master/mlog tables are remote..
There is only one MV attached to the master table as evident from the results below...
//On the Master site
select owner,name, mview_site, mview_id from all_registered_mviews where owner='SSP' and name='TRANS_STATUS'
Owner Name MVIEW_SITE MVIEW_ID
SSP TRANS_STATUS SSPRD     12864
The above output is expected and good but I was surprised to see the output below...
select owner,master,to_char(mview_last_refresh_time,'MM-DD-YYYY HH:MI:SSAM'), mview_id from all_base_table_mviews where owner='SSP' and master='TRANS_STATUS'
Owner Master MVIEW_LAST_REFRESH_TIME MVIEW_ID
SSP TRANS_STATUS     01-27-2011 06:32:05PM     12724
SSP TRANS_STATUS     01-29-2011 12:03:06PM     12844
SSP TRANS_STATUS     06-18-2011 07:32:55AM     12864
I'm not sure why I see differnt MVIEW_IDs...We refresh this MV every day....
On 01-27-2011 it was a regular normal refresh using dbms_mview.refresh
On 01-29-2011 we had to drop and recreate our MV and then refresh it using dbms_mview.refresh
On 06-18-2011 it was a regular normal refresh using dbms_mview.refresh
Why are there different MVIEW_IDs when there is only one MV that is attached to the master table. Could this be the reason why the logs are not getting flushed out?
Thanks for your time...

What is your database version?
How did you even manage to create two objects with the same name?
As I know, it is impossible, oracle will throw errors like below:
SQL> create table FOO (str varchar2(5), num number(3,0));
Table created.
SQL> CREATE MATERIALIZED VIEW FOO
2 BUILD DEFERRED
3 REFRESH COMPLETE ON DEMAND
4 enable query rewrite as
5 select SUM(NUM)
6 from FOO GROUP BY STR;
from FOO GROUP BY STR
ERROR at line 6:
ORA-00955: name is already used by an existing object
SQL>

Materialized View Log table with sequence

I have a materialized view log in Database A..a very simple one...similar to "create materialized view log on t WITH PRIMARY KEY"...The primary key is a composite key of 2 columns...Description of the mlog table looks like this...
desc mlog$_t
emp_ctr NUMBER
emp_date DATE
SNAPTIME$$ DATE
DMLTYPE$$ VARCHAR2(1)
OLD_NEW$$ VARCHAR2(1)
CHANGE_VECTOR$$ RAW(255)
The Materialized view is in database B...again a simple one...no aggregation...This gets refreshed on demand manually evey week. The records that get accumulated in the MLOG every week is ~ 300K..The manual refresh used to finish in about 20mins but since last week it is running for ever. Upon reviewing the contents of MLOG I noticed that it contained a mixture of inserts and updates. I'm not sure if the MLOG contanied only inserts in the past when the MV used to refresh very quickly...Based on the documentation, Oracle recommends creating MLOGS with "sequence" whenever inserts/updates/deleted are expected. I'm planning to drop and recreate the MLOG with sequence with the hope that this would fix the slow refresh issue...Appreciate if you could let me know your thoughs...
I'm also planning to trace the session to get some wait event statistics to find out the reason for the slow refresh...

There are a few reasons why refreshes slow down over time.
1. Is the log table being cleared out after a refresh? If not, you may have another mview (maybe even one that doesn't exist any more) registered against this log. When this happens, the log table never stops growing.
2. How big is the segment occupied by the table? If it has grown very large at some time in the past (e.g., because refresh was delayed), then when the refresh does a FTS on the log it will scan the whole segment - even if only a few rows are present.
3. It may help to add an index to the PK columns, and another to SNAPTIME$$. Without them, the refresh will FTS the log. For a big segment, that can take a long time.
-- Phil

SRKIM: Snapshot Inv.Mlog$_mtl_system_items_b Records 수가 계속 증가함

PURPOSE
Tablespace 의 효과적인 관리를 위하여 아래의 작업을 진행 한다.
Problem Description
INV.MLOG$_MTL_SYSTEM_ITEMS_B table 이 계속적으로 증가하여 tablespace 를 차지할 뿐만 아니라 performance 에도 영향을 주고 있다.
Workaround
N/A
Solution Description
아래의 작업을 수행 후 해당 table 의 data volume 을 확인 하도록 한다.
Refresh Collection Snapshot 을 Complete Refresh 나 Automatic 으로 수행.
Complete Refresh 는 모든 snapshots 을 process 하고 refresh 하는 작업을 수행.
Automatic Refresh 는 snapshot log 를 truncate 한 후 complete
refresh of the snapshot(s) 작업을 수행 하는 역할이다.
Reference Documents
335747.1 Snapshot Inv.Mlog$_mtl_system_items_b Records Increasing

HI,
Please go through below MOS docs:-
When do Snapshot Logs get Purged [ID 35217.1]
SNAPSHOT LOGS GROWS DUE TO MISSING/INVALID SNAPSHOT [ID 1031924.6]
How To Improve the Performance of the Refresh Collection Snapshots When Running Very High Volumes [ID 550005.1]
MLOG$_ENI_OLTP_ITEM_STAR is Growing too Large, can it be Truncated? [ID 367693.1]
Materialized View Refresh : Log Population and Purge [ID 236233.1]
Refresh Collection Snapshots Performance - Managing MLOG$ Tables and Snapshots for Data Collections [ID 1063953.1]
Thanks,
JD

Deleting the staging tables

Hi all,
We are upgrading from 8.4 to 9.0 financials.
we are at re-applying customizations phase now.
In previous version(8.4), there was a custom app engine to delete the Voucher Staging tables(EC tables).
in that app engine, all deletes were based on ECQUEUEINSTANCE field.
(for ex delete from PS_VCHR_HDR_EC WHERE ECQUEUEINSTANCE BETWEEN 1234 AND 1235)
Peoplesoft changed EC tables to STG tables in 9.0 version
So my question is that in 8.4 in PS_VCHR_PYMT_EC has the ECQUEUEINSTANCE field in it. but the corresponding table PS_VCHR_PYMT_STG table does not have the ECQUEUEINSTANCE field. I am just wondering if any one got into this situation and how did you delete the PS_VCHR_PYMT_STG table?
I don't want to delete everything in PS_VCHR_PYMT_STG table.
Thank you.

Please post the details of the application release, database version and OS.
Do you have the statistics collected up to date?
Please see these docs.
PERFORMANCE ISSUE - REFRESH COLLECTIONS SNAPSHOT WHEN RUN FOR ALL [ID 1067892.1]
Refresh Collection Snapshots Performance - Managing MLOG$ Tables and Snapshots for Data Collections [ID 1063953.1]
How To Improve the Performance of the Refresh Collection Snapshots When Running Very High Volumes [ID 550005.1]
How To Run MSRFWOR - Refresh Collections Snapshots Concurrent Request From The Application [ID 211121.1]
Advanced Supply Chain Planning ASCP Performance TIPS Profile Options [ID 209996.1]
Fast Refresh Is Slower After OATM and 10.2.0.3 Upgrade [ID 875532.1]
MSRFWOR Refresh Collection Snapshots Performance Database Bug 4196039 [ID 369173.1]
Master Note for Materialized View (MVIEW) [ID 1353040.1]
Thanks,
Hussein

APS Collections Refresh Snapshot Thread running for very long

Hi,
Program "APS Collections Refresh Snapshot Thread" for "BOM_INV_COMPS_SN" snapshot is running for very long time.
Can we cancel it?
It's running in FAST refresh mode.
Thanks.

Hi,
Count the records in the mlog tables of these MVs. If the record count is more than do a complete refresh.
Thanks,
Abhishek Sharma

Query on materialized view

Hi,
Materialized view can't be renamed, so how can I reduce the downtime for any new column addition in the materialized view.
Regards,
Koushik

Agree with your reply.
I like to do the following steps assuming there is already a materialized view created on a base table :
1. Add any new column to the base table.
2. Drop and recreate the mlog table.
3. execute the statement "alter materialized view <mv_name> consider fresh" to simulate the error "ORA-12034: snapshot log on "<schema>"."<mv_name>" younger than last refresh"
4. Create a new MV with the additional columns and with a different name.
5. Drop the existing(old) MV.
6. Rename the new MV with the name of the old one.
Now this renaming is not possible. Is there any alternative way do the thing whatever I am trying to do by the above steps.
Can you please also tell me what is use of "ENABLE QUERY REWRITE" option during creation of a materialized view.
Thanks & Regards,
Koushik

High invalidations in v$sqlarea for 1 query tag with "SQL Analyze"

Hi All,
Hopefully post to the right forum, if not please do let me know. Thanks
I have one pre-production issue still don't have any clue how to move forward.
This is 2 RAC nodes in linux platform with Oracle 11.2.0.2
In the begininng this environment having a lot of performance issue, as huge "cursor: pin S wait on X", "latch: shared pool"
and "library cache:Mutex X" causing very bad performance in this environment. After oracle support suggest to disable few hidden paramter
and adjust some parameter, then it help to stablized the environment (according to oracle, the initial issue was caused by high version count).
But we still can find minimal "latch:shared pool" and "library cache:Mutex X" on top 5 wait event list on hourly AWR report.
This time oracle was saying it might caused by high reload and high invalidatiosn in sqlarea (not sure how true it is), luckily the event
did not caused the performance issue at this moment, but we're asking support how can we get rid of the "mutex/latch" event.
They give me one query to check the invalidations in v$sqlarea, and they suspect the high validation is causing by application.
select *
from v$sqlarea
order by invalidations DESC;
Weird thing is, there have one SQL tag with "SQL Analyze" always causing high invalidations. But we're not able to get more detail (base on SQL_ID)
in v$sql or v$session table. This SQL insert into v$sqlarea and remove within 1 or 2 seconds, hard to get more information.
And the statement is exactly the same, but don't know why SQL Analyze always checking on it.
This SQL is triggering by SYS user, and it is inserting into MLOG$ table (one of the application materialized log file)
insert into "test"."MLOG$_test1" select * from "test"."MLOG$_test1"
The v$sqlarea information as below, sometime the invalidations can hit more than 10,000
SQL_ID              SQL_TEXT                                                                                        LOADS INVALIDATIONS
0m6dhq90rg82x /* SQL Analyze(632,0) */ insert into "test"."MLOG$_test" select * from "test"."MLOG$_test 7981    7981
{code}
Anyone have any idea how can i move forward for this issue? As Oracle is asking me to use SQLTXPLAIN get the detail?
Please share with me if you have any idea. Thanks in advance.
Regards,
Klng

Hi Dom,
We have checked there have no SQL Tuning enable for this SQL_ID. Below is the optimizer parameter in this environment, the hidden parameter was changed which suggest by oracle support.
NAME                                 TYPE        VALUE
_optimizer_adaptive_cursor_sharing   boolean     FALSE
_optimizer_extended_cursor_sharing_r string      NONE
el
object_cache_optimal_size            integer     102400
optimizer_capture_sql_plan_baselines boolean     FALSE
optimizer_dynamic_sampling           integer     2
optimizer_features_enable            string      11.2.0.2
optimizer_index_caching              integer     90
optimizer_index_cost_adj             integer     10
optimizer_mode                       string      ALL_ROWS
optimizer_secure_view_merging        boolean     TRUE
optimizer_use_invisible_indexes      boolean     FALSE
optimizer_use_pending_statistics     boolean     FALSE
optimizer_use_sql_plan_baselines     boolean     TRUE
plsql_optimize_level                 integer     2
SQL> select * from dba_sql_plan_baselines;
no rows selected
SQL>yeah we did run the ash, but the high invalidation did not caputre in the report. Actually this SQL tag with sql analyze it gone from v$sqlarea very fast (only 1 or 2 seconds only).
Thanks.
Regards,
Klng

Problem regarding Materialized View

Hi,
I have a master table "nms_num_schm" on SID-SLBANCS and its corresponding materialized view "mlog$_nms_num_schm". The MV is supposed to move data from this master table to a table "nms_num_schm_mv" on SID-ORCL.
The MV is set to select data after every 5 mins and the db link is also set. also the grants have also been provided.
I inserted the data in master table and data populated in the mlog table.But the problem is that its staying in mlog table and not moved to the "_mv" table even after 1 hr.Even though snaptime is populated with a time of refresh,the refresh didnt happen.
So 3 things here -
1) Why did the refresh didnt happen
2) If the refresh didnt happen because of any issue/error, where can I check what was the issue.
3) To make things worse, there are 17 more tables such similar setup. Some data refresh works sometimes, sometimes not.
Please provide your valuable comments to resolve the same.
Here's a snapshot of the mlog table -
insert into MLOG$_NMS_NUM_SCHM (NMS_SEC_ID, NMS_NMBRNG_SCHM, SNAPTIME$$, DMLTYPE$$, OLD_NEW$$, CHANGE_VECTOR$$)
values ('ZA00ISCDWD', 1, to_date('05-11-2008 11:17:07', 'dd-mm-yyyy hh24:mi:ss'), 'I', 'N', 'FEFF');

Hi,
I have a master table "nms_num_schm" on SID-SLBANCS and its corresponding materialized view "mlog$_nms_num_schm". The MV is supposed to move data from this master table to a table "nms_num_schm_mv" on SID-ORCL.
The MV is set to select data after every 5 mins and the db link is also set. also the grants have also been provided.
I inserted the data in master table and data populated in the mlog table.But the problem is that its staying in mlog table and not moved to the "_mv" table even after 1 hr.Even though snaptime is populated with a time of refresh,the refresh didnt happen.
So 3 things here -
1) Why did the refresh didnt happen
2) If the refresh didnt happen because of any issue/error, where can I check what was the issue.
3) To make things worse, there are 17 more tables such similar setup. Some data refresh works sometimes, sometimes not.
Please provide your valuable comments to resolve the same.
Here's a snapshot of the mlog table -
insert into MLOG$_NMS_NUM_SCHM (NMS_SEC_ID, NMS_NMBRNG_SCHM, SNAPTIME$$, DMLTYPE$$, OLD_NEW$$, CHANGE_VECTOR$$)
values ('ZA00ISCDWD', 1, to_date('05-11-2008 11:17:07', 'dd-mm-yyyy hh24:mi:ss'), 'I', 'N', 'FEFF');

Materialized View Log options

I have read the documentation. I know you can specify options such as 'with primary key' and/or 'with rowid' when creating a materialized view log. Also, that you can specify to include additional columns in the log -and that these can then be seen in the MLOG$ table that gets created. But I don't know why or in what circumstances you'd specify the one or the other, or include columns or not. Can anyone give some example scenarios where you'd do one or the other?

Hello again,
The fundamental reason (why you would specify primary key and/or ROWID) is to facilitate fast refreshes (as opposed to a complete refresh) of the materialized view -- a lot will depend on the MV query itself, and whether one or both of primary key & ROWID are needed, i.e., if there's a COUNT(*) involved, where the primary key would play a role, or without such an aggregate, the ROWID will be necessary (in any case) for fast refresh.
Edited by: SeánMacGC on Jul 9, 2009 5:54 PM
If you run the utlxmv.sql script in $ORACLE_HOME/rdbms/admin, that will create the MV_CAPABILITIES_TABLE, which when you create an MV and execute DBMS_MVIEW.EXPLAIN_MVIEW('your_mview') will populate that with what that MV is capable of, i.e.,
SQL> desc mv_capabilities_table;
Name                                      Null?    Type
STATEMENT_ID                                       VARCHAR2(30)
MVOWNER                                            VARCHAR2(30)
MVNAME                                             VARCHAR2(30)
CAPABILITY_NAME                                    VARCHAR2(30)
POSSIBLE                                           CHAR(1)
RELATED_TEXT                                       VARCHAR2(2000)
RELATED_NUM                                        NUMBER
MSGNO                                              NUMBER(38)
MSGTXT                                             VARCHAR2(2000)
SEQ                                                NUMBER
SQL> select capability_name, possible from mv_capabilities_table;
CAPABILITY_NAME                P
PCT                            N
REFRESH_COMPLETE               Y
REFRESH_FAST                   N
REWRITE                        N
PCT_TABLE                      N
REFRESH_FAST_AFTER_INSERT      N
REFRESH_FAST_AFTER_ONETAB_DML N
REFRESH_FAST_AFTER_ANY_DML     N
REFRESH_FAST_PCT               N
REWRITE_FULL_TEXT_MATCH        N
REWRITE_FULL_TEXT_MATCH        N
REWRITE_PARTIAL_TEXT_MATCH     N
REWRITE_PARTIAL_TEXT_MATCH     N
REWRITE_GENERAL                N
REWRITE_GENERAL                N
REWRITE_PCT                    N
PCT_TABLE_REWRITE              N

Performace issue on MATERIALIZED view

Hi Gurus,
Need help to understand perfoamance issue on MATERIALIZED view. I have created mat view on some big table of 76GB. Mat view is of 25 GB.
I have refreshed mat view before running report. In OEM it ish showng going for full table scan and estimated time is of 2 hrs where full tablescan on base table on which mat view is created is of 20 Mins . I am using fast refresh on demand .
We are using Oracle 10.2.0.4 on Sun Sprac 64bit 10 platform and version.
Could you please let me know what could be the reason why mat views are performing poor ?
Thanks & Regards

You have MLOG created on your master table, right?
OK, then check DBA_MVIEWS. Look for LAST_REFRESH_TYPE, If everything is OK, i should be FAST.
If everything is OK by now, the problem can be the nature of master table. If there is great amount of changes in master table, set periodic job which will do refresh often (since 'often' is fuzzy word, it can be every 5, 10, 30 minutes...). Incremental refresh will perform beter if there is small amount of changes in MLOG table!
You can check your MLOG table. If it is huge (size in MB) and there is only few records in it, try to realocate the space issuing "ALTER TABLE MLOG$_table_name;"
Hope something will be helpfull...
Best regards

Queries about snapshots and snapshot logs in Oracle Ebusiness Suite

Hi ,
We are running Oracle E-business Suite 11.5.8, and have noticed some on-demand snapshots with associated snapshot logs.
The reason we have noticed them is that the snapshot logs have grown large in size (up to 20GB).
What we need to know is why are they growing. As they are on-demand snapshots, something need to refresh them manually, but we do not know what.
Can we purge these logs and reclaim the space, or is there a process involved that we are not doing?
The snapshot details are as follows:
Snapshot log: INV.MLOG$_MTL_SYSTEM_ITEMS_B
Sanpshot table: INV.MTL_SYSTEM_ITEMS_B
Snapshot: INV.MTL_SYS_ITEMS_SN
Snapshot log: INV.MLOG$_MTL_DEMAND
Sanpshot table: INV.MTL_DEMAND
Snapshot: INV.MTL_DEMAND_SN
Snapshot log: INV.MLOG$_MTL_SUPPLY
Sanpshot table: INV.MTL_SUPPLY
Snapshot: INV.MTL_SUPPLY_SN
Regards.

HI,
Please go through below MOS docs:-
When do Snapshot Logs get Purged [ID 35217.1]
SNAPSHOT LOGS GROWS DUE TO MISSING/INVALID SNAPSHOT [ID 1031924.6]
How To Improve the Performance of the Refresh Collection Snapshots When Running Very High Volumes [ID 550005.1]
MLOG$_ENI_OLTP_ITEM_STAR is Growing too Large, can it be Truncated? [ID 367693.1]
Materialized View Refresh : Log Population and Purge [ID 236233.1]
Refresh Collection Snapshots Performance - Managing MLOG$ Tables and Snapshots for Data Collections [ID 1063953.1]
Thanks,
JD

Snap shot delete worker taking time

I am trying to reduce the time taken for a plan to run. specifically reduce the memory based snapshot time,
Are there any profile options/ methods that can be suggested to achieve a significant reduction. Currently the Memory based Snapshot takes about 1hr
the target is to reach 30mins.
previous trials included deleting redundant record pertaining to BOM, from the staging tables, this has however not improved the performance drastically?

Please post the details of the application release, database version and OS.
Do you have the statistics collected up to date?
Please see these docs.
PERFORMANCE ISSUE - REFRESH COLLECTIONS SNAPSHOT WHEN RUN FOR ALL [ID 1067892.1]
Refresh Collection Snapshots Performance - Managing MLOG$ Tables and Snapshots for Data Collections [ID 1063953.1]
How To Improve the Performance of the Refresh Collection Snapshots When Running Very High Volumes [ID 550005.1]
How To Run MSRFWOR - Refresh Collections Snapshots Concurrent Request From The Application [ID 211121.1]
Advanced Supply Chain Planning ASCP Performance TIPS Profile Options [ID 209996.1]
Fast Refresh Is Slower After OATM and 10.2.0.3 Upgrade [ID 875532.1]
MSRFWOR Refresh Collection Snapshots Performance Database Bug 4196039 [ID 369173.1]
Master Note for Materialized View (MVIEW) [ID 1353040.1]
Thanks,
Hussein

MLOG$ TABLES.

Similar Messages

Maybe you are looking for