Delta and Complete Refresh

Hi,
What is significance of Cache Refresh (SXI_CACHE)?
And what is difference between Delta Refresh and Complete Refresh?
Thanks and Regards,
Vijay Raheja

Hi Vijay,
You can view all cached objects by running transaction SXI_CACHE. You can see whether the cache is up-to-date or not. You can view all cached data and start a manual cache refresh.
If you suspect that a change in a Integration Directory has not been replicated to the runtime cache, you can refresh the cache manually. To refresh the cache in SXI_CACHE, from the menu choose XI runtime Cache.
In a Delta cache all the data are not replicated. Only the data that is changed from the last cache is updated.
Hope this clarifies.
Regards.
Praveen

Similar Messages

Delta and complete cache refresh.

HI,
Difference between Delta and complete cache refresh.
thanks
sunil

Hi,
There are several variants of the cache refresh mechanism depending on the scope of the cache refresh (delta only or entire cache refresh) and on the triggering component (tool or messaging component).
Delta Cache Refresh
Delta Cache Refresh involves the missing activated change lists to be included in the directory cache.
Complete Cache Refresh
To restructure the cache completely, in the menu bar choose XI Runtime Cache à Start Complete Cache Refresh.
Cache refreshing means getting the newly created component in the cache. Usually cache get refreshed automatically by SAP system and user do no thave to refresh it but in some cases the newly created component does not get dispalyed in cache. In that case this cache should be refreshed and it will pull out the new component in it.
Thanks
Swarup

Help understanding fast and complete refresh

hi
-i have a table with 3 rows with col2='T' and 1 column with col2=null.
-my query(fast refresh) is "select * from table where col='T'"
-after first sync the 3 rows are on my mobile.
-then i set col2='T' in 4th row and make a sync with msync, but on my mobile are only 3 rows after the sync.
with complete refresh all 4 rows would be on my mobile.
but what will happen with changed data in my 3 rows on mobile at this complete refresh???
i want this 4th row on my mobile too without change the changes in my 3 rows on mobile.
thx
rico

If you are using fast refresh, then after changes are made on the server side,, the MGP compose process must run to build the out queue data for the client before the change will be available for download.
For tables with a fast refresh, if you look at the database, you will see when you publish, three triggers are created for the base table (<tablename>1/u/d) and a table CLG$<tablename> (there are others as well). when a change is made, it will fire the triggers. this will but the primary key of the changed record into the CLG$ table, and also create a record in mobileadmin.c$all_sid_logged_tables. this triggers the list of objects to process for the compose cycle.
the MGP compose sometimes stops processing for no apparent reason, so this may be a problem. Also for snapshots on tables, this works fine. If however the object is a view, or the column is derived (say from a function) the trigger just goes on the base table(s), if the base table data does not change, no data will be composed.
complete refreshes should not necessarily take longer to process (may be longer to download if a big table), but have the disadvantage of overwriting data just created on the client. this will not re-appear until the next synchronise (after it has been posted to the server) - this is the main disadvantage

Materialized view (creating and complete refresh)

Good day.
I have a huge query that is used to create a materialized view. The query consist of 9 joins, a lot of aggregations, some subqueries, so we can say it is rather huge. The query itself executes for about 30 seconds and returns about 200 rows. The materialized view creates and refreshes for more than 30 minutes. Can someone please explain me the mechanism of materialized view creation which causes such bad performance.
We use Oracle Database 9.2.0.4.
Thank you in advance.

I've fount the solution. May be it will be useful for someone not regarding that 9.2 database is less used today than 10.2.
I studied carefully the plan of the query and the plan of insert statement that is used when creating materialized view and found the cause of trouble. Insert statements generates VIEW PUSHED PREDICATE and BITMAP CONVERSION FROM ROWIDS when parsing. Bitmap conversion can be removed by setting environment parameter btree_bitmap_plans to false (a well-known issue), but I decided not ot change the production environment. The pushed predicate can be removed by using hint NO_PUSH_PRED to each subquery used in a materialized view. This step reduced the time of materialized view creation and execution to about a minute.
Thank everyone who tried to help.

