DSO activation - long runtime

Hello guys,
in our BW system, activation of a DSO request takes a long time (> 1 hr), although only a small number of records (some hundred) has been loaded. When examining the log in sm37, I found out that there are no entries for the time in question (mind the time gap between 08:21:18 and 09:25:55):
08:21:13 Job started
08:21:13 Step 001 started (program RSPROCESS, variant &0000001044887, user ID BWBATCH)
08:21:18 Activation is running: Data target CUSDSO06, from 132,353 to 132,353
09:25:55 Overlapping check with archived data areas for InfoProvider CUSDSO06
09:25:55 Check not necessary, as no data has been archived for CUSDSO06
09:25:55 Data to be activated successfully checked against archiving objects
09:25:57 Status transition 2 / 2 to 7 / 7 completed successfully
... (further lines concerning SID generation etc. omitted)
The actual activation is executed within several seconds. So I wondered what happens in the time between 08:21 and 09:25. I tried to find out more on that by tracing (transaction st05) the process. The trace shows that for each request that has ever been loaded into the DSO, some tables are read (see below). Since there are more than 4000 requests and reading for each request takes around 1 second, the runtime sums up to more than one hour.
Yet, only ONE request has to be activated (all other of these requests have been activated during the months before, so they should be quite irrelevant to the actual activation job).
226
RSBKREQUE
FETCH
1
0
7
RSSTATMAN
REOPEN
0
SELECT WHERE "RNR" = 'DTPR_4669H4NELXUK91DGMUIWCY6FY' AND "DTA_SOURCE" = '/BIC/B0000302' AND "DTA_SOURCE_TYPE" = 'TFSTRU' AND "DTA_DEST" = 'CUSDSO06' AND "DTA_DEST_TYPE" = 'ODSO'
263
RSSTATMAN
FETCH
0
1403
6
RSSTATMAN
REOPEN
0
SELECT WHERE "RNR" = 'DTPR_4669H4NELXUK91DGMUIWCY6FY' AND "DTA_SOURCE" = 'SALES_CUSTOMERS_DS            FILE_HU' AND "DTA_SOURCE_TYPE" = 'DTASRC' AND "DTA_DEST" = 'CUSDSO06' AND "DTA_DEST_TYPE" = 'ODSO'
232
RSSTATMAN
FETCH
1
1403
5
RSSTATMAN
REOPEN
0
SELECT WHERE "RNR" = 'DTPR_4669H4NELXUK91DGMUIWCY6FY' AND "DTA_SOURCE" = 'SALES_CUSTOMERS_DS            FILE_HU' AND "DTA_SOURCE_TYPE" = 'DTASRC' AND "DTA_DEST" = 'CUSDSO06' AND "DTA_DEST_TYPE" = 'ODSO'
227
RSSTATMAN
FETCH
1
1403
6
RSSELDONE
REOPEN
0
SELECT WHERE "RNR" = 'REQU_4669GG41VH6YPLG04AL85I5GE' AND ROWNUM <= 1
902
RSSELDONE
FETCH
1
0
6
/ /RREQUID
REOPEN
0
SELECT WHERE "SID" = 119751
220
/ /RREQUID
FETCH
1
0
5
RSBKREQUE
REOPEN
0
SELECT WHERE "REQUID" = 119751
230
RSBKREQUE
FETCH
1
0
6
RSBKREQUE
REOPEN
0
SELECT WHERE "REQUID" = 119751 AND ROWNUM <= 1
684
RSBKREQUE
FETCH
1
0
6
RSBKREQUE
REOPEN
0
SELECT WHERE "REQUID" = 119751
201
RSBKREQUE
FETCH
1
0
6
RSBKREQUE
REOPEN
0
SELECT WHERE "REQUID" = 119751
194
RSBKREQUE
FETCH
1
0
6
RSBKREQUE
REOPEN
0
SELECT WHERE "REQUID" = 119751
195
RSBKREQUE
FETCH
1
0
6
RSBKREQUE
REOPEN
0
SELECT WHERE "REQUID" = 119751
195
RSBKREQUE
FETCH
1
0
6
RSBKREQUE
REOPEN
0
SELECT WHERE "REQUID" = 119751
309
RSBKREQUE
FETCH
1
0
6
RSBKREQUE
REOPEN
0
SELECT WHERE "REQUID" = 119751
264
RSBKREQUE
FETCH
1
1403
7
RSBMNODES
REOPEN
0
SELECT WHERE "LOGID" = 'DTPR_119751' AND "NODE" = 0
410
RSBMNODES
FETCH
1
0
5
RSBMNODES
REOPEN
0
SELECT WHERE "LOGID" = 'DTPR_119751' AND "NODE" = 0
242
RSBMNODES
FETCH
1
0
6
RSBMLOG
REOPEN
0
SELECT WHERE "LOGID" = 'DTPR_119751'
247
RSBMLOG
FETCH
1
0
12
RSBMNODES
REOPEN
0
SELECT WHERE "LOGID" = 'DTPR_119751'
761
RSBMNODES
FETCH
30
1403
6
RSBMONMESS
REOPEN
0
SELECT WHERE "LOGID" = 'DTPR_119751' ORDER BY "NODE" , "POSIT"
645
RSBMONMESS
FETCH
17
1403
6
RSBMLOGPAR
REOPEN
0
SELECT WHERE "LOGID" = 'DTPR_119751'
431
RSBMLOGPAR
FETCH
7
1403
5
RSBKDATAP
REOPEN
0
SELECT WHERE "REQUID" = 119751
353
RSBKDATAP
FETCH
2
1403
6
RSBKDATAP
REOPEN
0
SELECT WHERE "REQUID" = 119751
246
RSBKDATAP
FETCH
0
1403
6
RSBKDATA_V
REOPEN
0
SELECT WHERE "REQUID30" = 'DTPR_4668XBCECQQT3RHYI54CCMUQM'
314.804
RSBKDATA_V
FETCH
0
1403
13
RSBMNODES
REOPEN
0
SELECT WHERE "LOGID" = 'DTPR_119751'
1.114
RSBMNODES
FETCH
30
1403
6
RSBMONMESS
REOPEN
0
SELECT WHERE "LOGID" = 'DTPR_119751' ORDER BY "NODE" , "POSIT"
639
RSBMONMESS
FETCH
17
1403
7
RSBMLOGPAR
REOPEN
0
SELECT WHERE "LOGID" = 'DTPR_119751'
374
RSBMLOGPAR
FETCH
7
1403
6
RSBKDATAP
REOPEN
0
SELECT WHERE "REQUID" = 119751
329
RSBKDATAP
FETCH
2
1403
6
RSBKDATAP
REOPEN
0
SELECT WHERE "REQUID" = 119751
242
RSBKDATAP
FETCH
0
1403
6
RSBKDATA_V
REOPEN
0
SELECT WHERE "REQUID30" = 'DTPR_4668XBCECQQT3RHYI54CCMUQM'
312.963
RSBKDATA_V
FETCH
0
1403
8
RSBKREQUE
REOPEN
0
SELECT WHERE "REQUID" = 119751
589
RSBKREQUE
FETCH
1
0
6
RSBKSELECT
REOPEN
0
SELECT WHERE "REQUID" = '                       119751'
287
RSBKSELECT
FETCH
0
1403
|        6|RSBKREQUE |REOPEN |     |     0|SELECT WHERE "REQUID" = 119751
Any ideas?
Many thanks,
Regards,
Günter

