2LIS_11_VAHDR - Initialize delta process error

Hi,
I have an issue initializing infosource 2LIS_11_VAHDR for delta process on a new BW3.1c instance created from a system copy. Other delta loads work properly but not this one.
In the AWB monitor, the status indicates 'no data available' even if the source system LIS setup tables have been recreated with some records available. What's more puzzling is the fact that the error also indicates that 'the data request was a full update' even if the update mode is set to initialize delta process.
Any tips would be appreciated.
Thank you,
Frank

RSA3 simulated 0 records but the R/3 table had plenty of records to be processed.
But what resolved the problem was deleting and re-creating the BW infopackage and re-initializing the delta process.
Thank you all for your time.
Frank

Similar Messages

Initialize Delta Update Error

Hi to all!
I need your help, I had encountered runtime error in running initialize delta process and here's the error:
<i>DBIF SQL ERROR
An SQL error occurred while accessing a table.
The database system detected a deadlock and avoided it by rolling back your transaction.</i>
Please advise on how do I go about this, many thanks!=)

hi,
already checked in st22(DBIF SQL ERROR
An SQL error occurred while accessing a table.
The database system detected a deadlock and avoided it by rolling back your transaction.) and we read oss notes regarding the problem, it says "the deadlock is caused by a problem in the application. It can be traced back to a programming error. Under certain conditions, a deadlock may also be triggered by Oracle."
As per checking of our basis problem was not triggered by Oracle. We don't know how to do it on the programming side, please help.
many thanks =)

Initialize Delta Process without data transfer

Dear Gurus,
I am facing a problem when I try to "initialize Delta Process without data transfer" an ODS.
I first deleted the initialization request in Scheduler->Initialization Options for Source system and then I executed the Infopackage.
The status of the new init. request is red and I get the following error message :
Request REQU_DMJI1J66397EM5OZMC1EQJLWZ (192.384) for DataSource 8ZSALETXT from source system PW1CLNT600 has the status green and a lesser SID (and is therefore older) than the request that you currently want to update into the DataStore object.
This is not possible because the sequence of requests has to be followed.
Delta- and init requests have to be updated to the DataStore object in the request sequence.
The problem is that I can't find this request (REQU_DMJ...) anywhere.
Could you please explain me what to do with this issue and tell me if it is possible to make the system just ignore this request ?
Thank you in advance
Fabien

Hi............
U r not able to find REQU_DMJI1J66397EM5OZMC1EQJLWZ in the Manage screen of the ODS right?.........
Go to RSRQ...................give this request number and check...........if the Status is green........in the Header tab check whether the load is till PSA or not............if it is till PSA............then go to the Status tab and click on Process Manually to push the request in the target........otherwise just make the QM status red here..............then do the load.......
Regards,
Debjani.........

Initialize Delta Process with Data Transfer - Split the job in two/three

Hello,
I am trying to load master data into BI (DEV) and there are 700,000 master data records in my source system. When I tried to load Initialize Delta Process with data transfer, at some point (after 300,000 records) my load failed in source system and job log I found that this issue "ABAP/4 processor: TSV_TNEW_OCCURS_NO_ROLL_MEMORY"
When I informed this issue to BASIS consultant, they suggest me to split the job in 3 (Three). My question: how can I split the job in three? I can do one Initialize Delta Process load and followed by delta load.
Regards,
Md

Hi Md.
Even at Infopackage level you can reduce the number of records per package.
Go to Infopackage Schedular Menu -> DataS. Default Data Transfer. you can reduce the Maximum size of a data packet in kByte.
Regards,
Pratap Sone

How to initialize delta for a new data target

Hi
I have an ODS from which there are several other targets getting updated thru an export datasource. The delta initialization happend some 6 months back. I now have a new ODS into which i need to load the data from the original ODS. How can i initialise the delta to my new target without changing the delta initialization of the other targets and continue the delta for all of them together?
can i use the same initialization for my new target??
If i do a full update and then a initialise w/o data transfer, will the further delta bring the data from the correct point, is there a possiblity of data loss??
Regards,
Sujai

