Does Delete Overlapping Requests drop the BIA index like Selective deletion

Hi,
Does Delete Overlapping Requests process in a chain drop the Accelerator index like Selective Deletion does?

Hi,
No is does not.
-Vikram

Similar Messages

Process Maintenance: Delete Overlapping Requests from InfoCube

Hi Experts,
How can I open Process Maintenance: Delete Overlapping Requests from InfoCube Screen? What's T-code? Is that in Process Chain? Please tell me that....
Thanks in advance,

Hi
'Delete overlapping request' is an option(its a process type) in the process chains..
RSPC>Process types>Load Process and post process folder--->Delete overlapping request from the infocube..
here you can have more options like 'source systems are same',and infosources are same etc...
How to delete most recent request in a Cube by using process chain
Hope it helps
Thanks,
Teja
Edited by: Teja badugu on Apr 28, 2008 11:35 AM

Delete overlapping requests from cube not working in processchain.

In a process chain, 'deletion of overlapping requests from the cube ' step is used.
Before this step a DTP step runs with a full update to load the cube. This process chain is scheduled every day.
Issue is, the process chain failed at the DTP step and after correcting and repeating, the step got executed.
However, the next step after the DTP,'delete overlapping requests from the cube'
gets executed but without deleting the previous day's request.
In the step details a message that 'No request for deletion were found' can be seen.
Then next day when the DTPstep is executed without any problem the 'delete overlapping requests from cube' step is successful
and the previous requests from cube are deleted.
the deletion selections in the step ' delete overlapping request from infocube' is
Delete existing requests
Conditions:
only delete requests from same DTP
Selections
Same or more comprehensive
Because of this issue on a particular day because of the presence of 2 days requests the data is getting aggregated and shown as double in the reports.
Please help.

Hi Archana,
When you delete the bad request from target and before repeating your DTP in PC, make sure the bad request deleted from table RSBKREQUEST also.
If you find the same request in table, first delete the request from table and repeat the DTP in PC.
Now Delete overlapping step should work.
As this is not the permanent solution, please raise an OSS for SAP
Regards,
Venkatesh

Delete overlapping requests identification

Hi guys,
In my Process chain, after a daily full load delete overlapping requests (as part of pc) is setup. How do I identify if something was deleted. The Data Target is a Infocube.

zsl05,
There are two ways you can do the delete overlapping request.
1. In the info package, under the Data Targets tab, the sixth colum if you clcik that push button against the info provider, you will see a pop up saying ''Deleting request from infocube and you can set different options here like simillar info source, data source etc' also you can set 'Do Not delete Requests'. If manual update was done, unless you have selected 'Delete Existing Requests' and condition it cannot have deleted. IT IS ONLY FOR MANUAL LOADS.
2. When you execute thru process chain even if you use the same info package with all this options it won't delete unless you attached the process type 'Delete Overlapping Request' and the info package technical name. If you have not done these setup , you can be sure the data is not deleted, worse yet if you have rolled up as part of your process chain with out this it would have rolled up, you have to fix it by selective deleteion, and more work.
3. If you have done all correctly, the request would have gone, and if it is the only request you would see only one active request with Green under requests all the deleted identical request will be under 'Reconstruction' Tab.
I hope you have done everything right and just need to be sure of it.
Hope this helps, award points if useful.
Goodluck,
Alex (Arthur Samson)

Delete overlaping requests doesnt work with delta

Hello
I need to delete previous request delivered by delta DTP. Process type "Delete overlaping requests from cube" doesnt allow to select delta DTP.
Is it only for full load DTP?
Alex

Hi ,
Delete Overlapping request from cube works only for full loads.
Also if you have any such query regarding DTP functionality please reger this article
http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/10339304-7ce5-2c10-f692-fbcd25915c36
-Vikram

How does Delete overlapping requests work?

We have a extract which does a full loads into a cube for the current year and a we run this daily. In the process chain we do a delete overlapping requests which I understand will delete the previous requests with the same condition. What happens when the year changes? On Dec 31 we will load 2008 data while the next time it runs on Jan 2 it will load only 2009 data (variant only looks at current year). Will deletion of overlaps delete all the 2008 data it loaded on Dec 31? Thanks.

what is removed depends on the settings of your delete request.
You can use only dtp-name, or dtp name with same selection parameters or with same selection parameter in a certain amount of time.
Take a look at the settings; i found them quite self explanatory.

Delete Overlapping Requests from InfoCube: Before or After the Generate Ind

Hi,
Delete Overlapping Requests from InfoCube Before or After the Generate Index of the Infocube? Why?
I think "After", but the system (transaction RSPC)suggest 1.Generate Index 2.Overlapping Requests from InfoCube ...
Thanks
Alessandro

