Converting Full Load - Delta load

Hi Experts,
I am trying to convert ODS from Full Load to Delta Load.
The problem is already there are full req so its not allowing me to activate delta.
I have tried running the program "RSSM_SET_REPAIR_FULL_FLAG" which would convert full req into repair req and then I should be able to load Init/Delta.( see OSS Note 689964)
Problem is even after running the program succesfully I m getting same message and not able to activate Init.
I again tried running running the prog but now progr does nt show any req which could be converted to Repair req.
So how to proceed from here and Full load ODS -> Delta...???
All help would be appreciated and awarded by points...
Thanks in advance!!!
Sorabh

Hi Ajai,
I checked RSREQDONE; in tht Qm status of req is Green...I dont know what I shud check in this table..
Also as per my understandings loading thru reqs in PSA is another way (if the request still exist in PSA)apart from the program given.
Program shud work in any condition whether req is there in PSA or not.
Correct me if I am wrong..
but again struck ..on same issue...:)..
Thanks,
Sorabh

Similar Messages

Difference: Full load, Delta Load & INIT load in BW

Hi Experts,
I am new to SAP BW Data warehousing.
What is the difference between Full load, Delta Load & INIT load in BW.
Regards
Praveen

Hi Pravin,
Hope the below helps you...
Full update:
A full update requests all the data that corresponds with the selection criteria you have determined in the scheduler.
You can indicate that a request with full update mode is a full repair request using the scheduler menu. This request can be posted to every data target, even if the data target already contains data from an initialization run or delta for this DataSource/source system combination, and has overlapping selection conditions.
If you use the full repair request to reload the data into the DataStore object after you have selectively deleted data from the DataStore object, note that this can lead to inconsistencies in the data target. If the selections for the repair request do not correspond with the selections you made when selectively deleting data from the DataStore object, posting this request can lead to duplicated data records in the data target.
Initialization of the delta process
Initializing the delta process is a precondition for requesting the delta.
More than one initialization selection is possible for different, non-overlapping selection conditions to initialize the delta process when scheduling InfoPackages for data from an SAP system. This gives you the option of loading the data
relevant for the delta process to the Business Information Warehouse in steps.
For example, you could load the data for cost center 1000 to BI in one step and the data for cost center 2000 in another.
The delta requested after several initializations contains the upper amount of all the successful init selections as the selection criterion. After this, the selection condition for the delta can no longer be changed. In the example, data for cost
centers 1000 and 2000 were loaded to BI during a delta.
Delta update
A delta update requests only the data that has appeared since the last delta. Before you can request a delta update you first have to initialize the delta process. A delta update is only possible for loading from SAP source systems. If a delta update fails (status red in the monitor), or the overall status of the delta request was set to red manually, the next data request is carried out in repeat mode. With a repeat request, the data that was loaded incorrectly or incompletely in the failed delta request is extracted along with the data that has accrued from this point on. A repeat can only be requested in the dialog screen. If the data from the failed delta request has already been updated to data targets, delete the data from the data targets in question. If you do not delete the data from the data targets, this could lead to duplicated data records after the repeat request.
Repeat delta update
If the loading process fails, the delta for the DataSource is requested again.
Early delta initialization : This is a advanced concept, but just for your information ...
With early delta initialization you can already write the data to the delta queue or to the delta tables in the application while the initialization is requested in the source system. This enables you to initialize the delta process, in other
words, the init request, without having to stop posting the data in the source system. You can only carry out early delta initialization if this is supported by the extractor for the DataSource that is called in the source system with this data
request. Extractors that support early delta initialization were first supplied with.

Init Load,Historical Data Load & Delta Load with 'No Marker Update'

What is the difference b/w Compression in Inventroy cube while Init Load,Historical Data Load & Delta Load with 'No Marker Update'???
please help for this quesy..
Thanks
Gaurav

Hi Gaurav,
I believe you will find the answers here...
[http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/e0b8dfe6-fe1c-2a10-e8bd-c7acc921f366&overridelayout=true]
regards
Pavel

Full-Init-Delta Loads

