Full or delta at DTP

Hi
i am extracting data fromECC 6.0 to BI 7.0
i created 3 infopackages
full
delta initialization
delta
so i need 1 dtp is enough
at dtp i need select delta only.
what scenerio we use full dtp only?

Hi Sunil,
Basically, FULL DTP (or) Full Loads are used to load Master Data and small volumes of data. Full Loads are also used when the Data Target is loaded for the first time with data ( though Init can also be used for the same purpose in case Delta is to be followed with ). Their could be scenarios where U want to make a Full Repair, I think during this case also a Full Load is taken.
I hope this solves your query.
Regards,
Syed.
Edited by: syed shujaath ali on Aug 11, 2008 7:27 AM

Similar Messages

Full and Delta DTP doubts

There was a ongoing delta load happening between DSO 1 to DSO 2.
I deleted all requests from DSO 2.
And then ran first Full DTP ( DSO 1* to DSO 2) and immediately after full DTP ran Delta DTP ( DSO 1 to *DSO 2).
In Full DTP : There were 10,000 Records added into DSO 2
In delta DTP : there were 2,000 records added into DSO 2
I was bit surprised when I saw some data added in delta since before ( just 5 mins back ) I had ran full DTP therefore my understanding was delta would not bring anything.
By looking at various thread , I came to know that Full DTP get data from Active table and delta DTP get data from change log table.
However what if , if same records present in Active table and change log , so same records will be pick up by Full DTP run and also while delta DTP run , assume target DSO is in addictive mode then in such scenario duplicate record will be added and final result would be diffrent 9( i.e data get double up ).
How do we avoid such situation ?.
Any thoughts ?.
Edited by: Prashant on Aug 12, 2010 2:24 PM

HI,
DTP FULL: if you have 1 request in psa today and your dtp extraction mode is full it will load the data into the target.
                  in the next day you have run the infopackage and you habve got another request wich means in totall you have got
                  2request in psa so what the full dtp does is it will try to load both of them and you will get error saying duplicate records.
DTP DELTA:   it will load only the the fresh request from the source.
howe ever we dont do any initialisation in dtp the full and delta are only the extraction modes of data from the source. and its the infopackage which will fetch the deltas once the intialisation is done.
hope it helps.
Thanks & Regards
krishna.y

Full and delta Data loads in SAP BI 7.0

Hi,
Kindly explain me the difference between full and delta data loads in cube and DSO.
When do we select change log or active table(with or without archive) with full/delta in DTP for DSO.
Please explain the differences in data load for above different combinations.
With thanks and regards,
Mukul

Please search the forums. This topic has already been discussed a lot of times.

Extraction - full or delta or neither?

Hi all,
I have encountered a strange behaviour.
I am having a DataSource extracts data from R/3 to BW. In the "Test DataSource" screen, I put a range 2007.10 to the posting period, and it extracts all the records for 2007.10 for me.
But when I execute the InfoPackage in BW, and subsequently DTP and activation of DSO, I have got both 2007.10 and 2007.11 data in my DSO (which means all data ran into my DSO).
I suspect there is something wrong with my DS or DTP, because in my Data Transfer Process Monitor under "Details" tab, under "Process Request", there are multiple data package -- and it seems like this includes all the previous request and load that I have performed onto this DSO.
In my DTP extraction mode, I have tried both "Full" and "Delta" and in both cases, I got same problem.
Does anybody have any clue on how to resolve this? Is there a way to reset or I have missed out something? Appreciate for help. Thanks a lot.
- JK

Hi Alec,
If I delete the InfoPackage, would all the requests be deleted as well?
What I have tried is to delete the InfoPackage, delete data in DSO, and create Infopackage again, then execute DTP again.
As said, the PSA got only the data I need, but when loaded DTP and activate ODS, I got everything...
Still don't know why it behaves like that...
- JK

Issue regarding Full and Delta InfoSpoke

Hi Experts,
I have created 2 Infospokes Full and Delta to extract data from DSO to SQL server, the settings in both the InfoSpokes are identical except for the extraction mode. However, the delta InfoSpoke is pulling the correct number of records from the DSO (360 records), but the full InfoSpoke is extracting only 196 records. I also tried loading the DSO using both Full/delta Infopackage and Full/Delta DTPs but still the results were same. Can anyone tell how this issue can be resolved.
Thanks,
Rajan