check the profile parameter settings in RZ10. You can try number range buffering for better performnce

Similar Messages

DSO activation in Process Chains - takes long time

Dear All,
We have included DSO activation in Process Chains. This process takes a long time to execute. We manually cancel the corresponding process in Process Overview and repeat it from chain. The chain runs daily and this issue also occurs on a daily basis.
Does anyone one of you have an idea of how to deal with this performance issue?
Regards.

Figure out in which class does your process fall in:
Class A- High Priority
Class B- Medium Priority
Class C- Least Priority
Background processes
Class A jobs
The number of work processes reserved for job class A is a subset of the number of background processes.
You should only reserve work processes for job class A if it makes sense within your system organization. Work processes reserved for class A jobs are no longer available for job classes B or C.
Set parallel processing for a specific BW process in the (variant) maintenance of the process
Call the function for setting the parallel processes.
You can call the function in the process variant maintenance of a process chain or in the process maintenance. The function call varies for the different BW processes.
For example, in the data transfer process you call the function with Goto--> Background Manager Settings.
The Settings for Parallel Processing dialog box appears
Under Number of Processes, define the maximum number of work processes that should be used to process the BW process.
If you enter 1, the BW process is processed serially.
If you enter a number greater than 1, the BW process is processed in parallel
In the Parallel Processing group frame, make the relevant settings for parallel processing in the background:
Enter a job class for defining the job priority.
The job priority defines how the jobs are distributed among the available background work processes
In the group frame Parallel Processing, you can define whether parallel processing should take place in dialog work processes or in background work processes for the processes ODSACTIVAT, ODSSID and ODSREQUDEL for the DataStore object
Transport:
The entries in tables RSBATCHPARALLEL and RSBATCHSERVER are written on a transport request of the Change and Transport System.
Edited by: ram.pch on Oct 7, 2011 9:55 PM