Friends
I have done full loads into a ODS and then I did Init with no data transfer. But the Message said that the request cannot be activated because the ODS has had full loads and activating INIT and DELTAS is not possible...Any Ideas?
Regards
VISHAL

Hi Ashwin,
there is a seperare procedure to activate delta mechanism in ODS. After you load the full requests you cannnot run init without making all the full requests to "Reapir full requests".
See SAP Note: 689964
Symptom
You want to switch the upload procedure for an ODS object from full to delta. However, the delta initialization fails with a message indicating that there are already full uploads in the ODS object and therefore inits or deltas cannot be posted or activated.
Other terms
Delta; ODS object: delta initialization, RSM 098, full, Init
Reason and Prerequisites
If a full upload occurs once for an ODS object, you can no longer activate an init for the same DataSource/source system combination in this ODS object. The system does not check for overlapping selection conditions.
Solution
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.
Note the following:
Since the repair full requests are not checked, duplicate data records may be created or data may disappear if there is a subsequent init.
Since the repair full requests are not checked, you should take account of the extractor behavior, update modes, aggregational behavior of key figures and characteristics, among other things, when you are deciding whether you want to mark the full requests as repair full requests.
If you perform an init simulation after changing to repair full requests, make sure that no data is updated between the last full upload and the first delta upload.
Procedure for changing full requests to repair full requests:
After you import Support Package 19 (3.0B) or Support Package 13 (3.1C), the <b>RSSM_SET_REPAIR_FULL_FLAG report is available which you can use to convert all full requests for a DataSource/source system combination that are in an ODS object into repair full requests.
Before you import this Support Package:
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.</b>CAUTION: This ONLY concerns those requests that begin with 'REQU_...'. The repair flag CANNOT be set for activation requests that begin with 'ODSR_'.
If the full requests still exist in the PSA, you can also use the scheduler under the 'Scheduler' menu option in the PSA tree (when you post from the PSA) to switch a PSA full request to a repair full request before loading.
If you load new requests with an InfoPackage, you can also assign the repair indicator to this full report.

Changing From Full to delta load

Could someone please help with this
i have used a Functional Module to extract data from R/3
i have created a new InfoCube and did a full load and everything is fine
There is NO ODS involved
i now want to change data loads from FULL to DELTAs
Can i do this without using an ODS and RECORDMODE - if so, how?
Thankyou
Pushpa

HI Pushpa,
For generic DS we need to maintain the generic delta. We can define in three ways.
1.Calday
2.Numeric Pinter
3.Timestamp
If we go for calday then there should a field (0calday). Which holds both created and changed the date of the record. We have 1 drawback in this we can only run the load only at the end of the day.
Numeric Pointer will only fetches the changed records.
Most of the time we preffer we go for timestamp.
U will get these option in RSo2 in R/3
Regards

Give difference between full load, delta load, repair full load

Can i run full update after delta load?? if yes tell me a scenario??Can anyone tell me the difference between all three & when to use these??
Regards,
Asish

Hi,
For Repair full load please check OSS note 689964 which is about repairing the full load by executing the program RSSM_SET_REPAIR_FULL_FLAG.
Basically in this you provide your ODS, Data Source and Source System name and execute the program RSSM_SET_REPAIR_FULL_FLAG and hit Repair full load.
It will repair the full load.
But after this you cannot go directly for delta load which is for new added records or changed records. Before delta load do initialization without data loading and then go for delta load.
So delta load will run after init run (without data transfer) and add new added record or changed records to exisitng full upload records.
Technically you cannot go for delta load with out init load.
So, If you have already done full load, you can go for delta load after doing initializing (init load) without data loading.
Hope it helps.
Regards,
Mona

Full and delta loads

Hi,
Is there any procedure (program or table) to find out list of fullloads and delta loads in BW system?
Regards
Jaya
Edited by: Jayalakshmi Busetty on Feb 19, 2010 6:04 AM

Hi Jayalakshmi,
Your can find in datatarges in Manage Button.
Thanks & Regards,
Venkat.

Init load, delta load and full load

Hi BW,
Please when can I use init delta, delta and full load in a data load process.
Which of them is suppose to be in a process chain and which one is manual.
Regards.