Dear Rajan,
I'd try to help you about your question,
Your case it's curious, did you check the filter in both InfoPackage?, try to delete and create them again (it is very important check whole filter). Otherwise, I suggest use Open Hub Destination which BI 2004s have the same functional (export data)
I hope this suggestion can help you,
Luis

Is there any repair full load option in DTP?

Hi Experts,
I have run delta DTP from Cube A to Cube B with selection less than or equal to 31.03.2004 and I want to run grater than 31.03.2004. Now the problem is this load is not bringing the required records because data mart symbol is already set in Cube A.
How do I extract grater than 01.04.2009?
Is there any repair full load option in DTP?

Hi,
I am afraid that we have only full and delta options available in DTP, but the several other options available on extraction tab will enable us to do something similar to it.
If you looking to get data after 31.03.2004, in you selction condition change the from date to 01.04.2004 and try extracting, I am sure it will give you the desired records.
Please follow info on this link and decide which would suit to your requirement, if you get stuck, post back and I'll try to assist you.
http://help.sap.com/saphelp_nw70/helpdata/en/42/fa50e40f501a77e10000000a422035/frameset.htm
Regards,
Ray
Edited by: Rayapa on Apr 4, 2009 9:04 AM

Error in Full and Delta CPACache refresh.

Hi Experts,
In our production environent we have a SOAP -> XI - > PROXY scenario [Synchronous].
The Consumer of the WebService has reported an error:
500_Internal_Server_Error = SOAP:Server_Server_Error_XIAdapter_ADAPTER.JAVA_EXC
When I checked there are no messages in SXMB_MONI , but when I checked the Cache Refresh History I found that
there was error in both Full and Delta Cache Refresh. But the restart of the XI(Production) server resolved the issue.
The error is as shown below:
<?xml version="1.0" encoding="UTF-8" ?>
- <CacheRefreshError>
<EngineType>AE</EngineType>
<EngineName>af.pxi.su0956</EngineName>
<RefreshMode>F</RefreshMode>
- <GlobalError>
<Message>Couldn't parse Configuration Data cache update XML string from Directory.</Message>
org.xml.sax.SAXException: JavaErrors Tag found in cache update XML. at com.sap.aii.af.service.cpa.impl.cache.directory.DirectoryDataSAXHandler.startElement(DirectoryDataSAXHandler.java:157) at com.sap.engine.lib.xml.parser.handlers.SAXDocHandler.startElementEnd(SAXDocHandler.java(Compiled Code)) at com.sap.engine.lib.xml.parser.XMLParser.scanElement(XMLParser.java(Compiled Code)) at com.sap.engine.lib.xml.parser.XMLParser.scanContent(XMLParser.java(Compiled Code)) at com.sap.engine.lib.xml.parser.XMLParser.scanElement(XMLParser.java(Compiled Code)) at com.sap.engine.lib.xml.parser.XMLParser.scanDocument(XMLParser.java(Compiled Code)) at com.sap.engine.lib.xml.parser.XMLParser.parse0(XMLParser.java(Compiled Code)) at com.sap.engine.lib.xml.parser.AbstractXMLParser.parseAndCatchException(AbstractXMLParser.java(Compiled Code)) at com.sap.engine.lib.xml.parser.AbstractXMLParser.parse(AbstractXMLParser.java(Inlined Compiled Code)) at com.sap.engine.lib.xml.parser.AbstractXMLParser.parse(AbstractXMLParser.java(Compiled Code)) at com.sap.engine.lib.xml.parser.Parser.parse_DTDValidation(Parser.java(Inlined Compiled Code)) at com.sap.engine.lib.xml.parser.Parser.parse(Parser.java(Compiled Code)) at com.sap.engine.lib.xml.parser.SAXParser.parse(SAXParser.java(Compiled Code)) at javax.xml.parsers.SAXParser.parse(Unknown Source) at javax.xml.parsers.SAXParser.parse(Unknown Source) at com.sap.aii.af.service.cpa.impl.cache.directory.DirectoryDataParser.updateCentralCache(DirectoryDataParser.java:56) at com.sap.aii.af.service.cpa.impl.cache.CacheManager.updateCacheWithDirectoryData(CacheManager.java:871) at com.sap.aii.af.service.cpa.impl.cache.CacheManager.performCacheUpdate(CacheManager.java:640) at com.sap.aii.af.service.cpa.impl.servlet.CacheRefresh.process(CacheRefresh.java:104) at com.sap.aii.af.service.cpa.impl.servlet.CacheRefresh.doGet(CacheRefresh.java:53) at javax.servlet.http.HttpServlet.service(HttpServlet.java(Compiled Code)) at javax.servlet.http.HttpServlet.service(HttpServlet.java(Compiled Code)) at com.sap.engine.services.servlets_jsp.server.HttpHandlerImpl.runServlet(HttpHandlerImpl.java(Compiled Code)) at com.sap.engine.services.servlets_jsp.server.HttpHandlerImpl.handleRequest(HttpHandlerImpl.java(Compiled Code)) at com.sap.engine.services.httpserver.server.RequestAnalizer.startServlet(RequestAnalizer.java(Inlined Compiled Code)) at com.sap.engine.services.httpserver.server.RequestAnalizer.startServlet(RequestAnalizer.java(Compiled Code)) at com.sap.engine.services.httpserver.server.RequestAnalizer.invokeWebContainer(RequestAnalizer.java(Compiled Code)) at com.sap.engine.services.httpserver.server.RequestAnalizer.handle(RequestAnalizer.java(Compiled Code)) at com.sap.engine.services.httpserver.server.Client.handle(Client.java(Inlined Compiled Code)) at com.sap.engine.services.httpserver.server.Processor.request(Processor.java(Compiled Code)) at com.sap.engine.core.service630.context.cluster.session.ApplicationSessionMessageListener.process(ApplicationSessionMessageListener.java(Compiled Code)) at com.sap.engine.core.cluster.impl6.session.MessageRunner.run(MessageRunner.java(Compiled Code)) at com.sap.engine.core.thread.impl3.ActionObject.run(ActionObject.java(Compiled Code)) at java.security.AccessController.doPrivileged1(Native Method) at java.security.AccessController.doPrivileged(AccessController.java(Compiled Code)) at com.sap.engine.core.thread.impl3.SingleThread.execute(SingleThread.java(Compiled Code)) at com.sap.engine.core.thread.impl3.SingleThread.run(SingleThread.java(Compiled Code))
Can anyone tell me what is the cause of this error and how restart of the XI server resolved the issue?
Thannks,