Hi Alessandro,
Bottom Line Index will speed up the Process. While loading the Data you need to delete the Index.
Index will degrade the performence while updating or modifying DB Entries(Loading). Index will improve the performence while reading the DB(Reporting).
It's not with BW. all RDBMS need this.
Regards,
Nagesh.

Delete overlapping requests runs for 5+ hours ...This is too long

We are on BW 3.5 and have a process chain that loads 3 years of data from a cube on the APO Server and AOP data from the BW server into a cube on the BW server. Each load is in its own infopackage. This loads happens every week. We want to delete the loads that occurred the week before using the delete overlapping requests. It is set up as follows:
1.Drop index of Cube
2.Load Current Year data into Cube via Infopackage #1. Loads approximately 32 million records. Selections on calweek: 200701 200752. Infosource: InfoSource for APO-DP Cube from APO(ZAPODP_I11). Datasource: APO-DP Backup Cube(8ZAPODPC73). Source System: APP Client 200(APPCLNT200). The Data targets tab is set up as follows: Automatic Loading of similar/identical requests from the cube wherein Delete Existing Requests Conditions: Infosources are the same. Selections are overlapping.
3.Load Current Year + 1 data into Cube via Infopackage #2. Loads approximately 32 million recordsSelections on calweek: 200801 200852. Rest is same as above #2.
4.Load Current Year +2 data into Cube via Infopackage #3. Loads approximately 32 million recordsSelections on calweek: 200901 200952. . Rest is same as above #2.
5.Load AOP data into Cube via Infopackage #4. Loads approximately 135,000 records. Infosource: AOP Plan(8ZAOPC01). Datasource: AOP Plan(8ZAOPC01). Source System: BW Production(BWPCLNT100). The Data targets tab is set up as follows: Automatic Loading of similar/identical requests from the cube wherein Delete Existing Requests Conditions: Infosources are the same. Selections are overlapping
6.Create index on cube
7.Delete overlapping requests from cube. The process chain step is set up to Use Delete Selections for Infocubes from the Infopackages
The issue is that step #7 runs for more than 5 hours. That is way too long. When we manually delete the requests, it takes 5 minutes. How can I fine tune this processing? Thanks in advance!


What is your dbms? Does it support partitioning? If it does then deleting requests merely drops the corresponding partitions, which should be very fast.
If it does not support partitioning then you're running SQL delete statements to delete the data, which could take a long time if you're deleting tens of million of records. BTW how long does it take to load the same data?
P.S. Just saw your last point about manually deleting the requests taking only 5 minutes. Did you delete one request at a time or multiple request at once? The previous poster wanted to know whether you had background processes to run the deletion job. i.e. Did the deletion really took 5 hours, or did it wait a few hours to start the job?
Message was edited by:
Rick Chau

Proc Chain - Delete Overlapping Requests fails with aggregates

BW Forum,
Our weekly/daily load process chain loads several full (not delta) transaction infopackages. Those infopackages are intended to replace prior full loads and are then rolled up into aggregates on the cubes.
The problem is the process chains fail to delete the overlapping requests. I manually have to remove the aggregates, remove the infopackages, then rebuild the aggregates. It seems that the delete overlapping request fails due to the aggregates or a missing index on the aggregates, but I'm not certain. The lengthy job log contains many references to the aggregate prior to it failing with the below messages.
11/06/2004 13:47:53 SQL-END: 11/06/2004 13:47:53 00:00:00                                                 DBMAN        99
11/06/2004 13:47:53     SQL-ERROR: 1,418 ORA-01418: specified index does not exist                        DBMAN        99
11/06/2004 13:47:59 ABAP/4 processor: RAISE_EXCEPTION                                                       00        671
11/06/2004 13:47:59 Job cancelled                                                                           00        518
The raise_exception is a short dump with Exception condition "OBJECT_NOT_FOUND" raised.
The termination occurred in the ABAP program "SAPLRRBA " in
"RRBA_NUMBER_GET_BW".
The main program was "RSPROCESS ".
I've looked for OSS notes. I've tried to find a process to delete aggregates prior to loading/deletion of overlapping requests. In the end, I've had to manually intervene each time we execute the process chain, so I've got to resolve the issue.
Do others have this problem? Are the aggregates supposed to be deleted prior to loading full packages which will require deletion of overlapping requests? I presume not since there doesn't seem to be a process for this. Am I missing something?
We're using BW 3.3 SP 15 on Oracle 9.2.0.3.
Thanks for your time and consideration!
Doug Maltby