Hi Ajay,
the steps are as follows.
1 delete the initialization. open infopackage >> menu scheduler >> Initialization options for source systems >> delete the request thats there.
2. Now go to the Update tab of the infopack >> select option Initialize Delta process >> check the option initialize without Data transfer
3. Goto Schedule tab and start the job.
here the data targets will be all the targets the infopack loads.
4. Create a new infopack
5. goto Data targets tab >> select data targets >> put a check on your new ODS/Cube
6. Goto Update tab >> select the option Full update
7. goto menu Scheduler >> select Repair full request >> put a check on Indicate request as Repair Request >> hit OK
8. Goto schedule tab >> start the job.
9. Continue with the existing Delta infopack that was load the old ODS/Cubes and make sure your new ODS/Cube is also cheked for the delta.
Regards
Sujai

Error in delta process

Hi people,
I'm using the process delta, but it occurred one problem. When i execute the initialization of process delta, i extract 536 registers, but when i execute delta, i get 0 registers. I went to font (R3 ) and created one document to test the delta, but nothing happened. In R3, i executed RSA3 and my document that i created is there, but not in process delta.
Note: i created a filter in initialization and delta (period 2006) and the document that i created to test, was also in period 2006.
I apreciate your help in resolution of my problem. Thanks!
JA

I have other problem... i went to table BWOM_SETTINGS and changed the parameter BWFIOVERLA to X, and i can extract data from delta. The problem is.. i execute one time the delta, and the changed data appears, but when i execute again the delta, it was supposed just appear the data changed after the last time i executed the delta, and that not occurs.
Suppose.. in the first time i execute the delta, it appeared 20 registers.. then, i changed one document, 2 new registers, when i execute the delta, appears 22 registers, and not just 2..
Anyone can help me?
Thanks!

COPA Realignment in R/3 -do i need to Re-initialize the Delta Process in BI

Hi frnds,
Im facing an issue related COPA realignment,
1.Once the COPA realignment is done in R/3, Do i need to Re-initialize the Delta Process in BI?
Edited by: MohanDP on May 4, 2011 8:37 AM

But i need historical data too,so how to avoid Re-initialization to get historical data.Can u please help
if you need the changed historical data, you have no choice but to reinit. you can do this at anytime, you don't need any downtime for copa init.
M.

Error when perform init delta process (w/data)

Hello all!
when i perform init delta process (without data transfer), i am receiving the follow message:
SUBRC= 2 The current application triggered a termination wi
Recently we upgrated to SapNetWeaver 7.31 (before was 7.0).
Is there anything that i need to do to execute a init delta (without data transfer)?
SPK 731 LEVEL 10.
thanks.

Hi,
What data source and at which server you doing this?
Can you check your extract structure(source system side) was active or not?
replicate your data source into bw and activate it.
later try to do init without data transfer.
Thanks

Problem to initialize delta queue of datasource from CRM 7.0.

Hi all,
I've some problem to initialize delta queue of datasource from CRM 7.0. After initialize the Init in BW, the delta queue was created but after the user changed data, this changed didn't populated into delta queue.
I tried the steps below but without any success. Anybody know how can I correct this issue?
Suggestion 3: Please check the following.
Please Check if the services have been generated in transaction GNRWB.
If they are not active(not marked 'X' before their names) then activate
the services following the steps here.
Go to transaction GNRWB
Select BUS_TRANS_MSG
Select (on the right, the services) : BWA_DELTA3, BWA_FILL, BWA_queue
Press Generate.
Also check for the following:
1. The delta should have been initialized successfully.
2. Confirm that all Bdocs of type BUS_TRANS_MSG
are processed with success in SMW01.
3. If there are queues in SMQ1 with erroneous status then activate
these queues.
In Transaction SMQ1 if there are Queues existing with
names beginning with CRM_BWAn (n is number) then
activate these queues in the same transaction.
4.a)If required activate the datasource
Go to transaction BWA5 > select the required datasource and
activate.
4 b) The Delta may not be active ,activate the delta in BWA7 by
selecting the name of the datsource and pressing the candle icon for
'activate delta'.
5. In BW system
Go to transaction RSA1 > modeling > infosources > select the
infosource > right mouse click on the selected
infosource > choose option replicate datasource
Activate the infosource.
6. Go to the scheduler for the infosource > select delta in the
update >choose the option PSA only (in the Processing tab)