Hi,
When you want to run delta, you have to initialize it first, thats when you run the init delta.Here you have 2 options with data transfer and without data transfer. If the data target is empty and there's no data, you can run the init with data transfer. This'll act as a full pull and also set up the initialization. If there's data already present, then you are better off running the init w/o data transfer. This dosen't pull over any data, but just sets up the initialization.
Then you can start using the delta pulls.That'll just bring over the changes and any new records rather than the whole data and is much more efficient.
You can use full pulls for say generic datasources that are not delta enabled or during a first time data load, or if there is a specific business requirement that needs you to pull over the full data everyday. Or in cases where the std datasource is not delta enabled.
Cheers,
Kedar

Full to delta load in generic extration

Hi All,
I am loading the data form R/3 to BW with full load by using the generic data sources.
Now I need to change the full load to delta. But I get the data 2 views and one FM.
Some what I have got the solution, that is going RSO2 there generic delta will be available
If I click I will get the one wind there 3 deltas form there I took time stamp. Then I need
Select the field name.
1) Now only my problem started in that field name there is no creation
Date and last changed data, based on this we need to get the data from R/3 to BW.
2) In that 3 datasorce I used the one DS function module in this also that field name is not
available .
3) In safety interval what I need to give.
Please help on above 3 issues.
Thanks
kumar.

Hi,
plz check with this most proberly it works.
Go to RSO2 >> Now select the right option(Transaction data,Master data attributes or texts) >> Now in the next screen enter the Application Component >> enter the descriptions >> Now select how you want to populate data in your data source .....following options are there :
View/table >> Choose the extraction from view button if you want to want to extract the data from a transpatrent table or database view,and enter the name of the table or view...the extraction structure of the generated datasource is then identical to that of view or table.......
SAP Query/Infoset>> Choose the extraction from query button if you want to use SAP query infoset as datasource..then select the required infoset from the infoset catalog...you can go to the screen for maintaining an existing infoset by double click on its name...
Function Module
To make your datasource delta enable >> Click on Generic Delta on the top >> Here first give the field name .This field from the extract structure of a DataSource meets one of the following criteria:
1. The field has type: time stamp. New records to be loaded into the BW using a delta upload have a higher entry in this field that those which have already been loaded.
2. The field has type: calendar day. The same criteria applies to new records as in the time stamp field.
3. The field has another type. This case is only supported for SAP Content DataSources. In this case, the maximum value to be read must be displayed using a DataSource-specific exit when beginning data extraction.
Now choose one of the three options :
Time Stamp
Calender day
Numeric pointer...
Safety Interval Upper Limit >>This field is used by DataSources that determine their delta generically using a repetitively-increasing field in the extract structure.
The field contains the discrepancy between the current maximum when the delta or delta init extraction took place and the data that has actually been read.
Leaving the value blank increases the risk that the system could not extract records arising during extraction.
Example: A time stamp is used to determine the delta. The time stamp that was last read is 12:00:00. The next delta extraction begins at 12:30:00. In this case, the selection interval is 12:00:00 to 12:30:00. At the end of extraction, the pointer is set to 12:30:00.
A record - for example, a document- is created at 12:25 but not saved until 12:35. It is not contained in the extracted data but, because of its time stamp, is not extracted the next time either.
For this reason, the safety margin between read and transferred data must always be larger than the maximum length of time that it takes to create a record for this DataSource (with a time stamp delta), or it must display an interval that is sufficiently large (for determining delta using a serial number).
Safety Interval Lower Limit >> This field contains the value taken from the highest value of the previous delta extraction to determine the lowest value of the time stamp for the next delta extraction.
For example: A time stamp is used to determine a delta. The extracted data is master data: The system only transfers after-images that overwrite the status in the BW. Therefore, a record can be extracted into the BW for such data without any problems.
Taking this into account, the current time stamp can always be used as the upper limit when extracting: The lower limit of the next extraction is not seamlessly joined to the upper limit of the last extraction. Instead, its value is the same as this upper limit minus a safety margin. This safety margin needs to be big enough to contain all values in the extraction which already had a time stamp when the last extraction was carried out but which were not read. Not surprisingly, records can be transferred twice. However, for the reasons above, this is unavoidable.
DataSource Is Real-Time Enabled
The "Real-time enabled" indicator determines whether a delta-enabled DataSource can supply data for a real-time demon.
If the DataSource finds the delta generically using a delta-relevant field, observe the following with regard to the safety intervals:
The safety interval at the lower limit may cause redundant data to arrive in BW. This data is not suitable for InfoCubes and ODS objects with key figures that are updated in appended order. With real-time updates, the redundancy of the data is increased by the short time spans between the individual runs of a real-time demon. With a lower safety interval of 2 minutes and a demon frequency of one per minute, all data may potentially arrive in the PSA three times. This can lead to database and runtime problems.
The safety interval at the upper limit makes the data less up to date. How up to date the data is with real-time is always the sum of the upper safety interval and the time span between two runs of the demon.
The system uses the delta type to determine how extracted data is to be interpreted in BW, and into which data targets it can be posted.
A distinction is made between the following:
1. Additive delta
The key figures for extracted data are added up in BW. DataSources with this delta type can supply data to ODS objects and InfoCubes.
2. New status for changed records
Each record to be loaded delivers the new status for the key figures and characteristics. DataSources with this delta type can write to ODS objects or master data tables.