OLAP Re-Aggrigation functionality or Alternative for complete refresh

I have a question related with reaggrigation.
My scenario:
1) I have Product Dimension (dim) and Sales Cube.
2) In Sales Cube, product dim is used.
3) In first time, i have complete refresh of dim and cube.
4) But if i modify data in Product dim for one of hierarchy and complete refresh of dim. So new data will available in product dim and after that i have to complete refresh of Sales cube to get reflect new dim hierarchy data.
5) My question is, if i have changed data in dim for one of hierarchy and complete refresh. So is there any way that i can get this data in cube without complete refresh? Is there any re-aggregation functionality in oracle OLAP cube to get data reflect in cube without complete refresh?
Please answer soon?
Thanks in adv.

Try enabling the materialized view logs on source star schema (dim/fact tables) i.e. create all objects as advised by Relational Schema Advisor in Materialized Views tab of cube ... sales cube in your case.
This will enable you to achieve a compromise - F - Fast Refresh or ? - FAST SOLVE capability automatically ... (w/o need to code/alter your maintenance scripts in response to changing hierarchy nodes)
a) If only facts have changed, then the cube will be refreshed via FAST REFRESH (only modified partitions of cube) will be loaded.
b) If dimension/facts have changed, then worst case scenario is a FAST SOLVE in which the entire table is reloaded but the cube solve/aggregation will still be incremental (involving a recalc of the modified/"relevant" part of the hierarchy alone). Doing this is quite simple refesh the cube via call to DBMS_CUBE.REFRESH passing '?' for method.
=> Presence of materialized view logs etc will ensure that the relational load to cube is optimal (if loading a section of fact table is sufficient it will do so).
=> Olap materialized view related metadata will ensure that the olap side post load aggregation/solve is optimal (if only a section/branch of hierarchy is needed to be recalculated then it will only re-aggregate the affected portion of hierarchy/cube)
c) Try to control your etls to ensure that dimension hierarchy change is a low frequency occurrence => Load facts multiple times in a day from source system (every hour if needed) but allow resync or reload of dimension hierarchy tables only once a day if its ok with business users.
More details:
1) Adding Materialized View Capability to a Cube: http://docs.oracle.com/cd/E11882_01/olap.112/e17123/cubes.htm#OLAUG9156
2) DBMS_CUBE.BUILD procedure: http://docs.oracle.com/cd/E11882_01/appdev.112/e40758/d_cube.htm#ARPLS65742
HTH
Shankar

Snapshot Refresh (How to stop COMPLETE refresh and run FAST refresh)?

Hi,
I have a snapshot refresh executed as COMPLETE which is taking very long. When I try to kill this and try to run a FAST I get:
ERROR at line 1:
ORA-12057: materialized view "PORTALSNP1"."V21_BILLING_ACCOUNT" is INVALID an must complete refresh
How can I resolve this to stop the COMPLETE refresh altogether and be able to run the FAST refresh.
Also is there a way to get the time it will take to complete the running snapshot refresh?
Please and thankYou!
Regards,
A

You don't resolve it ... you drop the materialized view. Then you create a materialized view log. Then a properly coded MV.
http://www.morganslibrary.org/library.html
bookmark this link
then look up "Materialized Views and "Materialized View Logs"
The log must be created first.

Error in INTEGRATION_DIRECTORY_HMI and CACHE REFRESH

Hi guys, well after checking the forum and several blogs i can't get rid of my problem!
I have a problem concerning INTEGRATION_DIRECTORY_HMI and CACHE REFRESH.
i wanted to get a file from a FTP-Server via CC and i got error:
<SAP:AdditionalText>Error when reading HTTP destination: INTEGRATION_DIRECTORY_HMI.</SAP:AdditionalText>
<SAP:ApplicationFaultMessage namespace="" />
<SAP:Stack>Error while refreshing the XI runtime cache</SAP:Stack>
<SAP:Retry>M</SAP:Retry>
Because of this i tried to update my cache (SXI_CACHE). When i do a Delta Cache Refresh i get:
Prefix Number: entry missing for system SSID client 100.
When i do a complete Cache Refresh nothing happens at all. I also checked the cache notification in IB - Integration Directory where i fin dout that only the Integration Server (ABAP Cache) won't refresh. Well status is started but nothing else is happening.
Then i checked the RFC INTEGRATION_DIRECTORY_HMI, did a connection test where i get an Internal Server error.
Let me tell u that the systems runs very well in the last days but now i have no clue what might be wrong.
Can somebody please advice me? I already read all blogs concerning this and also did a complete system-restart....
br Jens