DSO Activation Time - "TIME_OUT"

Hello,
i've added a new InfoObject to an existing DSO.
Then, i saved the DSO and wanted to activate it.
Now to the problem:
The activation time is so long, that the process terminate.
So that we get the runtime error "TIME_OUT".
I ask for your help.
Regards
Marco

Hi Marco,
As you are trying to activate the DSO in front end and it is ending with time out error(This may be your DSO taking long time to activate).
activate using program RSDG_ODSO_ACTIVATE
goto SE38-->give the program name and execute -->give the DSO name -->before you click on execute, in menu bar under execute click on execute in background.
in the next screen give the local printer name and enter.
In the next screen make the job condition as immediate and remove the periodic option and enter.
Now you can see the job in SM37, monitor this job until it's get finished.
Regards,
Venkatesh

DSO activation faster

Dear Experts,
Is there any way that the DSO activation can happen fast.I need it for reporting so I cannot remove the setting SIDs upon activation and reporting flag.
Can you advise as I have DSO which is taken huge long time of 3 hrs which has 2 request but with huge data.
Thanks in advance..
Tati

Dear Tati,
Recommendations for improving the performance,
1. Recommendations regarding RSODSO_SETTINGS
(available from 7.0, for 3.X release use transation RSCUSTA2):
                                                                  Page 2
If you want the processes to run in background, you may have to increase
the amount of batchjobs available in your system (RZ04). The activation
can not run in parallel if there are no batchjobs available. This could
also occur because there are other programs using batchjobs.
- Increase the number of parallel processes for activation and for SID
generation.
- If it is necessary, decrease the packet size in the transaction
RSODSO_SETTINGS to 10.000 and increase the wait time.
DataStore configuration (RSODSO_SETTINGS) should reflect the server
configuration
- Check the number of batch processes in SM50/SM51
- Verify that your application server has enough free processes (dialog
or batch, depending on the settings).
SAP common recommendations:
Batch processes    = (All Processes/2)+1
Wait Time in Sec. =   3 * rdisp/max_wprun_time
rdisp/max_wprun_time - RZ11 (Note 25528)
Please refer to the Note 1118205 for more detailed info.
2. Recommendations regarding ODS maintainance settings:
- Do not set automatic activation when loading in parallel to an ODS as
this might lead to activation starting when requests are not yet green
in the ODS.
- The runtime of the request activation is dominated by the SID
creation, therefore using flag "SIDs Generation upon Activation" will
have significant impact on the activation time. If you deactivate this
flag, reporting is still possible since missing SIDS will be created
during the query runtime from 7.0
3. Recommendations/limitations regarding ODS operations:
- Do not activate too many large requests together
The following applies as a rule of thumb:
<Number of requests> * <Sum of all records in these requests> /
<Package size of the activation step> must be less than 100.000
This rule is implemented by note 1157070
- Ensure serial loading by using the option in the processing tab of the
scheduler for "PSA only" and check the "update subsequent data targets"
- In case of a large number of requests in an ODS refer to note 620361
"Data loading performance/Admin. data target"
This system limitation for the maximum number of requests for one
ODS/cube is also described in the Notes 543212 and 892513
- Using DTP also causes poor performance in some cases, please check the
                                                                  Page 3
Notes 1367407 and 1365901
4. Recommendations regarding db related actions:
- Update statistics for the ODS tables (DB20)
- Create secondary indexes
- To prevent performance problems with ODS activation it can be
necessary to unbuffer large tables in the master data upload according
to the following guidelines;
- Generally, it is recommended to unbuffer large SID (tables named
/BIC/S* or /BI0/S) or attribute tables (tables names /BI/P, /BI/Q*,
/BI/X and /BI/Y)
When new rows have to be added into the single record buffer, this can
lead to problems with the performance even with appropriate extent sizes
Regards,
Arvind

Process Chain - Follow on dependencies to DSO Activation