Full vs. Delta Load

Hi BI-Experts!
This is a rather general question.
Is there a recommendation when to use Full or Delta Load?
I know the functional differences but do SAP or some technical reasons say that each of them may only be used in special cases?
For example Delta Load can only be used with SAP source systems?
Best regards,
Philipp

Hi Philipp,
This is a pretty open-ended question. I will give you a few examples of when I use each ....
Delta's:
1.) If the record set is large and changes a lot daily. If you have a large initial load, let's say 2Million records and you get about 200k records per month, then you want to use a delta mechanism. There are just too many records to reload daily.
2.) If the record set is wide (many fields instead of a few), it will take less load time to run a delta than a full load.
3.) Datasource restrictions....some business content datasources don't have full loads and vice versa (some don't have deltas).
4.) Do my loads take too long? If so, I will convert full loads to delta's to shave off time here and there.
Full
1.) I gauge this mainly based on load time. If it takes 5 minutes to load 100k records, then it's going to take longer to figure out what delta's were missed (if there was a problem) than it would to just reload the dataset.
2.) Do my requirements dictate that I need to drop and reload the dataset? The best example of this would be the current year's forecast. Some companies revise the forecast and don't want to keep any previous revisions.
3.) Some data loads load a snapshot of a specific date. So, if I wanted to take a snapshot of inventory in a DSO/ODS on Monday, I would Datamart it into a Cube doing a full load for Monday's date.
Hope it helps!
Thanks,
Brian

Coverting Full load to delta load

Hello All....
I have an infosource which was delta enabled, but by mistake somebody has done it Full Load.Now i dont want to teminate the job.
Can nybody tell me what will be the effect of doing full load & what should i do to convert it to DELTA load again?
Plz help...

Hi,
With a data transfer process, you can transfer data either in FULL extraction mode or in DELTA mode. In FULL mode, the entire dataset of the source is transferred to the target; in DELTA mode, only the data that was posted to the SOURCE since the LAST data transfer is transferred.
So I believe you should be fine as it would only transfer the data from change log which was LAST posted in to your changelog table of datastore.
However;this is my theory and understanding derived from SAP help,might worth taking a shot if you are in DEV or wait for some one from SAP to confirm on the same.
NOTE - Applies only if you want to MIX FULL and DELTA loads of DTP in ODS Datastore ,then activation of REQUESTS could create problem so follow below solution.
Note 967100 - P10:Activate DTP requests from full and delta DTP in DSO
Hareesh

Difference between delta load and full load