when you check INTEGRATION_DIRECTORY_HMI with SM59 it is normal to get
HTTP Response 500 - Internal Server Error. In this case it meens everything OK
see the rediness check, that is attached to SAP note 817920
when you start the complete cache refresh, you can see
the function module SAI_CACHE3_REFRESH_BACKGROUND in SM58. As long as you can see this entry, the cache
refresh is ongoing. If the refresh takes too long and runs on an error, try to specify another timeout in INTEGRATION_DIRECTORY_HMI or in the ICM
Best Regards
Alexander
Message was edited by:
        Alexander Wrobel
Message was edited by:
        Alexander Wrobel
Message was edited by:
        Alexander Wrobel

Problems in SLD and Cache refresh (SXI_CACHE).

Dear Experts,
I am facing SLD and Cache refresh problems in PI 7.0 on HP-UX.
1) SXI_CACHE : Last Error During Cache refresh is showing LCR_GET_OWN_BUSINESS_SYSTEM - NO_BUSINESS_SYSTEM error. And also Start Delta Cache Refresh / Start Complete Cache refresh are in deactive mode (Frozen).
2) SLDCHECK : Log says No Business System for ABC Client 100 ".
where ABC=SID. Business System INTEGRATION_SERVER_ABC is declared in SLD and client 100 is assigned.
My question is : Is this a BASIS or DEVELOPER issue? Also please let me know if you have any solutions for the above mentioned issue. Thanks in Advance.
SLDCHECK Log Snippet:
SLD server access settings:
host name: ABCXIDEV
port number: 50000
user : PIAPPLUSER
Use transaction SLDAPICUST if you wish to maintain the SLD server access data
Launching the SLD GUI in a separate browser window...
=> Verify in the browser GUI that the SLD is in a healthy running state!
Calling function LCR_LIST_BUSINESS_SYSTEMS
Retrieving data from the SLD server...
Function call terminated sucessfully
List of business systems maintained in the SLD:
INTEGRATION_SERVER_ABC
ERP_DEV_100
Calling function LCR_GET_OWN_BUSINESS_SYSTEM
Retrieving data from the SLD server...
No corresponding business system found for system ABC client 100
=> Check and maintain the SLD content for the current client

Hello,
Since this is an PI system, your XI consultant must have created/will need to create business systems in SLD for the scenario to work properly. This error is because it cannot find the business system.
You cannot point out the fingers on Basis or XI and say that it is THEIR issue. Please consult with the consultant who is doing the XI interface and check if the business systems he require are properly created in SLD. If not, create them or ask them to create it (if they are allowed to..).
From the error, what i can see is that you have defined an integration server INTEGRATION_SERVER_ABC in SLD . the XI interface is checking the required business system in the integration server INTEGRATION_SERVER_ABC in SLD but cannot find it over there. Please check the integration server INTEGRATION_SERVER_ABC in SLD and talk to the XI consultant and you will be able to fix this with their help.
Hope this helps you..
Regards,
Jazz

Materialized view fast refresh or complete refresh?

Hi Guys,
Need help here.
We were ask to provide recommendation regarding the replication of our Production schema to Reporting Schema.
Here are the conditions:
1. Production schema and Reporting schema resides in one database server, only in different instance.
2. Tables to replicate is more or less 300 tables.
3. They only want to replicate changes that happen on the table on the said day.(insert,update)
4. Replication will only happen on the end of business hours(end of day).
What we have in mind is Materialized view.
What would be best to use, fast refresh or complete refresh?
What will be the effect on performance?Resources?
Or will there be any other method?
Appreciate your reply on this.
Thanks,
Nina