Hi Peter,
Thank you for your answer.
But we need to find out what the reason for this import error is.
Our customer will not be very pleased to see that all IDocs from CRM system cannot be found in the IDOC folder.
IDX2 import of metadata is no issue.
We were successful for standard and customer Idocs here.
Additional information:
We are already importing Idocs from a SAP ECC 6.0 system into PI in another SWCV
successfully. So this is a CRM system specific issue in our environment.
Regards
Dirk
Edited by: Meinhard Dirk on Aug 27, 2010 10:30 AM

Delta Load Error in the Data Extraction

Hi BI Guru`s,
The issue is with the extractor 2LIS_13_VDKON (Pricing conditions), The regular delta till 22.07.2010 has run successfully, But on 23.07.2010 the delta got failed with the error message " Data Package 58 : arrived in BW ; Processing : Processing not yet finished, entry 70 still missi" for one of the Datapacket. We have repeated the load even though we got the same error message, Since the client is retailer we will be having the delta records of 200 million ( approx. 23369612) in a day. Since because of this error we could't load any of the delta from that day onwards.
Need Help on this:
1. How to get the old delta
2. How to re-initialize the process for delta. (Pls keep it in mind the volume of the records).
Thanks in Advance,
Venkat

Hi,
Here we need decrease the datapacket size as well as prallel proceesing .
than we need to load the historical data through dalta repetition
hope..helpful for you!
Regards!
Malli.

ODS Delta Process, DataSource and Delta Queue

Hi to all,
loading data from a SAP source system into SAP BW 7.0 via generic 3.x datasource causes problems.
Here is a short description:
The data flow is from a source table using a generic extractor into a target ODS in full update mode.
Update rules should move data from table structure into ODS structure in this way:
Source table structure
CustKey1     Key2
13386          C23
13386          B14
13387          A13
13387          E25
ODS structure
CustKey1     col1     col2
13387          A13     E25
This works pretty well - as long as all records with the same CustKey1 are transfered in the same data package. Data Browser (SE16) shows the situation in ODS-"New data" view (data is not activated):
Request    Data_packet_number     Data_record_number      CustKey1
112           000003                  1.061              0000013386
112           000004                      1              0000013386
112           000004                      2              0000013387
There are two records for CustKey1 0000013386 with
data record 1.061 in data packet 000003   and
data record       1 in data packet 000004.
The obove constellation is the cause for errors in the ODS Delta Queue and subsequent data processing.
I think there may be one solution to solve the problem by changing the Delta Process of the Data Source.
The properties are:
- Record type: Full, delta, before, after images
- Delta type: Delta from delta queue or from extractor
- Serialization: No serialization, serialization of request, serialization of data packages
But how can I change these settings? Transactions RSA2 RSO2 RSO6 RSO8 don't do this.
What is the right delta process to use?
I have tried changing the delta process generating several 3.x datasources with the following delta processes (see table RODELTAM)
- " " (Full-upload)
- AIE
- ADD
Unfortunately with no effect.
Who can help?
Regards
Josef
Edited by: Josef L. on Mar 20, 2009 7:44 PM

hi venkat,
whenever you load a delta from ods to cube , whatever the data changed in ods since last delta will be updated, hence from you case, both req1 and req2 will be loaded to cube.
Assign Points if useful
Ramesh

Query on delta process

Hi BW Experts,
For AP(Accounts payable),AR(Accounts receivable) we can run delta process to pick delta records. How?
Could anyone please let me know?
Thanks

FI extractors are worked on after image delta. Delta records are diractly selected from the R/3 tables using a time stamp mechanism.delta records are diractly transfored to bw no need to writen to the bw Plz go through reg FI OFI_Gl_4,OFI_AP_4,OFI_AR_4 0FI_GL_4 (G/L Accounts: line items) No redundant fields are transferred into BW: Only fields from the FI document tables (BKPF/BSEG) that are relevant to general ledger accounting (compare table BSIS), No customer or vendor related fields. 0FI_AP_4 (AP: line items) and 0FI_AR_4 (AR: line items) Vendor / Customer related information (e.g. payment/dunning data). Coupled consistent snapshot of FI data in BW:extraction G/L account extraction determines selection criteria (comp.code, fiscal period) and upper time limit of all extracted FI line-items. AP and AR extraction: no further selection criteria necessary / possible. Uncoupled extraction possible with PlugIn PI 2002.2, see OSS note 551044. 0FI_GL_4, 0FI_AP_4, 0FI_AR_4 use an After Image Delta Delta type Extractor: Delta records are directly selected from the R/3 tables using a timestamp mechanism. Delta records are directly transferred to BW. No record is written to the BW delta queue. After Image Delta: FI line items are transferred from the source system in their final state (= After Image). This delta method is not suitable for direct InfoCube update. ODS object is obligatory to determine the delta for InfoCube update. Delta queue and BW scheduler ensure correct serialization of the records (e.g. inserts must not pass changes) Distribution of delta records to multiple BW systems. Selection criteria of Delta-Init upload are used to couple the datasources logically. time mechanism... New FI documents Posted in R/3 since the last line-item extraction. Selection based on the field BKPF-CPUDT. Hierarchy Extractor for Balance Sheet & P&L Structure Technical name: 0GLACCEXT_T011_HIER Technical Data Type of DataSource Hierarchies Application Component FI-IO Use The extractor is used for loading hierarchies (balance sheetl/P&L structures) for the characteristic (InfoObject) 0GLACCEXT. Fields of Origin in the Extract Structure Field in Extract Structure Description of Field in the Extract Structure Table of Origin Field in Table of Origin .INCLUDE ROSHIENODE RFDT CLUSTD FIELDNM RSFIELDNM RFDT CLUSTD GLACCEXT GLACCEXT RFDT CLUSTD RSIGN RR_RSIGN RR_PLUMI RFDT CLUSTD PLUMI ROSHIENODE RFDT CLUSTD Features of Extractor Extractor: FBIW_HIERARCHY_TRANSFER_TO Extraction structure: DTFIGL_HIERNODE_1 Financial Accounting: Line Item Extraction Procedure General Information About the Line Item Extraction Procedure BW Release 3.1 makes consistent data extraction in the delta method possible for line items in General Ledger Accounting (FI-GL), and selected subsidiary ledgers (Accounts Receivable FI-AR and Accounts Payable FI-AP) and tax reporting. The extraction procedure delivered with BW Release 2.0B, based on DataSources 0FI_AR_3 and 0FI_AP_3 , can be replaced. This is described in note 0410797. The decisive advantage of choosing R/3 line item tables as the data source is that extra fields can be transferred to the BW. These were not available with transaction figures from table GLTO, the previous R/3 data source in General Ledger Accounting FI-GL. This provides more extensive and flexible analysis in BW. To enable you to assure consistent Delta data, four new InfoSources are provided in the OLTP system (with the corresponding DataSources and extractors in the SAP R/3 system): Application InfoSource Description FI-GL 0FI_GL_4 General Ledger: Line Items FI-AP 0FI_AP_4 Accounts Payable: Line Items (Extraction Linked to 0FI_GL_4) FI-AR 0FI_AR_4 Accounts Receivable: Line Items (Extraction Linked to 0FI_GL_4) FI-TX 0FI_TAX_4 General Ledger: Data for Tax on Sales/Purchases For the General Ledger, selection is made from tables BKPF and BSEG, while selection for the subsidiary accounts is made from tables BSID/BSAD (Accounts Receivable) and BSIK/BSAK (Accounts Payable). InfoSource 0FI_GL_4 transfers only those fields that are relevant for General Ledger Accounting from the Financial Accounting document (tables BKPF and BSEG) to the BW system. The consisten recording of data from General Ledger Accounting and Subledger Accounting is provided by means of coupled delta extraction in the time stamp procedure. General ledger accounting is the main process in delta mode and provides subsidiary ledger extraction with time stamp information (time intervals of previously selected general ledger line items). This time stamp information can also be used for a loading history: this shows which line items have previously been extracted from the SAP R/3 system. Delta Method Delta extraction enables you to load into the BW system only that data that has been added or has changed since the last extraction event. Data that is already loaded and is not changed is retained. This data does not need to be deleted before a new upload. This procedure enables you to improve performance unlike the periodic extraction of the overall dataset. Financial Accounting line items are read by extractors directly from the tables in the SAP R/3 system. A time stamp on the line items serves to identify the status of the delta data. Time stamp intervals that have already been read are then stored in a time stamp table. The delta dataset is transferred to the BW system directly, without records being transferred to the delta queue in the SAP R/3 system (extraktor delta method). The Financial Accounting line items are extracted from the SAP R/3 system in their most recent status (after-image delta method). This data method is not suitable for filling InfoCubes directly in the BW system. To start with therefore, the line items must be loaded in the BW system in an ODS object that identifies the changes made to individual characteristics and key figures within a delta data record. Other data destinations (InfoCubes) can be provided with data from this ODS object. Time Stamp Method With Financial Accounting line items that have been posted in the SAP R/3 system since the last data request, the extractors identify the following delta dataset using the time stamp in the document header (BKPF-CPUDT). When a delta dataset has been selected successfully, the SAP R/3 system logs two time stamps that delimit a selection interval for a DataSource in table BWOM2_TIMEST: Field Name Key Description MANDT X Client OLTPSOURCE X DataSource AEDAT X SYSTEM: Date AETIM X SYSTEM: Time UPDMODE Data update mode (full, delta, deltainit) TS_LOW Lower limit of the time selection (time stamp in seconds since 1.1.1990) TS_HIGH Upper limit of the time selection (time stamp in seconds since 1.1.1990) LAST_TS Flag: 'X' = Last time stamp interval of the delta extraction TZONE Time zone DAYST Daylight saving time active? The time stamps are determined from the system date and time and converted to the format seconds since 1.1.1990, taking into account the time zone and daylight saving time. To ensure correct and unique reconversion to date and time, the time zone and daylight saving time must be stored in table BWOM2_TIMEST. Table BWOM2_TIMEST therefore serves to document the loading history of Financial Accounting line items. It also provides defined restart points following incorrect data requests. To provide a better overview, the time stamps in the example table are entered in the date format. The columns TZONE and DAYST were left out. OLTPSOURCE AEDAT/AETIM UPD DATE_LOW DATE_HIGH LAST_TS 0FI_GL_4 16 May 2000/20:15 Init 01 Jan. 1990 15 May 2000 0FI_GL_4 24 May 2000/16:59 Delta 16 May 2000 23 May 2000 0FI_GL_4 02 June 2000/21:45 Delta 24 June 2000 01 June 2000 0FI_GL_4 15 June 2000/12:34 Delta 02 June 2000 14 June 2000 0FI_GL_4 21 June 2000/18:12 Delta 15 June 2000 20 June 2000 X 0FI_AP_4 18 May 2000/21:23 Init 01 Jan. 1990 15 May 2000 0FI_AP_4 30 May 2000/12:48 Delta 16 May 2000 23 May 2000 0FI_AP_4 10 June 2000/13:19 Delta 24 June 2000 01 June 2000 X 0FI_AR_4 17 May 2000/18:45 Init 01 Jan. 1990 15 May 2000 0FI_AR_4 04 June 2000/13:32 Delta 16 May 2000 01 June 2000 0FI_AR_4 16 June 2000/15:41 Delta 02 June 2000 14 June 2000 X 0FI_TX_4 17 May 2000/18:45 Init 01 Jan. 1990 15 May 2000 0FI_TX_4 04 June 2000/13:32 Delta 16 May 2000 01 June 2000 0FI_TX_4 16 June 2000/15:41 Delta 02 June 2000 14 June 2000 X Constraints Per day, no more than one delta dataset can be transferred for InforSource 0FI_GL_4. The extracted data therefore has the status of the previous day. For further data requests on the same day, the InfoSource does not provide any data. In delta mode, data requests with InfoSource 0FI_AR_4 and InfoSource 0FI_AP_4 do not provide any data if no new extraction has taken place with InfoSource 0FI_GL_4 since the last data transfer. This ensures that the data in the BW system for Accounts Receivable and Accounts Payable Accounting is exactly as up to date as the data for General Ledger Accounting. If you delete the initialization selection in the source system for InfoSource 0FI_GL_4 in the BW system Administrator Workbench, the time stamp entries for InfoSources 0FI_GL_4, 0FI_AP_4, 0FI_AR_4 and OFI_TX_4 are also removed from table BWOM2_TIMEST. Recording Changed Line Items In the case of Financial Accounting line items that have been changed since the last data request in the SAP R/3 system, there is no reliable time stamp that can document the time of the last change. For this reason, all line items that are changed in a way relevant for BW must be logged in the SAP R/3 system

MAster Data - Delta Load Error?

Hi,
I am having error in 0COSTCENTER delta load. In the Info Package of 0COSTCENTER, it was not selected to PSA. It was selected to InfoObject directly.
Since this is a delta load for Master data, how can i correct this error?
Thanks!
Venkata

Hi Venkat,
You can done a full upload without affecting Delta upload. Make a test on Dev or Qual and you will see that a full on Master Data does not stop delta process.
Ciao.
Riccardo.

Problem in initialization delta load

Hi All,
I am facing a problem while doing an initialization delta from one ODS obj to another.
Error says "data is not been updated in PSA table"
The ODS object I am trying to load is getting data from 3 ods below ODS obj, out of 3ODS's 2 were successfully loaded.
While doing this particular load it's coming with the same error. I tried full load also, but results are same.
Can anyone have some answers?
Regards,
Kironmoy

Hi,
In first init the data will move from the active data table to further data target then we will run delta at that tome the dat will go from change log table to further datatarget in our case u rrunning init but there is no daa in active data table so it is happening
here two options are there
1)either u can delete the change log table data and reload the data once again and do INIT with data transfer for further data target then it goes for next onwords delta data will come from change log table.
2)otherwise u go for INIT WITH OUT DATATRANSFER now no records will come to ur targeted datatarget just it gives delta flexibility only (by default 1 record willl come it is for delta initilization) now u go for the delta. now which are the records are avilable in change log those records will move from changelog to ur targeted datatarget.
Thanks
sathish

AS2 Receiver Error: MIC not verified # unexpected-processing-error

When sending out a test message using Seeburger AS2 receiver channel I get the following error:
MIC not verified # unexpected-processing-error
So obviously this problem is related to digital signature I think? However I get the same error even if digital signature is deactivated in the communication channel.
Do you have any idea on this?

Hi ,
I have been facing this error and tried all the refresh and reimporting of certificate.
"MIC not verified # unexpected-processing-error"
could you be bit specific how to fix this ?
thanks in advance
Praveen

2LIS_11_VAHDR - Initialize delta process error

Similar Messages

Maybe you are looking for