HI,
i am getting confused with full load and delta load.
The scenario is as follows:
I have 4 records which i need to pass to DSO.(Standard DSO)
These are the fields and records.
IO_amount          io_QTY         0UNIT     0CURRENCY     Matnr
1519     195     EA     USD     MM01
2643.85     12     EA     USD     MM02
3580.4     10     EA     USD     MM03
6049.8     12     EA     USD     MM04
Now i need to change the record as
IO_amount          io_QTY         0UNIT     0CURRENCY     Matnr
1500     195     EA     USD     MM01
2643.85     12     EA     USD     MM02
3580.4     10     EA     USD     MM03
6049.8     22     EA     INR     MM04
When i passed it as full and delta load but could not make out any difference..
I can see the data only in active data and change log tables.how can i see that in DSO?
please help out,Points for sure.

Hello Susmitha,
You are right & your view of data is also correct
But only thing here is ODS which you are using mait have Overwright option in its Update Rules /Transformations
Here Q is
Which fields are in KeyFields in DSO Design
If
this Field Values are same in Delta are Full Upload
it will overwrite the records in ODS / DSO
If not
it will add the records to DSO /ODS
Comming to Delta & Full Loads
If you use Full always all data Present will be loaded
if you use Delta always changed & New records will be updated
This happens through Pointers Set ( Snap Shot of Previous Load )
Some tables where you can see RSOLTPSOURCE,RODELTAM etc
Try to wiew this ,Its tough to get
Thanks
Hari

BI7 : Change full load to delta load - things to do?

http://wiki.sdn.sap.com/wiki/display/profile/2007/04/30/Differencebetweenfull,intialanddeltaupdatemodes
Difference: Full load, Delta Load & INIT load in BW
Hi.
Since am not familiar with BW request clarity as to how to achieve the following :
We are on BI 7.
On our BW server, One of the Existing process chain loads data as full load daily Till date.
This schedule runs for about 4 to 6 hours during the nights. And the data seems to be growing.
And doing full load, now seems, not that meaningful for data analysis.
So we now feel we need not do a full load every day. But do only the incremental load.
How to make this effective in our existing process chains.
I went thro the 2 links above, but a few things am not clear.
What exactly needs to be done to change a full load into a delta load.
Also do not wish to have any data loss happening.
We run the schedules on a particular process chain for BW around 1 am.
Say from tomorrow I want to have the data loading as delta.
What exactly are the steps to be followed.
Precautions to be taken
So that we have the correct data load and no data is lost - while doing this.
Things to do am not clear :
do initialization with data transfer / or without data tranfer ?
The make it delta?
So that from tomorrow all data loading becomes delta ?
Or
since in our scenario,
daily basis it is full load.
Just make it delta load,
so that whatever changes will run in the next days schedule.
What all things are to be done stepwise.
if anyone could advise.
That would be very helpful.
Also any documentation which explains all these if someone could share the link please ?
Many thanks
indu
Edited by: Indumathy Narayanan on Aug 26, 2011 5:50 PM

Hi,
Kindly look at following links as well
http://help.sap.com/saphelp_nw04s/helpdata/en/44/9821620553053de10000000a1553f6/content.htm
Generic Delta
If a field exists in the extract structure of a DataSource that contains values which increase monotonously over time, you can define delta capability for this DataSource. If such a delta-relevant field exists in the extract structure, such as a timestamp, the system determines the data volume transferred in the delta method by comparing the maximum value transferred with the last load with the amount of data that has since entered the system. Only the data that has newly arrived is transferred.
To get the delta, generic delta management translates the update mode into a selection criterion. The selection of the request is enhanced with an interval for the delta-relevant field. The lower limit of the interval is known from the previous extraction. The upper limit is taken from the current value, such as the timestamp or the time of extraction. You can use security intervals to ensure that all data is taken into consideration in the extractions. After the data request was transferred to the extractor, and the data was extracted, the extractor then informs generic delta management that the pointer can be set to the upper limit of the previously returned interval.
The delta for generic DataSources cannot be used with a BW system release prior to 3.0. In older SAP BW releases, the system does not replicate DataSources for master data and texts that were made delta-enabled using the delta for generic DataSources.
Determining the Generic Delta for a DataSource
       1.      Choose Generic Delta.
       2.      In the subsequent dialog box, specify the delta-determining field and the type for this field.
       3.      Maintain the settings for the generic delta:
                            a.      Specify a security interval.
