data loading in cube with init/delta after full update m/d

Question: [color=blue][size=18]Hello guys,
Is it possible to run initialize delta process update mode after loading the data using full update. this issue is related to 0fi_ap_4 where we have uploaded the data from r/3-->psa-->ods-->infocube using full update mode but now we want to reset the update method to delta.
cheers[/size][/color]

Answer:
in an ODS object you can't mix full loads and delta loads (there is one exception - see OSS)
in an InfoCube that's no problem

Answer:
EL is rite

u cant do INITS after FULL update,so plan accordingly while designing ODS.
_________________
Chetan
@ CP...

Answer:
Hi CHETAN

Does it mean that SAP has not provided to do INITS after Full Loads.
Then how do we solve these problem??
If u are in the middle of the project and u have loads of data say history data for 2 years in millions.


Thanks in advance

Answer:
(there is one exception - see OSS)

PS this is only valid for ODS objects... you don't want to load history into ODS's, do you???

Answer:
(there is one exception - see OSS)

Just read OSS Note 689964 ... think this will explain things

Answer:
Fanna, when i said it cant means with the DESIGN of ODS yes u cannot but there was an exception as mentioned by EL and TFR the note 689964 explains well

Explaination :-
In the case if an ODS object, you can change the upload procedure from full to delta by subsequently marking the full requests that exist in the ODS object for this DataSource/source system combination as repair full requests.

These requests are therefore characterized by the fact that they can be posted into any data targets in any sequence. The repair full requests are never checked in a data target, that is, you can activate initializations and deltas (also with selections) in the ODS object. All ODS objects filled with these full requests behave as if the full requests did not exist in the ODS object.Checks do not take place in all of these ODS objects.

Procedure for changing full requests to repair full requests:

Use transaction SE16 to call the RSSELDONE table.

Here, enter an "x" in the "Repair_Full" field for all full request records that you want to mark as repair full requests.
_________________
Chetan
@ CP...

Answer:
I am working on scenario: Same InfoSouce connected to multiple ODS's (same ODS design with different selection criteria)

Did a full load on ODS A, activated ODS

2. Did a full load on ODS B, activated ODS

3. Noted the request (REQU_) for ODS A,
then SE11 -> RSSELDONE -> REQU_ -> REPAIR_FULL = 'X'

4. Repeated step 3 for ODS B REQU_

5. Scheduler -> Infopackage related to ODS A REQU_ -> Update mode = Init Delta (Init w/o data transfer checked). Activation of ODS A with that 1 record (delta) was successful

6. Repeated step 5 with Infopackage related to ODS B REQU_ ->
Activation of ODS B is unsuccessful as it is expecting to upload the ODS A REQU_ first ??

am I missing something here ???

Answer:
Can I mention an alternative method. It means more ODS objects, which could mean it's not appropriate for this application.

If you load full loads into a copy of your ODS, then load from the copy ODS to the original ODS, then initialise the delta into the original ODS, there will be no problem with delta management. An ODS has not problem if one datasource is a full load, and another a delta.

It means you are removing the risk of changing control table entries.

Ken

Answer:
I am working on scenario: Same InfoSouce connected to multiple ODS's (same ODS design with different selection criteria)

Did a full load on ODS A, activated ODS

2. Did a full load on ODS B, activated ODS

3. Noted the request (REQU_) for ODS A,
then SE11 -> RSSELDONE -> REQU_ -> REPAIR_FULL = 'X'

4. Repeated step 3 for ODS B REQU_

5. Scheduler -> Infopackage related to ODS A REQU_ -> Update mode = Init Delta (Init w/o data transfer checked). Activation of ODS A with that 1 record (delta) was successful

6. Repeated step 5 with Infopackage related to ODS B REQU_ ->
Activation of ODS B is unsuccessful as it is expecting to upload the ODS A REQU_ first ??

am I missing something here ???

Hi
Uptill steps 5 every thing seems to be perfect and the fact that it allowed u to do an INIT after Full is the evidence of that.

can u plz elaborate more on the Error message it throwed??

Hope it helps
_________________
Chetan
@ CP...

Answer:
When I tried to repeat Step 5 - Activating the second ODS (with different Init Selections)....it is retrning with the following

*************************************************************
ODS object B was built incorrectly. Cannot update request REQU_

Message no. RSM1147

Diagnosis
Request ABC (of ODS A) has still not been uploaded.

System response
The system cannot upload request REQU_(&V3).

Procedure
You can find information and the monitor log for a request in data load monitor for a single request. You can also display the assignment of a request number to a SID here by selecting the request number in the header tab page.

First upload request ABC (of ODS A) to ODS-B.

*************************************************************

Is it because, the Delta Queue in R/3 is already set when Init was performed for ODS A.

Can we use same Infosource to link multiple ODS's with different selections and to make them delta capable (for each selection criteria in ODS's)

Answer:
When I tried to repeat Step 5 - Activating the second ODS (with different Init Selections)....it is retrning with the following

*************************************************************
ODS object B was built incorrectly. Cannot update request REQU_

Message no. RSM1147

Diagnosis
Request ABC (of ODS A) has still not been uploaded.

System response
The system cannot upload request REQU_(&V3).

Procedure
You can find information and the monitor log for a request in data load monitor for a single request. You can also display the assignment of a request number to a SID here by selecting the request number in the header tab page.

First upload request ABC (of ODS A) to ODS-B.


Quick question -is your ODS B loaded from ODS A with Init/Delta.
Shouldnt be a problem in any case though just a sanity check.

Is it because, the Delta Queue in R/3 is already set when Init was performed for ODS A.

Can we use same Infosource to link multiple ODS's with different selections and to make them delta capable (for each selection criteria in ODS's)


Answer is with NON-OVERLAPPING Selection criteria u can do multiple Inits/Delta with same/different Datasources.

Hope it Helps
_________________
Chetan
@ CP...

Answer:

Quick question -is your ODS B loaded from ODS A with Init/Delta.
Shouldnt be a problem in any case though just a sanity check.

NO, ODS B is not loaded from ODS A. But when I tried to do Init for ODS B, I can see init (funds range) of ODS A in Scheduler -> Init opions for source system. Is it because of the same Infosource for the two ODS objects ??


Answer is with NON-OVERLAPPING Selection criteria u can do multiple Inits/Delta with same/different Datasources.

I am using different selection criteria for each ODS which is not overlapping.

Ex:
Scheduler -> Funds (10000 - 10999 only) -> Init Delta for ODS A
Scheduler -> Funds (20000 - 20999 only) -> Init Delta for ODS B

As said, activation of ODS B terminates with the above message (from above post ...... First upload request ABC (of ODS A) to ODS-B.

Answer:
I'm also trying to do something similar to this. I don't have a problem with following the rule of doing Inits with unique criteria, but whenever I enter the criteria in the Infopackage for the ODS-to-ODS load, then click on "Initialize", the criteria disappears. I assume this is because it is an ODS-to-ODS load. When I did this using a generic R/3 extractor-to-ODS, it worked fine.

Man, the ODS restrictions for Inits and Deltas are killers. I wish it were like the Infocube where you can do multiple full loads, then init w/out data transfer, and you're all set.

Answer:
The repair full requests are never checked in a data target, that is, you can activate initializations and deltas (also with selections) in the ODS object.

If this is true, how about this scenario: Can I do like 10 full loads to the ODS, delete them package-by-package, then re-insert/recover them all, then initialize a delta?
Copyright ?2007 - 2008 www.jt77.com