Hi, I have a Data Load Process where the start routine is dependent on DSO data that was just previously activated. For some reason it looks like the the time before the load and the time after the DSO activation are close by just seconds.
The Data Load Routine will drop records if the activated DSO data is not available and this seems like what I am witnessing. I thought there was a way to configure the chain or job to wait until the previous is completely done. or did that go away with 7.0...
Is there a way to make sure the loading process doesn't start until the previous DSO activation is completed and the data is available?
Thanks!

Hi,
Interuppt concept :
If a process chain is only processed either in part or in its entirity if more than one start condition is filled, you use this process type to specify the additional conditions.
The chain is started when the condition of the start process is filled. However, the interrupt process will interupt the processing of the chain (as long as its status is "active") up until the point at which the condition of the interrupt process is filled. Should the start process condition be filled again before the interupt process condition is filled, the chain will start again and will only run up until the point of interruption. As soon as the interrupt process condition is filled, the system continues the last run of the chain only. The earlier runs remain unchanged.
The interrupt process schedules an additional background job that starts based on the relevant condition. Therefore the interrupt process is not really active during the interrupt phase; it does not use any resources during this time.
If the interrupt processes are filled before the start process condition, the chain starts as soon as the start condition is filled; the interrupt process no longer interupts the chain because its condition has already been filled. If the interrupt process condition is is filled again before the start condition of the chain is filled, this does not influence the chain. It is not stopped by the interrupt process..
so basically your interrupt will wait for an event like ex:..YABAP_YGTRFCEVENTRAISE_0035 ... so you can raise that event eother by some job or some program..bUt for you i think adding the waiting timw will be better option ..
hope i cleared you ..
Regards,
Shikha

How to reduce Time taken by DSO Activation.

Hi
My Inventory Transaction DSO taking nearly 18min for 180,000 records to activate. It means it takes 1 min for every 10,000 records to activate. I think its too much.
Is there any way i can reduce DSO activation time... what are factors that increases the DSO activation Time.
Pls let me know if u have some idea this issue.
Thanks.....

Hi,
Some of the factors which affect DSO activation are
1) Data volume and size of DSO (if the volume and no of fields are more then it takes long time)
2) SID generation(uncheck this if the DSO is not used for reporting)
3) Secondary index (remove unwanted secondary index)
4) No of background jobs and packages siz allocated for activation (check the settings for ur DSO in tcode RSODSO_SETTINGS)
Apart from this it also depends on database performance and other factors
Regards,
Raghavendra.

Deadlock when deleting from rsstatmanpsa during DSO activation

We are experiencing intermittent Oracle deadlocks during DSO activation in our BI system. The deadlocks occur when the following SQL statement is executed:
      delete from rsstatmanpsa where
             partnr >= l_s_status-rnr_sid and
             psa     = l_s_status-dta.