Guys,
I have deployed the below components and after this repository could not be started which gives the below error.
1000.7.11.10.18.20130529165100
SAP AG
sap.com
SAP_XIAF
1000.7.11.10.11.20130529165100
SAP AG
sap.com
SAP_XIESR
1000.7.11.10.15.20130529165100
SAP AG
sap.com
SAP_XITOOL
We have the same issue. Still the Restart did not solve ths issue.
Can anybody help? We are not able to start the XI Repository.
Our PI components are as below
com.sap.engine.services.ejb3.runtime.impl.refmatcher.EJBResolvingException: Cannot start applicationsap.com/com.sap.xi.repository; nested exception is: java.rmi.RemoteException: [ERROR
CODE DPL.DS.6125] Error occurred while starting application locally and wait.; nested exception is:
        com.sap.engine.services.deploy.container.DeploymentException: Cannot activate endpoint for message-driven bean sap.com/com.sap.xi.repository*xml|com.sap.xpi.ibrep.server.jar*xm
l|CacheRefreshMDB^M
        at com.sap.engine.services.ejb3.runtime.impl.DefaultContainerRepository.startApp(DefaultContainerRepository.java:315)^M
        at com.sap.engine.services.ejb3.runtime.impl.DefaultContainerRepository.getEnterpriseBeanContainer(DefaultContainerRepository.java:106)^M
        at com.sap.engine.services.ejb3.runtime.impl.DefaultRemoteObjectFactory.resolveReference(DefaultRemoteObjectFactory.java:55)^M
1000.7.11.10.6.20121015232500
SAP AG
sap.com
MESSAGING
Regards
Omkar

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.

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.

Two Extractor logics for full and delta?

Hi,
I have a situation where in the logics for full upload and delta uploads are drastically dfifferent!
What is best way to deal it?
shuould i have two different extractors for full and delta ?
Raj