Using MV (Materialized views) is onle of the possible way how to do what you are asked for.
Fast refresh of MV is faster than complete refresh because it's based on "deltas" from last refresh. But it require MV log on table in primary DB. This MVLog consume same space in tablespace. And maintainig this MVlog during DML operation on table add some overhead to DML operation -> it's take a little bit longer time to complete.
How much space is consumend by MV log depends on many factors:
1/ number of DML changes on table
2/ number of consumers (there can be more than on MV based on same table using same MV log)
3/ period of MV refresh
Plus of using MV is that it is very simple and you don't need no special license to use them.
Other possible option is Golden gate (Streams previously)
Next option is procedural replication - you have to write your own replication mechanism.

Peformance on complete refresh of a Materialized View

We are currently doing a complete refresh of a materialized view (35 mil rows) on a monthly basis. My question is would it be faster to disable all the indexes prior to refresh? if so, should we enable the indexes or simply rebuild and which would be faster? Below is the package we are calling to refresh the MV. Also, our platform is Oracle 11g1 Rac on Solaris 10. Thanks.
DBMS_MVIEW.REFRESH(MVIEW_NAME, 'C', ATOMIC_REFRESH => FALSE, PARALLELISM=>16);

Trace it and see.
With ATOMIC_REFRESH set to FALSE, Oracle would be doing a TRUNCATE. See if it does a Direct Path Insert. (It should be doing so).
In which case, Index maintenance is deferred to the end.
Yet, Oracle builds "temporary" index segments when doing the insert and merges them later.
You might still get a performance benefit from setting the indexes to UNUSABLE (or DROPping them) and then doing a REBUID/CREATE with NOLOGGING and a different degree of Parallelism.
You'd have to test it yourself and see what the difference is.
Hemant K Chitale

Issue with complete refresh on materialized view when using rownum

Hi all,
I had an issue with rownum when using complete refresh
I am using rownum when creating materialized view and it is generation correctly.But the issue was when i am refreshing the same ,rownum was not getting sorted in ascending order.
anyone had come across this scenario

rownum is determined as the row is output, so "order by rownum" does literally nothing.
http://docs.oracle.com/cd/B19306_01/server.102/b14200/pseudocolumns009.htm

Issue in Complete Refresh of a Materialized View

Hello,
We have an MV in the Datawarehouse that does a FAST REFRESH daily. Every Saturday, a COMPLETE REFRESH is done as part of the normal Database Activities. The Database is Oracle 9i. The MV contains a Join between a Dimension and Fact Table of a Datawarehouse and does a FAST REFRESH using the MV logs.
However, last Sat, the COMPLETE REFRESH has failed. The DBA tried to run the script twice again but it failed on both occasions with an UNDO TABLESPACE error (ORA-30036). The DBA tried to extend the Tablespace; it did not help either.
- Could this be linked to Tablespace allocations for the MV? Are there any specific steps that can be followed to resolve this?
- Can the MV be dropped and re-created?
Would appreciate a response on the same.
Many Thanks,
Ketan

Hi Ketan,
I guess this is probably because MV complete refresh performs "delete" from the MV and then insert. If the MV is large, it may fail on undo allocation.
Please take a look at Re: materialized view refresh time! Plz Help me! you can see the explanation, metalink note and the solution (how to perform truncate instead of delete).
HTH
Liron Amitzi
Senior DBA consultant
[www.dbsnaps.com]
[www.orbiumsoftware.com]

Issue with materialized view and fast refresh between Oracle 10g and 11g