Are the aggregates compressed after the rollup? If you compress the aggregate completely, the Request you are trying to delete is no longer identifiable once it is in the compressed E fact table (since it throws away the Request ID).
So you need to change the aggregate so that it the most recent Requests remain in the uncompressed the F fact table. Then the Request deletion should work.
I thought what was supposed to happen if the aggregate was fully compressed and then you wanted to delete a Request, the system would recognize that the Request was unavailable due to compression and that it would automatically refill the aggregate - but I'm not sure where I read that. Maybe it was a Note, maybe that doesn't happen in a Process Chain, just not sure.
The better solution when you regularly backout a Request is just not the fully compress the aggregate, letting it follow the compression of the base cube, which I'm assuming you have set to compress Requests older than XX days.

Non-compressed aggregates data lost after Delete Overlapping Requests?

Hi,
I am going to setup the following scenario:
The cube is receiving the delta load from infosource 1and full load from infosource 2. Aggregates are created and initially filled for the cube.
Now, the flow in the process chain should be:
Delete indexes
Load delta
Load full
Create indexes
Delete overlapping requests
Roll-up
Compress
In the Management of the Cube, on the Roll-up tab, the "Compress After Roll-up" is deactivated, so that the compression should take place only when the cube data is compressed (but I don't know whether this influences the way, how the roll-up is done via Adjust process type in process chain - will the deselected checkbox really avoid compression of aggregates after roll-up OR does the checkbox influences the manual start of roll-up only? ).
Nevertheless, let's assume here, that aggregates will not be compressed until the compression will run on the cube. The Collapse process in the process chain is parametrized so that the newest 10 requests are not going to be compressed.
Therefore, I expect that after the compression it should look like this:
RNR | Compressed in cube | Compressed in Aggr | Rollup | Update
110 |                    |                    | X      | F
109 |                    |                    | X      | D
108 |                    |                    | X      | D
107 |                    |                    | X      | D
106 |                    |                    | X      | D
105 |                    |                    | X      | D
104 |                    |                    | X      | D
103 |                    |                    | X      | D
102 |                    |                    | X      | D
101 |                    |                    | X      | D
100 | X                  | X                  | X      | D
099 | X                  | X                  | X      | D
098 | X                  | X                  | X      | D
If you ask here, why ten newest requests are not compressed, then it is for sake of being able to delete the Full load by Req-ID (yes, I know, that 10 is too many...).
My question is:
What will happen during the next process chain run during Delete Overlapping Requests if new Full with RNR 111 will already be loaded?
Some BW people say that using Delete Overlapping Requests will cause that the aggregates will be deactivated and rebuilt. I cannot afford this because of the long runtime needed for rebuilding the aggregates from scratch. But I still think that Delete Overlapping should work in the same way as deletion of the similar requests does (based on infopackage setup) when running on non-compressed requests, isn't it? Since the newest 10 requests are not compressed and the only overlapping is Full (last load) with RNR 111, then I assume that it should rather go for regular deleting the RNR 110 data from aggregate by Req-ID and then regular roll-up of RNR 111 instead of rebuilding the aggregates, am I right? Please, CONFIRM or DENY. Thanks! If the Delete Overlapping Requests still would lead to rebuilding of aggregates, then the only option would be to set up the infopackage for deleting the similar requests and remove Delete Overlapping Requests from process chain.
I hope that my question is clear
Any answer is highly appreciated.
Thanks
Michal

Hi,
If i get ur Q correct...
Compress After Roll-up option is for the aggregtes of the cube not for the cube...
So when this is selected then aggregates will be compressed if and only if roll-up is done on ur aggregates this doesn't affect ur compression on ur cube i.e movng the data from F to E fact table....
If it is deselected then also tht doesn't affect ur compression of ur cube but here it won't chk the status of the rollup for the aggregates to compress ur aggregates...
Will the deselected checkbox really avoid compression of aggregates after roll-up OR does the checkbox influences the manual start of roll-up only?
This check box won't give u any influence even for the manual start of roll-up....i.e compression of aggreagates won't automatically start after ur roll-up...this has to done along with the compression staus of cube itself...
And for the second Q I guess aggregates will be deactivated when deleting oveplapping request if tht particular request is rolled up....
even it happens for the manual deleting also..i.e if u need to delete a request which is rolled up and aggregates are compressed u have to deactivate the aggregates and refill the same....
Here in detail unless and until a request is not compressed for cube and aggregates are not compressed it is anormal request only..we can delete without deactivating the aggregates...
here in urcase i guess there is no need to remove the step from the chain...
correct me if any issue u found......
rgds,

Delete Overlapping requests question

Hi ,
How would a Delete overlapping requests (DOR)type work in a PC to a Cube that gets a full load every day with selections for rolling 12 months?
Say there is a scenario to load data into an AR line items cube to update open to closed items history and the loads are configured for a 12 month rolling. eg yesterdays full would be for 03/23/09 to 03/23/10
today's 03/24/09 to 03/24/10
Now how can we utilize DOR instead in a PC that would delete the doubling behaviour of data for dates 03/24/09 to 03/23/10?
All thoughts appreciated.
Thanks

Hi,
in The selection criteria of the info package u can have the following code which takes the selection criteria as the first day to last day of the month based on previous days date(SY-DATUM - 1.)
data: l_idx like sy-tabix,
        dDATE1 LIKE SY-DATUM,
        dDATE LIKE SY-DATUM,
        L_LOW LIKE RSSDLRANGE-LOW,
        L_HIGH LIKE RSSDLRANGE-HIGH.
read table l_t_range with key
       fieldname = 'END_SHIFTDATE'.
l_idx = sy-tabix.
dDATE1 = SY-DATUM - 1.
CALL FUNCTION 'ZFNC_FIRSTDAY_MONTH'
    EXPORTING
      DDATE      = dDATE1
    IMPORTING
      DLAST_DATE = dDATE.
L_LOW         = dDATE.
L_T_RANGE-LOW = L_LOW.
L_T_RANGE-SIGN   = 'I'.
L_T_RANGE-OPTION = 'BT'.
CLEAR dDATE.
CALL FUNCTION 'ZFNC_LASTDAY_MONTH'
    EXPORTING
      DDATE      = dDATE1
    IMPORTING
      DLAST_DATE = dDATE.
L_HIGH         = dDATE.
L_T_RANGE-HIGH = L_HIGH.
modify l_t_range index l_idx.
and DOR deletes the previous day's request as the selection criteria is same. on first day of the next month it has a request with selection criteria as first to last date of the previous month. and this request is not deleted since on 2nd of the month it has different selection criteria(Start daay and end day of that month)
Hope its clear
Thanks,
Sandeep

Delete Overlapping Request from InfoCube.

Hello,
I am using process Type "Delete Overlapping Request from infocube" in this I am selecting object type as a "DTP"
Under "Delete Selection" I am selecting following
1. Only Delete Requests from same DTP
2. Only Delete Full DTP request
3. Only Delete DTP Requests from Same Source
I am using "Full Load" in my DTP.
My requirements are like I need to delete old data and load new data every day in to a cube for that I am using this process type.
If anybody have better solution please let me know.
Thanks,

Also
I am not deleting Index OR Not creating Indexs while using process type "Deleting overlapping request InfoCube"
what will be the impact on the cube?
How many index will have infocube?
If the cube having more than one index if i delete index, which index will be deleted?
Thanks,

Delta DTP and Delete Overlapping Requests

Hi,
Please check the article:
http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/10339304-7ce5-2c10-f692-fbcd25915c36
-Vikram

Hi
In the Delete Overlapping Requests from Infocube Process there is an button Deletion Selections Check what are all the options selected in that there are some 3 check boxes like
a) Only Delete Requests from Same DTP
b) Only Delete Full DTP Requets
c) Only Delete DTP Requests from Same Source
if option B is checked it will work only for Full Requests not for Delta. Check the same in your system.
Thanks