This is at line 83 of the SET STATUS method of class CL_RSSM_STATMAN. (See below for runtime error details.)
When these errors occur the background job for the DSO activation is cancelled with the message ABAP/4 processor: DBIF_RSQL_SQL_ERROR. Strangely, when this occurs as part of a process chain, the status of the process variant does not get updated until/unless someone displays the process chain log, at which point the status changes and follow-on events are triggered. In other words, the process chain does not seem to be receiving word that the DSO activation process has abended, so we do not receive alerts that a problem has occurred.
Has anyone else experienced this issue?
Thanks,
Bob
P.S. We are running BI 7.0, Patch Level 15 on Oracle 10.2.0.4.0
Runtime Errors         DBIF_RSQL_SQL_ERROR
Exception              CX_SY_OPEN_SQL_DB
Error analysis
An exception occurred that is explained in detail below.
The exception, which is assigned to class 'CX_SY_OPEN_SQL_DB', was not caught
in
procedure "SET_STATUS" "(METHOD)", nor was it propagated by a RAISING clause.
How to correct the error
Database error text........: "ORA-00060: deadlock detected while waiting for
resource"
Internal call code.........: "[RSQL/DELE/RSSTATMANPSA ]"
Please check the entries in the system log (Transaction SM21).
If the error occures in a non-modified SAP program, you may be able to
find an interim solution in an SAP Note.
If you have access to SAP Notes, carry out a search with the following
keywords:
"DBIF_RSQL_SQL_ERROR" "CX_SY_OPEN_SQL_DB"
"CL_RSSM_STATMAN===============CP" or "CL_RSSM_STATMAN===============CM008"
"SET_STATUS"
If you cannot solve the problem yourself and want to send an error
notification to SAP, include the following information:
1. The description of the current problem (short dump)
To save the description, choose "System->List->Save->Local File
(Unconverted)".
2. Corresponding system log
Display the system log by calling transaction SM21.
Restrict the time interval to 10 minutes before and five minutes
after the short dump. Then choose "System->List->Save->Local File
(Unconverted)".
3. If the problem occurs in a problem of your own or a modified SAP
program: The source code of the program
In the editor, choose "Utilities->More
Utilities->Upload/Download->Download".
4. Details about the conditions under which the error occurred or which
actions and input led to the error.
The exception must either be prevented, caught within proedure
"SET_STATUS" "(METHOD)", or its possible occurrence must be declared in the
RAISING clause of the procedure.
To prevent the exception, note the following:
Information on where terminated
Termination occurred in the ABAP program "CL_RSSM_STATMAN===============CP" -
in "SET_STATUS".
The main program was "RSPROCESS ".
In the source code you have the termination point in line 83
of the (Include) program "CL_RSSM_STATMAN===============CM008".
The program "CL_RSSM_STATMAN===============CP" was started as a background job.
Job Name....... "BI_PROCESS_ODSACTIVAT"
Job Initiator.. "ALEREMOTE"
Job Number..... 05302800
The termination is caused because exception "CX_SY_OPEN_SQL_DB" occurred in
procedure "SET_STATUS" "(METHOD)", but it was neither handled locally nor
declared
in the RAISING clause of its signature.
The procedure is in program "CL_RSSM_STATMAN===============CP "; its source
code begins in line
1 of the (Include program "CL_RSSM_STATMAN===============CM008 ".
Source Code Extract
Line
SourceCde
53
if i_with_internal_check is initial.
54
l_s_status = i_s_status.
55
call function 'RSSM_GET_TIME'
56
importing
57
e_timestamps = l_s_status-ts_last_changed.
58
if l_s_status-ts_proc_started <= '10000101000000'.
59
l_s_status-ts_proc_started = l_s_status-ts_last_changed.
60
endif.
61
if l_s_status_exist is initial.
62
insert rsstatmanstatus from l_s_status.
63
if sy-subrc <> 0.
64
message x000.
65
endif.
66
else.
67
modify rsstatmanstatus from l_s_status.
68
if sy-subrc <> 0.
69
message x000.
70
endif.
71
endif.
72
delete from rsstatmanpart where
73
rnr      = l_s_status-rnr and
74
dta      = l_s_status-dta and
75
dta_type = l_s_status-dta_type.
76
select single * from rsstatmanpsa into l_s_psa where
77
rnr      = l_s_status-rnr and
78
psa      = l_s_status-dta.
79
if sy-subrc = 0.
80
delete from rsmdatastate_psa where
81
psa = l_s_status-dta and
82
type = l_s_status-dta_type.
>>>>>
delete from rsstatmanpsa where
84
partnr >= l_s_status-rnr_sid and
85
psa     = l_s_status-dta.
86
else.
87
select single * from rsmdatastate_psa into l_ds_psa where
88
psa = l_s_status-dta and
89
type = l_s_status-dta_type.
90
if sy-subrc = 0 and l_ds_psa-sid_checked > l_s_status-rnr_sid.
91
delete from rsmdatastate_psa where
92
psa = l_s_status-dta and
93
type = l_s_status-dta_type.
94
delete from rsstatmanpsa where
95
partnr >= l_s_status-rnr_sid and
96
psa     = l_s_status-dta.
97
endif.
98
endif.
99
if i_with_commit = 'X'.
100
call function 'DB_COMMIT'.
101
endif.
102
endif.

Walter,
Thanks for the suggestion. This is the same recommendation I just received from SAP.
We are currently in the midst of regression testing for a major release, so cannot implement these corrections immediately. I'll post again after we implement the corrections and let you know if they solve our problem.
Thanks again.
Bob

DSO Activation failed

HI,
Process step dso activation is failed due to Runtime error...I Checked in JOB Log it says ABAP/4 Processor : MESSAGE_TYPE_X and job is cancelled. So i went to ST@@ Tcode and released the dump. and again repeated the failed step.then it again failed due to same.Please tell me how to fix this issue.
Regards,
Swathi

Hi,
Please check the following threads, an SAP note has to be applied:
Loaded for 4 times same dump in BI system
DSO Activation Dump
Thanks,
Arminder

Getting Shor Dump while DSO Activation

Hi Experts,
I am getting Error while DSO Activation, I checked in ST22 Error is (SYSTEM_CORE_DUMPED), Please suggest me.
Category               Internal Kernel Error
Runtime Errors         SYSTEM_CORE_DUMPED
Date and Time          25.02.2014 18:38:47
Short Text
     Process terminated by signal 10.
What happened?
     Error in the SAP kernel
     The current ABAP program "CL_RSODSO_DATASTORE=====
      terminated because the ABAP
     processor detected a system error.
Thanks
Sunil

Hi,
Take basis team help. error itself saying as related to internal kernel error.
recently any changes were applied on server? if yes then those might be causing.
please refer note - 517824.
Inform to basis team and sort it out.
Thanks

Getting Short Dump while DSO Activation

Hi,
I am getting Error while DSO Activation, I checked in ST22 Error is (SYSTEM_CORE_DUMPED), Please suggest.
The kernel is latest version.
Also we had implemented a couple of SAP Notes while we searched on the SDN and service market place. But still no luck.
Category Internal Kernel Error
Runtime Errors SYSTEM_CORE_DUMPED
Date and Time 09.04.2014 16:14:13
Short Text
Process terminated by signal 10.
What happened?
Error in the SAP kernel
The current ABAP program
"CL_RSODSO_DATASTORE=====
terminated because the ABAP
processor detected a system error.
Thanks,
Sameer

Hi,
Yes this happens for a particular DSO only - 0FIAR_O03(DSO)
Also the kernel is the latest one.
I am from Basis. I have checked all the possibilities and have raised OSS message as well.
Thanks,
Sameer

Long runtimes due to P to BP integration

Hi all,
The folks from my project are wondering if any of the experts out there have faced the following issue before. We have raised an OSS note for it but have yet to receive any concrete solution from SAP. As such, we are exploring other avenues of resolving this matter.
Currently, we are facing an issue where a standard infotype BADi is causing extremely long runtimes for programs that update certain affected infotypes. The BADi name is HR_INTEGRATION_TO_BP and SAP recommends that it should be activated when E-Recruitment is implemented. A fairly detailed technical description is provided as follows.
1. Within IN_UPDATE method of the BADi, a function module, HCM_P_BP_INTEGRATION is called to create linkages between a person object and business partner object.
2. Function module RH_ALEOX_BUPA_WRITE_CP will be called within HCM_P_BP_INTEGRATION to perform the database updates.
3. Inside RH_ALEOX_BUPA_WRITE_CP, there are several subroutines of interest, such as CP_BP_UPDATE_SMTP_BPS and CP_BP_UPDATE_FAX_BPS. These subroutines are structured similarly and will call function module BUPA_CENTRAL_EXPL_SAVE_HR to create database entries.
4. In BUPA_CENTRAL_EXPL_SAVE_HR, subroutine ADDRESS_DATA_SAVE_ES_NOUPDTASK will call function module, BUP_MEMORY_PREPARE_FOR_UPD_ADR, which is where the problem begins.
5. BUP_MEMORY_PREPARE_FOR_UPD_ADR contains 2 subroutines, PREPARE_BUT020 and PREPARE_BUT021. Both contain similar code where a LOOP is performed on a global internal table (GT_BUT020_MEM_SORT/GT_BUT021_MEM_SORT) and entries are appended to another global internal table (GT_BUT020_MEM/GT_BUT021_MEM). These tables (GT_BUT020_MEM/GT_BUT021_MEM) will be used later on for updates to database tables BUT020 or BUT021_FS. However, we noticed that these 2 tables are not cleared after updating the database, which results in an ever increasing number of entries that are updated into the database, even though many of them may have already been updated.
If any of you are interested in seeing if this issue affects you, simply run a program that will update either infotype 0000, 0001, 0002, 0006 subty 1, 0009 subty 0 or 0105 subty (0001, 0005, 0010 or 0020) to replicate this scenario if E-recruitment is implemented in your system. Not many infotype updates are required to see the issue, just 2 are enough to tell if the tables in point 5 are being cleared. (We have observed that this issue occurs during the creation of a new personnel number (and hence a new business partner). For existing personnel numbers, the same code is executed but the internal tables in point 5 are not populated.)
System details: SAP ECC 6.0 (Support package: SAPKA70021) with E-Recruitment (Support package: SAPK-60017INERECRUIT) implemented.
Thanks for reading.

Hi Annabelle,
We have a similar setup, but are on SAPK-60406INERECRUIT. Although the issue does not always occur, we do have a case where the error ADDRESS_DATA_SAVE_ES is thrown.
Did you ever resolve your issue? Hoping that solution can help guide me.
Thanks
Shane

DSO activation issue

hi gurus,
we have started facing problem in bw system suddenly for dso activation.
earlier it was running fine for 2 million records it used to take ard 3600 sec to complete but now its running for 10-11000 sec and getting failed.even for dso whwre its 20000 records its failing wit message "bi_bctl failed due to missing confirmation"
and it is happening very frequently.we have maintained settings as 3600 sec -max wait time in RSODSO_SETTINGS.
But nthng is wrkng and now problems seems to be more complex as even dtp loads are running for long time to load data to cube
can anyone guide us as when we check in SM50 BGD process are also free so not able to find root cause as several dumps are also cmng in ST22.what can we ask basis team to check ?any parametrs.setitng.etc
Any quick help appreciated
thanks
nilesh

Hi
Check how many parallel processes(child jobs) you have for this DSO activation step. this will happen due to non availability of background processes.
Check you have enough background processes and try to decrease the number of child jobs.
if you are running DSO activation PC, make sure you have not selected option "automatic activate the data upon loading" in DSO.
check below blog
DSO activation job log and settings explained
Regards,
Venkatesh

Dso activation number

from where I can see the dso activation request number . DSO taking long time for activation .I want to know how many data packet activated and how many are stilll waiting for activate .
Thanks

Ram,
When the request is getting activated - you will not have a request number - the request number ( even though it exists in principle ) will not be recorded until the request is fully activated.
It is kind of hard to find out where your activation process is at because :
1. The DTP packages the data into request sizes that are based on the DTP settings and the memory settings
2. The DSO packages the same differently when trying to activate the data.
You can get a fair idea of where your activation is at by
Comparing the number of data packets in the DTP and then go to SM37 and look at the activation job log to see how many packets got activated - this will give you an idea but not an exact measure of how much data has got activated.

Dso activation is not happening

HI guru's,
I am loading the data to dso and manually activating the request ,it is taking long time and finally not activating
dso activation is always failing , Iam not able to figure out the problem , please help me out.
After some time the job is failed and showing the message
"Activation sid for datastore object changed from 0 to 68"

Hi,
There are a couple of places where you can see the activation progress.
1) To start with SM37 job log > (give BI_PROCESS_ODSACTIVAT or BI_ODSA*)
and it should give you the details about the activation job. If its active make sure that the job log is getting updated at frequent intervals. If its completed check the log for ODS activation.
2) For very huge number of records SM37 job log may not get update frequently. In that case you have a workaround.
Go to contents > Active Data table > No. of entries > This will keep on increasing at frequent intervals.
3) SM66 > Get the job details (server name PID etc from SM37) and see in SM66 if the job is running or not. See if its accessing/updating some tables or is not doing anything at all.
4) Go to Activate button in Target > Request tab. Inside you can see a job log button. It will also show some log regarding the last activation.
5) If the Reporting icon has appeared near the request id in ODS. If it appears that may indicate that request is available for reporting
6) Check the request status in these tables.
Table RSICCONT table contains the requests that are actually loaded in a target.
Table RSMONICDP contains the request id of the fact table.
Table RSODSACTREQ contains information if an ODS is available for reporting/deleting inactive requests also possible.
Table RSODSACTUPDTYPE.
Check and let us know.
Hope this helps.
Thanks,
JituK

DSO activation problem after creating the secondary indexes

Hi,
I am facing the problem with DSO activation after creating the secondary indexes.
Compared with Info Cubes there is no functionality available which allows dropping and recreating a secondary index before/after the data activation.
As a workaround I can write a simple report which drops and creates the indexes on database level.
By using a process chain, we can simply insert the drop index report before data activation and the create index report after the data activation process.
Can any body help me step by step procedure or Material to write the programs for delete index and create index reports on DSO object?..
Thanks in advance for your help.
Thanks & Regards,
Bala

hi,
in BI if you are using the dso for reporting then you can simply chk the settings of dso for SID generation.
no need to create the indexes or delete it.
if the dso is not used for report then no need to use indexes.
Ramesh

DSO activation - long runtime

Similar Messages

Maybe you are looking for