Hi all,
I've hit a problem when trying to create a fast-refreshable materialized view.
I've got two databases, one 10.2.0.10, another 11.2.0.1.0, running on 32-bit Windows. Both are enterprise edition, and I'm trying to pull data from the 10g one into the 11g one. I can happily query across the database link from 11g to 10g, and can use complete refresh with no problem except the time it takes.
On the 10g side, I've got tables with primary keys and m.v. logs created, the logs being of this form ...
CREATE MATERIALIZED VIEW LOG ON table WITH PRIMARY KEY INCLUDING NEW VALUES
On the 11g side, when I try to create an m.v. against that ...
CREATE MATERIALIZED VIEW mv_table REFRESH FAST WITH PRIMARY KEY AS SELECT col1, col2 FROM table@dblink;
... I get an ORA-12028 error (materialized view type is not supported by master site).
After running the EXPLAIN_MVIEW procedure it shows this;
REFRESH_FAST_AFTER_INSERT not supported for this type mv by Oracle version at master site
A colleague has managed to build a fast-refresh m.v. from the same source database, but pulling to a different one than I'm using; his target is also 10g, like the (common) source, so I've no idea why I'm getting the 'not supported' message whilst he isn't.
I've been able, on previous projects, to do exactly what I'm trying to achieve but on those someone with more knowledge than me has configured the database!
I'm now stumped. I'm also no DBA but despite that it's been left to me to install the new 11g database on the 32-bit Windows server from scratch, so there are probably a couple of things I'm missing. It's probably something really obvious but I don't really know where to look now.
If anyone can give me any pointers at all, I'd be really grateful. This question is also duplicated in the Replication forum but hasn't had any replies as yet, so I'm reproducing it here in hope!
Thanks in advance,
Steve

Hi Steve,
You should have a look at metalink, Doc ID 1059547.1
If that does not help, there may be something else in Mater note ID 1353040.1
Best regards
Peter

Materialized View Initial Creation vs Complete Refresh - MAJOR differences

Hi All,
I am currently in the process of setting up MV's for replication via a DBLink and have noticed something that I find quite odd. Basically If I create an MV I get v. large differences than when I do a complete refresh on the same MV after the initial "load". Actual stats are shown below :
Action TimeTaken Undo Reqd (Bytes)
Initial Load 00:01:07 37254998
Complete Refresh 00:02:41 463919012
Question is why does a complete refresh require 12x the amount of Undo than the creation of the MV? I though tit would be roughly the same or at most twice as much?
The Instance is only being used by myself so no other processes are causing this difference and this can be reproduced. Undo calculated from V$ROLLSTAT.
Thanks
MH

Hi tekicora,
Thanks for your help and suggestions. I have tried this method of evaluating UNDO with the following results:
STATISTIC# NAME SID VALUE
176 undo change vector size 115 132
CREATE MATERIALIZED VIEW mytest1
TABLESPACE TABSPACEA NOLOGGING BUILD IMMEDIATE
USING INDEX TABLESPACE TABSPACEB REFRESH FORCE WITH ROWID ON DEMAND AS
select * from ptable@remdb;
STATISTIC# NAME SID VALUE
176 undo change vector size 115 332860
exec DBMS_MVIEW.REFRESH('MYTEST1', 'C',ATOMIC_REFRESH=>TRUE);
STATISTIC# NAME SID VALUE
176 undo change vector size 115 261460092
exec DBMS_MVIEW.REFRESH('MYTEST1', 'C',ATOMIC_REFRESH=>FALSE);
STATISTIC# NAME SID VALUE
176 undo change vector size 115 272282756
This is still creating masses of undo (particulalry atomic refresh). Could this be because mv table source is on a remote db?
Thanks
Mark H
Message was edited by:
markyb0y

Materialized View Fast Refresh been ignored For Complete refresh.

Hi,
I have a script that create a materialised view with a refresh method of 'FAST'.
When I refresh the view on one machine it refreshes using the 'FAST' method (i.e. LAST_REFRESH_TYPE = FAST) in 22 seconds, however, when I run the same script on a different machine the database chooses a 'COMPLETE' refresh method, despite me stating explicitly for it to use the FAST method. The complete refresh completes in about four hours.
Does anyone know the logic that Oracle uses in determining the type of refresh to use?
Thanks.

Assuming that the Materialized View definition is the same (and doesn't conflict with any FAST REFRESH requirements for that specific Oracle Version), check to see if the source table(s) has/have Materialized View Logs defined on them. MV Logs with PK/Rowid would be required.
Hemant K Chitale

Delta and Complete Refresh

Similar Messages

Maybe you are looking for