Process Type - Delete overlapping requests from an Info Cube

I have read many threads on this topic, still have some questions. To give you background, I will be doing delta load (delta process chain). But before delta, I want to do setup initialization (init process chain). I want to use this process type in my init process chain to delete all data in my cube loaded from a specific ods. I cannot use delete all contents process type because many odss feed the same cube.
1.     Do you put this process type after Load Data or before Load Data. I have seen both cases in SDN forums.
2.     Variant of this process type is an info package. Does this info package have to be same as in load data step or it can be different.
3.     I want to delete all data in cube which was loaded from my ods. Term overlapping is confusing to me. Will this process type delete all data or not.
Tanks in advance.

Yes, you can do that. Goto RSPC - under process types Load Process and Post Processing, you will see DELETE OVERLAP REQUESTS FROM INFOCUBE option is there.
Select the proper check boxes like same sourcesystem, same datasource etc...
If it is one time deletion, why not do that manually?
Also check: How to delete most recent request in a Cube by using process chain
Hope it helps..

Delete overlapping requests of same DTP from cube

Dear All,
i want to delete over lapping requests of same DTP in cube, but here while i am searching for the DTP in process variant, the system is not showing the DTP(it is active).
can you people have any suggestions.
Br,
Vamshi.

Hey Vamshi,
Is your DTP a full one or delta one ? Delete Overlapping reqs is not possible for Delta loads.
In Load Process and Post-Processing option you will find Delete Overlapping Requests from InfoCube, drag and drop and make the following settings:
Object Type = DTP
Object Name : DTP Name.
Check Edit all InfoCubes with the following Delete Selections and click on Delection Selection
Check Delete Existing Request and check Only Delete Req from same DTP
Activate and execute the PC.
Hope this helps!
Sheen

Does Delete Overlapping Requests drop the BIA index like Selective deletion

Similar Messages

Maybe you are looking for