The purpose of a security interval is to make the system take into consideration records that appear during the extraction process but which remain unextracted (since they have yet to be saved) during the next extraction.
You have the option of adding a security interval to the upper limit/lower limit of the interval.
A security interval should only be specified for the lower limit when the delta method results in a new status for changed records, in other words, when the status is overwritten in BW. In this case, duplicate data records that could arise in such a safety interval have no affect on BW.
                            b.      Choose the delta type for the data to be extracted.
The delta type is used to determine how extracted data is interpreted in BW and which data targets in which it can be posted.
With the delta type additive delta, the record to be loaded for summarizable key figures only returns the change to the key figure. The extracted data is added in BW. DataSources with this delta type can supply both ODS objects and InfoCubes with data.
With the delta type New Status for Changed Records, every record to be loaded returns the new status for all key figures and characteristics. The values are overwritten in BW. DataSources with this delta type can write the data into ODS objects and master data tables.
       4.      Save your entries.
Delta transfer is now possible for this DataSource.
After generating the DataSource, you can see this from the marking for the field Delta Update on the DataSource: Customer Version screen.
In systems from release 4.0B, you can display the current value of the delta-relevant field in the delta queue.
Thanks and regards

Delta load from r3 to bw ?

i have one question on the mechanism of data transfer from r3 to bi 7.0. the followings is my concerns:
scenario:
The total numer of data is 1000 rows and these rows are seperated into 10 data package , each package contains 100 rows.
Now bw is trying to recieve these 10 packages from r3 in sequence.
When 5 data packages have been transfer to bi psa. the network is broken and the tranfer is canceled at the 6th data package.
What i want to know is when the network is reconnected ,Does the transfer start from the 6th data package?
How to find out whether its a delta load or a full load if a transfer is scheduled from r3 to bw ? For both CUBE & ODS.
How to find out how many records have been transfered from r3 to bw while the transfer has ended in
the middle ? I mean how to check how many records have been successfully transfered from r3 to cube/ods .Please tell me for ods as well as cube.
Is the continuation of transfer process is same for both ODS & INFOCUBE, if it ends in the middle ?
What is the procedure for full load & Delta load in case of CUBE & ODS ? I mean how to reschedule the transfer.
And if the whole scenario is is in the support, SO I will be handling these issues on the live production server. Am I right ? So in this case my user id should have access to all the production r3 and production bw to do these change status to red and delete the request and reload the request etc., So I should be logging on to the production server and do all the manipulation, Am I right ?
Last doubt, what is repair request and so if the transfer stops in the middle we change the status to red and reload the request again , Is it called repair request ?
What is the difference between repeat delta & repair request & repair delta ? When do we choose these options, In which scenarios ?
How do we schedule a daily load job from r3 to bw without the use of process chains ? I mean daily it should fetch the records from r3 to bw from the SD datasources at 10.00 PM ,how do we do that ?
Please I am having all these doubts and I want you SAP experts to answer them please so that I can clear my doubts in production support . I really appreciate if someone explain me the scenarios here. It will be a really great help if someonce clears these doubts.

