We have table ROOSPRMSC which stores the successful last delta request time stamp for each data source(if it is delta enabled).
When ever the delta IP got successful, the time stamp will get update in the table (it doesn't bother about whether request is there in target or not). If the over all status of IP comes to green, then time stamp will get updated to system table.
So when ever you have any failed delta request or if you want to load the previous delta request again, follow the below steps.
1) Open the failed request or request you want to run again by going into manage tab of target and click on monitor of request, then change the over all status to red.(you can do the same like, open the delta IP in RSA1 --> on top click on monitor --> in left side you will get all requests)
here system will prompt you message saying that" you have to perform repeat delta".click on "Repeat Delta"
2) Now goto target and make the request red and delete it.
Now run your delta IP, it will pick earlier and present delta records.
Note: If you are already deleted the request from target, then open the request in RSRQ and make the request to Red. This is enough to get the last delta records.
Hope it helps...
I am loading from psa in to DSO. DSO to cube further. whenever load fails at cube level for some invalid char, then we delete the request in cube and dso and do the correction in psa and then load from psa to dso. on activation of dso it goes further automatically to cube along with last successful load. How to come out of this.
ReplyDeleteHello Srinath,
ReplyDeleteThanks for visiting my blog.
Here I have some basic doubt. If you have invalid characteristics then how come you DSO activation is successful. Infact the load should fail while loading to DSO.
Coming to your issue, can you check the DSO settings whether "Update further target upon activation is checked" or not. If this is checked then it will get update further.
Regards,
Venkatesh
Hi Venkatesh,
ReplyDeleteI have a question based upon failed requests. Below is the scenario.
Day 1 -> Init load from ECC to PSA and PSA to Cube Successful
Day 2 -> Delta load from ECC to PSA and PSA to cube successful
Day 3 -> Delta load from ECC to PSA failed and PSA to cube
either successful or failed
(is it possible that failed IP can get successfully
loaded to cube in process chain?)
Day 4-> Delta load from ECC to PSA and PSA to cube successful
(is it possible that after one failed delta at
infopackage, second day delta can get successful and
loaded to target? )
If possible then plz tell me how to get the first failed delta as if second delta is successful then first delta records will be deleted from R/3 system. Please correct me if I am wrong anywhere.
Thanks,
Naveed.
Hi Venkatesh ,
DeleteExactly what naveed mentioned was encountered and while browsing thorug found your bog.
My case is loading to PSA then to CUBE ( 10 cubes ).
Req showing red in PSA
Of 10 cubes 6 cubes the request is Green and rest 4 its is red.
It is delta from R/3 using 2LIS_03_BF
Error is short dump in DW . Below are the details .
My Analysis :
BD87 - ok
SM58 - ok
SM12 - ok
Monitor has error messages :
Extraction (messages): Errors occurred
13233 Records sent ( 13233 Records received )
14308 Records sent ( 14308 Records received )
Transfer (IDocs and TRFC): Errors occurred
Data Package 1 : arrived in BW ; Processing : Processing not yet finished, entry 70 still missi
Data Package 2 : arrived in BW ; Processing : Processing not yet finished, entry 70 still missi
Update rules ( 13233 -> 78375 Records ) : Errors occurred
Message missing: Update rules finished for YYYIC_C03
Message missing: Update rules finished for YYYMM_C01
Message missing: Update rules finished for YYYYM_C01
Message Missing: Update Finished for YYMM_C_01
------------------------------------------------------------
Monitor - Status
Short dump in the Warehouse
Diagnosis
The data update was not finished. A short dump has probably been logged in BI. This provides information about the error.
System Response
"Caller 70" is missing.
DBIF_RSQL_SQL_ERROR CX_SY_OPEN_SQL_DB
The database system detected a deadlock and avoided it by rolling back
your transaction.
If possible (and necessary), repeat the last database transaction in the
hope that locking the object will not result in another deadlock.
Note which actions and input led to the error.
For further help in handling the problem, contact your SAP administrator
.
You can use the ABAP dump analysis transaction ST22 to view and manage
termination messages, in particular for long term reference.
Short Dump : error at the Insert statement below :
CALL FUNCTION 'RSDU_DB_COMMIT'. "Commit falls duprec bei insert!
c_lines = 0.
SORT g_t_u BY
KEY_YYMM_C_01P
KEY_YYMM_C_01T
KEY_YYMM_C_01U
KEY_YYMM_C_011
KEY_YYMM_C_012
KEY_YYMM_C_013
KEY_YYMM_C_014
KEY_YYMM_C_015
KEY_YYMM_C_016
KEY_YYMM_C_017
KEY_YYMM_C_018
KEY_YYMM_C_019
.
INSERT (l_facttab) FROM TABLE g_t_u.
c_lines = sy-dbcnt.
Kindly advice on how should i resolve this issue and load back with out any duplicates.
Thanks and Regards,
Sudhir
Hi Sudhir,
DeletePlease post the same issue in SCN forum and lets wait for replies. Please let me know at mohdnaveed03@gmail.com after posting your issue in SCN forum......thx