Hi Raj,
I hope that u are working with the Generic Extractors. If the volume of the posting is too high then u need to restrict the data definitely from R3 side interms of the performance. And u need to maintain the Delta Functionality for the same.
If u cannt maintain the Delta from the R3 side then atleast try to restrict the same from BW side at the infopack level where u can extract the data based on the changed on and created with the two different IP's and update the same to the ODS(here make sure all the objects are with the overwrite).... and then u can maintain the Delta load from ODS to the Cube easily..
If the volume of the data is pretty less then u can use Full load to the ODS and then Delta to the Cube.
Thanks
Hope this helps..

Criteria to upload Master Data by Full or Delta

Dear Experts,
In our project, all the master data are extracted bu the Full Upload method. However, our users asked for the criteria to judge whether we should use Full or Delta for master data.
E.g.
1) the volume of data - (If there are a few records for master data, use full upload) - What is the exact figure that we can use to check? For example, more than 10000 records, use delta upload.
2) the change of master data - (if the master data is changed every day, use delta upload)
etc.
Is there any SAP document recommending these things?
Thank you in advance.

Hi,
One criteria that you can consider is to check whether the datasource is delta enabled or not.
In few cases where frequent changes of data is not expected e.g. 0PLANT_ATTR (plant master data) , SAP delivers without the option of enabling delta load. In such case, you can go only for full update. In other cases , where data change is expected more frequently like 0MATERIAL_ATTR , it is delta enabled.
Regards,

Full To Delta (changing load type)

Hello Everybody
I am planning to convert few laad type from FUll to delta because its just taking too long to load. But here are my questions.
Besides the fact that (full load)it's a business requrement(snapshot); i cannot change it right or there is still a way.
1. what are the technical considerations for converting full load from a dso to a cube . If ths dso is getting a full load itself does it have to be set to overwrite to further do a delta to a cube. what if the dso is getting delta load . do i have to consider from source to dso as well if its delta or full; how does it affect it.
2. what happens to the existing laods/requests in a cube/dso if i change the load type. (does it get affected)
thanks

Hi,
1. When changing the data load to delta from DSO to cube, just you can go ahead an do init. Since the base leve is DSO it doesnot matter if the base level data load is full or delta. Also make sure the DSO is standard one. If the source is DSO there is no problem in converting from full to delta.
2. Make sure only one full load exist in cube. Then do a init and going further you can pull delta. The existing data in DSO will not be affected or cube data. Since delta will fetch data from change log table there will not an issue.
Regards
Akhan

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

Delta Init DTP DSO- Cube loads all requests

Hi,
i've loaded several Full Request to a DSO (Datasource 2LIS_02_ITM).
I had to to fragment it to 3 months per Full load because otherwise the data volume was too much for the rollback segment.
Now i want to load these requests from the DSO to a Cube.
I created a Delta DTP and selected the "All new data by request" option.
The DTP starts as a Delta Init but selects all open requests at once and crashes with a "ORA-01555: snapshot too old..." error.
As a workaround i created several Full DTPs that only load part of the data but i really want to understand why the Delta Init doesn't work as expected and documented (to load request by request in a new process).
thanks
Carsten

Hemant Khemani wrote:>
> Please check if you have selected the option "Get All New Data Request by Request" in the Delta DTP.
> If you have selected this option then the delta DTP will select only one request (oldest - yet to be updated to the target) from the DSO.
That's the option i've selected.
When monitoring the DTP-Request i see in the head data that all requests from the DSO are selected at once.

Delta in DTP(BI 7.0)

Hi, all,
I have an ODS ZODS01 which data have been loading into it for more than one year, now I need a new ODS ZODS02 to load data from ZODS01, but I don't need the historical data from ZODS01, only need new daily data when this ODS put in production. In BI 7.0 DTP, there is no option to do initialize without data transfer as in 3.x infopackage. So how can I acheive this?
Thanks a lot.

HI ,
Like delta transfer using an InfoPackage, an explicit initialization of the delta process is not necessary for delta transfer with a DTP. When the data transfer process is executed in delta mode for the first time, all existing requests are retrieved from the source, and the delta status is initialized.And then DTp will pick deltas only ..
check this link
http://help.sap.com/saphelp_nw70/helpdata/en/42/fa50e40f501a77e10000000a422035/content.htm
regards,
shikha

Full or delta at DTP

Similar Messages

Maybe you are looking for