Hi......
What i want to know is when the network is reconnected ,Does the transfer start from the 6th data package?
If your connection is broken in between......inspite your load is through PSA...........you have to delete the request from the target(after making the QM status red)............then you have to reload it again............But before repeating the load check the connection is ok or not in SM59........
How to find out whether its a delta load or a full load if a transfer is scheduled from r3 to bw ? For both CUBE & ODS
This you can check in IP scheduler in the Update tab...........whether it is delta or full load.......
or you can also check in IP monitor(You can go here through RSMO..........IP monitor screen will open directly here............or you can also go through RSA1>> Find your IP >> Double click on it >> Click on the monitor icon in the top >> From the you will go to the IP monitor>> the under the Header Tab you can see whether it is a delta or Full update...........
Or you can check the datasource also..........
If it is a generic datasource go to RSO2..........and check...........If it is a standard datasource check it in RSA5...........
How to find out how many records have been transfered from r3 to bw while the transfer has ended in the middle ? I mean how to check how many records have been successfully transfered from r3 to cube/ods .Please tell me for ods as well as cube
Your load cannot be ebded in the middle.........it can failed.............if it fails then you have to delete the request from the target..........and then repeat the load.......
Is the continuation of transfer process is same for both ODS & INFOCUBE, if it ends in the middle
Yes.........
What is the procedure for full load & Delta load in case of CUBE & ODS ? I mean how to reschedule the transfer
If a full or delta load fails after extraction got completed due lock issue or SID issue.....etc..........and if you load is through PSA.............then just delete the request from the target without making the QM status red.......and reconstruct the request.........no need to repeat the whole load again........
But if you r load is not through PSA..........then make the QM status red........delete the request from the target........and repeat the load...........
And if the whole scenario is is in the support, SO I will be handling these issues on the live production server. Am I right ? So in this case my user id should have access to all the production r3 and production bw to do these change status to red and delete the request and reload the request etc., So I should be logging on to the production server and do all the manipulation, Am I right ?
Yes.......
What is repair request and so if the transfer stops in the middle we change the status to red and reload the request again , Is it called repair request or reload request?
Suppose you delta load has failed ............and you have deleted the request from the target without making the QM status red............In this case your data will be lost and your delta mechanism will get corrupted............In this situation.............
1) Delete the init flag........
2) You have to do Full repair..........(After filling the set up table)
3) Init without data transfer to set back the init flag
4) Then Delta upload.............
In case of an ODS............you cannot load Full update and delta upload parrallely..............Your ODS activation will fail...........suppose you want full upload in the ODS..............then you have to go for Full repair............
What is the difference between repeat delta & repair request & repair delta ? When do we choose these options, In which scenarios ?
I think Full repair concept is now clear............
Suppose your delta load fails...........After that you delete the request after making the QM status red............Then system will ask for a repeat delta when you will try to repeat the load...........which means it will pick the same delta records of the failed load..........
How do we schedule a daily load job from r3 to bw without the use of process chains ? I mean daily it should fetch the records from r3 to bw from the SD datasources at 10.00 PM ,how do we do that ?
This you can do via infopackage or infopackage group...........schedule it at the specific time.....
Check these links :
http://help.sap.com/saphelp_nw04/helpdata/en/20/ad673844a7114be10000009b38f842/frameset.htm
Re: Schedule Infopackage for last day of a fiscal period
Hope this helps you.........
Regards,
Debjani...........

Manging delta loading in 0FITV_C01

Hi Experts,
I have the following cube implemented: 0FITV_C01, with no DSO in the flow.
I'm interested in managing delta for this infocube, but when i've created the infopackage, only full upadate is allowed (consistent with what i found later online).
So, i'm wondering if the following steps is the best aproach to manage delta.
1) create a flow (3.5): infoprovider in full update mode, and in PSA only mode
2) create a DTP, from datasource to cube, in delta mode. In this case what Infopackage should I have on the DTP "tree" - with what characterisctics. I supose it can't be the same infopackage as mentioned in 1)
3) create process chain with 1) followed by 2)
Q: How would I do the initial loading? Is it like old BW? Meaning, I would first set the DTP to full for first loading, and then change it to delta?
From your experience, is this a good aproach? would you suggest any other thing to load data in delta mode?
Many thanks
Joana

hi
Ful load is used to load the data based on the selection conditions from your source to target.
Init is used to enable the delta mechanism for your targets.
It is always recommended to have separate infopackages for
1) Initialization
2) Full Load (Repair Full)
3) Delta Load
Init loads are of two types: With data and without data. Init intializes a pointer or counter in the source which helps to bring only new data from the source, rather than bringing the complete data once again. Now With data transfer brings the first time data as well as sets the counter where as the Without data transfer only sets the counter and no data is transffered.
Another Type is there Repair full Request.
If you are in BW 3.5, then it is not possible to do separate initializations to different targets from a single source.
For ex, you have the data flow from DS1 to 3 targets,
DS1 --> cube1
DS1 --> cube2
DS1 --> cube3
Then when you do Init with data transfer, you have to select all the targets and do it simulataneously.
If you have loaded to only one target, say ODS1 and want to load the same init data with data transfer to other ODS, it will not be possible.

Converting Full Load - Delta load

Similar Messages

Maybe you are looking for